chiavi di sessione di crittografia simmetrica in SSL / TLS

3 motivi (ora):

1. La crittografia asimmetrica è più lenta, molto più lenta, rispetto alla crittografia simmetrica. Gli ordini di grandezza sono più lenti.
2. Dato lo stesso keylength, asimmetrico è molto più debole di simmetrico, bit-per-bit. Pertanto, è necessaria una chiave molto più ampia per fornire una protezione equivalente. Ciò contribuisce anche alla lentezza menzionata in 1.
3. (Secondo il commento di @ ThomasPornin :) La crittografia asimmetrica comporta un aumento delle dimensioni dell'output. Ad esempio, se si utilizza RSA, i dati crittografati sono almeno il 10% più grandi del testo in chiaro. La crittografia simmetrica, d'altra parte, ha un overhead di dimensione fissa anche durante la crittografia di gigabyte di dati.

Gli algoritmi di crittografia asimmetrica sono molto meno efficienti degli algoritmi simmetrici. Quindi, in sostanza, tutto l'uso della crittografia tramite chiavi asimmetriche implica la crittografia di una chiave di sessione simmetrica, con la quale il messaggio reale viene crittografato.

Oltre alle utili note di AviD sulla lunghezza della chiave, si noti che se gli attacchi di calcolo quantico diventano fattibili, renderanno inefficaci tutti gli algoritmi di chiave pubblica mainstream (e quindi SSL / TLS). Ma il dritto AES-256 rimarrebbe strong anche in seguito a un attacco quantistico da parte di un computer. Vedere Dimensione chiave - Effetto degli attacchi di Quantum Computing - Wikipedia . La domanda sarebbe quindi tornare a come scambiare quelle chiavi e stabilire fiducia in loro.

Questo è un approccio standard, chiamato hybrid cryptosystem . La crittografia simmetrica e la crittografia asimmetrica hanno ciascuna i loro punti di forza e di debolezza. In particolare:

• La crittografia asimmetrica consente a chiunque di crittografare i messaggi che solo un partecipante sarà in grado di decodificare e consente a chiunque di verificare i messaggi che solo un partecipante può aver firmato.
• La crittografia simmetrica è molto più veloce della crittografia asimmetrica. Davvero, molto.

La sicurezza non è davvero una preoccupazione nella scelta tra crittografia simmetrica e asimmetrica. La crittografia asimmetrica risolve i problemi che la crittografia simmetrica non può; per tutto il resto, viene utilizzata la crittografia simmetrica, perché è molto più veloce.

(Come conseguenza dell'essere più veloce, la crittografia simmetrica tende ad avere un margine di sicurezza più elevato: dimensioni chiave comuni - AES a 128 bit - sono abbastanza grandi da escludere una svolta matematica completamente nuova, tutti i computer attualmente esistenti sulla terra Per tutto il tempo in cui l'universo è esistito si avrebbe solo una piccola possibilità di rompere la crittografia. La crittografia asimmetrica gira su margini minori a causa delle sue scarse prestazioni e ci sono occasionalmente miglioramenti matematici nei metodi di cracking che rendono le dimensioni delle chiavi comunemente utilizzate per alcuni anni ma non necessariamente per alcuni decenni, ma questa è una preoccupazione secondaria rispetto all'alternativa capacità / prestazioni.)

I crittosistemi ibridi risolvono il dilemma utilizzando la crittografia asimmetrica solo dove è necessario:

• Per verificare la firma di un messaggio, il messaggio è hashed e la crittografia asimmetrica viene utilizzata solo sull'hash, non direttamente sul messaggio a lunghezza variabile.
• Per crittografare alcuni dati, viene generata una chiave di sessione simmetrica. La crittografia asimmetrica viene utilizzata per condividere questa chiave simmetrica tra i partecipanti (il client e il server). I dati "reali" sono crittografati e autenticati utilizzando questa chiave simmetrica.

In HTTPS come viene comunemente usato sul web, il server ha una chiave pubblica, ma il client non lo fa - qualsiasi browser può contattare il server, al server non importa chi sia il client. ( I certificati lato client sono usato dove ha senso .) Una vista molto alta e incompleta di una sessione di sessione HTTPS è:

1. Il server invia il suo certificato al client. Il certificato contiene la chiave pubblica del server e una firma di tale chiave pubblica da un'autorità di certificazione . Il client verifica che l'autorità di certificazione sia nota (i browser vengono forniti con un elenco di chiavi pubbliche delle autorità di certificazione).
2. Il client e il server decidono di scegliere una chiave simmetrica, in modo tale che un attaccante non sarà in grado di ricostruire la chiave semplicemente ispezionando il traffico o anche modificandolo (o almeno verrà rilevato un aggressore attivo e il client o il server interromperanno la sessione). Uno scambio di chiavi Diffie-Hellman più una firma dal server (per consentire al client di verificare che il lo scambio è stato condotto con il server, e non con un attaccante man-in-the-middle) è una possibilità di generare la chiave simmetrica. È anche possibile fare affidamento esclusivamente sulla chiave privata del server (a spese di non garantire inoltrare la segretezza ).
3. Tutte le comunicazioni successive utilizzano quella chiave simmetrica.

Nota che ho fatto molte semplificazioni sopra. Per maggiori dettagli, leggi:

• Come funziona SSL / TLS?
• Come è possibile che le persone che osservano una connessione HTTPS stabilita non sappiano come decrittografarla?