Diffie-Hellman è usato in SSL / TLS, come "effimero Diffie-Hellman" (le suite di crittografia con "DHE" nel loro nome; vedi lo standard ). Ciò che raramente si incontra è "static Diffie-Hellman" (suite di crittografia con "DH" nel loro nome, ma né "DHE" o "DH_anon"): questi pacchetti di crittografia richiedono che il server possieda un certificato con una chiave pubblica DH, che è raramente supportata per una varietà di ragioni storiche ed economiche, tra cui la principale è la disponibilità di uno standard libero per RSA ( PKCS # 1 ) mentre lo standard corrispondente per Diffie-Hellman ( x9.42 ) costa un centinaio di dollari, il che non è molto, ma è sufficiente per scoraggiare la maggior parte degli sviluppatori amatoriali.
Diffie-Hellman è un protocollo dell'accordo chiave , il che significa che se due parti (ad esempio, il client SSL e il server SSL) eseguono questo protocollo, finiscono con un K segreto condiviso. Tuttavia, né il client né il server possono scegliere il valore di K ; dal loro punto di vista, K sembra generato casualmente. È secret (solo loro conoscono K ; gli eavesdroppers sulla linea non lo fanno) e shared (entrambi hanno lo stesso valore K ), ma non scelto . Questa non è crittografia. Un K segreto condiviso è abbastanza buono, tuttavia, per elaborare terabyte di dati con un algoritmo di crittografia simmetrica (stesso K per cifrare da un lato e decodificare dall'altro), e questo è ciò che accade in SSL.
Tuttavia, esiste un algoritmo di crittografia asimmetrica noto come RSA. Con RSA, il mittente può crittografare un messaggio M con la chiave pubblica del destinatario, e il destinatario può decrittografarlo e recuperare M usando la sua chiave privata. Questa volta, il mittente può scegliere il contenuto M . Quindi la tua domanda potrebbe essere: in un mondo RSA, perché ci preoccupiamo di AES? La risposta si trova nei seguenti punti:
-
Ci sono dei vincoli su M . Se la chiave pubblica del destinatario ha dimensione n (in byte, ad es. n = 256 per una chiave RSA a 2048 bit), allora la dimensione massima di M è n-11 byte. Per crittografare un messaggio più lungo, dovremmo dividerlo in blocchi sufficientemente piccoli e includere alcuni meccanismi di riassemblaggio. Nessuno sa davvero come farlo in modo sicuro . Abbiamo buone ragioni per credere che RSA su un singolo messaggio sia sicuro, ma debolezze sottili possono nascondersi in qualsiasi sistema di divisione e rimontaggio e non ci sentiamo a nostro agio. È già abbastanza brutto con cifre simmetriche , dove la situazione matematica è più semplice.
-
Anche se potessimo gestire la suddivisione e il rimontaggio, ci sarebbe un'espansione della dimensione. Con una chiave RSA a 2048 bit, un chunk di messaggio interno ha una dimensione massima di 245 byte, ma restituisce, quando crittografato, una sequenza di 256 byte. Questo spreca la nostra forza vitale, cioè la larghezza di banda della rete. La crittografia simmetrica comporta solo un sovraccarico limitato (beh, SSL aggiunge un leggero overhead proporzionale alla dimensione dei dati, ma è molto più piccolo di quello che si verificherebbe con un protocollo RSA-only).
-
Rispetto ad AES, RSA è lento come l'inferno.
-
Ci piace davvero avere l'opzione di utilizzare protocolli di accordi chiave come DH invece di RSA. Nei tempi più antichi (prima del 2001), la RSA era stata brevettata ma non la DH, quindi il governo degli Stati Uniti raccomandava la DH. Al giorno d'oggi, vogliamo essere in grado di cambiare algoritmi nel caso in cui uno si rompa. Per supportare i protocolli di accordo chiave, abbiamo bisogno di una crittografia simmetrica, quindi possiamo anche usarla con RSA. Semplifica l'implementazione e l'analisi del protocollo.
Vedi questa risposta per una descrizione dettagliata di come funziona SSL .