linux user group brescia

Il Mon, 29 Nov 2004 12:26:45 +0100
marco ghidinelli <marcogh a linux.it> ha scritto:

> > - la chiave deve essere casuale e non solo pseudo-casuale - Verissimo:
> > questo punto è spesso trascurato, ma è importantissimo;
> 
> perche' questa? una chiave pseudocasuale e' anche una chiave casuale
> valida. perche' importantissimo?

Nell'OTP, la chiave deve essere indistinguibile dal "rumore di fondo"; in
altre parole nella chiave non deve essere presente nessuna "struttura". Una
chiave pseudo-casuale possiede una sua struttura. Certo, tutto funziona lo
stesso anche con una chiave pseudo-casuale, ma bisogna porsi la domanda: cosa
farebbe un attaccante di fronte ad un messaggio OTP? Poichè non è possibile
attaccare l'algoritmo, l'unica possibilità è attaccare la chiave.
Linux ha due comodissimi "device": /dev/urandom e /dev/random.
Il primo produce in output (basta un cat) un flusso di dati pseudo-casuali,
mentre il secondo un flusso di dati casuali. Come fa random a dare dei dati
casuali? Mentre noi lavoriamo raccoglie entropia dal sisteme e in base a
questa genera dei numeri casuali. Il problema di /dev/random è che produce
pochi byte casuali (in sostanza, fino a che non raccoglie abbastanza entropia
non può generare i numeri casuali), mentre /dev/urandom produce tutti i byte
che si vuole.
Tornando al problema del perchè la chiave deve essere casuale, riporto qui di
seguito un estratto di man /dev/random, che chiarisce molto la cosa:

       The random number generator  gathers  environmental  noise
       from  device  drivers  and  other  sources into an entropy
       pool.  The generator also keeps an estimate of the  number
       of  bits  of noise in the entropy pool.  From this entropy
       pool random numbers are created.

       When read, the /dev/random device will only return  random
       bytes  within the estimated number of bits of noise in the
       entropy pool.  /dev/random should  be  suitable  for  uses
       that  need  very  high quality randomness such as one-time
       pad or key generation.  When the entropy  pool  is  empty,
       reads  from  /dev/random will block until additional envi­
       ronmental noise is gathered.

       When read, /dev/urandom device will return as  many  bytes
       as are requested.  As a result, if there is not sufficient
       entropy in the entropy pool, the returned values are theo­
       retically  vulnerable  to  a  cryptographic  attack on the
       algorithms used by the driver.  Knowledge  of  how  to  do
       this is not available in the current non-classified liter­
       ature, but it  is  theoretically  possible  that  such  an
       attack  may  exist.  If this is a concern in your applica­
       tion, use /dev/random instead.

 
> > - la cifratura OTP attualmente non gode di grande fortuna - Vero:
> > ultimamente si parla molto di più di cifratura asimmetrica (e.g. GPG);
> 
> infatti, se per mandare un messaggio sicuro devi innanzitutto mandare la
> chiave a quel punto la cifratura simmetrica non ti risolve nulla.

Dipende dagli scenari di utilizzo.
Se si ha la necessità della certezza assoluta dei messaggi, si può anche
essere disposti a pagare una persona fidata per portare dei DVD con la
chiave(4,7 GB  bastano per migliaia di mail).
Se un domani i computer quantici divenissero comuni (e magari sono *già*
comuni alla NSA), l'unica soluzione sarebbe l'OTP.
E poi non dimentichiamoci che la crittografia quantistica (che nulla ha a che
vedere con in computer quantici) sfrutta sì i quanti nella prima fase, ma
nella seconda usa proprio l'OTP.

Ciao,
Gio