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==--