Cifrado simétrico y asimétrico
explicado con las manos
Fundamentos de criptografía | unfantasmaenelsistema.com
Casi todos los artículos de seguridad mencionan el cifrado simétrico y el asimétrico de pasada, dan por hecho que ya sabes la diferencia y siguen adelante. TLS «usa criptografía de clave pública», SSH «tiene una clave privada», WireGuard «intercambia claves», las passkeys «firman un reto». Si esas frases te suenan pero no terminarías de explicárselas a alguien, este artículo es para ti.
Vamos a ver los dos tipos de cifrado con analogías físicas, sin una sola fórmula: qué problema resuelve cada uno, por qué se usan siempre juntos (el llamado cifrado híbrido), y un par de detalles que separan una implementación correcta de una vulnerable: la autenticación del mensaje y el uso único del nonce.
Qué aprenderás en este artículo
Cómo funciona el cifrado simétrico y cuál es su único gran problema: repartir la clave · Cómo el cifrado asimétrico resuelve ese reparto usando un par de claves pública y privada · Por qué TLS, SSH, PGP, WireGuard y las passkeys usan cifrado híbrido y no uno solo · Qué es AEAD y por qué «cifrar sin autenticar» es un fallo de seguridad, no un descuido · Qué son el nonce y el IV, y por qué reutilizar uno puede tumbar todo el cifrado
1. Cifrado simétrico: una sola llave para cerrar y abrir
En el cifrado simétrico, la misma clave secreta sirve para cifrar y para descifrar. La analogía es una caja fuerte con una única llave: quien la tiene puede meter documentos y sacarlos; quien no la tiene, ve una caja de acero y nada más.
Es el caballo de batalla de la criptografía moderna porque es rápido: cifrar y descifrar gigabytes con AES o ChaCha20 apenas cuesta a un procesador actual, en parte porque las CPU traen instrucciones dedicadas. Todo lo que ocupa volumen —el contenido de tus mensajes, los ficheros de un disco cifrado, el tráfico de una VPN— viaja protegido con cifrado simétrico.
| Algoritmo | Tipo | Dónde se ve |
|---|---|---|
| AES-GCM | Cifrado de bloque autenticado | TLS, discos (BitLocker, LUKS), casi todo |
| ChaCha20-Poly1305 | Cifrado de flujo autenticado | TLS y SSH en móviles, WireGuard |
| AES-CBC / AES-CTR | Modos sin autenticación integrada | Heredado; requiere un HMAC aparte |
1.1 El problema del reparto de clave
El cifrado simétrico tiene un talón de Aquiles: las dos partes necesitan compartir la misma clave antes de empezar, y esa clave no puede viajar en claro por el mismo canal inseguro que se quiere proteger. Si te la envío por correo, cualquiera que lea el correo la tiene. Si somos dos personas en la misma sala, podemos acordarla en persona; si somos un navegador y un servidor que no se han visto nunca, no. Ese es exactamente el hueco que rellena el cifrado asimétrico.
2. Cifrado asimétrico: un candado abierto que cualquiera puede cerrar
En el cifrado asimétrico (o de clave pública) cada parte tiene dos claves distintas y matemáticamente ligadas: una pública, que se reparte sin problema, y una privada, que no sale nunca de su dueño. Lo que una cierra, solo la otra abre.
La analogía: imagina que reparto por todo el mundo candados abiertos con mi nombre, pero me quedo yo con la única llave. Cualquiera puede coger uno de mis candados, meter un mensaje en una caja, cerrarla y enviármela. Solo yo, con mi llave privada, puedo abrirla. No hemos tenido que acordar ningún secreto de antemano.
- Cifrar para alguien: usas su clave pública; solo su clave privada descifra
- Firmar algo: usas tu clave privada; cualquiera verifica con tu clave pública que fuiste tú (esto es el tema del artículo de firmas digitales)
- Acordar una clave compartida: con Diffie-Hellman, dos partes combinan su material público y privado y llegan cada una, por su lado, al mismo secreto, sin haberlo transmitido nunca
| Familia | Se apoya en | Uso típico | Nota |
|---|---|---|---|
| RSA | Factorizar números enormes es difícil | Firmas, cifrado de claves | Claves grandes (3072+ bits); en retirada lenta |
| Diffie-Hellman (DH/ECDH) | Logaritmo discreto | Acordar clave de sesión | La base del handshake de TLS 1.3 |
| Curva elíptica (Ed25519, X25519) | Logaritmo discreto en curvas | Firmas y acuerdo de clave | Claves pequeñas y rápidas; opción por defecto hoy |
El precio del cifrado asimétrico es que es lento y limitado: cientos o miles de veces más costoso que el simétrico, y solo puede cifrar directamente mensajes más cortos que la propia clave. Nadie cifra un vídeo con RSA. Por eso no se usa solo.
3. Cifrado híbrido: lo mejor de cada uno
La solución que usa absolutamente todo el software serio es combinar los dos: el asimétrico resuelve el arranque (acordar un secreto sin haberse visto antes) y el simétrico hace el trabajo pesado (cifrar los datos rápido).
3.1 El patrón, paso a paso
- Las dos partes usan criptografía asimétrica (Diffie-Hellman de curva elíptica, normalmente) para acordar una clave de sesión simétrica que solo ellas conocen
- A la vez, se autentica al servidor: presenta un certificado y firma con su clave privada un resumen del intercambio, de modo que el cliente sabe que habla con quien dice y no con un intermediario
- A partir de ese momento, todo el tráfico se cifra con la clave de sesión simétrica (AES-GCM o ChaCha20-Poly1305)
- Al terminar la conexión, la clave de sesión se descarta. La siguiente conexión negocia otra nueva
| Sistema | Parte asimétrica | Parte simétrica |
|---|---|---|
| TLS 1.3 (HTTPS) | ECDHE para acordar clave + firma del certificado | AES-GCM / ChaCha20-Poly1305 |
| SSH | Intercambio de clave (curve25519) + clave del host y del usuario | AES-GCM / ChaCha20 |
| WireGuard | Handshake Noise con claves X25519 estáticas y efímeras | ChaCha20-Poly1305 |
| PGP / correo cifrado | RSA o ECC para cifrar la clave de sesión | AES para el cuerpo del mensaje |
| Passkeys (WebAuthn) | El dispositivo firma un reto con su clave privada | El canal ya va sobre TLS |
Forward secrecy: por qué las claves son efímeras
Si la clave de sesión se deriva de valores de un solo uso que se destruyen al acabar, un atacante que grabe hoy tu tráfico cifrado y consiga dentro de un año la clave privada del servidor seguirá sin poder descifrar aquellas conversaciones. En TLS 1.3 y en WireGuard esto es obligatorio
4. Cifrar no basta: hay que autenticar (AEAD)
Un error histórico, y todavía frecuente en código hecho a mano, es cifrar los datos y no comprobar que nadie los ha tocado. El cifrado por sí solo oculta el contenido, pero no impide que un atacante modifique el texto cifrado. Según el modo, cambiar bytes concretos del mensaje cifrado produce cambios predecibles en el descifrado, y observar cómo reacciona el sistema (¿error de formato? ¿error de relleno?) permite ir recuperando el texto original poco a poco.
La respuesta moderna es AEAD (Authenticated Encryption with Associated Data): un cifrado que, además de ocultar, incluye una etiqueta de autenticación. Si al descifrar la etiqueta no cuadra, la operación falla entera y no se devuelve ni un byte. AES-GCM y ChaCha20-Poly1305 son AEAD; por eso son los recomendados.
- Regla práctica: usa siempre un modo AEAD. No combines a mano «cifrar» y «comprobar» salvo que sepas exactamente lo que haces
- La parte de «associated data» permite autenticar sin cifrar metadatos que deben ir en claro pero no deben poder falsearse (cabeceras, números de secuencia)
5. El nonce y el IV: úsalo una vez y solo una
Los cifrados simétricos modernos necesitan, además de la clave, un valor llamado nonce (number used once) o IV (initialization vector). Su función es hacer que cifrar dos veces el mismo mensaje con la misma clave produzca resultados distintos. No es secreto y viaja junto al mensaje.
La condición crítica: con una misma clave, nunca se repite un nonce. Reutilizarlo tiene consecuencias graves según el algoritmo:
- En cifrados de flujo (ChaCha20, AES-CTR), repetir nonce con la misma clave permite combinar dos mensajes cifrados y eliminar el cifrado de ambos por completo
- En AES-GCM, repetir nonce además filtra material que permite falsificar mensajes con etiqueta válida: se rompe la autenticación, no solo la confidencialidad
De dónde salen los nonce en la práctica
Un contador que nunca vuelve atrás, o un valor aleatorio de suficiente tamaño (los 96 bits de AES-GCM se quedan cortos para volúmenes enormes; XChaCha20 usa 192 bits precisamente para poder sortearlos sin miedo). El fallo aparece cuando alguien fija el nonce a ceros «para simplificar», o cuando una máquina se clona con su estado y dos instancias empiezan a contar desde el mismo punto
6. Resumen operativo
| Necesito… | Uso | Ejemplo concreto |
|---|---|---|
| Cifrar muchos datos rápido entre dos que ya comparten clave | Simétrico AEAD | AES-256-GCM para un fichero, un backup, un disco |
| Que dos que no se conocen acuerden una clave por un canal abierto | Asimétrico (Diffie-Hellman) | El handshake de TLS al abrir una web |
| Enviar algo cifrado a alguien conociendo solo su clave pública | Híbrido | PGP, Age, mensajería cifrada |
| Demostrar que un mensaje es mío y no se ha alterado | Firma asimétrica | Commit de Git firmado, paquete de distribución |
| Autenticar un mensaje entre dos que comparten un secreto | HMAC (simétrico) | Tokens de sesión, webhooks firmados |
Referencias
«Serious Cryptography» (Jean-Philippe Aumasson) — el libro divulgativo de referencia sobre esto · RFC 8446 (TLS 1.3) y la documentación de WireGuard (whitepaper del protocolo Noise) · Cryptographic Right Answers (Latacora) — qué usar hoy para cada necesidad, en una página · libsodium / age — librerías modernas que aplican estas decisiones por ti y son difíciles de usar mal · Nuestros artículos sobre TLS y PKI, SSH hardening, WireGuard y passkeys, que se apoyan en todo esto
Conclusión
El cifrado simétrico es rápido y se usa para todo el volumen de datos, pero exige que las dos partes compartan una clave de antemano. El asimétrico resuelve ese arranque —acordar un secreto o autenticar a la otra parte sin haberla visto nunca— a cambio de ser lento y limitado. Por eso no se elige uno u otro: se combinan, y a esa combinación se le llama cifrado híbrido. Es lo que hacen TLS, SSH, WireGuard, PGP y las passkeys.
Dos detalles convierten una implementación en segura o en vulnerable: usar siempre cifrado autenticado (AEAD), para que nadie pueda manipular el mensaje cifrado sin que se note, y no repetir jamás un nonce con la misma clave. La buena noticia es que las librerías modernas —libsodium, age, las primitivas de cada lenguaje— toman esas decisiones por ti si no intentas montártelo a mano.
unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)