Criptografía: guía completa aplicada a la ciberseguridad (2026)

La criptografía es la disciplina que permite comunicar y almacenar información de forma que solo quien tiene la clave adecuada puede leerla. Lleva con nosotros desde el cifrado de sustitución del César hasta los algoritmos que protegen hoy las transacciones bancarias, los mensajes de WhatsApp y las conexiones a cualquier web con HTTPS. En ciberseguridad, la criptografía no es un complemento: es la base sobre la que se construyen la confidencialidad, la integridad y la autenticación de prácticamente todos los sistemas digitales.

Esta guía cubre el tema de principio a fin: qué problemas resuelve la criptografía, cómo funcionan los algoritmos más importantes (con la suficiente profundidad técnica para entenderlos de verdad, no solo nombrarlos), cómo se aplica en la práctica en TLS, VPN, mensajería cifrada y cifrado en reposo, y qué está cambiando con la llegada de la computación cuántica. Si quieres entender por qué la criptografía importa en ciberseguridad — y no solo de oídas — estás en el lugar correcto.

Qué es la criptografía y qué problemas resuelve

La palabra viene del griego kryptós (oculto) y gráphein (escribir). En la práctica moderna, la criptografía es la ciencia de construir y analizar algoritmos matemáticos que transforman información de modo que cumpla cuatro propiedades de seguridad fundamentales:

• Confidencialidad: solo quien tiene la clave puede leer el mensaje. Nadie más, aunque lo intercepte.
• Integridad: cualquier modificación del mensaje — aunque sea de un solo bit — es detectable. No puedes alterar datos sin que la verificación falle.
• Autenticación: podemos verificar la identidad del origen. El mensaje viene de quien dice venir, no de un impostor.
• No repudio: quien firmó un documento no puede negar haberlo hecho. La firma digital es jurídicamente vinculante precisamente porque la criptografía lo garantiza.

Cada mecanismo criptográfico ataca uno o varios de estos cuatro problemas. El cifrado simétrico resuelve la confidencialidad. Las funciones hash garantizan la integridad. Las firmas digitales dan autenticación y no repudio. La infraestructura de clave pública (PKI) combina todo para que puedas confiar en un servidor que nunca has visto antes.

Hay una distinción clave entre criptografía (la ciencia de construir esos mecanismos) y criptoanálisis (la ciencia de romperlos). La criptología engloba ambas. Cuando un algoritmo es considerado seguro, significa que los mejores criptoanalistas del mundo no han encontrado una forma práctica de romperlo — no que sea imposible en teoría.

Un principio fundacional, formulado por Auguste Kerckhoffs en 1883 y conocido como principio de Kerckhoffs, establece que la seguridad de un sistema criptográfico debe depender únicamente del secreto de la clave, nunca del secreto del algoritmo. Todos los algoritmos que se usan en la práctica moderna (AES, RSA, ECC, SHA-256…) son públicos y han sido analizados durante décadas. Su fortaleza no viene de que nadie los conoce, sino de que con la clave correcta la única forma de romperlos es por fuerza bruta.

Cifrado simétrico: AES y sus modos de operación

En el cifrado simétrico (también llamado de clave secreta o de clave compartida), emisor y receptor comparten la misma clave. La misma clave que cifra, descifra. Es el tipo de cifrado más rápido y adecuado para proteger grandes volúmenes de datos.

Cómo funciona AES

AES (Advanced Encryption Standard) es el algoritmo simétrico estándar desde que el NIST lo seleccionó en 2001 a partir del algoritmo Rijndael, diseñado por Joan Daemen y Vincent Rijmen. Opera sobre bloques de 128 bits de datos y admite claves de 128, 192 o 256 bits. La diferencia entre ellos es el número de rondas de transformación: 10, 12 y 14 respectivamente. AES-256 es el más común en contextos de alta seguridad.

Internamente, AES transforma el bloque de datos mediante cuatro operaciones que se repiten en cada ronda:

1. SubBytes: cada byte del bloque se sustituye por otro valor según una tabla fija (S-Box), que introduce no-linealidad al sistema — lo que hace que romper el cifrado por álgebra sea extremadamente difícil.
2. ShiftRows: las filas del bloque se desplazan cíclicamente, lo que mezcla los bytes entre sí.
3. MixColumns: cada columna se multiplica por una matriz fija en el campo GF(2⁸). Esto asegura la difusión: un bit de entrada afecta a varios bytes de salida.
4. AddRoundKey: el bloque se combina mediante XOR con la subclave de esa ronda, que se deriva de la clave original mediante un proceso llamado key schedule.

El resultado es que cada bit del texto cifrado depende de todos los bits de la clave y de todos los bits del texto original (propiedades de confusión y difusión que describió Claude Shannon). No existe ataque práctico conocido contra AES bien implementado: el mejor ataque teórico contra AES-128 requiere 2^126,1 operaciones, lo que lo hace computacionalmente irrompible con tecnología actual.

Modos de operación

AES es un cifrado de bloque: opera sobre bloques de 128 bits. Pero los mensajes reales rara vez miden exactamente 128 bits. Los modos de operación definen cómo se encadena AES para cifrar datos de longitud arbitraria:

• ECB (Electronic Codebook): cada bloque se cifra de forma independiente con la misma clave. No lo uses nunca: bloques de texto idéntico producen bloques cifrados idénticos, lo que filtra información estructural del mensaje (el «pingüino de ECB» es el ejemplo clásico).
• CBC (Cipher Block Chaining): cada bloque de texto claro se combina con el bloque cifrado anterior antes de cifrarse. Necesita un vector de inicialización (IV) aleatorio para el primer bloque. Fue el estándar durante muchos años, pero su naturaleza secuencial (no paralelizable) y vulnerabilidades como BEAST o POODLE lo han desplazado en protocolos modernos.
• CTR (Counter): convierte AES en un cifrado de flujo: cifra un contador incremental con la clave y hace XOR del resultado con el texto. Es paralelizable y sin vulnerabilidades de CBC. Es la base de GCM.
• GCM (Galois/Counter Mode): combina CTR para cifrar y un código de autenticación de mensajes (GHASH) para verificar integridad. Produce un AEAD (Authenticated Encryption with Associated Data): cifra y autentica en una sola operación. AES-256-GCM es el modo recomendado hoy: es el que usa TLS 1.3, SSH moderno y el almacenamiento cifrado de la mayoría de sistemas modernos. Si usas AES, usa GCM.

El problema del intercambio de claves

El gran talón de Aquiles del cifrado simétrico es que emisor y receptor deben compartir la misma clave de antemano. ¿Cómo la intercambian sin que nadie la intercepte? Esta pregunta parecía irresolvable hasta 1976, cuando Diffie y Hellman publicaron el concepto de clave pública, y hasta que RSA mostró cómo implementarlo. El cifrado asimétrico resuelve exactamente este problema.

Cifrado asimétrico: clave pública y privada

El cifrado asimétrico (o de clave pública) usa un par de claves matemáticamente relacionadas: una clave pública que cualquiera puede conocer y una clave privada que solo el propietario conoce. Lo que se cifra con una, solo se puede descifrar con la otra. Y derivar la clave privada a partir de la pública es computacionalmente inviable (con la tecnología actual).

RSA: factorización de números grandes

RSA (Rivest–Shamir–Adleman, 1977) basa su seguridad en la dificultad de factorizar el producto de dos números primos grandes. Su funcionamiento simplificado:

1. Se eligen dos números primos grandes p y q (en la práctica, de 1024-4096 bits cada uno).
2. Se calcula n = p × q. Este es el módulo público.
3. Se elige un exponente público e (habitualmente 65537, un primo de Fermat).
4. La clave pública es el par (n, e). La clave privada es d, el inverso multiplicativo de e módulo φ(n) = (p-1)(q-1).
5. Cifrar: C = M^e mod n. Descifrar: M = C^d mod n.

Quien tiene n pero no conoce p ni q no puede calcular d, porque factorizar n (producto de dos primos grandes) no se puede hacer en tiempo razonable con algoritmos clásicos. Para RSA, se recomienda hoy una longitud de clave mínima de 2048 bits, siendo preferible 3072 o 4096 bits para contextos de alta seguridad y largo plazo.

RSA no se usa para cifrar grandes volúmenes de datos (es lento y su texto cifrado es del tamaño de la clave). Se usa para cifrar claves simétricas o para firmas digitales. En TLS, por ejemplo, RSA o ECDHE se usa para que las dos partes acuerden una clave simétrica de sesión; a partir de ahí, AES-GCM cifra los datos reales.

ECC: curvas elípticas

ECC (Elliptic Curve Cryptography, criptografía de curva elíptica) basa su seguridad en la dificultad del problema del logaritmo discreto en una curva elíptica (ECDLP). Una curva elíptica es una ecuación de la forma y² = x³ + ax + b sobre un campo finito; el «punto» en la curva tiene propiedades algebraicas especiales que permiten construir sistemas de clave pública con claves mucho más cortas que RSA para el mismo nivel de seguridad.

La comparación es brutal: una clave ECC de 256 bits proporciona seguridad comparable a RSA de 3072 bits. Una clave de 384 bits equivale a RSA de 7680 bits. Esto significa claves más pequeñas, operaciones más rápidas y menor consumo energético — fundamental en dispositivos móviles e IoT.

Las curvas más usadas en la práctica son:

• P-256 (secp256r1 / prime256v1): la más común en TLS y certificados web.
• P-384: para entornos que requieren mayor seguridad (por ejemplo, ciertos estándares gubernamentales).
• Curve25519 / X25519: diseñada por Daniel Bernstein para ser segura por construcción y resistente a implementaciones débiles. Es la base del protocolo de intercambio de claves que usan Signal, WhatsApp y TLS 1.3 con ECDHE.

ECDSA (Elliptic Curve Digital Signature Algorithm) es el equivalente de RSA para firmas, pero con claves mucho más cortas. EdDSA (con la variante Ed25519) es más moderna, más rápida y más difícil de implementar incorrectamente que ECDSA.

Diffie-Hellman y el intercambio de claves

El protocolo Diffie-Hellman (DH) permite a dos partes acordar un secreto compartido a través de un canal público sin que nadie que intercepte la comunicación pueda calcularlo. La versión moderna sobre curvas elípticas se llama ECDHE (Elliptic Curve Diffie-Hellman Ephemeral), donde «ephemeral» significa que se genera un par de claves nuevo para cada sesión. Esto otorga Perfect Forward Secrecy (PFS): aunque se comprometa la clave privada del servidor en el futuro, las sesiones pasadas siguen siendo secretas.

TLS 1.3 hace obligatorio el uso de ECDHE con PFS — eliminó los modos de intercambio de claves estáticas que existían en versiones anteriores.

Funciones hash criptográficas

Una función hash criptográfica transforma una entrada de longitud arbitraria en una salida de longitud fija (el digest o resumen), con tres propiedades fundamentales:

1. Resistencia a preimagen: dado un hash h, es computacionalmente inviable encontrar un mensaje m tal que hash(m) = h. No puedes «invertir» el hash.
2. Resistencia a segunda preimagen: dado un mensaje m1, es inviable encontrar un mensaje distinto m2 con el mismo hash.
3. Resistencia a colisiones: es inviable encontrar cualquier par de mensajes distintos m1 y m2 con el mismo hash.

SHA-2 y SHA-3

La familia SHA-2 (Secure Hash Algorithm 2), publicada por el NIST, incluye las variantes más utilizadas en la práctica: SHA-256 (256 bits de salida), SHA-384 y SHA-512. SHA-256 es el estándar de facto para la gran mayoría de aplicaciones: integridad de archivos, certificados TLS, blockchain, firmas digitales, HMAC. SHA-512 se usa cuando se necesita mayor seguridad o cuando el rendimiento en arquitecturas de 64 bits es crítico.

SHA-3 (aprobado por el NIST en 2015) utiliza una construcción completamente distinta a SHA-2 (la esponja Keccak en vez de la construcción Merkle-Damgård). No es una mejora de SHA-2 ni lo reemplaza; es un algoritmo independiente, diseñado como alternativa en caso de que SHA-2 resultara vulnerable. SHA-2 sigue siendo seguro y es el estándar recomendado para uso general. SHA-3 existe como respaldo arquitectónico si SHA-2 fuera comprometido.

Para qué SÍ sirve un hash (y para qué NO)

Sirve para:

• Verificar integridad: si descargas un archivo y el hash coincide con el publicado por el fabricante, no ha sido manipulado en tránsito.
• Firmas digitales: en vez de firmar todo el mensaje (lento), se firma su hash (rápido). Si el hash es válido, el mensaje es auténtico.
• Almacenamiento de contraseñas — con matices importantes (ver abajo).
• HMAC: Message Authentication Code basado en hash; combina un hash con una clave secreta para autenticar mensajes.

No sirve para:

• Cifrar datos: el hash no es reversible a partir de la clave, y no hay clave. No confundas cifrado y hashing.
• Proteger contraseñas directamente con SHA-256: las GPUs modernas calculan miles de millones de hashes SHA-256 por segundo. Una contraseña hasheada con SHA-256 sin más puede crackearse por fuerza bruta o tablas rainbow en minutos.

Salting y algoritmos de derivación de claves para contraseñas

Para almacenar contraseñas de forma segura, nunca se usa SHA-256 directamente. Se usan algoritmos diseñados específicamente para ser lentos y resistentes a ataques de diccionario y fuerza bruta:

• bcrypt: algoritmo de 1999 con un factor de coste ajustable. A mayor coste, más lento es computar el hash (y más difícil para el atacante). Sigue siendo válido y ampliamente usado.
• scrypt: además de ser costoso en CPU, requiere mucha memoria, lo que defiende contra ataques con ASIC y GPU de alta gama.
• Argon2: ganador del Password Hashing Competition (2015). Tiene variantes para optimizar uso de CPU (Argon2d), uso de memoria (Argon2i) o ambos (Argon2id, la recomendada). Es la opción más moderna y recomendada hoy.

El salt es un valor aleatorio único generado para cada usuario que se combina con la contraseña antes de hashear. Su función es que aunque dos usuarios tengan la misma contraseña, sus hashes sean distintos, lo que invalida las tablas rainbow (que precomputan hashes de contraseñas comunes sin salt). El salt no es secreto: se almacena junto al hash y solo sirve para asegurar unicidad.

Firmas digitales

Una firma digital es el equivalente criptográfico de una firma manuscrita, pero con garantías mucho más fuertes. No es una imagen de una firma; es una transformación matemática que prueba que quien posee una clave privada concreta firmó un mensaje concreto.

El proceso funciona así:

1. Alice calcula el hash del mensaje (por ejemplo, SHA-256 del documento).
2. Alice cifra ese hash con su clave privada. El resultado es la firma digital.
3. Alice envía el mensaje + la firma.
4. Bob calcula el hash del mensaje recibido y descifra la firma con la clave pública de Alice.
5. Si ambos hashes coinciden, la firma es válida: el mensaje viene de Alice (autenticación) y no ha sido modificado (integridad), y Alice no puede negar haberlo firmado (no repudio).

Los algoritmos más usados para firmas son:

• RSA-PKCS1v1.5: el más antiguo; considerado seguro pero con padding propensa a errores de implementación. Usar RSA-PSS en su lugar.
• RSA-PSS: variante más segura de RSA para firmas. Recomendado sobre PKCS1v1.5.
• ECDSA con P-256 o P-384: estándar en TLS y código signing. Sensible a la calidad del número aleatorio usado en la firma — una mala implementación puede filtrar la clave privada.
• Ed25519 (EdDSA): más rápido y más seguro de implementar que ECDSA. No depende de un número aleatorio en la firma (usa hashing determinista). Recomendado para nuevas implementaciones.

PKI, certificados digitales y autoridades de certificación

El cifrado asimétrico resuelve el problema del intercambio de claves, pero crea uno nuevo: ¿cómo sé que la clave pública que me has mandado es realmente tuya y no de un atacante que se interpuso en la comunicación (ataque man-in-the-middle)?

La respuesta es la Infraestructura de Clave Pública (PKI, Public Key Infrastructure). Una Autoridad de Certificación (CA) es una entidad de confianza que firma con su propia clave privada un certificado digital que vincula una clave pública a una identidad (un dominio, una empresa, una persona). El certificado sigue el estándar X.509.

Un certificado X.509 contiene, entre otros campos:

• La clave pública del titular.
• La identidad del titular (Common Name, organización, país…).
• El período de validez (fechas de emisión y expiración).
• El nombre de la CA que lo firmó.
• La firma digital de la CA sobre todos los campos anteriores.

Cuando tu navegador se conecta a https://banco.com, el servidor envía su certificado. Tu navegador verifica que:

1. La firma de la CA es válida (tiene la clave pública de la CA en su almacén de CAs raíz de confianza).
2. El certificado no ha expirado.
3. El certificado no ha sido revocado (via CRL o OCSP).
4. El nombre del certificado coincide con el dominio al que te has conectado.

Las CAs se organizan en una cadena de confianza jerárquica. Las CAs raíz (Mozilla, DigiCert, Google Trust Services, Let’s Encrypt…) son las que están preinstaladas en el sistema operativo y los navegadores. Pueden emitir certificados para CAs intermedias, que a su vez emiten certificados para dominios. La revocación funciona via CRL (Certificate Revocation List, lista de certificados revocados) o OCSP (Online Certificate Status Protocol, que permite consultar el estado de un certificado en tiempo real).

En entornos corporativos, las organizaciones despliegan su propia PKI privada: una CA interna cuyos certificados se distribuyen a los dispositivos gestionados de la empresa. Esto permite cifrar el tráfico interno, autenticar dispositivos y firmar código o documentos de forma controlada.

Cómo funciona TLS/HTTPS paso a paso

TLS (Transport Layer Security) es el protocolo que protege la mayoría del tráfico en internet: HTTPS, SMTP con STARTTLS, IMAP, las APIs de cualquier servicio web. Cuando ves el candado en el navegador, TLS está funcionando. Aquí desglosamos qué ocurre durante un handshake TLS 1.3 (la versión actual):

1. ClientHello: el navegador envía al servidor qué versiones de TLS soporta, qué algoritmos de cifrado (cipher suites) soporta y una cadena aleatoria (client random). También envía su clave pública efímera ECDHE.
2. ServerHello: el servidor elige la cipher suite (en TLS 1.3, por ejemplo, TLS_AES_256_GCM_SHA384), envía su propia clave pública efímera ECDHE y su certificado X.509.
3. Acuerdo de clave: con el par de claves efímeras ECDHE, ambas partes calculan independientemente el mismo secreto compartido (Diffie-Hellman). De este secreto se derivan las claves simétricas de la sesión.
4. Fin del handshake: servidor y cliente se envían mensajes Finished cifrados con las claves derivadas, que verifican que el handshake no fue manipulado.
5. Transferencia de datos: todos los datos se cifran con AES-256-GCM (u otro AEAD acordado). El candado en el navegador indica que estás en este punto.

TLS 1.3 (RFC 8446, 2018) elimina algoritmos inseguros del pasado (RC4, 3DES, RSA estático sin PFS, DH <1024 bits), requiere ECDHE, hace PFS obligatorio y reduce el handshake a 1 round-trip (antes eran 2 en TLS 1.2). Si tu servidor todavía acepta TLS 1.0 o 1.1, deberías deshabilitarlos — son obsoletos y vulnerables a ataques como POODLE y BEAST.

Para profundizar en cómo los atacantes explotan fallos en implementaciones TLS y cómo proteger aplicaciones web, consulta nuestra guía hacking web: guía completa.

Cifrado en reposo vs. cifrado en tránsito

Son dos tipos distintos de protección que se aplican en momentos distintos del ciclo de vida de un dato.

Cifrado en tránsito

Protege los datos mientras se mueven de un punto a otro: navegador a servidor, entre servicios en la nube, entre oficinas. TLS es el mecanismo más común. Si los datos viajan sin cifrado (HTTP en vez de HTTPS, FTP en vez de SFTP), cualquier actor con acceso a la red en el camino — un router comprometido, un punto de acceso WiFi malicioso, un ISP — puede leerlos o modificarlos.

Cifrado en reposo

Protege los datos mientras están almacenados: en un disco duro, en una base de datos, en almacenamiento en la nube. Si un atacante roba el disco o accede al almacenamiento físico, los datos cifrados son inútiles sin la clave.

Puede aplicarse a varios niveles:

• Full-disk encryption (FDE): cifra todo el disco a nivel de dispositivo. Windows usa BitLocker (AES-XTS-256), Linux usa LUKS, macOS usa FileVault. Si alguien roba un portátil, no puede leer los datos sin la clave de cifrado.
• Cifrado a nivel de sistema de archivos o carpeta: solo se cifran ciertas carpetas o archivos. Más granular, pero no protege contra un atacante con acceso mientras el sistema está en marcha.
• Cifrado de bases de datos: puede ser TDE (Transparent Data Encryption, que cifra los archivos en disco pero no las queries en memoria) o cifrado a nivel de columna (más granular).
• Cifrado a nivel de aplicación: la aplicación cifra los datos antes de almacenarlos. El proveedor de almacenamiento (aunque sea en la nube) nunca ve los datos en claro. Es el modelo de los servicios zero-knowledge.

Una falacia común es pensar que basta con el cifrado en tránsito. Si los datos llegan cifrados al servidor y éste los descifra para procesarlos, un atacante con acceso al servidor ve los datos en claro. Y a la inversa: el cifrado en reposo solo protege contra robo físico del medio de almacenamiento — no contra un atacante que ya ha comprometido el sistema en ejecución.

Para un análisis más detallado de cómo gestionar el cifrado en entornos cloud, consulta nuestra guía sobre seguridad en la nube: guía completa.

Gestión de claves criptográficas

La criptografía es tan segura como las claves que usa. Un algoritmo perfectamente implementado es inútil si las claves se gestionan mal. La gestión de claves (key management) cubre su generación, distribución, almacenamiento, rotación y destrucción.

Generación de claves

Las claves deben generarse con un generador de números aleatorios criptográficamente seguro (CSPRNG: Cryptographically Secure Pseudo-Random Number Generator). En sistemas Unix: /dev/urandom o la llamada al sistema getrandom(). En Windows: BCryptGenRandom. La entropía (aleatoriedad real) proviene de fuentes de ruido del hardware: tiempos de interrupción, movimiento del ratón, tráfico de red, ruido térmico. Nunca usar funciones de números aleatorios genéricas (como rand() en C) para generar claves criptográficas.

Almacenamiento y HSM

Las claves no deben almacenarse en texto plano. Las opciones más seguras:

• HSM (Hardware Security Module): módulo físico certificado (FIPS 140-2 o FIPS 140-3) que almacena claves en hardware resistente a manipulaciones. Las claves nunca salen del HSM en claro; el HSM realiza las operaciones criptográficas internamente. Lo usan bancos, CAs y entornos de alta seguridad. También existen servicios HSM en la nube (AWS CloudHSM, Azure Dedicated HSM).
• KMS en la nube (AWS KMS, Azure Key Vault, Google Cloud KMS): servicios gestionados que almacenan y controlan el acceso a las claves. Más accesibles que un HSM propio, con auditoría completa de cada operación.
• Keystores seguros del sistema operativo: Windows Credential Manager, macOS Keychain, GNOME Keyring. Adecuados para claves de aplicación en dispositivos de usuario final.

Rotación y ciclo de vida

Las claves tienen un período de vida útil limitado. Rotar las claves periódicamente limita el daño si una clave es comprometida: solo los datos cifrados con esa clave están en riesgo, no todos los datos pasados. El estándar NIST SP 800-57 establece guías sobre el período máximo de uso de cada tipo de clave. Por ejemplo, claves de cifrado de datos deben rotarse al menos cada 2 años; claves de firma de código, anualmente.

La destrucción segura de claves (crypto-shredding) es tan importante como su generación: si destruyes las claves de cifrado de datos que ya no necesitas, esos datos se vuelven irrecuperables — útil para RGPD, donde «eliminar» datos cifrados puede cumplirse destruyendo sus claves.

Criptografía aplicada: VPN, Signal y mensajería E2E

VPN: cifrado de red

Una VPN (Virtual Private Network) crea un túnel cifrado entre dos puntos de la red. Los dos protocolos más relevantes desde el punto de vista criptográfico son:

• IPsec: protocolo estándar IETF que opera en la capa de red. Usa AES para cifrar (típicamente AES-256-GCM) y RSA o ECDSA para autenticar. Se usa mucho en VPNs corporativas site-to-site.
• WireGuard: protocolo moderno (2020, RFC 9276 vía su inclusión en Linux kernel 5.6) que usa Curve25519 para intercambio de claves, ChaCha20-Poly1305 para cifrado y BLAKE2s para hashing. Su código es extremadamente pequeño (~4.000 líneas vs ~400.000 de OpenVPN), auditado y considerado más seguro por diseño que OpenVPN.

OpenVPN sigue siendo muy extendido y usa TLS para el canal de control, pero WireGuard está ganando terreno rápidamente por su simplicidad, rendimiento y seguridad.

Signal y el cifrado extremo a extremo

El cifrado extremo a extremo (E2E) significa que el mensaje solo puede leerlo el destinatario: ni el servidor que lo transmite, ni el proveedor del servicio tienen acceso al contenido. WhatsApp, Signal y iMessage (en parte) usan E2E.

Signal es el protocolo más estudiado y copiado del sector. Su stack criptográfico en detalle:

• X3DH (Extended Triple Diffie-Hellman): protocolo de establecimiento de sesión inicial que permite iniciar un chat cifrado con alguien sin que ambos estén en línea al mismo tiempo. Usa múltiples pares de claves Curve25519 (clave de identidad, signed prekey, one-time prekeys).
• Double Ratchet Algorithm: una vez establecida la sesión, cada mensaje usa una clave derivada con un doble mecanismo de actualización: un ratchet Diffie-Hellman y un ratchet de cadena simétrica. El resultado es que cada mensaje usa una clave diferente, y comprometer una clave no compromete los mensajes pasados ni los futuros. Esto es forward secrecy (equivalente a PFS en TLS) y break-in recovery combinados.
• AES-256-CBC + HMAC-SHA256 para el cifrado del cuerpo del mensaje, o ChaCha20-Poly1305 según la implementación.

El protocolo Signal es de código abierto, ha sido auditado múltiples veces por investigadores académicos y no se ha encontrado ninguna vulnerabilidad criptográfica de diseño.

Criptografía post-cuántica: la mayor amenaza en el horizonte

Un ordenador cuántico suficientemente potente (con millones de qubits estables, que hoy no existen) podría romper los algoritmos asimétricos actuales en tiempo polinomial usando el algoritmo de Shor (1994). En concreto:

• RSA y Diffie-Hellman se basan en la dificultad de factorizar o calcular logaritmos discretos en enteros. Shor los resuelve eficientemente en un ordenador cuántico.
• ECC se basa en logaritmos discretos en curvas elípticas. También vulnerable a Shor.
• AES-256 es mucho más resistente: el algoritmo de Grover reduciría su seguridad efectiva de 256 a 128 bits (cuadrado de la búsqueda), lo que hace recomendable usar AES-256 en vez de AES-128 en entornos que requieran resistencia cuántica, pero no lo rompe.
• SHA-256/SHA-3 también degradan algo su resistencia ante ataques cuánticos con Grover, pero siguen siendo seguros con longitudes actuales.

La amenaza no es para mañana: los ordenadores cuánticos actuales (2026) tienen unos pocos miles de qubits físicos con tasas de error muy altas, muy lejos de los millones de qubits lógicos que necesitaría Shor para romper RSA-2048. Pero el riesgo de «harvest now, decrypt later» es real y urgente: un adversario puede grabar hoy el tráfico cifrado con RSA y descifrarlo en el futuro cuando tenga la capacidad cuántica. Para datos sensibles con ciclo de vida largo (secretos de Estado, datos médicos, propiedad intelectual estratégica), la transición a algoritmos post-cuánticos es una prioridad.

Los estándares NIST PQC (finalizados en agosto de 2024)

El NIST inició en 2016 un proceso de estandarización de algoritmos resistentes a ataques cuánticos. En agosto de 2024 publicó los primeros tres estándares finales:

• FIPS 203 — ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism, basado en Kyber): algoritmo para encapsulamiento de claves (KEM, el equivalente post-cuántico del intercambio de claves asimétrico). Es el mecanismo recomendado para sustituir el intercambio de claves RSA/ECDH. Se basa en el problema de aprendizaje con errores sobre módulos (Module-LWE, un problema de retículas que no tiene solución eficiente conocida en ordenadores cuánticos ni clásicos).
• FIPS 204 — ML-DSA (Module-Lattice-Based Digital Signature Algorithm, basado en Dilithium): algoritmo de firma digital basado también en retículas. Diseñado para sustituir RSA y ECDSA en firmas. Ofrece claves y firmas más grandes que Ed25519, pero con seguridad post-cuántica.
• FIPS 205 — SLH-DSA (Stateless Hash-Based Digital Signature Algorithm, basado en SPHINCS+): algoritmo de firma basado en funciones hash (no en retículas). Su seguridad solo depende de la resistencia criptográfica de las funciones hash que usa (SHA-256/SHA-3), que son bien comprendidas. Es más lento que ML-DSA pero ofrece una base criptográfica completamente distinta — útil como alternativa en caso de que se encontrara un fallo en los algoritmos de retículas.

También hay un cuarto estándar en preparación: FIPS 206 — FN-DSA (basado en FALCON), para firmas con firmas más compactas que ML-DSA, aunque más complejas de implementar de forma segura.

La transición no es sencilla. Los algoritmos post-cuánticos tienen claves y firmas más grandes (por ejemplo, una clave pública ML-KEM-768 ocupa 1.184 bytes frente a los 65 bytes de una clave pública P-256), lo que impacta en el rendimiento de los handshakes TLS y en el tamaño de los certificados. La estrategia recomendada mientras avanza la transición es la hibridación: usar simultáneamente un algoritmo clásico (ECDHE) y uno post-cuántico (ML-KEM), de forma que el canal sea seguro incluso si uno de los dos falla. Chrome, Firefox, Cloudflare y muchos servidores ya han implementado X25519+ML-KEM en TLS de forma experimental.

Si tu organización maneja datos sensibles con un ciclo de vida superior a 5-10 años, el inventario criptográfico (qué algoritmos usa cada sistema) y la hoja de ruta de migración a PQC son tareas que deberían comenzar ahora.

Errores comunes y qué nunca debes hacer

Implementar criptografía a mano es una de las actividades más peligrosas en seguridad. Los errores no suelen ser visibles hasta que alguien los explota. Estos son los fallos más frecuentes y costosos:

No inventes tu propio cifrado

El error fundamental, tan extendido que merece ser el primero. Diseñar tu propio algoritmo de cifrado o tu propio protocolo criptográfico sin ser un criptógrafo experto es garantía de fallos. La criptografía moderna ha tardado décadas en madurar; los algoritmos estándar han sido analizados por miles de investigadores durante años. Usa AES-GCM, usa TLS, usa librerías auditadas. No reinventes la rueda.

Reutilizar IVs y nonces

En GCM, reutilizar el mismo IV (nonce) con la misma clave es catastrófico: permite al atacante recuperar la clave de autenticación y falsificar mensajes. Cada operación de cifrado debe usar un IV o nonce único, generado aleatoriamente o con un contador. Este error tumbó la seguridad de varios sistemas reales, incluyendo WPA2 (KRACK attack, 2017).

Almacenar contraseñas con MD5 o SHA-1

MD5 y SHA-1 son algoritmos rápidos diseñados para integridad, no para contraseñas. Una GPU moderna puede calcular decenas de miles de millones de hashes MD5 por segundo. Usar bcrypt, scrypt o Argon2id — nunca MD5, SHA-1 ni SHA-256 directamente para contraseñas.

No validar certificados

Código que desactiva la verificación de certificados TLS («ssl_verify=False», «InsecureSkipVerify=true») porque «es más fácil para el desarrollo» y acaba en producción. Sin validación de certificados, TLS no proporciona autenticación: cualquiera puede presentar un certificado falso y el código lo aceptará. Es el mismo riesgo que comunicarse sin cifrado.

Cifrado de libro de códigos (ECB)

Ya mencionado: nunca usar AES-ECB para cifrar datos reales. La estructura del texto claro queda visible en el texto cifrado.

Claves hardcodeadas

Incrustar claves criptográficas o contraseñas directamente en el código fuente es uno de los vectores de compromiso más comunes. Los repositorios de código (incluso privados) se filtran, se hacen públicos por error, o los accede alguien no autorizado. Las claves deben vivir en variables de entorno, en gestores de secretos (Vault, AWS Secrets Manager, Azure Key Vault) o en HSMs, nunca en el código.

Algoritmos obsoletos

RC4 (roto desde 2001, prohibido en TLS por RFC 7465), 3DES (retirado de TLS, vulnerable a SWEET32), DES (56 bits, roto en 1999), MD5 para firmas (colisiones prácticas desde 2004), SHA-1 para certificados (colisiones prácticas desde 2017). Si cualquiera de estos aparece en tu sistema, es deuda técnica urgente.

Criptografía aplicada en ciberseguridad: casos de uso concretos

La criptografía no es solo un tema teórico — aparece en cada capa de la seguridad:

• Autenticación sin contraseña: FIDO2/WebAuthn usa un par de claves asimétrico por dispositivo y sitio. La clave privada nunca sale del dispositivo (almacenada en chip TPM o Secure Enclave); el servidor solo guarda la clave pública. Es inmune al phishing y al robo de base de datos de contraseñas.
• SSH: el acceso seguro a servidores usa pares de claves RSA/ECDSA/Ed25519. La clave pública se instala en el servidor; la clave privada la guarda el usuario. El servidor nunca ve la clave privada. Puedes ver cómo se aplica esto en administración de sistemas en nuestra guía cómo empezar en ciberseguridad desde cero.
• Código signing: las actualizaciones de software llevan una firma digital del fabricante. Tu sistema verifica la firma antes de instalar: si alguien modificó el paquete, la firma falla y la instalación se rechaza. Crítico para la cadena de suministro de software.
• PGP/GPG: estándar de cifrado y firma de email y archivos. Usa RSA o ECC para clave asimétrica y AES para el cuerpo del mensaje. La red de confianza (web of trust) es una alternativa descentralizada a la PKI.
• Blockchain: usa firmas digitales ECDSA para autorizar transacciones y funciones hash SHA-256 para el encadenamiento de bloques. La inmutabilidad del blockchain viene directamente de las propiedades de las funciones hash.
• Cifrado de disco en endpoints: BitLocker, FileVault, LUKS protegen los datos de usuarios si el dispositivo se pierde o roba. En un entorno corporativo, la gestión centralizada de claves (escrow) es crítica para evitar que un empleado que olvida su PIN bloquee el acceso corporativo.

Para entender cómo los atacantes explotan fallos criptográficos en aplicaciones web (padding oracles, BEAST, POODLE, JWT none algorithm…), consulta nuestra guía de hacking web. Para cómo proteger la infraestructura cloud, la guía de seguridad en la nube.

Cómo aprender criptografía en la práctica

La criptografía es un campo vasto: si quieres entenderla a fondo, necesitas combinar teoría matemática con práctica de implementación y análisis de fallos reales. Una hoja de ruta razonable:

Fundamentos teóricos

El libro de referencia accesible es Serious Cryptography de Jean-Philippe Aumasson (No Starch Press, 2017): cubre los algoritmos actuales con profundidad matemática sin requerir un doctorado. Para una introducción más ligera, el Crypto 101 de Laurens Van Houtven es gratuito y explica los fundamentos desde cero. Para la matemática profunda, el clásico es Introduction to Modern Cryptography de Katz y Lindell.

Práctica y retos

• Cryptopals Challenges (cryptopals.com): 8 sets de retos prácticos que enseñan criptografía implementando ataques reales. Empiezas rompiendo ECB y terminas atacando protocolos de cifrado de flujo y MAC. Es la forma más efectiva de entender por qué no debes inventar tu propio cifrado.
• CryptoHack (cryptohack.org): plataforma gamificada con retos de criptografía en Python, desde básico hasta avanzado. Cubre RSA, ECC, difusión, modos de operación y más.
• CTF competitions: los CTFs (Capture the Flag) tienen habitualmente una categoría de criptografía donde se practican ataques a implementaciones reales.

Librerías y herramientas

Para implementar criptografía en código, usa siempre librerías auditadas:

• libsodium: librería en C con bindings para prácticamente todos los lenguajes, con APIs de alto nivel que hacen difícil cometer los errores más comunes. Diseñada por Daniel Bernstein.
• Python cryptography: el paquete cryptography (PyCA) es el estándar para Python. Usa OpenSSL bajo el capó pero expone una API de alto nivel.
• BouncyCastle (Java/.NET), Go crypto stdlib (Go), WebCrypto API (JavaScript en navegador): cada ecosistema tiene sus librerías auditadas.

Certificaciones relevantes

Si quieres acreditar conocimientos de criptografía aplicada a la seguridad, las certificaciones más relevantes son el mapa de certificaciones de ciberseguridad te da la visión completa. CISSP cubre criptografía en su dominio de arquitectura de seguridad. CompTIA Security+ incluye una sección de criptografía. Para profundidad en criptografía pura, la certificación SANS/GIAC tiene el SEC504 y el FOR610 que incluyen análisis forense de implementaciones criptográficas. Ver también nuestros mejores cursos gratuitos de ciberseguridad para recursos accesibles.

Recursos y guías relacionadas

La criptografía es la base de la seguridad digital, pero es solo uno de los pilares que necesitas dominar para trabajar en ciberseguridad. Nuestras guías del sector completan la visión:

• Cómo empezar en ciberseguridad desde cero — orientación completa para quien empieza, con rutas de aprendizaje y primeras certificaciones.
• Hacking web: guía completa — vulnerabilidades web, OWASP Top 10, explotación práctica.
• Seguridad en la nube: guía completa — cifrado, IAM, cumplimiento y seguridad en AWS, Azure y GCP.
• Mejores cursos gratuitos de ciberseguridad — plataformas y recursos sin coste para aprender.
• Mapa de certificaciones de ciberseguridad — todas las certificaciones por nivel y especialidad.
• Todas las guías de ciberseguridad — catálogo completo de guías del sitio.

Preguntas frecuentes sobre criptografía

¿Es lo mismo cifrado que criptografía?

No. La criptografía es la disciplina completa (cifrado, hashing, firmas, protocolos). El cifrado es solo la parte que transforma datos para mantenerlos confidenciales. El hashing, por ejemplo, no cifra: genera una huella digital del mensaje que no puede revertirse.

¿Puede descifrarse AES-256 con un ordenador cuántico?

No en el sentido práctico. El algoritmo de Grover reduce la seguridad efectiva de AES-256 de 256 bits a 128 bits, pero 128 bits siguen siendo suficientes para resistir cualquier ataque foreseeable — incluyendo el cuántico. AES-128 pasaría a tener seguridad efectiva de 64 bits, lo que podría ser insuficiente en el futuro. Por eso se recomienda AES-256 para datos sensibles a largo plazo.

¿Por qué no se usa siempre cifrado asimétrico para todo?

Porque es entre 100 y 10.000 veces más lento que el cifrado simétrico para volúmenes grandes de datos. RSA-2048 cifrar 1 MB de datos no es práctico. El enfoque estándar es asimétrico para intercambiar la clave (rápido, un único dato pequeño) y simétrico (AES) para cifrar el cuerpo del mensaje. Esto es exactamente lo que hace TLS.

¿Por qué no se puede invertir un hash SHA-256?

Porque SHA-256 es una función de una sola dirección por diseño: muchos mensajes posibles producen el mismo resultado (aunque encontrar una colisión no es trivial). El proceso aplica transformaciones no lineales que «mezclan» completamente la entrada. No existe una operación inversa matemáticamente definida: la única forma de «invertir» un hash es por fuerza bruta (probar todas las entradas posibles), lo que con 256 bits de salida es computacionalmente imposible.

¿Qué es Perfect Forward Secrecy y por qué importa?

PFS significa que aunque un atacante capture el tráfico cifrado hoy y más tarde robe la clave privada del servidor, no puede descifrar ese tráfico pasado. Lo garantiza el uso de claves efímeras (ECDHE): la clave de sesión se genera fresca para cada conexión y se descarta al terminar, sin nunca almacenarse en el servidor. Así, comprometer la clave del servidor en 2030 no descifra las sesiones de 2026.

¿Cuándo debo preocuparme por la criptografía post-cuántica?

Ahora, si tu organización maneja datos con ciclo de vida largo (más de 5-10 años). El riesgo de «harvest now, decrypt later» es real: actores sofisticados pueden estar grabando ya el tráfico cifrado con RSA/ECC esperando tener capacidad cuántica en el futuro. Para datos de vida corta (una sesión web, un chat), puedes esperar a que los estándares maduren y los proveedores los implementen. Para datos muy sensibles y duraderos, el inventario criptográfico y la planificación de la migración a ML-KEM/ML-DSA deberían comenzar ya.

¿Qué diferencia hay entre SSL y TLS?

SSL (Secure Sockets Layer) fue el predecesor de TLS. SSL 2.0 y 3.0 están obsoletos y son vulnerables (POODLE, DROWN). TLS 1.0, 1.1 también están obsoletos. El protocolo en uso hoy es TLS 1.2 (aceptable) y TLS 1.3 (recomendado). En la práctica, cuando la gente dice «SSL» hoy en día se refiere a TLS; el nombre coloquial persiste pero el protocolo es TLS. Los certificados X.509 que la gente llama «certificados SSL» son certificados TLS.