Perché i numeri primi vengono riutilizzati negli scambi di chiavi Diffie-Hellman?

1

Leggendo l' attacco Logjam , ho appreso che gli scambi Diffie-Hellman spesso * si basano su la stessa particolare chiave a 1024 bit . Capisco che quando DH è stato inventato, anche le chiavi a 512 bit sono state considerate sicure per i decenni a venire. Ma non è mai successo ai progettisti, o ai molti programmatori che hanno lavorato alle implementazioni di DH nel corso degli anni, che riutilizzare gli stessi numeri primi potrebbe portare a una vulnerabilità finale (catastrofica)?

Mi manca qualcosa con la difficoltà computazionale? Generare il proprio p e g una volta, nella configurazione iniziale del servizio, dovrebbe essere sufficiente e dovrebbe garantire l'immunità da qualsiasi difetto con i numeri primi standardizzati.

*: Come al solito due terzi delle attuali implementazioni mondiali .

    
posta detuur 12.07.2016 - 21:52
fonte

2 risposte

1

È possibile visualizzare le seguenti domande sulle difficoltà nel generare i propri parametri EXhcange della chiave DH e anche utilizzando i parametri del gruppo DH standard: È più sicuro generare i tuoi numeri primi Diffie-Hellman o utilizzare quelli definiti in RFC 3526? e Dove trovo? ottenere i numeri primi per Diffie-Hellman? Posso usarli due volte?

For plain Diffie-Hellman, what you need is p, q and g, such that:

  • p is a big enough prime (2048 bits are more than enough nowadays);
  • q is smaller, but still big enough (say 256 bits), prime value which divides p-1 ;
  • g is a generator of a subgroup modulo p with an order that is a multiple of q.

Nella maggior parte dei casi, non è facile, e anche non applicabile, creare un gruppo di scambio di chiavi DH prima che si verifichi lo scambio di chiavi effettivo. Si noti che logjam sfrutta piccoli numeri primi utilizzati nei gruppi DH (512 bit). Penso che dovresti essere sicuro se usi un gruppo DH con un p di 2048 bit anche se il gruppo è utilizzato anche da altri.

    
risposta data 12.07.2016 - 23:27
fonte
0

Il numero dei due terzi a cui fai riferimento è specifico per i server VPN che utilizzano IPsec. Scommetterei che questo è il risultato di Sys Admins e Security Individuals che non impiegano il tempo necessario per modificare altre impostazioni predefinite nei loro server rispetto a quelle assolutamente necessarie durante la configurazione.

Oppure, potrebbe essere un problema con l'implementazione specifica di IPsec in quanto riguarda un sottoinsieme specifico di server VPN, ad esempio se questi due terzi è il modo in cui Cisco lo implementa nei propri dispositivi VPN o ASA (poiché sono probabilmente il leader mondiale nelle VPN implementate per l'hardware), o come alcune versioni di Linux l'hanno implementato nei loro build di server, o Windows Server, ecc ... Ad ogni modo, sembra che potrebbe essere più un problema di implementazione che un problema reale con DH o IPsec stesso, poiché entrambi sono stati ampiamente esaminati dagli specialisti di Security e Crypto per anni. DH è solo l'algoritmo, fintanto che viene fornito con un numero primo di X bit, l'algoritmo eseguirà il suo lavoro. IPsec è un framework utilizzato per implementare la sicurezza. L'implementazione è ciò che effettivamente preleva e fornisce il numero primo all'algoritmo, tramite il framework.

    
risposta data 12.07.2016 - 23:20
fonte

Leggi altre domande sui tag