Re: Usare XTEA per l'autenticazione
Giuseppe Bordoni <geppo_nospam2004-7NN/[email protected]> Sun, 02 Nov 2008 02:56:22 +0100
| Newsgroups | gmane.comp.security.italian.crypto |
|---|---|
| Message-ID | <[email protected]> |
--===============1945377554== Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Ciao Alessandro. Alessandro Barenghi wrote: >> Viste le scarse risorse del dispositivo embedded pensavo di utilizzare >> XTEA (http://en.wikipedia.org/wiki/XTEA) in questo modo: >> 1. Il dispositivo invia al PC due numeri a 32 bit pseudo-casuali. >> 2. Il PC cifra questi due numeri usando come chiave 4 numeri a 32 bit >> che conosce sia lui che il dispositivo (pre-shared key). >> 3. Il PC invia i due numeri cifrati al dispositivo. >> 4. Il dispositivo decifra i numeri ricevuti usando la stessa chiave. >> Se ottiene i numeri originali allora pu=F2 iniziare l'invio dei dati= . > Ok , un metodo challenge-response classico. Direi che va benissimo. Altrove mi hanno consigliato il testo "Handbook of Applied Cryptography" (http://www.cacr.math.uwaterloo.ca/hac/). Nel capitolo 10, pagina 402 viene illustrato un meccanismo per la mutua autenticazione delle due parti che mi pare decisamente migliore di quanto m'ero inventato io. > No il challenge response =E8 un protocolli di autenticazione corretto a > patto che il cifrario che stai usando sia solido. > Il problema =E8 che XTEA =E8 , anche se non gravemente , rotto. Convien= e > usare XXTEA o Salsa20 in una delle sue varianti , se non =E8 troppo pes= ante Se non ho capito male =E8 la versione "Block TEA", presentata nello stess= o documento di XTEA, ad essere stato rotta; da quanto leggo sulla pagina di Wikipedia il migliore attacco *conosciuto* per XTEA richiede l'uso di 2^20 determinati testi in chiaro. Considerando che con il meccanismo illustrato nel libro di cui sopra, il testo in chiaro non viene mai passato da una parta all'altra, dovrei essere *abbastanza* sicuro, sbaglio? Scusa l'insistenza ma vorrei tenermi XTEA perch=E9, come ho gi=E0 ripetut= o, =E8 l'algoritmo pi=F9 semplice in assoluto: ho dato un'occhiata a Salsa20 ma mi sembra gi=E0 pi=F9 impegnativo... >> 2. Per implementare un meccanismo di autenticazione del genere credo s= ia >> pi=F9 corretto usare un algoritmo di hashing come SHA256 o simili >> purtroppo per=F2 risultano troppo pesanti per il piccolo processore = a >> 16 bit usato dal dispositivo. Conoscete qualche algoritmo di >> hashing "abbastanza" resistente alle collisioni ma al tempo stesso >> molto semplice da implementare? > In realt=E0 =E8 pi=F9 sicuro usare un meccanismo a challenge-response = che , > a patto di scegliere bene il cifrario , =E8 un sistema sicuramente soli= do , > mentre usare una Hash =E8 un po' come usare una pinza per martellare > chiodi qui... a meno di non pensare un protocollo di autenticazione > solido :) Di questo non sono sicuro ed una riprova l'ho avuta sempre a pagina 402 dell'HAC dove viene spiegato come usare un algoritmo di hashing per l'autenticazione mutua delle due parti. A presto (mailing-list permettendo :), Giuseppe --=20 _ Giuseppe Bordoni .oOo. http://www.geppozone.com ( _) (o)> ------------------------------------------------------- \\\'',) //\ Al mondo esistono 10 tipi di persone: quelle che \/ \ ^ V_/_ conoscono la notazione binaria e quelle che la ignorano _\'_/_) --===============1945377554== Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline ________________________________________________________ http://www.sikurezza.org - Italian Security Mailing List --===============1945377554==--