Seguridad: si no haces estupideces como usar una clave RSA de 512 bits, estas suites de cifrado son igualmente seguras: todas están muy lejos en la zona "no se puede romper" . Así que eso es un meh . No puedes decir que uno sea más seguro que otro.
Sin embargo, con una excepción: las suites "ECDHE" usan un par de claves efímeras para el cifrado real; ya que la clave privada correspondiente nunca se almacena en un archivo, esto otorga una propiedad ingeniosa conocida como Perfect Forward Secrecy . Básicamente, hace que las comunicaciones sean inmunes a los atacantes que roban una copia de la clave privada del servidor después del hecho. PFS se ve bien en las auditorías técnicas.
Los problemas de rendimiento existen solo después de haberlos medido debidamente. Como dijo Knuth: La optimización prematura es la raíz de todo mal . Así que no debes hacer tales preguntas; deberías probarlo y medir . En cualquier caso, la respuesta dependerá mucho del contexto: máquinas involucradas, ancho de banda, patrones de uso ...
Respuesta corta: no importará.
Respuesta larga:
Las suites de cifrado "GCM" utilizan GCM ; los conjuntos de cifrado que no son GCM usan AES en modo CBC y un HMAC adicional (aquí, con SHA-384). Los problemas de rendimiento dependen de los sistemas involucrados:
- En sistemas pequeños de 32 bits (ARM incrustado ...), la parte MAC de GCM será costosa, pero también lo será SHA-384 (debido a los cálculos de 64 bits ...); Supongo que una corbata.
- En la PC, el costo de AES dominará;
- ... excepto en una PC muy reciente con AES-NI , donde AES es muy rápido, y también lo es GCM .
Por lo tanto, la suite de cifrado GCM debería ser, por lo general, una mejor oferta. Sin embargo, se necesita una gran cantidad de ancho de banda, o una CPU muy pequeña, para notar la diferencia. Incluso sin AES-NI, un servidor normal tiene suficiente capacidad para hacer SSL a un ancho de banda de gigabit completo, con CPU de sobra.
Para la parte de criptografía asimétrica:
- Las suites ECDHE implican en el servidor una (curva elíptica) Diffie-Hellman y una firma para cada saludo completo, mientras que las suites de cifrado ECDH requieren solo la curva elíptica Diffie-Hellman, y la mitad de eso ya está hecho.
- ... Pero una PC normal procesará miles de esos por segundo y por código, por lo que esto rara vez importa.
- ... Especialmente porque los clientes SSL normales reutilizan las sesiones SSL, lo que significa que la criptografía asimétrica se produce solo para la primera conexión del día desde un cliente determinado.
- Las firmas ECDSA son más rápidas que las firmas RSA.
- ... Dependiendo de los tamaños de las llaves, por supuesto.
- ... Pero para verificación , esto es al revés.
- ... Y, nuevamente, se necesita una gran cantidad de nuevos clientes por segundo para que esto realmente importe. Una PC normal hará cientos de firmas RSA de 2048 bits por segundo, miles de firmas ECDSA de 256 bits por segundo.
- Las firmas ECDSA son más cortas que las firmas RSA, por lo que esto ahorra un poco de red (pero, nuevamente, solo unas pocas docenas de bytes por apretón de manos completo).
- Las suites de cifrado DHE y ECDHE también implican unas pocas docenas de bytes adicionales por apretón de manos completo.
- DHE es como ECDHE pero sin las curvas elípticas. Se necesita usar matemáticas más grandes para lograr los mismos niveles de seguridad (módulo de 2048 bits en lugar de un punto de curva de 256 bits), por lo que es como RSA vs ECDSA: un poco más grande, un poco más lento, no importará en la práctica .
Entonces, realmente, no harás una distinción útil basada en seguridad o incluso en rendimiento . De hecho, ya está haciendo una declaración de moda , insistiendo en AES-256 (en lugar de AES-128) y SHA-384 (en lugar de SHA-256). También puede mantenerlo encendido y llevarlo a su conclusión lógica: ¡use la mayor cantidad posible de GCM y curvas elípticas! Esto otorgará puntos brownie de auditores impresionables.