Perché la lunghezza del codice dh dovrebbe corrispondere alla lunghezza rsa in tls?

Nella suite di crittografia "DHE_RSA", la sicurezza è relativa sia a quella offerta da Diffie-Hellman, sia a quella offerta da RSA. "In generale", la sicurezza complessiva sarà quella del più debole dei due; così:

• è dannoso se il tasto DH è più debole della chiave RSA, perché la sicurezza generale viene ridotta (rispetto a ciò che offre la sola chiave RSA);
• è dannoso se il tasto DH è più strong della chiave RSA, perché non ottieni un'effettiva sicurezza extra (è limitato da quella della chiave RSA), ma devi comunque pagare la chiave extra large (più grande messaggi, costo computazionale più elevato e perdita di interoperabilità con client limitati.

Accade che DH e RSA sembrino offrire una forza simile se usati con chiavi di dimensioni simili, ad esempio il modulo DH a 1024 bit può essere detto un po 'strong come RSA con un modulo a 1024 bit (ma un modulo non-prime, ovviamente). Quindi questo dà la regola che il tasto DH e la chiave RSA dovrebbero avere la stessa lunghezza.

Quando guardi i dettagli, le cose sono meno chiare:

• In una suite di crittografia DHE_RSA, DH e RSA vengono utilizzati per scopi diversi. RSA è per una firma e il suo obiettivo di sicurezza è limitato al presente. Supponiamo che tu faccia una connessione SSL oggi. L'attaccante lo registra. Quindi si propone di interrompere la connessione. Tra cinque anni, dopo numerosi calcoli e grazie ai miglioramenti tecnologici, l'hacker riesce a rompere il codice DH: l'attaccante può quindi decrittografare la connessione registrata e imparare i tuoi segreti. Tuttavia, supponiamo che invece di concentrarsi su DH, l'utente malintenzionato ha rotto la chiave RSA del server. L'attaccante quindi ... non ha niente! Rompere la chiave RSA gli dà il potere di impersonare il server per la connessione futura, ma non lo aiuterà un po 'con la decrittografia delle connessioni passate. Nel frattempo, hai rinnovato il certificato del tuo server almeno una o due volte, con una nuova chiave ogni volta, quindi tutti gli sforzi dell'attaccante sono andati a vuoto.

  Per questo motivo, la sicurezza di RSA e la sicurezza di DH in una suite di crittografia "DHE_RSA" non possono essere facilmente confrontate; non hanno lo stesso scopo o livello obiettivo e, nel complesso, la sicurezza di RSA è meno importante di quella del DH.

• DH e RSA hanno una sicurezza paragonabile per la stessa lunghezza del modulo solo in senso approssimativo. Il migliore algoritmo noto per la rottura di RSA è il Numero generale di setacciamento di campo , e il miglior algoritmo conosciuto per interrompere DH è anche GNFS. Tuttavia, per il modulo grande (ad esempio 1024 bit o più), il collo di bottiglia di GNFS è la fase "algebra lineare", che è l'ultimo nell'algoritmo: è un calcolo matematicamente banale su una matrice di dimensioni estremamente non banali. Questo è molto difficile da calcolare in parallelo e richiede una macchina con una quantità enorme di RAM molto veloce. In effetti non esiste un computer che sia all'altezza del compito di RSA a 1024 bit o DH (una macchina dedicata può essere immaginata senza infrangere le leggi della fisica, ma costerebbe un bel penny).

  Risulta che la variante GNFS che interrompe DH ha lo stesso passo di algebra lineare, ma con una matrice "più grande"; non con più elementi, ma gli elementi sono ora interi modulo p (il modulo primario) anziché semplici bit. Ciò significa che la matrice per la rottura della DH è mille volte più grande (concettualmente) della matrice per rompere RSA con una dimensione della chiave simile. Ciò implica che, in pratica, il DH a 1024 bit è più difficile da interrompere rispetto a RSA a 1024 bit.

  (Anche nella pratica, 1024-bit DH e 1024-bit RSA sono intatti nel contesto economico-tecnologico corrente, quindi qualsiasi confronto di robustezza deve essere considerato con un pizzico di sale, un algoritmo non può essere meno rotto che non rotto. )

• Non puoi necessariamente scegliere il modulo DH come preferisci. Le implementazioni esistenti possono essere limitate, per una serie di ragioni storiche. Alcuni client potrebbero avere problemi a utilizzare un modulo DH più lungo di 1024 bit, anche se non hanno problemi con una chiave RSA a 2048 bit. L'uguaglianza di robustezza e l'equilibrio di sicurezza sono cose belle, ma i dati devono comunque fluire. Un fallimento nel stabilire una connessione è molto sicuro ma non molto utile.

Quindi, mentre un modulo DH a 2048 bit sistematico non danneggerà nulla di sicurezza, e incorrerà solo in moderato overhead (su un DH a 1024 bit, questo significa da 250 a 500 byte extra per handshake completo, e qualche CPU in più, ma niente di critico), potrebbe interrompere la compatibilità con i vecchi client esistenti, quindi questo richiede test. Almeno, dal punto di vista dello standard , 2048-bit DH va bene, indipendentemente dalle dimensioni di qualsiasi RSA chiave coinvolta nel mix.

"Ovviamente, non si vuole che il DH sia l'anello più debole della catena: usare AES-256 e solo assicurare lo scambio di chiavi con DH-512 è stupido, ovviamente." Esattamente. DH e RSA sono diversi, ma l'algoritmo più efficace per forzarli è lo stesso (vedi la risposta di Tom Leeks), quindi i loro livelli di sicurezza sono simili. (DH in realtà è un po 'più strong.) Rendere la tua dimensione dei parametri DH e delle chiavi RSA uguali è la cosa ovvia da fare.

"C'è qualche altra ragione per far corrispondere i keylength?" No, ma hai già tutte le ragioni.

"Soprattutto, c'è qualcosa nei protocolli, che richiede questo?" No, non hanno per abbinare. Puoi fare ciò che vuoi. TLS non si preoccupa. Infatti, molti i siti web usano chiavi RSA a 2048 bit, ma sfortunatamente usano ancora DH a 1024 bit. (Apache ha recentemente risolto questo problema, infine.)

"Se uso sempre il DH-2048 (e tutto il resto è relativamente sicuro o debole), farebbe male a tutto (tranne forse alle prestazioni)?" Bene, in una configurazione sicura, tutto il resto sarà relativamente sicuro (RSA) o più strong (AES). Se stai usando qualcosa di più debole, dovresti fermarti. :-) Per rispondere alla tua domanda, penso che andrebbe bene.

Per quanto riguarda le prestazioni, la maggior parte dei client supporta ECDHE, che non è molto più lento del non -Scambio chiave PFS . Il classico DHE è notevolmente più lento e peggiora con l'aumento della dimensione dei parametri, ma non farà una grande differenza se la maggior parte dei tuoi client non la usa e il tuo terminatore SSL non funziona sovraccarico.

Tieni presente che alcuni client, principalmente Java, non sono compatibili con i parametri DH superiori a 1024 bit. Se hai assolutamente bisogno di compatibilità con loro, potrebbe essere sensato sacrificare un po 'di sicurezza e usare il DH a 1024 bit, che è ancora sicuro, a malapena. Sarebbe meglio risolvere il problema in un altro modo, però. Le versioni Java più recenti supportano ECDHE, ad esempio.

Modifica: il punto fatto da CodesInChaos e Tom Leek, che la tua chiave RSA deve rimanere sicura per un anno o due fino alla scadenza del certificato, e la rottura consente solo di impersonare te, ma che la tua chiave DH deve rimanere al sicuro per decenni fino a quando non ti interessa più se i tuoi dati sono decifrati, è molto buono. Probabilmente è più importante di qualsiasi cosa abbia detto, quindi lo copierò e incollerò qui. :-D

Modifica: a proposito, vorrei fare attenzione a che supera 2048 bit. Entreresti in un regno di problemi di compatibilità del client meno studiati. Ad esempio, Firefox aveva un limite di circa 2200 bit (davvero). (Probabilmente si potrebbe chiedere alla community di GnuTLS. Hanno esperienza con DH straordinariamente grandi.)