CriptoPublica

Durante décadas, proteger un mensaje significaba que el emisor y el receptor debían compartir previamente una clave secreta. Este modelo, conocido como criptografía simétrica, funcionaba bien en entornos cerrados pero presentaba un problema fundamental: ¿cómo se entrega esa clave de forma segura? Si el canal de comunicación ya estuviera comprometido, la clave también lo estaría.

En 1976, Whitfield Diffie y Martin Hellman publicaron un paper que cambió la historia de la seguridad informática: "New Directions in Cryptography". La idea era revolucionaria — un sistema que usara dos claves matemáticamente relacionadas, pero donde conocer una no permitiera deducir la otra en tiempo razonable. Así nació la criptografía asimétrica o de clave pública.

El concepto del par de claves

Cada participante posee un par de claves generadas simultáneamente mediante un algoritmo matemático:

• Clave pública: Se distribuye libremente. Cualquier persona puede conocerla. Se usa para cifrar mensajes destinados al propietario, o para verificar su firma digital.
• Clave privada: Permanece en poder exclusivo del propietario. Nunca se comparte. Se usa para descifrar los mensajes recibidos, o para firmar documentos.

La analogía del candado

Una forma sencilla de entenderlo: imagina que distribuyes miles de candados abiertos (tu clave pública) por todo el mundo. Cualquier persona puede tomar uno y cerrar con él una caja que contenga un mensaje para ti. Una vez cerrado, solo tú tienes la llave maestra (clave privada) que puede abrirlo. Nadie más puede hacerlo, aunque todos tengan el candado.

¿Por qué fue una revolución?

Antes de 1976, establecer comunicaciones seguras a distancia requería un intercambio previo de claves en persona o por un canal completamente confiable — impracticable en internet. La criptografía de clave pública resolvió el problema del intercambio de claves, permitiendo que dos partes que nunca se han conocido puedan establecer un canal seguro. Esto es la base de HTTPS, el correo electrónico seguro, las firmas digitales, las blockchains y prácticamente toda la seguridad de internet moderna.

Firma digital: autenticación e integridad

El par de claves también funciona en sentido inverso para producir firmas digitales. El emisor cifra el hash de un documento con su clave privada. Cualquier receptor puede verificar la firma usando la clave pública del emisor. Esto garantiza tres propiedades críticas:

• Autenticidad: Solo el poseedor de la clave privada pudo generar esa firma.
• Integridad: Si el documento fue modificado, el hash no coincidirá y la verificación fallará.
• No repudio: El firmante no puede negar posteriormente haber firmado el documento.

En el ciclo de vida del desarrollo de software, estos conceptos son la base de la seguridad de artefactos: cuando descargas un paquete de npm, pip o cualquier gestor de dependencias, una firma digital verifica que el paquete no fue manipulado y proviene realmente del autor declarado.

La criptografía de clave pública no es un algoritmo único, sino una familia de criptosistemas que comparten la filosofía de dos claves pero difieren en el problema matemático difícil que los sustenta. Cada uno tiene fortalezas, contextos de uso y consideraciones de rendimiento distintos.

• RSA

  Factorización de enteros grandes. El más utilizado históricamente. Versátil: cifrado y firma digital.

• ECC

  Logaritmo discreto sobre curvas elípticas. Claves más cortas con igual seguridad. Estándar moderno.

• ElGamal

  Logaritmo discreto en grupos cíclicos. Base de DSA. Cifrado probabilístico.

• DSA / ECDSA

  Solo para firma digital. ECDSA es la versión sobre curvas elípticas. Usado en TLS y Bitcoin.

RSA: el veterano confiable

Creado en 1977 por Rivest, Shamir y Adleman (de ahí las siglas), RSA basa su seguridad en el problema de factorización: es computacionalmente trivial multiplicar dos números primos enormes, pero extremadamente difícil descomponer el resultado en sus factores. Con claves de 2048 bits, un ataque de fuerza bruta con la tecnología actual requeriría millones de años.

// Principio matemático simplificado de RSA
// 1. Elegir dos primos grandes: p y q
p = 61;  q = 53;
n = p * q;          // n = 3233  (módulo público)
φ = (p-1) * (q-1); // φ = 3120 (función de Euler)

// 2. Elegir e tal que gcd(e, φ) = 1
e = 17;   // Exponente público

// 3. Calcular d (inverso modular de e mod φ)
d = 2753; // Clave privada: d·e ≡ 1 (mod φ)

// Clave pública:  (e, n) = (17, 3233)
// Clave privada:  (d, n) = (2753, 3233)

// Cifrar m=65:  c = m^e mod n
c = 65**17 % 3233;      // c = 2790

// Descifrar:   m = c^d mod n
m = 2790**2753 % 3233; // m = 65 ✓

ECC: la nueva generación

La Criptografía de Curva Elíptica (ECC) usa las propiedades matemáticas de puntos sobre curvas elípticas definidas sobre campos finitos. Su ventaja principal es que ofrece el mismo nivel de seguridad que RSA con claves mucho más cortas. Una clave ECC de 256 bits equivale en seguridad a una RSA de 3072 bits. Esto se traduce en menor consumo de memoria, procesamiento más rápido y mejor rendimiento en dispositivos móviles e IoT.

ElGamal y DSA

El criptosistema ElGamal (1984) basa su seguridad en el problema del logaritmo discreto: dado un grupo cíclico G y un elemento g, conocer g^x es fácil, pero dado g^x deducir x es computacionalmente inviable para valores grandes. ElGamal es un cifrado probabilístico — cifrar el mismo mensaje dos veces produce criptogramas distintos, lo que añade seguridad frente a ataques de texto elegido.

El Algoritmo de Firma Digital (DSA) es una variante estandarizada por el NIST que solo provee firma digital (no cifrado), más eficiente para ese propósito. Su variante sobre curvas elípticas, ECDSA, es el estándar actual en TLS 1.3 y es el algoritmo de firma de Bitcoin.

Comparativa de rendimiento

La tendencia en la industria es migrar de RSA a ECC para claves de sesión, manteniendo RSA en contextos donde la compatibilidad con sistemas legacy es obligatoria. Mirando al futuro, el avance en computación cuántica plantea la necesidad de algoritmos post-cuánticos (como CRYSTALS-Kyber, estandarizado por el NIST en 2024), aunque la transición es gradual.

Comprender la diferencia entre los dos paradigmas criptográficos principales es esencial para diseñar sistemas de seguridad efectivos. No se trata de que uno sea "mejor" que el otro — en la práctica, los sistemas modernos usan ambos en combinación.

Criptografía Simétrica

En el modelo simétrico, emisor y receptor comparten la misma clave secreta. La misma clave que cifra es la que descifra. Los algoritmos más utilizados son AES (Advanced Encryption Standard), ChaCha20 y 3DES.

Tabla comparativa completa

El problema de escala del modelo simétrico

Si 5 personas quieren comunicarse de forma privada entre sí con criptografía simétrica, necesitan 10 claves distintas (una por cada par). Con 100 personas serían 4,950 claves. Con 10,000 usuarios serían casi 50 millones. La gestión de este volumen es impracticable. Con criptografía asimétrica, basta con que cada persona tenga su par de claves — 10,000 pares para 10,000 usuarios.

El modelo híbrido: lo mejor de ambos mundos

La solución real que usa internet es un modelo híbrido. La criptografía asimétrica resuelve el problema del intercambio de claves, y la simétrica hace el trabajo pesado del cifrado de datos:

1. Se usa RSA/ECC para autenticar las partes y negociar de forma segura una clave de sesión aleatoria (simétrica).
2. Toda la comunicación posterior se cifra con AES usando esa clave de sesión efímera.
3. Al finalizar la sesión, la clave simétrica es descartada.

Desventajas del modelo asimétrico a considerar

• Rendimiento: RSA es aproximadamente 1,000 veces más lento que AES para cifrar el mismo volumen de datos. Por eso nunca se usa solo para cifrar archivos grandes.
• Infraestructura de clave pública (PKI): Distribuir claves públicas de forma confiable requiere una infraestructura de certificados (CA) que implica complejidad operacional y costos.
• Gestión de la clave privada: Si se pierde o compromete la clave privada, todo el sistema de seguridad colapsa. Su custodia es el punto más crítico del modelo.
• Vulnerabilidad cuántica: RSA y ECC serían vulnerables a ataques con computadoras cuánticas suficientemente potentes (algoritmo de Shor). Esta amenaza, aunque no inmediata, está impulsando la migración a criptografía post-cuántica.

La criptografía de clave pública no es un concepto abstracto de laboratorio — está operando ahora mismo en cada conexión que haces a internet, en cada commit que firmas con Git y en cada login por SSH a un servidor. Aquí examinamos sus aplicaciones más importantes en el ciclo de vida del desarrollo de software.

Caso 1: HTTPS y el TLS Handshake

Cada vez que tu navegador muestra el candado de seguridad, ha ejecutado el siguiente proceso en milisegundos:

1. ClientHello: El navegador envía los algoritmos que soporta y un número aleatorio.
2. ServerHello + Certificado: El servidor responde con su certificado X.509 (que contiene su clave pública RSA o ECC), firmado por una Autoridad Certificadora (CA) de confianza.
3. Verificación: El navegador verifica la firma de la CA sobre el certificado usando la clave pública de la CA (pre-instalada en el sistema operativo).
4. Intercambio de clave: Se usa ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) para derivar una clave de sesión simétrica sin que nadie pueda interceptarla, aunque estuviera grabando el tráfico.
5. Cifrado simétrico: A partir de aquí, todo el tráfico se cifra con AES-GCM o ChaCha20-Poly1305.

Caso 2: SSH — acceso seguro a servidores

En el desarrollo profesional, el acceso a servidores de producción, contenedores y pipelines de CI/CD se realiza mediante SSH. La autenticación por par de claves es superior a las contraseñas por múltiples razones:

• La clave privada nunca viaja por la red — el servidor verifica mediante un challenge criptográfico.
• Son inmunes a ataques de fuerza bruta sobre contraseñas.
• Permiten acceso sin contraseña en scripts automatizados (CI/CD) sin almacenar credenciales en texto plano.

# Generar par de claves Ed25519 (recomendado sobre RSA para SSH)
$ ssh-keygen -t ed25519 -C "tu@email.com"

# Crea dos archivos:
# ~/.ssh/id_ed25519      ← clave PRIVADA (nunca compartir)
# ~/.ssh/id_ed25519.pub  ← clave PÚBLICA (copiar al servidor)

# Copiar clave pública al servidor
$ ssh-copy-id usuario@servidor.com

# El servidor guarda la clave en ~/.ssh/authorized_keys
# El próximo login no pedirá contraseña

Caso 3: Firma de commits en Git

GitHub, GitLab y Bitbucket permiten verificar la identidad del autor de un commit mediante firmas GPG o SSH. En proyectos críticos (paquetes de software, kernels, infraestructura), esto previene que un atacante con acceso al repositorio inyecte código malicioso suplantando a un desarrollador legítimo.

# Firmar commits automáticamente con GPG
$ git config --global user.signingkey TU_KEY_ID
$ git config --global commit.gpgsign true

# Verificar la firma de commits existentes
$ git log --show-signature
# gpg: Good signature from "Tu Nombre <tu@email.com>"

Caso 4: JWT en APIs REST

Los JSON Web Tokens (JWT) son el estándar de autenticación en APIs modernas. Usando RS256 (RSA + SHA-256) o ES256 (ECDSA + SHA-256), el servidor firma el token con su clave privada y cualquier microservicio puede verificar su autenticidad usando la clave pública expuesta en un endpoint JWKS.

// Verificar un JWT firmado con RSA en Node.js
const jwt = require('jsonwebtoken');
const publicKey = fs.readFileSync('public.pem');

const payload = jwt.verify(token, publicKey, {
  algorithms: ['RS256']
});
// Si la firma no es válida → lanza JsonWebTokenError

La ventaja sobre HMAC (simétrico) es que los microservicios solo necesitan la clave pública para verificar — no pueden emitir tokens falsos aunque estuvieran comprometidos, ya que no tienen la clave privada del servidor de autenticación.

Implementar criptografía asimétrica de forma incorrecta es frecuentemente peor que no implementarla: da una falsa sensación de seguridad mientras los datos permanecen vulnerables. Estas recomendaciones están basadas en estándares de la industria (NIST, OWASP) y errores comunes en proyectos reales.

Recomendaciones de implementación

• 🔑

  Elige el algoritmo y longitud de clave correctos

  Para nuevos proyectos: usa ECC con Curve25519 o P-256 en lugar de RSA. Si debes usar RSA (compatibilidad legacy), usa mínimo 2048 bits — nunca 1024 bits, ya que fue factorizado. Para firmas digitales, prefiere Ed25519 sobre ECDSA P-256 por su implementación más segura frente a ataques de canal lateral.

• 🏛

  Nunca implementes criptografía desde cero

  Usa bibliotecas auditadas y maduras: OpenSSL / LibreSSL para C/C++, Bouncy Castle para Java, cryptography para Python, Web Crypto API nativa para JavaScript en navegador. Implementar RSA manualmente, incluso si la matemática es correcta, es casi seguro que fallará en detalles de padding, timing attacks o generación de números aleatorios.

• 🔒

  El padding importa tanto como el algoritmo

  RSA sin padding adecuado es vulnerable a ataques matemáticos triviales. Usa siempre RSA-OAEP para cifrado y RSA-PSS para firma digital. Nunca uses PKCS#1 v1.5 en nuevos sistemas — tiene vulnerabilidades conocidas (Bleichenbacher attack) que se explotan activamente.

• 📅

  Implementa rotación de claves y revocación

  Las claves no son eternas. Define una política de ciclo de vida: los certificados TLS deben tener vigencia de 90 días (estándar actual). Las claves SSH de empleados deben rotarse al cambio de rol o salida de la empresa. Implementa OCSP o CRL para revocación de certificados. Una clave comprometida que no puede revocarse es una brecha permanente.

• 🗄

  Protege la clave privada como el activo más crítico

  La clave privada nunca debe almacenarse sin cifrar en disco ni en repositorios de código (ni en .gitignore — usa git-secrets o similar para prevenirlo). Usa un HSM (Hardware Security Module) o servicios como AWS KMS, Azure Key Vault, HashiCorp Vault para producción. En desarrollo, usa al menos una passphrase fuerte y almacenamiento cifrado.

• 🧪

  Verifica la implementación con pruebas específicas

  Incluye en tu suite de pruebas: verificación de que mensajes cifrados con clave pública se descifran correctamente con la privada, que firmas inválidas son rechazadas, que claves de longitud insuficiente son bloqueadas en la configuración, y pruebas de regresión que eviten downgrade attacks (aceptar TLS 1.0 cuando solo debería aceptarse 1.3).

Observaciones críticas del sector

Sobre la entropía en generación de claves: la seguridad de RSA y ECC depende de generar números realmente aleatorios. En servidores recién iniciados o entornos virtualizados, el pool de entropía puede ser bajo. Usa /dev/urandom (no /dev/random en sistemas modernos) o un CSPRNG del sistema operativo. Nunca uses Math.random() de JavaScript para operaciones criptográficas — usa siempre crypto.getRandomValues().

Sobre el futuro post-cuántico: el NIST finalizó en 2024 los primeros estándares de criptografía post-cuántica (FIPS 203, 204, 205). Si tu sistema maneja datos con requisitos de confidencialidad a largo plazo, considera una estrategia de migración. Los sistemas híbridos (combinar un algoritmo clásico con uno post-cuántico) son la aproximación recomendada durante la transición.

Checklist de implementación segura

• Algoritmo mínimo: RSA-2048 o ECC P-256/Curve25519
• Padding: RSA-OAEP para cifrado, RSA-PSS para firma
• TLS: versión 1.2 mínimo, 1.3 recomendado; deshabilitar versiones antiguas
• Certificados: emitidos por CA reconocida, renovación automatizada (Let's Encrypt + Certbot)
• Almacenamiento de clave privada: cifrada, fuera del repositorio, acceso mínimo
• Rotación: política definida y automatizada
• Revocación: OCSP Stapling habilitado
• Pruebas: incluir casos de fallo criptográfico en la suite de tests
• Auditoría: revisar configuración con herramientas como ssl-labs, testssl.sh