Criptografía de clave pública: cómo funcionan realmente RSA, ECDSA y PGP
La criptografía asimétrica sustenta HTTPS, SSH y la mensajería segura. Comprende las matemáticas y la mecánica sin necesidad de un doctorado.
Tabla de contenidos
El problema que la criptografía simétrica no puede resolver
Antes de que existiera la criptografía asimétrica, todo el cifrado usaba una clave secreta compartida: ambas partes tenían que conocer la misma contraseña o clave antes de poder comunicarse de forma segura. Esto creaba un evidente problema del huevo y la gallina: ¿cómo se intercambia la clave de forma segura en primer lugar? No puedes cifrar la clave con ella misma, y reunirse en persona no escala a millones de conexiones HTTPS.
La criptografía de clave pública, desarrollada en la década de 1970 por Diffie, Hellman, Rivest, Shamir y Adleman, resuelve esto con un notable truco matemático: un par de claves donde lo que una clave cifra, solo la otra puede descifrar. Una clave se hace pública; la otra permanece privada. Puedes distribuir tu clave pública a todo internet: un atacante que la intercepte no gana nada.
Cómo funciona RSA
RSA es el algoritmo asimétrico más reconocido. Su seguridad se basa en el problema de la factorización de enteros: multiplicar dos números primos grandes es trivial, pero factorizar su producto de vuelta a los primos originales es computacionalmente inviable con tamaños de clave suficientes.
El proceso de generación de claves a alto nivel:
- Elige dos números primos aleatorios grandes, p y q (cada uno de 1024+ bits)
- Calcula n = p × q (el módulo, que se hace público)
- Calcula φ(n) = (p−1)(q−1)
- Elige el exponente público e (comúnmente 65537)
- Calcula el exponente privado d tal que e × d ≡ 1 (mod φ(n))
La clave pública es (e, n). La clave privada es (d, n). Cifrado: texto_cifrado = mensaje^e mod n. Descifrado: mensaje = texto_cifrado^d mod n.
RSA se usa para el intercambio de claves y las firmas digitales, no para el cifrado masivo de datos: es órdenes de magnitud más lento que AES. En TLS, RSA (o ECDH) negocia una clave de sesión, y luego AES gestiona el flujo de datos real.
Tamaño de clave mínimo recomendado: 2048 bits hoy en día; 3072 o 4096 bits para seguridad a largo plazo.
Criptografía de curva elíptica (ECC)
ECC ofrece una seguridad equivalente a RSA con tamaños de clave drásticamente menores, lo que la convierte en la opción preferida para los sistemas modernos. Una clave ECC de 256 bits proporciona aproximadamente la misma seguridad que una clave RSA de 3072 bits.
En lugar de la factorización de primos, ECC se basa en el problema del logaritmo discreto de curva elíptica: dado un punto de partida G en una curva y el resultado Q = k×G, encontrar k es computacionalmente inviable. La clave privada es el escalar k; la clave pública es el punto Q.
ECDSA (Elliptic Curve Digital Signature Algorithm) se usa para firmar: es lo que protege las transacciones de Bitcoin, los handshakes de TLS 1.3 y los certificados de firma de código. ECDH (Elliptic Curve Diffie-Hellman) se usa para el intercambio de claves. Las curvas más comunes son P-256 (NIST), P-384 y Curve25519 (preferida por su resistencia a errores de implementación y a posibles puertas traseras en las curvas del NIST).
Firmas digitales: demostrar la autenticidad
La criptografía asimétrica hace más que cifrar: permite las firmas digitales:
- El remitente calcula un hash del mensaje (por ejemplo, SHA-256)
- El remitente cifra el hash con su clave privada: esta es la firma
- El destinatario descifra la firma con la clave pública del remitente para recuperar el hash
- El destinatario calcula de forma independiente el hash del mensaje y lo compara: si coinciden, el mensaje es auténtico y no ha sido modificado
Las firmas digitales proporcionan autenticación (solo el poseedor de la clave privada pudo haberlo firmado) e integridad (cualquier modificación del mensaje cambia el hash). Sustentan los certificados TLS, la firma de código y la autenticación de correo (S/MIME, DKIM).
PGP y la red de confianza
PGP (Pretty Good Privacy) y su implementación de código abierto GPG aplican la criptografía de clave pública al cifrado de correo y archivos. El flujo de trabajo:
- Genera un par de claves:
gpg --full-generate-key - Exporta y comparte tu clave pública:
gpg --export --armor you@example.com - Importa la clave de un contacto:
gpg --import their_key.asc - Cifra un archivo:
gpg --encrypt --recipient them@example.com secret.txt - Firma un mensaje:
gpg --sign --armor message.txt
PGP usa un modelo de red de confianza: en lugar de depender de autoridades de certificación (CA) centrales, los usuarios firman las claves de los demás para dar fe de su autenticidad. Si Alice confía en Bob, y Bob ha firmado la clave de Carol, Alice puede extender cierta confianza a Carol. Este modelo descentralizado contrasta con el modelo jerárquico de CA usado en TLS.
Autoridades de certificación y el modelo de confianza de TLS
Cuando tu navegador se conecta a https://bank.com, verifica la identidad del servidor mediante un certificado TLS: un documento que contiene la clave pública del servidor, firmado por una autoridad de certificación de confianza. Tu sistema operativo y navegador vienen precargados con ~100–150 CA raíz de confianza. La cadena de confianza: CA raíz → CA intermedia → certificado del servidor.
Este modelo centralizado tiene una debilidad conocida: cualquier CA de confianza puede firmar un certificado para cualquier dominio. Entre las mitigaciones se incluyen la Transparencia de Certificados (todos los certificados emitidos deben registrarse públicamente), los registros DNS CAA (restringen qué CA pueden emitir certificados para tu dominio) y HPKP (ahora obsoleto en favor de la CT).
Confidencialidad hacia adelante
El intercambio de claves RSA tradicional tiene un fallo crítico: si un atacante graba el tráfico cifrado hoy y más tarde obtiene la clave privada del servidor, puede descifrar todas las sesiones grabadas previamente. La confidencialidad directa perfecta (PFS) resuelve esto usando claves efímeras de Diffie-Hellman o ECDH para cada sesión: la clave de sesión nunca toca el disco y se descarta después de usarla. TLS 1.3 exige PFS. Al auditar la configuración TLS de un servidor, verifica que solo estén habilitadas las suites de cifrado ECDHE o DHE, no el intercambio de claves RSA estático.