Criptografía Aplicada: TLS 1.3, Cifrado, Hash y Seguridad en Comunicaciones (2026)

La criptografía es la base de la seguridad digital. Desde la conexión HTTPS de un sitio web hasta el cifrado de extremo a extremo en mensajería, los principios criptográficos protegen la confidencialidad, integridad y autenticidad de los datos. Este artículo cubre los fundamentos de criptografía aplicada que todo profesional de ciberseguridad debe conocer, con un enfoque en TLS 1.3, el estándar de comunicación segura más utilizado en 2026.

1. Conceptos Fundamentales

Confidencialidad, Integridad y Autenticidad

La tríada CIA (Confidentiality, Integrity, Availability) es la base de la seguridad de la información. En criptografía:

Confidencialidad: solo el destinatario legítimo puede leer el mensaje (cifrado)
Integridad: el mensaje no ha sido modificado en tránsito (MAC, Message Authentication Code)
Autenticidad: el mensaje proviene realmente de quien dice enviarlo (firmas digitales, certificados)

Cifrado Simétrico vs Asimétrico

Característica	Cifrado Simétrico	Cifrado Asimétrico
Claves	Una sola clave compartida	Par de claves (pública y privada)
Velocidad	Muy rápida	Lenta (100-1000x más lenta)
Uso típico	Cifrado de datos en tránsito y reposo	Intercambio de claves, firmas digitales
Algoritmos actuales	AES-256, ChaCha20	ECDH, ECDSA, RSA-3072+

En la práctica, TLS 1.3 usa criptografía asimétrica solo para el intercambio inicial de claves y autenticación del servidor. Una vez establecida la clave compartida, toda la comunicación se cifra con criptografía simétrica, que es mucho más rápida.

2. TLS 1.3 — El Estándar de Comunicación Segura

TLS 1.3 (RFC 8446, actualizado por RFC 9846 en 2025) es la versión más reciente del protocolo que asegura la comunicación en internet. Representa un rediseño completo respecto a TLS 1.2, eliminando algoritmos legacy y mejorando tanto la seguridad como el rendimiento.

Principales diferencias con TLS 1.2

Característica	TLS 1.2	TLS 1.3
Round trips (handshake completo)	2 RTT	1 RTT (0 RTT con reanudación)
Cifrado del handshake	ServerHello sin cifrar	Todo el handshake cifrado tras ServerHello
Forward secrecy	Opcional	Obligatorio
Algoritmos eliminados	RC4, 3DES, MD5, SHA-1, CBC	Todos los legacy
Cipher suites	~30+ combinaciones	5 combinaciones (solo AEAD)
Intercambio de claves	RSA o ECDH	Solo ECDH efímero

Forward Secrecy (Secreto Perfecto hacia Adelante)

TLS 1.3 exige que todas las conexiones usen Diffie-Hellman efímero (ECDHE). Esto significa que si la clave privada del servidor se ve comprometida en el futuro, las sesiones pasadas no pueden descifrarse porque la clave de sesión se genera a partir de claves efímeras que se descartan tras cada conexión.

En TLS 1.2, los cipher suites con RSA estático no tenían forward secrecy: si un atacante grababa todo el tráfico cifrado y luego obtenía la clave privada del servidor, podía descifrar sesiones pasadas. TLS 1.3 elimina esta posibilidad.

El Handshake de TLS 1.3

Cliente                               Servidor
  |                                      |
  |--- ClientHello (key_share, ---->     |
  |    supported_versions)               |
  |                                      |
  |<---- ServerHello + key_share --------|
  |<---- EncryptedExtensions ------------|
  |<---- Certificate + CertificateVerify-|
  |<---- Finished -----------------------|
  |                                      |
  |--- Finished ---------------------->  |
  |                                      |
  |========= Datos cifrados ============>|

Lo que ha cambiado respecto a TLS 1.2:

El cliente envía su clave pública ECDH en el ClientHello (key_share), eliminando un round trip
Todos los mensajes tras ServerHello van cifrados, incluyendo el certificado del servidor
La autenticación y el intercambio de claves ocurren en paralelo, no en secuencia

Cipher Suites en TLS 1.3

TLS 1.3 reduce las combinaciones posibles a solo 5, todas ellas AEAD (Authenticated Encryption with Associated Data):

Cipher Suite	Cifrado	Hash
`TLS_AES_128_GCM_SHA256`	AES-128-GCM	SHA-256
`TLS_AES_256_GCM_SHA384`	AES-256-GCM	SHA-384
`TLS_CHACHA20_POLY1305_SHA256`	ChaCha20-Poly1305	SHA-256
`TLS_AES_128_CCM_SHA256`	AES-128-CCM	SHA-256
`TLS_AES_128_CCM_8_SHA256`	AES-128-CCM-8	SHA-256

La mayoría de implementaciones modernas priorizan TLS_AES_128_GCM_SHA256 por su equilibrio entre seguridad y rendimiento, con soporte hardware AES-NI en procesadores modernos.

0-RTT (Zero Round Trip Time)

TLS 1.3 permite enviar datos en la primera petición si el cliente ya se ha conectado antes al servidor, usando un PSK (Pre-Shared Key) de una sesión anterior.

Advertencia de seguridad (RFC 8446, página 18): Los datos 0-RTT no tienen forward secrecy y son vulnerables a replay attacks. No deben usarse para operaciones que requieran protección contra repetición (ej: transacciones financieras, cambios de contraseña).

3. Cifrado Simétrico: AES-GCM

AES (Advanced Encryption Standard) es el estándar de cifrado simétrico más utilizado en el mundo. En TLS 1.3, solo se usan modos AEAD, siendo AES-GCM el más común.

AES-GCM (Galois/Counter Mode)

GCM combina cifrado (AES en modo CTR) con autenticación (GHASH) en una sola operación. Esto significa que proporciona confidencialidad e integridad simultáneamente, sin necesidad de un paso adicional de MAC.

Parámetros de AES-256-GCM:

Clave: 256 bits
IV/Nonce: 96 bits (12 bytes)
Tag de autenticación: 128 bits (16 bytes)

# Cifrar con AES-256-GCM usando OpenSSL
echo "Mensaje secreto" | openssl enc -aes-256-gcm -K $(openssl rand -hex 32) -iv $(openssl rand -hex 12) -out cifrado.bin

# Nota: en producción, la gestión segura de claves es responsabilidad del 
# sistema operativo o de un HSM/TPM

Errores comunes al usar AES-GCM

Reutilizar el mismo IV con la misma clave: rompe completamente la seguridad. El IV debe ser único por mensaje.
Nonce de 64 bits: GCM requiere un nonce de 96 bits. Nonces más pequeños reducen la seguridad.
No verificar el tag de autenticación: sin verificar el tag, no hay protección de integridad.
Usar AES-ECB o AES-CBC: ECB no oculta patrones; CBC es vulnerable a padding oracle attacks. GCM es la opción correcta.

4. Cifrado Asimétrico: ECDH e Intercambio de Claves

TLS 1.3 usa exclusivamente ECDH (Elliptic Curve Diffie-Hellman) para el intercambio de claves.

Curvas Elípticas Recomendadas

Curva	Tamaño de clave	Seguridad equivalente RSA	Uso
X25519 (Curve25519)	256 bits	RSA-3072	Intercambio de claves TLS 1.3 (recomendada)
P-256 (secp256r1)	256 bits	RSA-3072	Intercambio de claves, ECDSA
P-384 (secp384r1)	384 bits	RSA-7680	Cumplimiento gubernamental (SUCESIVO-B)
P-521 (secp521r1)	521 bits	RSA-15360	Máxima seguridad

X25519 es la curva recomendada para intercambio de claves por su seguridad, rendimiento y resistencia a implementaciones incorrectas. P-256 es ampliamente soportada pero tiene requisitos de implementación más estrictos.

Por qué X25519 es preferible a RSA para intercambio de claves

RSA para intercambio de claves fue eliminado en TLS 1.3 porque:

No proporciona forward secrecy: comprometer la clave privada descifra todas las sesiones grabadas
Requiere claves más grandes: RSA-3072 para seguridad equivalente a AES-128
Es más lento: el descifrado RSA es órdenes de magnitud más lento que ECDH

5. Hashing y HMAC

Funciones Hash

Algoritmo	Tamaño de salida	Seguridad en 2026
SHA-256	256 bits	Seguro
SHA-384	384 bits	Seguro
SHA-512	512 bits	Seguro
SHA-3	Variable	Seguro
SHA-1	160 bits	Roto (colisiones demostradas)
MD5	128 bits	Roto (colisiones triviales)

Usos de hashing en ciberseguridad:

Integridad de archivos (checksums SHA-256)
Almacenamiento de contraseñas (con salt, no hash directo)
Firmas digitales (el hash se firma, no el mensaje completo)
Identificación de malware (hashes como IoCs)

HMAC (Hash-based Message Authentication Code)

HMAC combina una función hash con una clave secreta para autenticar mensajes. En TLS 1.3, HMAC-SHA256 se usa para derivar claves y autenticar el handshake.

HMAC-SHA256(clave, mensaje) = SHA256((clave ⊕ opad) || SHA256((clave ⊕ ipad) || mensaje))

6. HKDF — Derivación de Claves

TLS 1.3 utiliza HKDF (HMAC-based Extract-and-Expand Key Derivation Function, RFC 5869) para derivar todas las claves de sesión a partir del secreto compartido establecido por ECDH.

HKDF tiene dos fases:

Extract: combina el material de clave inicial (ECDH shared secret) con un salt para producir un pseudo-random key (PRK) uniforme
Expand: genera múltiples claves a partir del PRK usando HMAC en modo contador

Este diseño permite separar claramente las claves para diferentes propósitos (cifrado de handshake, cifrado de tráfico, exportadores de clave) incluso si todas derivan del mismo secreto compartido.

7. Preguntas Frecuentes

¿Está roto AES? No. AES-128 y AES-256 siguen siendo seguros contra todos los ataques conocidos. El mejor ataque contra AES-128 reduce la complejidad de 2¹²⁸ a 2¹²⁶ — irrelevante en la práctica.

¿Los ordenadores cuánticos romperán TLS 1.3? Los algoritmos de intercambio de claves actuales (ECDH, RSA) serán vulnerables a ordenadores cuánticos suficientemente grandes. La estandarización de algoritmos post-cuánticos por NIST está completada: FIPS 203 ML-KEM (basado en CRYSTALS-Kyber, para intercambio de claves), FIPS 204 ML-DSA (basado en CRYSTALS-Dilithium, para firmas digitales) y FIPS 205 SLH-DSA (basado en SPHINCS+, para firmas basadas en hash) ya son estándares federales publicados. En 2026, la mayoría de implementaciones TLS aún no soportan híbridos clásico-cuánticos.

¿Qué es AEAD? Authenticated Encryption with Associated Data es un tipo de cifrado que proporciona confidencialidad, integridad y autenticación en una sola operación. AES-GCM y ChaCha20-Poly1305 son los únicos modos AEAD permitidos en TLS 1.3.

8. Checklist de Configuración Segura

TLS

TLS 1.3 habilitado como versión preferida
TLS 1.2 solo como fallback (deshabilitar TLS 1.0 y 1.1)
Cipher suites permitidas solo AEAD (AES-GCM y ChaCha20-Poly1305)
Curvas X25519 y P-256 habilitadas para intercambio de claves
Certificados firmados con ECDSA (P-256) o RSA-3072+
HSTS activado con max-age=31536000
Certificate Transparency habilitado

Cifrado general

AES-256-GCM para cifrado simétrico
SHA-256 o SHA-3 para hashing
PBKDF2 o Argon2 para derivación de contraseñas
Claves gestionadas con HSM o servicio cloud (AWS KMS, Azure Key Vault)
Rotación de claves cada 1-2 años para claves asimétricas

Conclusión

TLS 1.3 representa el estado del arte en seguridad de comunicaciones: forward secrecy obligatorio, cifrado del handshake completo, eliminación de algoritmos legacy, y un diseño que facilita implementaciones correctas. Para el profesional de ciberseguridad, entender los fundamentos de AES-GCM, ECDH, HKDF y AEAD es esencial para tomar decisiones informadas sobre configuración de servidores, desarrollo de aplicaciones y análisis de protocolos. La criptografía aplicada correctamente es invisible para el usuario — pero su ausencia es la causa de la mayoría de las filtraciones de datos masivas.