Re: [ml] Xorro Chat

Saluti a tutta la lista,

> -------------------------------------------------------------------------
> 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 ;-)
>
Non posso che concordare, indipendentemente dal merito dei contenuti. Mi à 
capitato di dirlo pià volte in questa stessa lista ed in altre. La Lista à 
tanto pià utile quando il "non esperto" (che lo sia, che lo sappia, che lo 
ammetta o meno) parla con "l'esperto", cosà come quando pià "esperti" 
disquisiscono dei massimi sistemi.

In ogni caso, Zanero ha indubbiamente ragione. 
Prima di tutto, separiamo i problemi teorici dell'"algoritmo" e del 
"protocollo" con quello delle vulnerabilitÃ.

Certamente, ogni implementazione puà avere delle falle, che consentono di 
aggirare il livello di sicurezza offerti dall'algoritmo e dal protocollo in 
modo diversamente efficace. In tutti i casi, le vulnerabilità non permettono 
di violare l'algoritmo o il protocollo in quanto tali, ma solo una loro 
implementazione, e non dal punto di vista crittoanalitico, ma solo 
relativamente all'environment di esecuzione, alla specifica implementazione 
etc...
Su questo, credo, possiamo essere tutti d'accordo.  Ma agli stessi sostenitori 
del progetto Xorro consiglio di vedere il changelog di OpenSSL per 
comprendere il ginepraio di problemi ai quali una buona implementazione di 
crittografia va incontro, nonostante l'esperienza dei suoi sviluppatori, il 
grande processo di revisione pubblica al quale questa libreria à esposta, 
etc..etc..etc... Ma sopratutto: nonostante il fatto che in quel caso 
(openssl) l'implementazione si basi su standard pubblici, consolidati, 
oggetto di crittoanalisi da esperti del settore.

Il fatto che questo problema si pone per algoritmi e protocolli standard, 
dovrebbe darvi occasione di riflessione (non faccio giudizi, saranno gli 
utenti ed i fatti a premiarvi o meno...) sul fatto che la vostra scelta ha un 
ordine superiore di problemi: sul piano teorico, non potete affermare quale 
livello di robustezza garantite, la qual cosa sarebbe possibile in caso di 
implementazione di algoritmi disponibili pubblicamente. 

L'accostamento dell'algoritmo a Vernam à errato
>Una chiave pseudocasuale generata da un segreto lungo meno dei messaggi
>da trasmettere NON E' UN CIFRARIO DI VERNAM.
Ha ragione Zanero.
Faccio un esempio:
Ogni cifrario simmetrico moderno, per esempio a blocchi come il DES, esegue la 
cifratura di tutto il documento con chiavi ogni volta diverse, prodotto 
dell'elaborazione di una passoword mnemonica (sono i cosiddetti PBE, Password 
Based Encryption).
In realtÃ, direte, la password non à diversa per ogni blocco cifrato!.... Di 
base no, ma il Padding Schema (es: CBC) permette di fare si che, con 
operazioni di XOR o analoghe, quello che si cifra al passaggio X sia 
combinato con il cifrato X-1.
Quindi, semplificando (moltissimo!!!), supponendo che le operazioni, come per 
XORRO, siano SOLO di XOR, il padding schema CBC combina con operazione XOR il 
testo in chiaro con la seguente chiave Vernam:
un vettore di inizializzazione + (un vettore di inizializzazione + il primo 
blocco cifrato di 56bit) + (un vettore di inizializzazione + il primo blocco 
cifrato di 56bit + il secondo blocco cifrato di 56bit) etc...: se seguo il 
vostro principio, il fatto fare XOR del testo in chiaro con qualcosa di 
dimensioni uguali e sempre diverso per ogni documento, rende CBC un Vernam. 
No: questo à un padding schema, neppure un algoritmo di cifratura (per altro, 
potremmo quindi dire che, con vettore di inizalizzazione variabile, vi siete 
reinventati CBC!).
Ripeto, sto semplificando, altrimenti DES CBC e XORRO non sarebbero 
paragonabili, a favore del DES.

Nel frattempo, il DES fa anche cifratura.
DES, perÃ, non à pià ritenuto sicuro. 
Ergo, cosa dire di XORRO?
 
Saluti, e scusate le "licenze" che mi sono liberamente preso...
-----------------------------------------------------------------
Luca Bechelli
Security Consultant
web:   www.bechelli.net
email: luca[at]bechelli.net
Tel.:  +39-328-3164385