Con un procesador x86 moderno pero no tan rápido, y una implementación lo suficientemente buena, la velocidad de criptografía no será el cuello de botella. Por ejemplo, considere un procesador AMD Athlon 2650e bastante barato, un procesador no tan moderno y realmente no tan rápido que tengo en mi servidor de archivos doméstico; tiene una velocidad de reloj de 1.6 GHz y tiene un solo núcleo. Todavía puede realizar alrededor de 2200 operaciones de clave privada RSA por segundo (para una clave RSA de 1024 bits). Dudo seriamente que el kernel de Linux en el que se ejecuta esta máquina pueda hacer frente a 2200 nuevas conexiones TCP por segundo ...
(Tenga en cuenta que para cualquier cosa relacionada con RSA, ejecutar una CPU x86 en modo de 64 bits es una gran ganancia. Eso es lo que hago con mi servidor barato, por cierto. En el modo de 32 bits, divida la cifra por 3 o 4; esto aún sería un desempeño bastante respetable.)
Además, SSL / TLS tiene una función conocida como "abreviatura de protocolo de enlace", que trata sobre un cliente que se conecta otra vez y reutilizando el secreto intercambiado asimétricamente de un saludo anterior. Consulte la sección 7.3 de la norma. El apretón de manos abreviado implica solo la criptografía simétrica, no RSA. Tenga en cuenta que, en la práctica , lo mejor del protocolo de intercambio abreviado es que implica menos paquetes de red y menor latencia; el menor uso de la CPU es ingenioso pero no tan visible cuando se mide realmente.
Suponiendo que, sin embargo, usted encuentra que la parte asimétrica de SSL es enorme en el presupuesto de la CPU, su mejor apuesta será una suite de cifrado "simple RSA", aunque podría haber un vínculo con las suites de cifrado ECDHE (pero la única elíptica La curva que es soportada decentemente por los clientes existentes es la curva P-256, que está bien pero es un tanto excesivo si solo apunta a la seguridad de 80 bits).
SSL / TLS también usa criptografía simétrica, y esa también puede usar un poco de CPU. Una CPU x86 es lo suficientemente poderosa como para cifrar todos los datos que pueden pasar por un enlace de 100 Mbits / s, pero puede tener algunos ahorros si elige sus algoritmos correctamente. En términos prácticos, esto significa: usar AES o RC4, no 3DES. AES será excepcionalmente rápido y barato si su CPU ofrece las instrucciones AES-NI (y si su implementación de SSL las usa, de curso).
Para el algoritmo hash, MD5 es algo más rápido que SHA-1, pero SHA-1 ya puede procesar 240 Mbytes / s (mega- bytes , no megabits) en mi CPU AMD barata.
Entonces, esto apunta a que TLS_RSA_WITH_RC4_128_SHA y TLS_RSA_WITH_AES_128_CBC_SHA son los conjuntos de cifrado de elección para quienes desean obtener la mayor cantidad de conexiones por segundo para la menor CPU. O posiblemente TLS_ECDHE_RSA_WITH_RC4_128_SHA o TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA , que será menos compatible, pero le dará Perfect Forward Secrecy , que Puede ser algo bueno tenerlo.
Dicho esto, el rendimiento puede depender mucho de los detalles arquitectónicos y de los entornos operativos exactos, por lo tanto, deberá medir . Pruébelo y vea si cambiar la suite de cifrado hace alguna diferencia real. Recuerde que el rendimiento a menudo tiene mucho más que ver con la cantidad de esfuerzos invertidos en la implementación del protocolo, que con los méritos intrínsecos de los algoritmos mismos.