Re: [ml] Xorro Chat

perdonatemi se mi intrometto, soprattutto perdonatemi perchà non mi
ritengo esperto di questi argomenti, anche se da un po di tempo mi
interesso di sicurezza informatica e di crittografia.
Esprimo solo un paio di considerazioni, che non volgiono essere critiche
personali, solo considerazioni, ma credo utili:

1) Sezione Azzurra, 2a pagina:
Alla stringa viene aggiunta entropia tramite un salt di 2 caratteri.
Viene aggiunto l'md5 (i primi 10 char) alla stringa ottenuta prima, ma
questo non aggiunge entropia alla stringa, ne aumenta solo la
dimensione, perchà MD5 à un processo deterministico , non invertibile
(forse... non à ancora matematicamente dimestrato), ma sempre
deterministico.

Viene fatto uno XOR con la stringa pseudocasuale del file hash.
Il file di Hash à pseudo casuale e non à considerabile un OneTimePad
perchà la lunghezza della chiave (zumpappero) à pià corta del messaggio
da trasmettere, non importa se si aggiungono operazioni deterministiche
che ne allungano la dimensione, l'entropia in entrata à sempre legata
alla stringa originale "zumpappero", o almeno questo sostieneva Shannon.

Viene tutto convertito in base64 (la codifica base64 comporta un forte
spreco di banda perchà utilizza solo i primi 6  bit di 8 bit disponibili
per char, viene usato nella mail per problemi di compatibilità di
encoding, ma nn credo sia una scelta ottimale in questo ambito).

capisco che era un'esempio quello sul pdf, ma da una stringa di 4
caratteri siamo arrivati ad un messaggio cifrato di 26 (credo..)
caratteri... un po di overhead, no?
inoltre dato che l'informazione non risiede nei primi 14 caratteri (che
in base64 diventano 18,6) questi sono scartabili a priori da qualunque
sniffer, e il resto à attaccabilissimo da attacchi di tipo ChosenText,
dato che il testo non à stato modificato in nessun modo (consiglerei di
effettuare una compressione del testo in chiaro, (zLib), cosi da
aumentarne l'entropia e da evitare gli attacchi pià semplici a
dizionario)

ma perchà non si usa RC4 se proprio si vuole un buono stream chiper?
cmq al posto di md5 (che comunque à stato dimostrato che à vulnerabile a
collisioni di tipo birthday attack e addirittura peggio.) Ã preferibile
SHA1 molto pià sicuro, anche se il meglio sarebbe un MAC, per esempio
HMAC-MD5, dove à dimostrato matematicamente l'impossibilità di attacchi
migliori di quelli a forza bruta e simili.

infine, se non si vuole utilizzare crittografia asimmetrica, senza
neanche DiffieHelmann sarà difficile proteggere la segretezza dei dati
da attacchi anche di tipo offline.
Affidarsi a SSl o TLS non trovo sia una scelta rischiosa, dato che sono
protocolli da lungo crittanalizzati e da lungo usati, si basano su
algoritmi crittografici solidissimi, bisogna solo stare attenti a come
si implementano e a come si configurano.

Inoltre problema ben pià grave à la mancanza della mutua autenticazione,
meglio non ripetere gli errori del passato: una delle falle principali
della rete GSM che ha permesso di clonare migliaia di SIM Ã stato
questo. Non veniva autenticato il server!
Esempio pratico: dal FW dell'azienda io posso ridirigere il traffico
XORRO (Ã possibile, anche se viaggia sulla porta 80 (e questa cosa mi
puzza, non si dovrebbero utilizzare porte di altri servizi per altre
cose!) a un programmino che accetta la tua connessione Xorro e ti
risponde positivamente con L'OK finale (a priori, ovviamente non ha
database da controllare) e tu ti ritovi collegato con un server che non
à il server ufficiale che perà ha dati necessari per iniziare a sua
volta una connessione XORRO con il vero server... un MITM, insomma, vero
e proprio.

buon lavoro cmq e in bocca al lupo, Ã sempre difficile cercare di
mettere già un protocollo di sicurezza... 

Ciao
Nicola

p.s. Mi scuso se ho detto qualche castroneria