[ml] Xorro Chat

-------------------------------------------------------------------------
>  (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.
-------------------------------------------------------------------------
Ciao Stefano,
come sempre in questi casi si rischia di "non costruire nulla", ma di 
far scadere la conversazione nell'attacco personale all'interlocutore. 
Io sono Gabriele Nardella, programmatore e utilizzatore di molti tra i 
più diffusi linguaggi (VB, C++, Assembly, Java, Prolog, etc etc.) e 
co-creatore di Xorro. Consiglio al mio collega MultiTaskinG di non fare 
critiche "ad personam" per mantenere alto il livello del servizio 
offerto dalla mailinglist e a te Stefano (così come a qualunque altro 
lettore) di non raccogliere provocazioni ;-)




-------------------------------------------------------------------------
> > Una chiave pseudocasuale generata da un segreto lungo meno dei
> > messaggi da trasmettere NON E' UN CIFRARIO DI VERNAM.
-------------------------------------------------------------------------
Ho letto con vivo interesse il vostro scambio e quello su cui sono 
perfettamente d'accordo è che la nostra non è l'implementazione di un 
vero Vernam, ma un algoritmo che si basa su alcuni schemi di 
funzionamento di Vernam, (e l'ho detto anche in privato a MultiTaskinG) 
dovrei spiegare il perchè di questa scelta (di non usare il vero Vernam 
ma qualcosa che ci andasse vicino)  parlando dell'entropia che si riesce 
ad accumulare su un calcolatore e soprattutto parlando in formule come 
si è abituati a fare nell'ingegneria, ma sarebbe lungo e inutile, 
piuttosto ho capito dalle tue critiche una cosa ben più importante: in 
effetti l'utente che per la prima volta si trova davanti il sito ed il 
programma non può comprendere a pieno i presupposti con cui è nato il 
tutto. Oltre tutto i newsgroup ed i forum in genere sono pieni di 
accesissimi dibattiti sull'accumulo di entropia, non serve al nostro (di 
noi autori di Xorro) scopo parlarne qui. Credo per questo che introdurrò 
a breve sul sito una sezione in cui "prima di scaricare il programma" 
l'utente è obbligato a leggere cosa gli autori (noi) intendevano 
realizzare prima di mettersi a codare:

1) I presupposti (ad esempio: come hai detto tu non c'è modo di 
difendersi da un attacco man in the middle, però è anche vero che tutte 
le registrazioni vanno effettuate online per cui i dati in qualche modo 
possono sempre essere sniffati e non conta se usi qualche tipo di 
algoritmo per criptarli come SSL perchè anche se funziona bene da anni 
come hai ricordato tu, nessuno assicura all'utente che non verranno mai 
letti, 15 anni di buon funzionamento non significano niente se domani 
appare su bugtraq un exploit che compromette l'SSL, qualsiasi 
script-kiddy sarà in grado di decodificare. Perciò quello che intendeva 
MultiTaskinG parlando della STR1 che viene inviata al server una sola 
volta e che è possibile aggiornare in qualsiasi momento, era solo VOLER 
RICORDARE una buona norma che tutti dovrebbero conoscere, cioè che ogni 
utente dovrebbe aver cura di effettuare le registrazioni a siti, servizi 
etc... in più fasi e da connessioni diverse quando possibile. A dire il 
vero inizialmente si era pensato di far effettuare la registrazione in 
più step obbligando l'utente ad effettuare connessioni diverse con il 
riconoscimento dell'ip e l'invio tramite mail di una conferma di 
registrazione, ma poi si è deciso di rimettere questa cosa alla 
diligenza dell'utente, dando la possibilità di modificare la STR1 in 
qualsiasi momento, come hai detto tu si parte dal presupposto che "lo 
spione" sia in grado di intercettare QUALSIASI tua connessione, però tu 
sai bene che ogni "realtà" viene descritta da un modello e in questo 
caso ci si mette nelle condizioni peggiori appositamente per prevedere 
ogni eventualità, inoltre i modelli non sono infallibili, essere 
scrupolosi è giusto, premettimi di chiamarti collega, però bisogna avere 
anche buon senso nel fare le cose. Io davvero vorrei trovare qualcuno 
che è in grado di spiarti in qualsiasi momento e da qualsiasi 
connessione. Qui taglio in po' corto comunque perchè ripeto anche io 
come MultiTaskinG che l'intenzione è di passare a chiave pubblica e 
chiave privata nel più breve tempo possibile). ;-)

2) La spiegazione di cosa gli autori danno per assodato che non competa 
a Xorro, cioè tutto ciò che non sarà espressamente specificato tra le 
competenze del programma (come ad esempio la protezione dei dati di 
registrazione che risiedono sul proprio Hard Disk, non saremo 
responsabili noi se il signor TIZIO lascerà il proprio Hard Disk alla 
mercè di tutti, ovvio).

3) La spiegazione (spero) il più possibile chiara di cosa il programma 
si prefigge di fare (tenendo presente che è un progetto ancora molto 
giovane e che indubbiamente può essere migliorato, anche con l'aiuto di 
persone come te che gentilmente ci dedicano la loro attenzione e il loro 
tempo, a tutto vantaggio di qualcosa che potrebbe un domani servire 
anche a loro dal momento che le specifiche pensiamo di continuare a 
rilasciarle anche in futuro ad uso e consumo di tutti).

4) Xorro è un progetto nato da tanta passione per le sfide di 
programmazione di cose non banali (parallelamente in php, c++, vb sia su 
linux che su windows) e soprattutto portato avanti nel tempo libero, ma 
cercando di fare le cose in modo serio, per cui il protocollo è libero, 
e tutti possono valutare se il modo in cui opera sia per essi 
soddisfacente o meno inoltre chiunque può crearsi grazie a ciò il 
proprio client se gli va e se non si fida, anzi noi come c'è scritto al 
sito invogliamo anche questa strada e siamo a disposizione per 
chiarimenti (non mi sembra poi tanto inaccettablie)

-------------------------------------------------------------------------
> > 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.
-------------------------------------------------------------------------
Esatto si ritorna sull'entropia, provo invece a spiegare più in 
dettaglio i motivi della scelta: MD5 è un One-Way Hash e come tale 
"abbastanza irreversibile" (dico abbastanza perchè in campo informatico 
1 giorno è una vita e non si sa mai cosa succede domani). Altra premessa 
da fare è che tutti i sistemi "comprovati" che io conosco per accumulare 
entropia non sono poi così veloci. Il programma similmente a un cifrario 
di Vernam prende una stringa e la Xorra con il testo che l'utente invia 
al suo interlocutore, poi quella stringa non verrà mai + riutilizzata 
perciò le stringhe a disposizione per effettuare i successivi Xor  ad un 
certo punto finiranno e sarà necessario generarne di nuove. Come puoi 
ben vedere cambia totalmente la maniera in cui viene utilizzato rispetto 
ai tradizionali sistemi. Se tu fossi un malintenzionato quale tipo di 
attacco proveresti a portare? Sniffare tutto il testo criptato che passa 
sulla rete OK quella è la base con cui ricostruire l'intero scambio, 
poi? Tieni presente che le stringhe successieve utilizzate per lo xor 
dei messaggi vengono generate sempre dall'MD5 di ciò che rimane dalle 
stringhe precedenti ed ogni messaggio viene xorrato con una stringa di 
pari lunghezza.




-------------------------------------------------------------------------
>  INFATTI LA CHIAVE E' SEMPRE PIU' LUNGA DEI MESSAGGI

> > 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.
-------------------------------------------------------------------------
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). Però è anche  vera un'altra cosa... c'è 
nessuno che sa tornare indietro da una stringa MD5 alla password da cui 
la stringa è stata generata? 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.




-------------------------------------------------------------------------
>  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.
-------------------------------------------------------------------------
Per l'ennesima volta devo darti ragione, però in ingegneria siamo 
abituati a circoscrivere i problemi, non si può fare un calderone 
pazzesco. Il problema della sicurezza HTTP non rientra tra le competenze 
di un client, no? Poi se la mettiamo su questo piano, è 
l'ammininistratore che deve preoccuparsi della sicurezza del webserver 
(bug di Apache IIS o qualsioglia server) anche perchè se ti preoccupi di 
quel "man in the middle" non dovresti neanche navigare, tutti si possono 
sostituire a tutti  e fare attacchi a previsione del numero di sequenza 
dei pacchetti per poi fingersi qualcun'altro.



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

> > Senza sorgenti, quindi l'analisi della sicurezza del suddetto e'
> > tutta da ridere...
-------------------------------------------------------------------------
E' tutto vero quello che dici, ma il protocollo è sempre open, e un 
esperto sa perfettamente che per quanto è semplice e lineare (mi pare 
anche abbastanza schematica la spiegazione) potrebbe pure reinventarsi 
da zero i files PHP che gestiscono il lato server, magari anche meglio 
di come abbiamo fatto noi. Cosa si può desiderare di più? La  luna? Io 
credo che per quanto tu possa amare l'open source non lavori se non ti 
pagano. Quindi cerca di capire anche noi... se il protocollo dovesse 
iniziare a prendere piede perchè non riservarci la possibilità di esser 
ripagati del lavoro fin qui svolto gratis? In ogni caso, se vogliamo 
essere "ingegneri" (e quindi pignoli e rompiscatole, mi ci includo anche 
io nell'etichetta di rompiscatole) l'analisi della sicurezza va fatta 
sul protocollo non sul programma dal momento che tutti possono crearsene 
uno a piacimento in base alle specifiche. Quindi a cosa servono i sorgenti?





-------------------------------------------------------------------------
>  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.
-------------------------------------------------------------------------
Per motivi che ti esporrò nell'ultimo punto credo che la chiave pubblica 
e privata non saranno un punto d'arrivo, ma solo un'aggiuta all'attuale 
funzionamento. Cosa esattamente è buggato?
Io davvero non l'ho capito, non voglio fare polemica... l'invio della 
STR1 in chiaro? Sono disponibile per qualsiasi  prova: se vuoi creo un 
un utente  e poi  io ti dico la mia STR1 facendo finta che tu l'abbia 
sniffata, può essere che mi sbaglio, ma credo lo stesso che non si 
arriverebbe da nessuna parte,  ma se mi sbaglio sarò felice di 
riconoscerlo e di correggere la procedura con tanti ringraziamenti.




-------------------------------------------------------------------------
>  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 :)
-------------------------------------------------------------------------
Sarà... conrollerò, intanto grazie per avermelo fatto notare.




-------------------------------------------------------------------------
>  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 :)
-------------------------------------------------------------------------
Anche se fosse perchè offendere il lavoro non retribuito e svolto con
impegno e passione da un'altra persona?



-------------------------------------------------------------------------
>  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
-------------------------------------------------------------------------
Ok ecco spiegato: Xorro è nato per scopi privati (lo so che sono 
ripetitivo), ma tante volte un estraneo vede cose che io non vedo perchè 
sono concentrato su altri aspetti, e poi del resto io ho una visione del 
tutto da programmatrore, mentre tu da esperto in ambito di sicurezza, 
un'altra persona magari da amministratore di rete, tutti insieme si va 
avanti nel modo giusto, da soli io e MultiTasking potremmo trascurare 
aspetti fondamentali. Infine il fatto che questo progetto ci stesse 
invogliando a fare le cose per bene ci ha anche convinti a mettere le 
nostre idee (considera che l'idea è tutto il client non conta niente 
perchè qui si sta parlando di un metodo per scambiarsi informazioni) a 
disposizione di tutti.





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

> > Il problema e' che chiunque si puo' sostituire al SERVER, e in
> > questo modo truffare l'utente.
-------------------------------------------------------------------------
Questo principio è valido per qualsiasi connessione. E' uno dei motivi 
principali per cui persone che si occupano come te di sicurezza 
lavorano. Se fosse possibile ovviare a questo non esisterebbero persone 
che sfruttano le broadcast per spoofare l'IP e lanciare i denial of 
service. Oltre tutto questa è una delle debolezze intrinseche del 
protocollo TCP, non poter stabilire con certezza da dove provenga un 
pacchetto. Se avessimo risolto questo problema senza cambiare 
l'architettura delle reti di tutto il mondo, credo che assumeremmo Bill 
Gate come lavandaio :-) sarebbe bello in effetti, però adesso skerzi a 
parte attribuire questo problema al protocollo Xorro mi pare francamente 
un po' esagerato.




-------------------------------------------------------------------------
>  la password va concordata tra gli utenti preventivamente

> > Aaaaaah beh, ottimo :)
-------------------------------------------------------------------------
Credo che non esista un modo + sicuro di questo per lo scambio delle 
password  e qualsiasi  manuale  di  crittografia  tu  possieda  sarà 
concorde con questa cosa. In certi casi può risultare poco pratico, ma 
sono pronto a scommettere che se avessimo previsto uno scambio delle 
password online, qualsiasi persona anche quella meno colta in materia a 
buon diritto avrebbe detto che non è una cosa sicura (forse tu saresti 
anche stato tra quelli) per cui non capisco francamente questo sarcasmo no?





-------------------------------------------------------------------------
>  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.
-------------------------------------------------------------------------
Io credo che alla fine il mondo è bello perchè è vario e per fortuna 
nessuno costringe nessuno nell'utilizzo di Xorro che per ora non  
pretende nulla, tanto meno di diventare il nuovo standard in fatto di 
chat, perciò non risponderò a tono a questa critica, se ne vogliamo 
parlare più in dettaglio, senza polemizzare però, sarò felice di farlo 
anche perchè personalmente ritengo che nessuno di questi sistemi che hai 
nominato sia destinato a durare nel tempo, in quanto la dimensione delle 
chiavi è sempre prestabilita e il workload dei processori in continua 
crescita. L'attaccante sa in anticipo la lunghezza della chiave, inoltre 
la chiave con cui i messaggi vengono cifrati è sempre la stessa, 
l'aggravante poi è che si può sempre sniffare il messaggio, di qui in 
poi è una pura questione di numeri, perciò verrà sempre il momento in 
cui il plugin della crittografia sarà da aggiornare. In Xorro invece si 
fa in modo tale che (come ho esposto qualche punto più in su)  lo  Xor 
avvenga  con stringhe di pari  dimensione del messaggio e sempre diverse 
e generando le stringhe nuove dalle rimanenze delle vecchie il processo 
non è invertibile, non serve un apporto matematico per comprendere 
questo. Certo se fossimo pagati io prenderei seriamente in 
considerazione anche la possibilità di scrivere la dimostrazione 
matematica di quanto è sicuro un sistema del genere funzionamento (nei 
vari passaggi critici), anzi credo che sarebbe proprio una bella 
soddisfazione, anche perchè giustamente aiuterebbe a capire meglio anche 
a noi che abbiamo implementato il client.


Cordiali saluti.

Gabriele Nardella