Re: [ml] segnalazione nuovo client di chat criptata

Segnalazione a margine: per favore, non inviate mail in formato HTML
alle mailing list. Grazie.

> (se solo avessi letto qualcosina eh ?)

Purtroppo per te, ho letto tutto. Credo piuttosto che a te manchi una
buona lettura come ad esempio lo Schneier, "Applied Cryptography". O lo
Stallings. O l'Anderson. O comunque, una qualsiasi nozione base di
crittografia.

Nel dettaglio:

>> MD5 non e' un buon algoritmo per generare uno stream pseudocasuale da 
>>una chiave statica.
> 
> si a livello teorico... 

Esatto, e siccome a livello teorico e' gia' sbagliato, e ci sono modi
migliori per fare la stessa cosa, perche' non usare i modi migliori ?

Quello che tu chiami "aumento arbitrario della lunghezza della chiave"
(che e' una bestialita' dal punto di vista entropico) si chiama "stream
cipher" in crittografia.

> intanto sono "secoli" che provano a fare collision

Questo non c'entra nulla.

>> Una chiave pseudocasuale generata da un segreto lungo meno dei messaggi 
>>da trasmettere NON E' UN CIFRARIO DI VERNAM.
> 
> INFATTI LA CHIAVE E' SEMPRE PIU' LUNGA DEI MESSAGGI (se solo avessi letto
> qualcosina eh ?)

No, e' falso. La chiave e' quella che usi per INIZIALIZZARE quel
sistema, non tutto il brodo che generi con MD5. Se solo avessi letto
qualcosina di crittografia... non dico l'articolo del '48 (credo, vado a
memoria) di Shannon, ma un qualsiasi abbecedario che spieghi cos'e' un
"one-time pad".

I.E. nel tuo esempio la chiave e' ZUMPAPPERO, e il massimo messaggio che
puoi cifrare, con la sicurezza garantita da Vernam, e' lungo quanto
ZUMPAPPERO.

Se e' piu' lungo di cosi', matematicamente, quello NON E' un one-time
pad. E non e' matematicamente garantito un bel nulla su di esso.

> si ma noi l'abbiamo implementato correttamente... non capisco di cosa ti
> preoccupi :-P

Apri Bugtraq.
Cerca "http server" nelle vulnerabilita'.
Capirai immediatamente di cosa mi preoccupo.

> oltretutto il client c'?.. il server pure... testalo se vuoi no ?

Senza sorgenti, quindi l'analisi della sicurezza del suddetto e' tutta
da ridere...

> l'hash della password viene trasmesso in chiaro (STR1) solo in fase di
> registrazione dell'utente... 

E dici poco :)

> per arrivare  a chiave pubblica e privata ci
> vuole un po' di tempo e stiamo valutando come procedere... 

Guarda, e' molto semplice: c'e' un algoritmo che si chiama
Diffie-Helman, fa questa cosa, la fa bene in modo dimostrabile.

Quello scambio di chiavi che fate voi e' buggato.

> ad ogni modo la
> STR1 conta solo per l'autenticazione dell'utente e non inficia minimamente
> la segretezzadel messaggio

Allora il documento sul tuo sito e' sbagliato :)

> questo vale SOLO in fase di registrazione. (quando sar? implementato uno
> scambio di chiave pubblica/privata di cui sopra questo "problema" non ci
> sar?)

E quando sara' implementata il programma sara' diverso e forse non sara'
una ciofeca :)

> attualmente lo scopo del programma ? quello di loggarsi con un ip dove non
> ci sono amministratori di rete che sniffano e poi usarlo al lavoro.

Ecco, secondo me "lo scopo" lo dovreste ridefinire, perche' questa frase
non significa nulla, con tutta la buona volonta' che ci metto per
leggerla...

> Inoltre per cautelare la segretezza della STR1 ? possibile anche aggiungere
> caratteri da vari IP

Ma a cosa serve se li passi in chiaro ? :)

> un eventuale sniffer per poter leggere la tua STR1 deve loggare il tuo
> traffico da entrambi i punti dove ti colleghi

Ah beh, questa si' che e' security :)

Per tua informazione, un protocollo robusto PARTE DAL PRESUPPOSTO che
l'aggressore possa loggare TUTTO IL TRAFFICO che passa tra te e l'altra
parte.

Si chiama "modello di attacco di Dolev-Yao", se lo fai formalizzando. Ma
questo, di nuovo, richiederebbe leggere qualcosa...

> inoltre questo processo di sniffare la STR1 non invalida la segretezza del
> messaggio ma (ripeto) "solo" l'autenticazione del mittente

Quindi il protocollo e' incompleto, capisco... Allora perche' lo rilasci
? :D

> se uno sniffer non ha la STR1 e l'hash md5 della password per intero non si
> pu? sostituire all'utente pur sniffando TUTTI i pacchetti AMEN

Il problema e' che chiunque si puo' sostituire al SERVER, e in questo
modo truffare l'utente. AMEN.

(Autenticazione mutua, cerca su google...)

> la password va concordata tra gli utenti preventivamente

Aaaaaah beh, ottimo :)

> usare SSL non ci convinceva per niente

Certo, giustamente usare un algoritmo che funziona bene da 15 anni non
e' convincente, inventarsi una serie indimostrata di cose messe assieme
con lo sputo e le preghiere del coder invece ha senso !

> lo standard e' li

Eh come no, ne manca ancora meta' :D

> posto che i nomi delle variabili possono essere RANDOM, e posto che gli ip
> dei server non sono noti ( e possono essere vari e dietro proxy, anche proxy
> php hostati dietro pagine su siti di hosting free ) non credo sia possibile
> bloccare il protocollo. 

Guarda, secondo me basta questa regola di Snort inline:

drop tcp any 80 -> $HOME_NET any (content:"\|OK\|"; msg:"Xorro";)

(puo' essere che non ti prenda l'escaping di |, in tal caso traduci
quello in esadecimale e funzionera')

Ma se non bastasse ti garantisco che per bloccare un protocollino del
genere ci vuole poca fatica invero.

>  voglio ripetere che l'utilizzo per il quale ? stato creato ? stato quello
> di registrarsi in un punto "sicuro" o non sniffanibile
> e poi usare il client altrove.

Per qualsiasi cosa questo oggetto sia stato creato, non fa quello che
deve fare. E in ogni caso, anche se venisse riscritto da capo e
funzionasse correttamente, non farebbe nulla in piu' di quanto non
faccia IRC + SSL o SILC o Qualsiasicosa + Gaim-encryption.

-- 
Cordiali saluti,
Ing. Stefano Zanero
---------------------------
Secure Network S.r.l.
www.securenetwork.it