Con un processore x86 moderno ma non così veloce e un'implementazione abbastanza buona, la velocità della crittografia non sarà il collo di bottiglia. Ad esempio, si consideri un processore AMD Athlon 2650e abbastanza economico, un processore non così moderno e davvero non così veloce che ho nel mio file server di casa; ha un clock a 1,6 GHz e ha un core singolo. Può ancora fare circa 2200 operazioni di chiave privata RSA al secondo (per una chiave RSA a 1024 bit). Dubito seriamente che il kernel Linux su cui viene eseguita questa macchina possa gestire 2200 nuove connessioni TCP al secondo ...
(Si noti che per qualsiasi cosa relativa a RSA, l'esecuzione di una CPU x86 in modalità a 64 bit è una grande vittoria - questo è quello che faccio con il mio server economico, tra l'altro. Nella modalità a 32 bit, dividere la cifra per 3 o 4: si tratta comunque di prestazioni abbastanza rispettabili.)
Inoltre, SSL / TLS ha una funzione nota come "stretta di mano abbreviata" che riguarda un client che connette ancora e riutilizzando il segreto scambiato asimmetricamente di una precedente stretta di mano. Vedere la sezione 7.3 dello standard. La stretta di mano abbreviata implica solo crittografia simmetrica, nessuna RSA. Nota che, in pratica , la cosa migliore dell'abbreviazione abbreviata è che implica meno pacchetti di rete e minore latenza; l'utilizzo della CPU più basso è elegante ma non così visibile se misurato effettivamente.
Supponendo che comunque la parte asimmetrica di SSL sia enorme nel budget della CPU, la tua migliore scommessa sarà comunque una suite di crittografia "semplice RSA", sebbene ci possa essere un legame con le suite di crittografia ECDHE (ma l'unica ellittica la curva che è decentemente supportata dai client esistenti è la curva P-256, che va bene ma in qualche modo un overkill se si punta solo alla sicurezza a 80 bit).
SSL / TLS utilizza anche la crittografia simmetrica e anche quella può utilizzare una CPU. Una CPU x86 è più che abbastanza potente da crittografare tutti i dati che possono passare attraverso un collegamento a 100 Mbits / s, ma puoi avere dei risparmi se scegli i tuoi algoritmi correttamente. In termini pratici, ciò significa: utilizzare AES o RC4, non 3DES. AES sarà eccezionalmente veloce ed economico se la tua CPU offre le istruzioni AES-NI (e se la tua implementazione SSL le usa, di ovviamente).
Per l'algoritmo hash, MD5 è un po 'più veloce di SHA-1, ma SHA-1 può già elaborare 240 Mbyte / s (mega- byte , non megabit) sulla mia economica CPU AMD.
Quindi questo punta a TLS_RSA_WITH_RC4_128_SHA e TLS_RSA_WITH_AES_128_CBC_SHA per essere le suite di crittografia di scelta per chi vuole ottenere il maggior numero di connessioni al secondo per la CPU minima. O possibilmente TLS_ECDHE_RSA_WITH_RC4_128_SHA o TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA , che saranno meno ampiamente supportati, ma ti forniranno Perfect Forward Secrecy , che può essere una cosa carina da avere.
Detto questo, le prestazioni possono dipendere molto dai dettagli architettonici e dagli ambienti operativi esatti, quindi devi misurare . Provalo e vedi se cambiare la suite di cifratura fa davvero la differenza. Ricorda che le prestazioni hanno spesso molto più a che fare con la quantità di sforzi investiti nell'implementazione del protocollo, piuttosto che con i meriti intrinseci degli algoritmi stessi.