Sicurezza: se non fai cose stupide come usare una chiave RSA a 512 bit, queste suite di crittografia sono tutte ugualmente sicure: sono tutte molto lontane nella zona "non può romperle" . Questo è un meh . Non puoi dire che uno è più sicuro di qualsiasi altro.
Con un'eccezione però: le suite "ECDHE" utilizzano una coppia di chiavi effimera per la crittografia effettiva; poiché la chiave privata corrispondente non viene mai memorizzata in un file, questo garantisce una proprietà nifty nota come Perfect Forward Secrecy . Fondamentalmente rende le comunicazioni immuni agli aggressori che rubano una copia della chiave privata del server dopo il fatto. PFS sembra buono in audit tecnici.
I problemi di prestazioni esistono solo dopo essere stati debitamente misurati. Come diceva Knuth: L'ottimizzazione prematura è la radice di tutti i mali . Quindi non dovresti fare queste domande; dovresti provarlo e misurare . In ogni caso, la risposta dipenderà molto dal contesto: macchine coinvolte, larghezza di banda, schemi di utilizzo ...
Risposta breve: non ha importanza.
Risposta lunga:
Le suite di crittografia "GCM" utilizzano GCM ; le suite di crittografia non GCM utilizzano AES in modalità CBC e un HMAC extra (qui, con SHA-384). I problemi di prestazioni dipendono dai sistemi coinvolti:
- Sui piccoli sistemi a 32 bit (ARM incorporato ...), la parte MAC di GCM sarà costosa, ma lo sarà anche SHA-384 (perché i calcoli a 64 bit ...); Immagino una cravatta.
- Sul PC, il costo AES sarà dominante;
- ... ad eccezione del PC molto recente con AES-NI , dove AES è molto veloce, così come GCM .
Quindi la suite di crittografia GCM dovrebbe, di solito, essere un affare migliore. Tuttavia, ci vuole molta larghezza di banda, o una CPU molto piccola, per notare effettivamente la differenza. Anche senza AES-NI, un server normale ha abbastanza succo per fare SSL a piena larghezza di banda gigabit, con CPU da risparmiare.
Per la parte di crittografia asimmetrica:
- Le suite ECDHE implicano sul server una (ellittica-curva) Diffie-Hellman e una firma per ogni full handshake, mentre le suite di crittografia ECDH richiedono solo la curva ellittica Diffie-Hellman, e metà di quello è già fatto.
- ... Ma un normale PC scricchiolerà attraverso migliaia di quelli al secondo e per codice, quindi questo molto raramente conta.
- ... Soprattutto perché i normali client SSL riutilizzano le sessioni SSL, il che significa che la crittografia asimmetrica si verifica solo per la prima connessione del giorno da un determinato cliente.
- Le firme ECDSA sono più veloci delle firme RSA.
- ... A seconda delle dimensioni dei tasti, ovviamente.
- ... Ma per verifica , questo è il contrario.
- ... E, ancora, ci vuole un sacco di nuovi clienti al secondo perché ciò sia davvero importante. Un PC normale eseguirà centinaia di firme RSA a 2048 bit al secondo, migliaia di firme ECDSA a 256 bit al secondo.
- Le firme ECDSA sono più brevi delle firme RSA, quindi questo consente di risparmiare un po 'di rete (ma, di nuovo, solo poche decine di byte per l'intero handshake).
- Le suite di crittografia DHE e ECDHE implicano anche alcune dozzine di byte in più per l'intero handshake.
- DHE è come ECDHE ma senza le curve ellittiche. Ne hai bisogno per usare la matematica più grande per ottenere gli stessi livelli di sicurezza (modulo a 2048 bit invece di un punto curva a 256 bit), quindi è come RSA contro ECDSA: un po 'più grande, un po' più lento, non importa nella pratica .
Quindi, davvero, non creerai un'utile distinzione basata su sicurezza o anche su performance . Infatti, state già facendo una istruzione di moda , insistendo su AES-256 (invece di AES-128) e SHA-384 (invece di SHA-256). Puoi anche tenerlo acceso e portarlo alla sua conclusione logica: usa il maggior numero possibile di curve GCM e ellittiche! Ciò consentirà di ottenere punti dai revisori impressionabili.