[Soci SLIP] Crittografia... :-)

[Massimo Nuvoli]

plsim a libero.it ha scritto:
> Grazie Massimo questa si che è una spiegazione, io infatti ho
> verificato un po' di cose il giorno dopo, in particolare ho visto
> che la mia banca cripta ai soli 128 bit, e per il resto è come tu
> dici...non verranno mai a chiederti con un email dati così
> sensibili, eccc...

128bit bastano per garantire un minimo di sicurezza... da nulla a 128
è tanto! :-)

> Ma tecnicamente cosa scatta per progettere i
> dati durante la trasmissione SSL? Rispondimi quando puoi. Grazie 
> Pier

E' abbastanza complicato da descrivere, anche tecnicamente, diciamo
che il server (la banca) e il client (il tuo pc con il browser):

1) prima di incominciare a scambiarsi i dati crittografati si presentano

2) il server porge la sua chiave pubblica per decrittare i propri dati
di qua parte una sessione in crittografia ASIMMETRICA

3) il client controlla la chiave e la Certification Autority che ha
rilasciato la chiave

4) a questo punto il client controlla se la chiave appartiene
realmente al sito

5) da qua in poi la connessione HTTPS è attiva i due estremi scambiano
una chiave SIMMETRICA che usano per trasferirsi le informazioni

Bene.. ora vi incasino la vita, il server usa in realtà due chiavi,
una privata e una pubblica, la crittografia infatti è asimmetrica,
ovvero il server critta con la chiave privata e il client decritta con
quella pubblica.

Infatti nella fase iniziale tutto va avanti così fino a quando usando
un meccanismo particolare che si chiama PKC (Public Key Cryptography)
i due estremi non si scambiano una ulteriore chiave temporanea per
fare la crittografia simmetrica (che è più rapida)

Bene, qualcuno potrebbe pensare MA il client come fa a scambiare i
dati con il server? quando risponde che chiave usa?

Quello che succede è semplicissimo: come ho scritto prima con la
chiave privata il server crittografa le informazioni, il client le
riceve e le decritta con quella pubblica.

Al contrario il client quando risponde al server usa la chiave
pubblica per crittografare i dati e solo il server con la chiave
privata può decrittografarli.

Quindi nella primissima fase tutto è assolutamente asimmetrico e sicuro.

Ovvero: con le chiavi asimmetriche dell'https una qualsiasi può essere
usata per crittografare e la sua "omologa" per decrittografare.

Una risposta ad una domanda di martedì sera... hehehe ora sono lucido :-)

E' vero che la crittografia https è asimmetrica, ma, una volta
stabilita la sessione (e questo come ho già detto è il primo punto
debole) la crittografia diventa simmetrica quindi potenzialmente più
facile da attaccare (in un secolo).

YahhhUUUUUUUUUUUUUUUUUUUUUUUUU

:-)

-------------- parte successiva --------------
Un allegato non testuale è stato rimosso....
Nome:        signature.asc
Tipo:        application/pgp-signature
Dimensione:  250 bytes
Descrizione: OpenPGP digital signature
Url:         http://mailman.pinerolo.linux.it/pipermail/soci/attachments/20060323/da0179ea/signature.bin