Re: [ml] Xorro Chat

Formichiere wrote:

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

Fare XOR con una sequenza di caratteri pseudorandom generati da un
algoritmo nel modo in cui lo fate in genere si chiama "stream cipher"

> dovrei spiegare il perchè di questa scelta

Piu' che altro, dovresti togliere questo dalle FAQ:

[...]
Quali sono le particolarità del protocollo Xorro 1.0 ?
[...]
Inoltre viene correttamente implementato il Cifrario di Vernam. Ossia
l'unico algoritmo di cui è stata matematicamente dimostrata la non
craccabilità. Nelle specifiche del protocollo è anche implementata una
funzionalità per elevare a infinito la durata della chiave del Cifrario
di Vernam usato per chattare.
[...]

In quanto e' completamente falso (oltre a indicare, in chi abbia qualche
nozione di crittografia, una scarsa comprensione di cosa sia un one-time
pad).

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

No, guarda, non e' lungo. Per poter usare un one-time pad devi scambiare
in modo sicuro una chiave lunga come il messaggio da cifrare. Questo e'
impraticabile. Si usano altri algoritmi che NON sono one time pad. Non
c'e' molto piu' di questo, da dire.

> 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

Infatti lo SCOPO di un protocollo sicuro e' garantirsi che i dati non
possano 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, 

La scusa "beh forse in futuro qualcuno potrebbe compromettere anche un
buon protocollo, quindi facciamone uno che non funziona", non regge molto.

SSL resiste al Man in the Middle, e' fatto apposta. L'unico modo per
comprometterlo e' compromettere l'infrastruttura a chiavi pubbliche
sottostante, ad esempio mediante social engineering.

Viceversa, il tuo protocollo non resiste nemmeno alla piu' basilare
forma d'attacco MITM. Quindi non e' sicuro.

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

Ma perche' mai ?! Anzi, usare una molteplicita' di punti d'accesso, se
possibile, peggiora le cose. Non sono assolutamente d'accordo con questa
affermazione generica.

> Io davvero vorrei trovare qualcuno
> che è in grado di spiarti in qualsiasi momento e da qualsiasi
> connessione. 

Chiunque, con un troiano installato sulla tua macchina ?

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

Ma cosa c'entra l'entropia ? Non stai "accumulando" nulla.

> Il programma similmente a un cifrario di Vernam 

Di nuovo: non c'entra proprio nulla.

> prende una stringa e la Xorra con il testo che l'utente invia
> al suo interlocutore, poi quella stringa non verrà mai + riutilizzata

E' quello che fanno, fondamentalmente TUTTI gli algoritmi di cifratura
stream cipher.

Come puoi
> ben vedere cambia totalmente la maniera in cui viene utilizzato rispetto
> ai tradizionali sistemi.

No, hai semplicemente re-inventato (senza le basi matematiche
necessarie) una cosa che esiste gia', e che si realizza appropriatamente
con un linear shift register o con altri meccanismi simili. Di nuovo,
consiglio caldamente una sfogliata ad un testo di crittografia.

> Se tu fossi un malintenzionato quale tipo di
> attacco proveresti a portare? 

Io non sono un matematico, quindi non mi avventuro a studiare e
realizzare algoritmi di cifratura. Ti inviterei a fare altrettanto,
visto che evidentemente non hai una conoscenza approfondita del campo.

Ti do' un input sul perche' questo cifrario non va bene. A parita' di
password iniziale, produce SEMPRE lo stesso keystream, quindi un attacco
di known-plaintext e' banalmente realizzabile.

Realizzare ex novo un cifrario e' SEMPRE un errore. E' facile fare un
cifrario che SEMBRA funzionare, il difficile e' sapere se funziona
davvero. E di solito, non funziona.

> la stessa passord per generare le
> stringhe dello Xor si automodifica in maniera IMPOSSIBILE da prevedere

Questa cosa e' bellissima da dire, ma impossibile da dimostrare.

> Per l'ennesima volta devo darti ragione, però in ingegneria siamo
> abituati a circoscrivere i problemi, non si può fare un calderone
> pazzesco. 

Il calderone lo hai fatto nel momento in cui hai mescolato un server
HTTP nel tuo programma di messaging.

K I S S ( Keep It Simple Stupid ): paradigma cardine della sicurezza nel
design.

> E' tutto vero quello che dici, ma il protocollo è sempre open

Gia', lo diceva anche Microsoft (*grin*)

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

Confondi "open source" con "gratuito".

> io nell'etichetta di rompiscatole) l'analisi della sicurezza va fatta
> sul protocollo non sul programma 

Di nuovo, un giretto su bugtraq aiuterebbe.

> Io davvero non l'ho capito, non voglio fare polemica... l'invio della
> STR1 in chiaro?

Santa pazienza.

Per la registrazione invii:
nick, nome, cognome, indirizzo, email, avatar, passwordMd5, STR1

Ti risponde con lo xon.

Per il prelogin mandi:
xon e md5(STR1 e xon e passwordMd5)

noti che io ho tutte le informazioni che mi servono a fare il prelogin
sniffando la registrazione che passa in chiaro ?

> Questo principio è valido per qualsiasi connessione. 

No, una connessione autenticata con un qualsiasi protocollo di
autenticazione MUTUA non e' soggetta a questo problema.

> lavorano. Se fosse possibile ovviare a questo non esisterebbero persone
> che sfruttano le broadcast per spoofare l'IP e lanciare i denial of
> service.

Per favore, limitiamo le sparate al solo campo della crittografia :)

> Se avessimo risolto questo problema senza cambiare
> l'architettura delle reti di tutto il mondo, 

Le soluzioni si chiamano IPSEC, TLS, ...

> Credo che non esista un modo + sicuro di questo per lo scambio delle
> password  

Esiste un modo altrettanto sicuro, si chiama "algoritmo Diffie-Hellman",
e oltre a lui ne esistono svariate altre decine...

> In certi casi può risultare poco pratico,

Non e' poco pratico, e' semplicemente assurdo.

Mi stai dicendo che hai inventato un protocollo sicuro di conversazione
online che si basa sull'ideona di scambiarsi prima una password TRA OGNI
COPPIA DI UTENTI ?

Ehm.

> anche perchè personalmente ritengo che nessuno di questi sistemi che hai
> nominato sia destinato a durare nel tempo,

Guarda, mi risparmio di rispondere all'ultima parte del messaggio
perche' e' francamente delirante.

> 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 

Te lo dico gratuitamente. Zero al quoto.

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