Introducción a los conjuntos de cifrado

Publicado: enero de 2025. Actualizado: agosto de 2026. Revisado por el equipo de asesoría en criptografía de Encryption Consulting.

Como consultores en el campo de la criptografía aplicada, a menudo nos preguntan si habilitar el cifrado es suficiente para garantizar la seguridad de las comunicaciones digitales. La respuesta es no, ya que la seguridad del cifrado depende de los algoritmos que se intercambian en la conexión, y precisamente esa negociación es lo que rige un conjunto de algoritmos de cifrado.

Cuando se envía un mensaje a través de una conexión, normalmente se utiliza una conexión TLS/SSL para cifrar los datos de dicho mensaje. Para establecer esta conexión se requiere un protocolo de enlace TLS, durante el cual el cliente y el servidor intercambian los conjuntos de cifrado que admite cada uno para poder acordar un conjunto común de algoritmos antes de que se envíen los datos de la aplicación.

¿Qué es un conjunto de cifrado?

Un conjunto de cifrado es una combinación estandarizada y con nombre de algoritmos criptográficos que un cliente y un servidor TLS acuerdan utilizar para una conexión determinada. Determina cómo se crean e intercambian las claves de la conexión, cómo cada parte verifica su identidad, cómo se cifra la mayor parte de los datos y cómo se comprueba su integridad. Dos entidades que eligen algoritmos diferentes para cualquiera de estas tareas no pueden entenderse entre sí, por lo que el conjunto de cifrado es el contrato que ambas partes firman antes de que se transmita cualquier dato.

Los cuatro componentes de un conjunto de cifrado

1. Algoritmo de intercambio de claves. Establecer un canal seguro requiere que ambas partes lleguen a la misma clave de sesión simétrica sin enviarla nunca en texto plano. El algoritmo de intercambio de claves es el que negocia esa clave. RSA, DH, ECDH y ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) son las opciones más comunes; ECDHE es el preferido actualmente porque proporciona confidencialidad directa, una propiedad que se analiza en profundidad en nuestro artículo complementario sobre Secreto adelante perfecto.
2. Algoritmo de autenticación. Así es como el servidor (y opcionalmente el cliente) demuestra su identidad, generalmente firmando parte del protocolo de enlace con la clave privada asociada a su certificado. RSA, DSA y ECDSA son los algoritmos de autenticación más comunes, y el certificado instalado en el servidor debe usar un tipo de clave que coincida con el algoritmo que espera el conjunto de claves negociado.
3. Algoritmo de cifrado de datos masivos. Este es el algoritmo de cifrado que encripta el contenido del mensaje una vez que se completa el protocolo de enlace, por lo que debe ser rápido y difícil de descifrar. AES es la opción predominante hoy en día; 3DES y RC4 fueron comunes históricamente, pero ahora están en desuso.
4. Algoritmo MAC o AEAD. El cifrado por sí solo no garantiza que un mensaje no haya sido manipulado durante su transmisión. Los sistemas de cifrado más antiguos combinaban un código de autenticación de mensajes (MAC) independiente, a menudo HMAC basado en SHA-2, con el cifrado principal. En cambio, los sistemas modernos utilizan un cifrado AEAD (cifrado autenticado con datos asociados), como AES-GCM o ChaCha20-Poly1305, que realiza el cifrado y la verificación de integridad en una sola operación y elimina toda una clase de errores de implementación a los que eran propensos los diseños de cifrado y MAC por separado.

El nombre de un conjunto de cifrado TLS 1.2 detalla los cuatro componentes, por ejemplo, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 : ECDHE es el intercambio de claves, RSA es el algoritmo de autenticación, AES_256_GCM es el cifrado masivo AEAD y SHA384 es la función hash utilizada en la construcción AEAD. Los nombres de los conjuntos de cifrado TLS 1.3 son más cortos porque los algoritmos de intercambio de claves y autenticación ya no forman parte del nombre; se negocian por separado mediante otras partes del protocolo de enlace. Por eso, un nombre de conjunto TLS 1.3 como TLS_AES_256_GCM_SHA384 solo enumera el cifrado AEAD y la función hash.

¿Cómo negocia un conjunto de cifrado un protocolo de enlace TLS?

Respuesta directa: El cliente envía los conjuntos de cifrado que admite en orden de preferencia, el servidor elige el más seguro que también admite, y el resto del protocolo de enlace se realiza utilizando únicamente los algoritmos incluidos en dicho conjunto. El número exacto de intercambios de mensajes depende de la versión de TLS.

1. Hola, cliente. El cliente envía las versiones de TLS que admite, una lista ordenada de conjuntos de cifrado, un valor aleatorio (el "valor aleatorio del cliente") y, en TLS 1.3, un conjunto de claves provisionales compartidas.
2. Mensaje de bienvenida del servidor y selección del conjunto de cifrado. El servidor selecciona una versión de TLS y un único conjunto de cifrado de la lista del cliente, genera su propio valor aleatorio (el "valor aleatorio del servidor") y, en TLS 1.3, devuelve una clave compartida coincidente para que ambas partes puedan derivar las claves de establecimiento de conexión de inmediato.
3. Certificado y autenticación. El servidor envía su certificado y demuestra la posesión de la clave privada correspondiente utilizando el algoritmo de autenticación que requiere el conjunto negociado. El cliente valida ese certificado a través de su Autoridad certificada cadena.
4. Establecimiento clave. En TLS 1.2, el cliente cifra o deriva una clave secreta pre-maestra mediante el algoritmo de intercambio de claves negociado y envía al servidor la información necesaria para dicho intercambio. En TLS 1.3, ambas partes combinan las claves compartidas ya intercambiadas en los pasos 1 y 2, lo que permite que TLS 1.3 finalice en un solo viaje de ida y vuelta en lugar de dos.
5. Derivación de clave de sesión. Ambas partes derivan de forma independiente las mismas claves de sesión simétricas a partir del secreto compartido y los valores aleatorios intercambiados previamente, utilizando la función hash especificada en el conjunto de cifrado.
6. Mensajes finalizados. Cada parte envía un mensaje de finalización autenticado con las claves recién obtenidas. Si ambas partes pueden verificar el mensaje de finalización de la otra, el protocolo de enlace se completa y cada registro posterior queda protegido con el cifrado masivo y los algoritmos MAC/AEAD especificados en el conjunto de cifrado negociado.

¿Qué conjuntos de cifrado debería utilizar para TLS 1.3?

Respuesta directa: Utilice los tres conjuntos AEAD que define RFC 8446 para uso general: TLS_AES_128_GCM_SHA256 , TLS_AES_256_GCM_SHA384 y TLS_CHACHA20_POLY1305_SHA256 . No es necesario tomar ninguna decisión de configuración más allá de cuál de estos tres priorizar, ya que TLS 1.3 eliminó del protocolo todas las opciones que no fueran AEAD ni de clave secreta directa.

RFC 8446 restringe TLS 1.3 a cifrados AEAD únicamente y elimina por completo el modo CBC, RC4 y el intercambio de claves RSA estáticas; cada protocolo de enlace TLS 1.3 es secreto hacia adelante por construcción. Existen dos conjuntos AEAD adicionales, TLS_AES_128_CCM_SHA256 y TLS_AES_128_CCM_8_SHA256 , para entornos restringidos como dispositivos integrados e IoT donde el costo de implementación de GCM es más difícil de justificar, pero rara vez son la opción adecuada para un servidor web de propósito general.

¿Qué conjuntos de cifrado debería utilizar para TLS 1.2?

Respuesta directa: Restrinja TLS 1.2 a los conjuntos AEAD basados ​​en ECDHE y solo agregue alternativas basadas en DHE si tiene una necesidad de compatibilidad documentada. No habilite los conjuntos RSA estático, DH estático, RC4, 3DES o CBC a menos que un cliente heredado específico no le deje otra alternativa.

• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (Recomendado, requiere un certificado ECDSA)
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Recomendado, requiere un certificado RSA)
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (Recomendado, requiere un certificado ECDSA)
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Recomendado, requiere un certificado RSA)
• TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (Recomendado, requiere un certificado ECDSA)
• TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Recomendado, requiere un certificado RSA)
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (Solo como alternativa de compatibilidad más amplia)
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (Solo como alternativa de compatibilidad más amplia)
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (Débil: modo CBC, evitar a menos que sea necesario para clientes heredados)
• TLS_RSA_WITH_AES_256_CBC_SHA (Débil: sin confidencialidad directa, intercambio de claves RSA estático, evitar)

¿Por qué se consideran débiles o en desuso algunos conjuntos de cifrado?

Respuesta directa: RC4, 3DES, los cifrados de grado de exportación y los conjuntos de cifrado en modo CBC tienen ataques prácticos documentados contra ellos. Los conjuntos de cifrado basados ​​en cualquiera de estos deben deshabilitarse en lugar de relegarse a un segundo plano.

• RC4. Los sesgos estadísticos en la secuencia de claves RC4 permiten que un atacante que observe suficiente tráfico pueda recuperar el texto plano. El RFC 7465 prohíbe formalmente la negociación de conjuntos de cifrado RC4 en TLS.
• 3DES. 3DES utiliza un tamaño de bloque de 64 bits, lo que lo hace vulnerable al ataque de colisión Sweet32 (CVE-2016-2183) cuando una conexión cifra suficientes datos con una sola clave. Debería considerarse obsoleto, aunque no presenta la misma vulnerabilidad que RC4.
• Exportar cifrados. Los conjuntos de claves deliberadamente debilitados para cumplir con los controles de exportación de la década de 1990 (identificables por la palabra "_EXPORT_" en su nombre) utilizan tamaños de clave lo suficientemente cortos como para ser atacados por fuerza bruta hoy en día. No tienen ninguna utilidad legítima en las implementaciones modernas.
• Ataques de oráculo de relleno en modo CBC. Los cifrados en modo CBC rellenan el texto plano hasta el límite de un bloque, y si el manejo de errores del servidor revela si ese relleno fue válido, un atacante puede descifrar el tráfico byte a byte sin conocer la clave. Lucky 13 y POODLE son los ejemplos más conocidos de este tipo de ataque contra los conjuntos de cifrado en modo CBC de TLS, razón por la cual ahora se prefieren los cifrados AEAD que no necesitan relleno a las construcciones CBC que utilizan MAC y luego cifrado.

Compromisos entre rendimiento e interoperabilidad

Respuesta directa: En hardware moderno de servidor y cliente, AES-GCM es la opción más rápida gracias a la aceleración por hardware AES-NI; en hardware sin dicha aceleración, ChaCha20-Poly1305 ofrece un mejor rendimiento por software. La interoperabilidad, y no la velocidad bruta, suele ser lo que determina la elección de una lista más amplia de conjuntos de cifrado.

AES-NI es un conjunto de instrucciones de CPU, disponible en prácticamente todos los procesadores modernos para servidores, ordenadores de sobremesa y dispositivos móviles, que realiza rondas AES directamente en hardware. Donde AES-NI está presente, el cifrado y descifrado AES-GCM prácticamente no consumen recursos de CPU. Donde no está presente, como en algunos chips móviles más antiguos o de menor potencia, calcular AES por software resulta comparativamente costoso, y ChaCha20-Poly1305 (diseñado desde el principio para funcionar de forma eficiente sin hardware dedicado) soluciona este problema, razón por la cual navegadores como Chrome lo priorizan para clientes móviles.

La disyuntiva más difícil suele ser la compatibilidad. Una lista de conjuntos de cifrado restringida a los conjuntos ECDHE-AEAD es la opción predeterminada correcta, pero no podrá conectarse a clientes realmente antiguos (middleware empresarial antiguo, algunos dispositivos integrados o navegadores heredados sin actualizar) que solo admiten conjuntos en modo CBC o DHE. Antes de añadir una alternativa de compatibilidad más amplia, confirme con los registros del servidor o una herramienta de monitorización qué clientes específicos la necesitan realmente y limite la excepción al máximo en lugar de volver a abrir la lista completa de conjuntos heredados.

Conjuntos de cifrado recomendados según el escenario

Escenario	Versiones de TLS	Conjuntos de cifrados	Notas
Solo para tecnologías modernas (API internas, comunicación entre servicios, navegadores/clientes más recientes)	Solo TLS 1.3	TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256	Configuración sencilla y rápida; sin ninguna exposición al intercambio de claves CBC o RSA.
Amplia compatibilidad con el público (web orientada al cliente, debe ser compatible con clientes algo más antiguos).	TLS 1.2 y TLS 1.3	Conjuntos TLS 1.3 AEAD mencionados anteriormente, además de TLS_ECDHE_ECDSA/RSA_WITH_AES_128/256_GCM y TLS_ECDHE_ECDSA/RSA_WITH_CHACHA20_POLY1305_SHA256	Coincide con las directrices "intermedias" de Mozilla; secreto anticipado en cada suite ofrecida.
Interoperabilidad heredada (clientes empresariales específicos que no se pueden actualizar)	TLS 1.2 mínimo, excepción con alcance	Agregue TLS_DHE_RSA_WITH_AES_128/256_GCM_SHA256/384 solo para el cliente específico que lo necesite.	Considérelo como una excepción temporal y documentada, no como una configuración predeterminada; evite por completo el modo CBC y RC4/3DES.

¿Cómo influye el tipo de clave del certificado (RSA frente a ECDSA) en la elección del conjunto de cifrado?

Respuesta directa: Un servidor solo puede ofrecer los conjuntos de cifrado ECDSA de su lista si su certificado utiliza una clave ECDSA, y solo puede ofrecer los conjuntos de cifrado RSA si su certificado utiliza una clave RSA. La selección del conjunto de cifrado no es independiente de la gestión de certificados; ambas decisiones deben tomarse conjuntamente.

Un conjunto de certificados denominado TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 requiere que el servidor se autentique con un certificado ECDSA; TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 requiere un certificado RSA para ese mismo paso de establecimiento de conexión. Por eso, las organizaciones que desean tanto el tamaño de clave más pequeño y la firma más rápida que ofrece ECDSA, como la compatibilidad de cliente más amplia posible que aún garantiza RSA, implementan certificados duales (uno RSA y uno ECDSA) en el mismo servidor y dejan que la pila TLS del servidor seleccione el certificado que coincida con el conjunto de cifrado que negoció el cliente. Un error en esto, como emitir solo un certificado ECDSA en un servidor cuyos clientes no pueden negociar conjuntos de certificados ECDSA, bloquea silenciosamente a los clientes que de otro modo se conectarían. Planificar conjuntamente la emisión de certificados y la política de conjuntos de cifrado es una parte fundamental de un programa PKI bien gestionado.

Limitaciones

Elegir los conjuntos de cifrado adecuados reduce el riesgo, pero no resuelve por sí solo todos los problemas de seguridad de TLS. Una lista de conjuntos de cifrado configurada correctamente no puede compensar una clave privada comprometida, un certificado emitido incorrectamente o un cliente que ignora los errores de validación del certificado. La selección de conjuntos de cifrado solo controla los algoritmos disponibles para negociar; no puede obligar a un cliente que no ofrece conjuntos robustos a utilizarlos; un cliente que se queda en TLS 1.0 con solo conjuntos en modo CBC no podrá conectarse o forzará al servidor a recurrir a una versión anterior, según la política. Por último, el endurecimiento de los conjuntos de cifrado no proporciona por sí solo garantías de confidencialidad directa más allá de lo que ofrece el intercambio de claves negociado. El intercambio de claves RSA estático, si aún está habilitado, expone cada sesión anterior a una única vulneración de la clave privada, un riesgo que se trata en detalle en nuestro artículo sobre confidencialidad directa perfecta .

¿Qué recomendaría Encryption Consulting?

Nuestra recomendación predeterminada es usar TLS 1.3 donde su base de clientes lo admita, ya que elimina por completo la decisión de conjunto débil, y configurar TLS 1.2 como un nivel mínimo de compatibilidad restringido al intercambio de claves ECDHE con AES-GCM o ChaCha20-Poly1305. Desactive RC4, 3DES, los cifrados de exportación y los conjuntos en modo CBC directamente en lugar de despriorizarlos, y vuelva a probar su lista de conjuntos de cifrado activos con su población real de clientes (a través de registros de acceso del servidor o una herramienta de escaneo TLS) al menos una vez al año, ya que los valores predeterminados del navegador y del sistema operativo cambian con el tiempo. Si su organización emite sus propios certificados, alinee la estrategia de tipo de clave de certificado (RSA, ECDSA o ambos) con los conjuntos de cifrado que pretende admitir antes del despliegue, no después. Nuestro equipo de Servicios de Asesoramiento en Cifrado puede realizar una evaluación completa del cifrado en su configuración TLS actual, y nuestro servicio de auditoría de cifrado puede validar que su política de conjuntos de cifrado se aplique realmente en producción, no solo esté documentada.

Impacto de la criptografía postcuántica en los conjuntos de cifrado

Las computadoras cuánticas suficientemente grandes que ejecuten el algoritmo de Shor romperían los algoritmos de intercambio de claves y autenticación RSA y ECDSA en los que se basan los conjuntos de cifrado actuales, ya que ambos dependen de la factorización de enteros y problemas de logaritmos discretos que las computadoras clásicas consideran inviables, pero las computadoras cuánticas no. Esto representa una amenaza para los componentes de intercambio de claves y autenticación de un conjunto de cifrado, no para el cifrado masivo AEAD en sí; AES-256 y ChaCha20-Poly1305 ya se consideran resistentes a la computación cuántica con sus tamaños de clave actuales.

El NIST ha estandarizado ML-KEM (basado en CRYSTALS-Kyber) para el establecimiento de claves y ML-DSA (basado en CRYSTALS-Dilithium), junto con FN-DSA (FALCON) y SLH-DSA (SPHINCS+), para firmas digitales. La solución a corto plazo para TLS es el intercambio de claves híbrido, que combina un algoritmo clásico como ECDHE con ML-KEM en el mismo protocolo de enlace, de modo que la conexión se mantenga segura incluso si solo uno de los dos algoritmos falla. Las implementaciones que manejan datos de larga duración y altamente sensibles deberían comenzar a planificar el intercambio de claves híbrido ahora, ya que los datos capturados hoy pueden descifrarse posteriormente una vez que exista una computadora cuántica criptográficamente relevante (el riesgo de "recolectar ahora, descifrar después"), aunque la parte de cifrado masivo del conjunto de cifrado no necesite cambiar.

Conclusión

Un conjunto de cifrado indica a un cliente y servidor TLS cómo cifrar, autenticar y verificar su comunicación. Elegir el conjunto de cifrado adecuado es uno de los cambios más efectivos y sencillos que se pueden implementar en un despliegue de TLS. Utilice TLS 1.3 siempre que sea posible, restrinja TLS 1.2 a los conjuntos ECDHE-AEAD, desactive RC4, 3DES, los cifrados de exportación y los conjuntos en modo CBC, y asegúrese de que los tipos de clave de certificado coincidan con los conjuntos de cifrado que pretende ofrecer. Los conjuntos de cifrado constituyen una capa de una conexión segura; para que una conexión sea realmente segura de extremo a extremo, es necesario gestionar correctamente los certificados , firmar el código y usar claves SSH seguras .

Preguntas Frecuentes

¿Qué es un conjunto de cifrado en términos sencillos? Un conjunto de cifrado es la combinación específica de algoritmos, para el intercambio de claves, la autenticación, el cifrado masivo y la integridad de los mensajes, que un cliente y un servidor acuerdan utilizar para una conexión TLS. Se negocia automáticamente al inicio de cada conexión HTTPS.

¿Cuáles son los cuatro componentes de un conjunto de cifrado TLS? Algoritmo de intercambio de claves (cómo se establece la clave de sesión, como ECDHE), algoritmo de autenticación (cómo el servidor demuestra su identidad, como RSA o ECDSA), algoritmo de cifrado masivo (el cifrado que protege los datos reales, como AES) y algoritmo MAC o AEAD (la comprobación de integridad, como SHA-384 o la etiqueta de autenticación integrada en GCM).

¿Qué conjuntos de cifrado debo habilitar para TLS 1.3? Los tres conjuntos AEAD de RFC 8446: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384 y TLS_CHACHA20_POLY1305_SHA256. No existe una opción más débil que se pueda habilitar accidentalmente en TLS 1.3, ya que el protocolo solo define conjuntos AEAD.

¿Por qué se considera débil el modo CBC en TLS? Los cifrados en modo CBC requieren relleno hasta el límite del bloque, y las implementaciones de TLS han revelado repetidamente la validez de dicho relleno debido a diferencias en la sincronización o en los mensajes de error. Ataques como Lucky 13 y POODLE explotaron precisamente esa vulnerabilidad para descifrar el tráfico sin recuperar la clave, razón por la cual ahora se prefieren los cifrados AEAD que evitan por completo el relleno.

¿Depende mi elección de conjunto de cifrado del tipo de clave de mi certificado? Sí. Los conjuntos de cifrado ECDSA solo funcionan si el servidor presenta un certificado ECDSA, y los conjuntos de cifrado RSA solo funcionan con un certificado RSA. Un servidor que desee ofrecer ambos tipos de certificados debe disponer de ambos y permitir que su pila TLS seleccione el que coincida en cada intercambio de claves.

Referencias

• IETF, RFC 8446: Protocolo de seguridad de la capa de transporte (TLS) versión 1.3
• IETF, RFC 7465: Prohibición de conjuntos de cifrado RC4
• IANA, Registro de conjuntos de cifrado TLS
• mozilla, Generador de configuración SSL y Directrices TLS del lado del servidor
• Sweet32.info, Ataques de cumpleaños contra cifrados de bloques de 64 bits en TLS y OpenVPN