Informazioni su SSL 2048 bit e crittografia a 256 bit

Il 2048-bit riguarda la coppia di chiavi RSA: le chiavi RSA sono oggetti matematici che includono un intero grande e una "chiave a 2048 bit" è una chiave tale che il grande numero intero è maggiore di 2 ²⁰⁴⁷ ma più piccolo di 2 ²⁰⁴⁸ .

Il 256-bit riguarda SSL. In SSL, la chiave del server viene utilizzata solo per trasmettere una chiave casuale a 256 bit ( che non ha una struttura matematica, è solo un mucchio di bit); più o meno, il client genera una chiave casuale a 256 bit, lo crittografa con la chiave pubblica RSA del server (quella che si trova nel certificato del server ed è una "chiave a 2048 bit") e invia il risultato al server. Il server utilizza la sua chiave RSA privata per invertire l'operazione e quindi ottenere la chiave a 256 bit scelta dal client. Successivamente, client e server utilizzano il 256 bit per eseguire i controlli di crittografia e integrità simmetrici e RSA non viene più utilizzato per tale connessione.

Vedi questa risposta per ulteriori dettagli. Questa configurazione è spesso chiamata "crittografia ibrida". Ciò avviene perché RSA non è appropriato per la crittografia di massa, ma la crittografia simmetrica non può eseguire il business pubblico / privato iniziale necessario per iniziare.

(SSL può fare lo scambio di chiavi con altri algoritmi di RSA quindi ho una descrizione semplificata un po 'nel testo sopra, ma questo è il succo dell'idea.)

Per aggiungere ulteriori dettagli, la chiave RSA a 2048 bit è qualcosa chiamata crittografia asimmetrica. Viene utilizzato per convalidare l'identità (firma) e garantire che solo un destinatario previsto possa accedere alle informazioni inviate (crittografia). È composto da due pezzi, una chiave pubblica e una chiave privata. Le chiavi sono effettivamente correlate tra loro, ma poiché sono collegate da due numeri pseudo-primi molto grandi (prime tra loro) sono molto difficili da capire la chiave privata dal pubblico.

Detto questo, poiché l'algoritmo è basato su qualcosa che è davvero difficile da capire (ma è risolvibile), è meno sicuro di un algoritmo simmetrico basato su un segreto condiviso, che non è matematicamente risolvibile e non si basa sulla complessità di un problema di matematica per la sicurezza (ne parleremo più avanti). Questo è il motivo per cui la chiave è molto più grande della controparte simmetrica (che è solo 256 bit). Per rendere l'equazione difficile da risolvere richiede la chiave molto più grande e inoltre, più informazioni vengono trasmesse con la chiave asimmetrica, più è probabile che sia interrotta (inoltre, la crittografia / decrittografia è più intensa del processore).

Per questo motivo, SSL utilizza solo RSA per le fasi di convalida e di scambio delle chiavi. Invece, una chiave simmetrica (in questo caso di 256 bit se supportata dal browser sul client) viene generata e trasmessa al server tramite la crittografia RSA e quindi il resto dei dati viene scambiato tramite la chiave condivisa e un algoritmo simmetrico.

Ciò avviene quando il client decodifica prima la risposta a una sfida che il server crittografa con la sua chiave privata, il client può quindi guardare la chiave pubblica del server (che è firmata da una chiave radice conosciuta che la CA questo caso DigiCert) è stato incluso nella maggior parte dei browser). Quando la risposta decodificata corrisponde alla richiesta, il client sa che il server ha risposto alla richiesta (anche se potrebbe esserci un intermediario che lo inoltra). Quindi il client genera la chiave simmetrica a 256 bit e la crittografa con la chiave pubblica del server e la invia al server. Poiché la chiave è crittografata con la chiave pubblica del server, solo il server (che conosce la chiave privata) può decodificarlo. Ciò significa che qualsiasi intermediario nel passaggio precedente non può conoscere la nuova chiave condivisa. Il cliente può ora fidarsi che qualsiasi informazione inviata tramite la chiave condivisa provenga solo dal server previsto.

Solo per aggiungere alcuni dettagli alle risposte esistenti ...

my question is how would the client know to generate a random 256 bit key? (Why not 128?).

Dipende dalla suite di crittografia che viene negoziata. L'elenco di quelli definiti come parte di TLS 1.1 si trova in RFC 4346 Appendice A.5 . Ad esempio TLS_RSA_WITH_AES_128_CBC_SHA utilizzerà una chiave a 128 bit, mentre TLS_DHE_RSA_WITH_AES_256_CBC_SHA utilizzerà una chiave a 256 bit.

Quale suite di crittografia viene negoziata dipenderà dalla configurazione del client e del server, non dal certificato installato sul server. Quando il client avvia la connessione con un messaggio Client Hello , invia un elenco di pacchetti di crittografia supportati. Il server sceglie quindi quello che vuole e lo dice nel suo messaggio Server Hello .

Questa suite di crittografia determina quindi in che modo queste chiavi simmetriche vengono infine condivise. Lo scopo immediato dell'handshake SSL / TLS è stabilire una condivisione pre-master secret tra il client e il server. Questo è più ampiamente definito come lo scambio di chiavi (vedi RFC 4346 Appendice F.1.1) .

Questo rientra in due categorie (escluso lo scambio di chiavi anonime):

• Scambio chiave RSA (ad esempio TLS_RSA_WITH_AES_128_CBC_SHA ): il client codifica il segreto pre-master utilizzando la chiave pubblica del server (presente nel certificato).
• Scambio chiave DH (E) (ad esempio TLS_DHE_RSA_WITH_AES_256_CBC_SHA ): avviene uno scambio di chiavi Diffie-Hellman. Il server firma i propri parametri DH e il client verifica la firma con la chiave pubblica nel certificato del server. (Avere un certificato basato su RSA non implica uno scambio di chiavi RSA.)

Alla fine della stretta di mano, a seconda di quale di questi due passi sono stati utilizzati, il client e il server sono in possesso di un comune pre-master secret , da cui derivano un master segreto (vedi RFC 4346 Sezione 8.1 ).

Da quel master secret , entrambe le parti possono derivare le chiavi di crittografia (e i segreti MAC), come descritto in RFC 4346 Sezione 6.3 .

Oltre al tipo di chiave (RSA o DSS), non c'è nulla in questo che faccia dipendere la dimensione della chiave di crittografia dal certificato. Inoltre, entrambi i tipi dispongono di pacchetti di crittografia che utilizzano chiavi a 256 bit: ad esempio TLS_DHE_DSS_WITH_AES_256_CBC_SHA e TLS_DHE_RSA_WITH_AES_256_CBC_SHA . (DSS è un algoritmo di sola firma, quindi non si otterrebbe uno scambio di chiavi simile a RSA per crittografare il segreto pre-master.)

La dimensione della chiave nel certificato conta solo per prevenire la contraffazione dello scambio di chiavi (o per essere in grado di decifrare il traffico registrato): se qualcuno è riuscito a trovare la chiave privata dalla chiave pubblica nel certificato, potrebbe agire come un MITM per impersonare il server reale o sarebbe in grado di decifrare il segreto pre-master cifrato (e quindi il traffico registrato) quando si utilizza uno scambio di chiavi RSA (le suite di cifratura DHE sono progettate precisamente per impedire l'accesso al -master secret, anche se l'hacker si impossessa della chiave privata e del traffico registrato, vedi questa domanda ). Ecco perché conta una chiave abbastanza grande e asimmetrica.

Le autorità di certificazione tendono a mettere "256 bit" sui loro siti web perché sembra buono dal punto di vista del marketing.

Non è sbagliato, ma può essere fuorviante per le persone che non capiscono che è come è configurato il tuo server e cosa supportano i tuoi clienti.