[ Home | Liste | F.A.Q. | Risorse | Cerca... ]


[ Data: precedente | successivo | indice ] [ Argomento: precedente | successivo | indice ]


Archivio: Gennaio 2006 ml@sikurezza.org
Soggetto: Re: [ml] Xorro Chat
Mittente: Alessandro Barenghi
Data: Tue, 24 Jan 2006 02:39:56 +0100 (CET)
On Sunday 22 January 2006 18:15, Formichiere wrote:
> Concordo te Stefano. In verità dicevo che non è un vero Vernam ma
> qualcosa di simile perchè le stringhe per lo Xor non sono affatto
> casuali, ma generate da una password a cui vengono fatti diversi MD5
> (che è un One-Way Hash) e che non uscira mai dal pc dell'utilizzatore
> tranne che per sua negligenza, e la stessa passord per generare le
> stringhe dello Xor si automodifica in maniera IMPOSSIBILE da prevedere
> (dal momento che è impossibile prevedere la somma delle lunghezze dei
> messaggi che l'utilizzatore scriverà al suo interlocutore e come
> spiagato nel .pdf la nuova password per i prossimi MD5 sarà la rimanenza
> delle stringhe non Xorrate). 
a dire il vero basta prendere la lunghezza del messaggio in cifra e sottrarre 
12 (10 char dell hash + 2 del noise inserito) per ottenere esattamente quanti 
caratteri sono stati inviati in un messaggio cifrato

> Però è anche  vera un'altra cosa... c'è 
> nessuno che sa tornare indietro da una stringa MD5 alla password da cui
> la stringa è stata generata? 
Hmm.... a parte la risposta banale (http://www.openwall.com/john/) direi che 
con poco sforzo si può adattare il sistema a rainbow tables per MD5 unsalted 
(per la versione salted usata nello shadow ci hanno già pensato...) e a 
questo punto basta solo un po' di spazio su disco e una macchina che adesso 
oscilla sui 350 euro per fare del cracking efficiente

> Aggiungo brevemente u'altra cosa, 
> l'utilizzo che il client fa dell'md5 è molto modulare e qualora Md5 si
> rivelasse inefficace verrebbe sostituituito seduta stante da un OneWay
> Hash più sicuro.
Ottima idea. MD5 è inefficace. Oltre al fatto che la sua complessità inizia a 
essere sufficientemente bassa da consentire attacchi con compromesso 
space-computing time c'è anche quello spiacevole fattaccio sulle collisioni 
arbitrarie (http://it.slashdot.org/article.pl?sid=05/11/15/2037232&from=rss) 
peraltro già postato in questa ML. Un mio personale suggerimento sarebbe 
anche evitare SHA1 dato che ha dato qualche piccolo segno di scricchiolio e 
in generale inizia a diffondersi l' opinione che l' intera struttura di 
Merkle-Damgaard non sia un buon modo di fare hashing.Una buona idea potrebbe 
essere usare un buon block cipher (AES, Serpent , TwoFish) per generare le 
firme , in letteratura ci sono una valanga di metodi sani per farlo.....
Oppure volendo , si potrebbe adottare un approccio più brutale , riscrivere il 
sistema di cifratura dei messaggi e usare per tutto un sistema più solido , 
ad esempio la versione su curve ellittiche di Diffie-Hellman per il key 
exchange iniziale quando un' utente si logga e poi usare un block cipher 
chiave di sessione con rekeying automatico ogni n messaggi (possibilmente con 
n variabile) per trasmettere il testo.

-- 
**********************************************

Old programmers never die
they just Terminate and Stay Resident

**********************************************




[ Home | Liste | F.A.Q. | Risorse | Cerca... ]

www.sikurezza.org - Italian Security Mailing List
(c) 1999-2005