Parte: 2 — Criptografía aplicada · Fuente: Real-World Cryptography (Wong) y Serious Cryptography (Aumasson) ⏱️ Duración estimada: 100 min · Nivel: Avanzado
Comprender cómo dos partes que nunca se han visto pueden acordar una clave secreta compartida sobre un canal público, mediante Diffie-Hellman (DH) y su variante de curva elíptica (ECDH). El alumno entenderá el problema del logaritmo discreto, la diferencia entre DH estático y efímero, el concepto de forward secrecy y por qué DH sin autenticación es vulnerable a un ataque de intermediario (MITM).
Al finalizar, el alumno podrá:
| # | Tema | Por qué importa |
|---|---|---|
| 1 | Problema del logaritmo discreto | Base de la seguridad |
| 2 | DH clásico (grupos multiplicativos) | Protocolo fundacional |
| 3 | ECDH / X25519 | Variante moderna eficiente |
| 4 | Efímero vs estático | Forward secrecy |
| 5 | Derivación de clave (HKDF) | Del secreto bruto a claves útiles |
| 6 | MITM y necesidad de autenticación | DH solo no autentica |
| 7 | Parámetros seguros | Evitar grupos débiles (Logjam) |
gˣ mod p y ambos calculan gˣʸ. Característica: acuerdan clave sin transmitirla.g, p y gˣ mod p, hallar x es inviable con parámetros grandes.openssl version
pip install cryptography
Laboratorio local. El MITM se simula solo entre procesos propios.
DH de juguete a mano. Con p=23, g=5, Alice elige a=6 y Bob b=15. Calcula A=5⁶ mod 23, B=5¹⁵ mod 23 y verifica que Bᵃ mod 23 = Aᵇ mod 23. Ese es el secreto compartido.
ECDH con X25519 y HKDF en Python:
python
from cryptography.hazmat.primitives.asymmetric.x25519 import X25519PrivateKey
from cryptography.hazmat.primitives.kdf.hkdf import HKDF
from cryptography.hazmat.primitives import hashes
a = X25519PrivateKey.generate(); b = X25519PrivateKey.generate()
shared = a.exchange(b.public_key())
key = HKDF(algorithm=hashes.SHA256(), length=32, salt=None,
info=b"canal").derive(shared)
print(key.hex())
Simula un MITM. Coloca un "atacante" entre A y B que reemplaza cada clave pública por la suya. Comprueba que A y B acaban con claves distintas que el atacante conoce → demuestra la necesidad de autenticar (certificados/firmas).
Forward secrecy. Genera efímeros por sesión y razona por qué revelar la clave estática no compromete sesiones antiguas.
p=97, g=5 y valores propios.gˣʸ = gʸˣ permite el acuerdo.info distintos.Implementa un handshake ECDHE autenticado: cada parte firma su clave pública efímera con Ed25519 (clave de largo plazo) y verifica la del otro antes de derivar la clave de sesión. Criterio de aceptación: un MITM que altere las claves efímeras es detectado porque la firma no valida, y el canal solo se establece entre las partes legítimas.
| Síntoma / mensaje | Causa y cómo arreglar |
|---|---|
| DH sin autenticación | Vulnerable a MITM; añade firmas o certificados |
| Usar el secreto DH directamente como clave | Deriva con HKDF; el secreto bruto no es uniforme |
| Grupos DH pequeños o compartidos débiles | Logjam; usa ≥2048 bits o X25519 |
| DH estático sin forward secrecy | Compromiso futuro descifra el pasado; usa efímeros |
| Reutilizar el par efímero | Anula forward secrecy; genera uno por sesión |
❓ ¿DH cifra datos? No; solo acuerda una clave. Luego cifras con AES/ChaCha20 usando esa clave derivada.
❓ ¿Qué es forward secrecy y por qué importa? Que capturar tráfico hoy y robar la clave del servidor mañana no permite descifrarlo, gracias a los efímeros. TLS 1.3 lo exige.
❓ ¿DH resiste cuántica? No; cae ante Shor, igual que RSA/ECC. De ahí la cripto post-cuántica.
Clase 052 — HMAC y autenticación de mensajes