Re: [ml] Xorro Chat

2006/1/23, nicola mondinelli <nicola.mondinelli@xxxxxxxxx>:

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

è vero che l'entropia rimane legata alla lunghezza di zumpappero ma è
anche vero che MD5 è un algoritmo irreversibile. In ogni caso in un
futuro molto prossimo ( a seguito delle giuste riflessioni espresse in
questa ML)  l'utente avrà la possibilità di inserire un keyfile così
il discorso sulla casualità dei dati sarà rimessa all'utente e si
potrà parlare di vero vernam.


> 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).

è necessaria per mandare le richieste tramite http ! abbiamo anche
dovuto eliminare il carattere + e sostitituirlo con il "!" per evitare
che il + venisse mal interpretato :-/

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



giusta osservazione. c'è da dire che i caratteri iniziali della
stringa criptata sono in numero fissi e non dipendenti dalla stringa
che si invia (quindi sono sempre una 15ina sia se si invia "A" sia se
si inviano 300 caratteri).
Questi caratteri non hanno lo scopo di aggiungere entropia o di
confondere ma solo di assicurare al destinatario di aver correttamente
xorrato il messaggio.
una volta effettuato lo XOR viene confrontato l'md5 del testo
decifrato con i caratteri iniziali della stringa per vedere se tutto
combacia. se combacia viene cancellato l'hash usato per decifrare.

> (zLib), cosi da
> aumentarne l'entropia e da evitare gli attacchi più semplici a
> dizionario)

gli attacchi a dizionario non sono possibili su una stringa XORRATA



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

Per la modalità secondo cui viene espanso l'hash, se si verifica una
collisione va tutto a vantaggio della pseudocasualità dell'hash
generata.




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


SSL si può tranquillamente bloccare con SQUID:

acl ssl method CONNECT
http_access deny ssl


e secondo me L'ing. Zanero sa anche come bloccarlo con una regoletta
di Snort :-)


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

in fase di registrazione di un nuovo utente questo è effettivamente un problema.
ci sono però alcuni esempi ottimali di utilizzo che eliminano questo problema.
In fase di login questo MITM non ha possibilità di fare nulla (sfido
chiunque a dimostrare il contrario anche in privato). L'OK indica
soltanto l'avvenuta ricezione del testo e non è un indice
dell'avvenuta autenticazione.



>
> buon lavoro cmq e in bocca al lupo, è sempre difficile cercare di
> mettere giù un protocollo di sicurezza...


grazie per i suggerimenti e gli spunti






altre risposte:

>Il vero rischio del concordare la pass tra utenti (IMHO) è che questa
>venga scambiata via IM in chiaro o via mail, quindi la cosa non mi
>pare molto pro-sicurezza.
>L'utente quadratico medio (se) arriva a pensare che una pass tipo
>6ma1yghaJUHFa78 è sicura non arriva a pensare che mandarla via mail
>NON è sicuro.
>Avete tenuto conto di questo aspetto, diciamo, psicologico della questione?


dato che Xorro si rivolge ad una fascia di utenti "smanettoni" e/o ad
un admin che sia capace di impostare correttamente tutti i client
questo è un aspetto che non è stato preso in considerazione. Anche
perchè l'utente quadratico medio non si interessa proprio di
crittografia.





>state
>scrivendo un sistema di comunicazione sicuro ma chiedete agli utenti
>di fidarsi ciecamente di voi. rilasciare il programma open source
>permette di dimostrare cosa stanno facendo il client e il server
>durante l'esecuzione.


Al momento i sorgenti non sono stati rilasciati per concentrarsi sugli
aspetti che interessano la sicurezza del protocollo. Non è escluso a
priori di rilasciare un client opensource anche per le discrete
richieste avute in tal senso.




--
< :-O >
I believe that every right implies a responsibility; every
opportunity, an obligation; every possession, a duty.
< /:-O >