Diffie-Hellman e il suo utilizzo TLS / SSL

25

Sto facendo fatica a capire l'uso (non) di Diffie-Hellman (DH) in TLS.

  • DH è in giro ormai da molto tempo, perché quasi nessuno lo usa ancora?
  • DH viene utilizzato solo per "condivisione delle chiavi", perché nessuno usa il segreto DH per crittografare tutto? Perché abbiamo bisogno di una chiave simmetrica, quando abbiamo già un segreto DH, che è abbastanza buono per trasportare ancora un altro segreto? Ciò vale anche per SSH (non?). Penso che ci sia una risposta semplice a questo, ma non ho potuto trovarlo.
posta David Halter 25.08.2013 - 22:02
fonte

2 risposte

35

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 .

    
risposta data 26.08.2013 - 14:42
fonte
3

Penso che Sicurezza ora ep. 412 "SSL e perfetto segreto avanzato" ha quello che vuoi.

Forse dovresti semplicemente cercare leggere la loro trascrizione per "Diffie", perché questi podcast hanno molto di notizie / materiale vario prima che arrivino al punto.

Citando:

But many browsers today, and many servers today, support what's called Diffie-Hellman Ephemeral, DHE. Ephemeral specifically means "just for the moment." So this is DHE, Diffie-Hellman Ephemeral, is a technology that is decoupled - and this is the key, "decoupled" - from the server's authentication. And as I just said with Diffie-Hellman, a third-party observing the interchange gets no knowledge. That is exactly the protection we want in our SSL connections from long-term archiving. Long-term archiving and subsequent revelation of the server's private key doesn't give anybody any help in cracking Diffie-Hellman Ephemeral protection.'

Si rivolgono specificamente al motivo per cui non è ancora pienamente utilizzato:

But Microsoft does not offer any Diffie-Hellman Ephemeral [...] that also has RC4, which is the cipher [...]. Unfortunately they're all CBC, Cipher Block Chaining. And that's the encryption protocol which is vulnerable to the BEAST attack.'

Qui si riferiscono ai test SSLLabs descritti in ep. 395 (e 396).

    
risposta data 26.08.2013 - 12:08
fonte

Leggi altre domande sui tag