Re: OpenVPN

On Thu, Oct 03, 2002 at 10:00:32AM +0000, tho wrote:
> > Per alcune applicazioni puo' essere utile, ma ... io non capisco
> > che utilita' possa avere IKE in ambito VPN classica.
> 
> il problema si chiama key lifetime
>  il rekeying e' un precetto in crittografia :-) e si applica in modo 
> naturale anche ai canali cifrati

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

> > punto perche' non utilizzare un tunnel user space ben collaudato
> > con un keyring statico, che non fa alcun uso della crittografia
> > asimmetrica?
> 
> nel senso di risolvere proceduralmente le questioni che la 
> crittografia asimmetrica risolve "automaticamente" (e.g. rekeying) ?

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.

> forse bisogna valutare l'opportunita' caso per caso

Concordo, ma la realta' ci ha mostrato come i problemi legati
alla implementazione di protocolli complessi (quali sono quasi
tutti quelli che si sono visti per ora che utilizzano la
crittografia asimmetrica) significa essere crackati senza
rimedio.

Tanto per tornare alle VPN, utilizzare protocolli simmetrici
significa dare accesso ad un attacker che non conosce una
chiave valida a soltanto 10 righe di codice.

> 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 
> 
> la stessa cosa in altri contesti (e.g. non sai a priori chi c'e'
> l'altra parte) diventa improponibile

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.

-- 
Salvatore Sanfilippo <antirez at invece dot org> s/at/@/ s/dot/\./
          finger antirez@tella.alicom.org for PGP key
      "Don't worry about what anybody else is going to do.
 The best way to predict the future is to invent it." (Alan Kay)

________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List