Re: [ml] segnalazione nuovo client di chat criptata

---- Forwarded message from MultiTaskinG <refirewall(at)gmail.com> -----
From: MultiTaskinG <refirewall(at)gmail.com>
To: ml(at)sikurezza.org
Subject: Re: [ml] segnalazione nuovo client di chat criptata

Il 19/01/06, Stefano Zanero <s.zanero(at)securenetwork.it> ha scritto:

> Prima regola della crittografia: MAI INVENTARE ALGORITMI CRITTOGRAFICI
> se non se ne hanno le basi.

ehm... non abbiamo inventato NULLA
abbiamo usato l'unico algoritmo che matematicamente non pu? essere craccato
(se solo avessi letto qualcosina eh ?)

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

si a livello teorico... intanto sono "secoli" che provano a fare collision
da qualche parte e ci riescono in casi estremamente rari. ad ogni modo QUEL
TIPO di attacchi ? infruttuoso per l'uso che il programma fa dell'MD5

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

>
> - HTTP e' un protocollo che induce un certo overhead, e peraltro
> complesso da implementare correttamente lato server.

si ma noi l'abbiamo implementato correttamente... non capisco di cosa ti
preoccupi :-P
oltretutto il client c'?.. il server pure... testalo se vuoi no ?

- L'hash della password viene trasmesso in chiaro, questa non e' una
> buona idea.

l'hash della password viene trasmesso in chiaro (STR1) solo in fase di
registrazione dell'utente... per arrivare  a chiave pubblica e privata ci
vuole un po' di tempo e stiamo valutando come procedere... ad ogni modo la
STR1 conta solo per l'autenticazione dell'utente e non inficia minimamente
la segretezzadel messaggio

- Seconda regola della crittografia: MAI INVENTARE PROTOCOLLI
> CRITTOGRAFICI. Sniffando una registrazione e' possibile effettuare il
> prelogin a nome del client e pertanto ottenere STR2; quindi, e' anche
> possibile effettuare il login completo e ottenere la STR2 successiva. Da
> qui in poi il protocollo e' compromesso.

questo vale SOLO in fase di registrazione. (quando sar? implementato uno
scambio di chiave pubblica/privata di cui sopra questo "problema" non ci
sar?)
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.
Inoltre per cautelare la segretezza della STR1 ? possibile anche aggiungere
caratteri da vari IP
(es. pensi che a casa non sei sicuro ? ti registri a casa creando una STR1,
poi vai al lavoro e di la aggiungi altri caratteri alla STR1)
un eventuale sniffer per poter leggere la tua STR1 deve loggare il tuo
traffico da entrambi i punti dove ti colleghi

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

torno a ripetere che questo ? un falso problema
1) perch? la STR1 si pu? modificare a piacimento anche da un internet point
2) perch? in futuro ci sar? uno scambio di chiave pubblica/privata

- Non c'e' modo di cautelarsi da un attacco man in the middle perche'
> l'autenticazione non e' mutua

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

- Non si capisce quale password condivisa venga usata per "cifrare",
> visto che in nessuno dei passaggi tra server e client viene scambiata
> una password tra due utenti.

la password va concordata tra gli utenti preventivamente
non abbiamo ANCORA implementato nulla per lo scambio di chiave
pubblica/privata
usare SSL non ci convinceva per niente

- Un programma di cifratura privo di sorgenti non e' un buon programma
> di cifratura.

lo standard ? li... puoi fare il tuo client :-P
il php ti risponde davvero sai ?

- Per quanto riguarda l'impossibilita' di bloccare questo protocollo,
> qualsiasi sistema con Linux, snort-inline e/o iptables con il modulo per
> filtrare il contenuto dei pacchetti e' in grado di bloccarlo al volo.

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. ? molto pi? semplice bloccare skype.

> Cordiali saluti,
> Ing. Stefano Zanero

le critiche costruttive dagli ingegneri son ben accette... per? anche
leggere con un po' di attenzione prima di sparare a zero ? gradito.

 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.

Esempio.
Azienda con X rappresentanti
all'interno della LAN aziendale (e quindi sul server Xorro dell'azienda
dotato di ip pubblico) gli utenti si registrano e si scambiano le chiavi.
da ora tutti i dipendenti possono comunicare anche da un internet caf? dati
in modo assolutamente riservato. (per la cronaca io ogni volta che scarico
la posta non da casa cambio la password).
 siamo indecisi se implementare il trasferimento di files (cosa facilissima
arrivati a questo punto ma di dubbio gusto per il server ;-)

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