Re: OpenVPN

On Sat, Oct 05, 2002 at 04:50:43PM +0200, antirez wrote:

> Qual'e' il problema a fare il rekey con la crittografia simmetrica?
> Client e Server condividono un segreto da cui generano nuove
> chiavi per ogni sessione e dopo ogni tot di byte/tempo, usando
> qualcosa di pseudo-random per fare session_key=HMAC(secret,random).

nel frattanto, io ti scopro il segreto, che magari avevate condiviso
a fatica, e poi dovete reiniziare tutto (sempre se vi accorgete di me) :)

> Io vedo il rekeying molto naturale anche con la crittografia
> simmetrica a dire la verita', e, correggetemi se sbaglio, non
> ci sono attualmente motivi scientifici per dire che e' meno
> sicuro di trasmettere le chiavi di sessione con RSA.

la kiave di sessione per sua natura ha una validita' limitata, e confinata
ad una ben determinata sessione (appunto). di conseguenza, non ti servono
motivazioni scientifiche, per affermare, che creare e sharare una chiave
di sessione, non e' uguale, ke creare e sharare un keyring di chiavi simmetriche.
in ogni caso le chiavi di sessioni, non DOVREBBERO essere trasmesse in chiaro;
ma cmq, utilizzando un sistema asimmetrico (appunto) fatto di piu' passi di handshake.
se il protocollo, fallisce, ed e' insicuro, e' per una debole implementazione.

> > ad esempio per canali con tempo di vita medio proporzionato alla
> > dimensione delle chiavi e una policy di scheduling delle chiavi 
> > concordata dalle due parti (e.g. uno schema OTP) puo' essere
> > piu' che sensato 

evidentemente, ti sfugge un particolare cruciale: il costo delle risorse
e delle energie che ti servono, per sharare i tuoi segreti ed instaurare
una trasmissione.

> Secondo me uno schema in cui c'e' un segreto per ogni diverso
> client nel keyring del server, e in ogni diverso client, e'
> ragionevole in un sacco di casi. E' possibile tagliare fuori
> i client togliendo la loro chiave nel keyring. Il segreto
> non viene mai esposto direttamente, passa sempre per una
> funzione ad una via in cui si mescola a qualcosa di casuale
> che passa in chiaro. Anche se SHA1 avesse dei problemi non
> conosciuti, non mi sembra banale ottenere masterkey se si
> parte dal seguente schema:
> 
> ksess1 = SHA1HMAC(masterkey, RAND1)
> ksess2 = SHA1HMAC(masterkey, RAND2)
> ksess3 = SHA1HMAC(masterkey, RAND3)
> ...
> ksessN = SHA1HMAC(masterkey, RANDN)
> 
> L'attacker conosce solo RAND1,RAND2,RAND3, ..., RANDN,
> e possiede del ciphertext cifrato con ksess1, ksess2, ... e cosi'
> via. Da quel che ne so, masterkey e' assolutamente al sicuro
> persino se il block cipher utilizzato per cifrare e' assolutamente
> insicuro.

quello di cui parli e' un principio di crittografia asimmetrica! :), che
manca pero' delle comodita' e delle agevolazioni che un sistema asimmetrico
ti offre.

-- 
[ valvoline :: VRL Team :: s0ftpj :: freaknet Medialab :: GPG key available  ]
[ key fingerprint :: - :: B7E2 48BC 705F AE8F 9ABE  E422 076A 2561 1D67 B4DD ]
[ GPG key available on keyserver :: pgp.mit.edu :: with keyID :: 1D67B4DD :: ]

PGP signature