El módulo anterior terminó con una lista de defensas que ya has visto funcionar —TLS, las URLs firmadas de 120 segundos, el HMAC del webhook de la pasarela, DKIM, las passkeys, la firma RS256 del JWT, el cifrado de las copias, la comparación en tiempo constante del TOTP— y con una constatación: todas descansan sobre el mismo cimiento y hasta ahora lo hemos tratado como una caja negra. Esta lección abre la caja. No vas a salir de ella sabiendo cifrar: vas a salir sabiendo qué pide uno a la criptografía, qué le puede pedir de verdad, con qué vocabulario preciso se habla de ella y por qué —esta es la idea que atraviesa todo el módulo— la parte difícil casi nunca es el algoritmo. Es importante porque la mayoría de los fallos criptográficos reales de las PYMES no consisten en romper AES, sino en usar la primitiva equivocada para el problema equivocado, confundir codificar con cifrar, o generar una clave con una fuente de aleatoriedad que no lo era.

1. Qué problema resuelve exactamente la criptografía
2. Vocabulario preciso: cifrar, codificar, hashear y ofuscar no son lo mismo
3. Historia como palanca conceptual: César, Vigenère y Enigma
4. El principio de Kerckhoffs y por qué la seguridad vive en la clave
5. Modelos de atacante y tipos de ataque criptográfico
6. Qué significa «seguro» hoy: bits de seguridad y tamaños de clave
7. Aleatoriedad criptográfica: el cimiento invisible
8. El mapa del módulo 3
9. La criptografía que Nimbus ya usa sin haberla explicado

La criptografía es el conjunto de técnicas matemáticas que permiten proteger información frente a un adversario que tiene acceso al canal, al soporte o a ambos. Esa última frase es la clave y conviene leerla despacio: la criptografía no supone un canal seguro ni un disco a salvo. Supone lo contrario. Asume que el atacante ve los datos, y aun así consigue que no le sirvan de nada.

Es la aplicación directa del principio de asume la brecha de 01-03. Una nota clínica de una clínica de fisioterapia cliente de Nimbus viaja por wifis de cafeterías, se guarda en discos de un proveedor cloud y se copia a buckets de respaldo. En ninguno de esos tres puntos controlamos el medio físico. La criptografía convierte «que nadie toque el medio» —imposible— en «que tocar el medio no sirva de nada» —alcanzable.

En 01-01 se definió la tríada CIA y sus complementos: autenticidad, no repudio y trazabilidad. Cada una de esas propiedades tiene una primitiva criptográfica concreta que la proporciona. Esta tabla es el mapa mental del módulo entero:

Tres lecturas importantes de esta tabla:

• Cifrar no da integridad por sí solo. Es el error conceptual más extendido. Un texto cifrado con un modo antiguo puede ser alterado por un atacante de forma controlada sin conocer la clave. Por eso hoy se usa cifrado autenticado, que junta las dos propiedades en una sola operación (03-02).
• Un MAC y una firma no son intercambiables. Ambos dan autenticidad e integridad, pero el MAC usa una clave compartida: si Nimbus y la pasarela comparten la clave, Nimbus podría haber fabricado ese mensaje, así que no sirve como prueba frente a un tercero. La firma, con clave privada, sí (03-03).
• La frescura no la da ninguna de las anteriores. Un mensaje cifrado, íntegro y auténtico de hace tres meses sigue siendo cifrado, íntegro y auténtico hoy. Reenviarlo es un ataque de repetición, y se combate con nonces y ventanas temporales, no con más cifrado.

Igual de importante que lo anterior. La criptografía no:

• Protege frente a quien tiene la clave legítimamente. Si un atacante roba las credenciales de Iván, la API descifra para él con total corrección. Ese es un problema de identidad (02-05) y de autorización, no de criptografía.
• Oculta metadatos. TLS oculta el contenido de la petición, no que tu portátil hable con nimbusreservas.example a las 03:14, ni el tamaño aproximado de la respuesta.
• Da disponibilidad. Un ransomware usa criptografía perfectamente correcta contra ti. Cifrar no evita que borren.
• Sustituye al control de acceso. Volveremos a esto en 03-07: cifrar una base de datos cuya API expone un IDOR no arregla el IDOR.
• Se arregla sola. Una clave mal guardada convierte AES-256 en un adorno. Ese es el asunto de 03-06.

El módulo entero depende de usar bien cinco palabras. Empecemos por las básicas:

Y ahora la distinción que más veces se hace mal en la práctica profesional:

Codificar no protege absolutamente nada. Base64 aparece constantemente en tokens, en cabeceras HTTP y en configuraciones, y con una regularidad deprimente alguien concluye que «está encriptado». Vamos a demostrar que no:

Salida:

Analicemos el código línea a línea, porque el detalle importa:

• dato.encode("utf-8") convierte el texto Python en bytes. Base64 opera sobre bytes, no sobre caracteres.
• base64.b64encode(...) produce la representación en el alfabeto A-Z a-z 0-9 + /, con = de relleno al final. No ha intervenido ninguna clave. El resultado depende únicamente de la entrada.
• base64.b64decode(...) revierte la operación. No se le pasa ningún secreto porque no existe ninguno.

La conclusión operativa: si ves un valor terminado en == en un log, un ticket o una URL, no está protegido; está transportado. Y si contiene datos personales, ese log es una fuga (esto conecta directamente con la regla de «qué registrar y qué no» de 02-04).

Prueba de bolsillo para distinguirlas. Pregúntate: ¿puedo deshacer esto sin ningún secreto? Si la respuesta es sí, es codificación u ofuscación, y no aporta seguridad. Si necesito un secreto, es cifrado. Si no se puede deshacer de ninguna manera, es un hash.

La historia de la criptografía no se estudia aquí por erudición, sino porque cada fracaso histórico dejó una lección que sigue vigente palabra por palabra.

Este ejemplo existe solo para que veas con tus propios ojos qué significa «espacio de claves pequeño».

Advertencia explícita. El cifrado César no tiene ningún valor de seguridad. No lo uses jamás para proteger nada, ni siquiera como «capa adicional». Aparece aquí exclusivamente como ilustración conceptual, igual que un dibujo de una cerradura de 1900 en un manual de cerrajería.

Fragmento de la salida:

Qué hay que entender de esto:

• No ha hecho falta ninguna matemática. El bucle prueba las 25 claves en microsegundos y un humano identifica la correcta de un vistazo.
• La operación % 26 es lo que hace que el alfabeto sea circular: tras la z vuelve la a.
• Descifrar es cifrar con el desplazamiento negativo: cesar(texto, -clave).
• Un ordenador moderno probaría del orden de mil millones de claves por segundo en un esquema tan simple. Con 25 claves, no hay defensa posible. Con 2^128, como veremos en el apartado 6, la fuerza bruta deja de existir como opción.

La lección permanente de César, la de Vigenère y la de Enigma se resumen en tres frases que valen para 2026: el espacio de claves tiene que ser astronómico; el material de clave no se reutiliza jamás; y el atacante ataca lo más débil, que casi siempre es el procedimiento humano, no el álgebra.

En 01-03 conociste el principio de Kerckhoffs como uno de los quince principios de diseño seguro. Aquí es donde cobra todo su sentido:

Un sistema criptográfico debe ser seguro incluso si todo lo relativo a él, salvo la clave, es de dominio público.

Dicho de otro modo: el algoritmo es público; el secreto es la clave, y solo la clave. Lo contrario —confiar en que nadie conozca el algoritmo— se llama seguridad por oscuridad y es una de las peores decisiones posibles en criptografía, por cuatro razones concretas:

De aquí sale la regla pedagógica central de este módulo, que vas a leer en las siete lecciones:

Nunca implementes criptografía a mano. Ni el algoritmo, ni el modo, ni el relleno, ni la comparación de etiquetas. Usa librerías establecidas, mantenidas y auditadas —en Python, cryptography, y los módulos hashlib, hmac y secrets de la biblioteca estándar—. Tu trabajo profesional no es inventar primitivas: es elegir la correcta, configurarla bien y gestionar sus claves. Las tres cosas se hacen mal a menudo, y las tres son suficientes para arruinar un sistema.

Esto no es una recomendación de estilo. La criptografía de calidad industrial exige defenderse de canales laterales, de errores de relleno, de multiplicaciones que tardan distinto según los bits, de generadores de números aleatorios defectuosos. Una implementación «que da el resultado correcto» puede estar filtrando la clave por el tiempo de ejecución sin que ningún test lo detecte.

Para decir que algo es seguro hay que decir frente a qué atacante. La criptografía formaliza esto en modelos de atacante, que se distinguen por lo que el adversario puede hacer:

El estándar moderno es exigir seguridad frente al modelo más fuerte. Un algoritmo actual como AES-GCM se considera seguro incluso frente a un atacante que elige textos claros a voluntad; si un esquema solo aguanta el modelo débil, se descarta.

Detengámonos en la de temporización porque es contraintuitiva. Si tu código compara un código de verificación carácter a carácter y devuelve False en cuanto encuentra una diferencia, tarda más cuando acierta más caracteres. Un atacante que mida miles de intentos reconstruye el secreto carácter a carácter, reduciendo un problema imposible a uno trivial. Por eso existe hmac.compare_digest, que verás en detalle en 03-04, y por eso comparar secretos con == está prohibido en todo este curso.

La idea que debes llevarte del apartado. Casi ningún incidente criptográfico real se debe a que alguien rompiera el álgebra. Se debe a claves mal guardadas, nonces repetidos, versiones obsoletas de protocolo, validaciones desactivadas y comparaciones ingenuas. El atacante ataca al implementador, no al algoritmo.

Un esquema tiene n bits de seguridad cuando el mejor ataque conocido requiere del orden de 2^n operaciones. No es lo mismo que el tamaño de la clave: RSA con clave de 2048 bits ofrece aproximadamente 112 bits de seguridad, porque factorizar es más fácil que probar todas las claves.

Los números grandes no significan nada hasta que se aterrizan. Supongamos una máquina imaginaria capaz de probar mil millones de claves por segundo (10^9), y supongamos que juntamos mil millones de esas máquinas (10^18 claves por segundo, muy por encima de toda la capacidad de cómputo del planeta):

Once billones de años frente a los ~13.800 millones de años de edad del universo. Y cada bit adicional duplica ese número: 256 bits no es «el doble de seguro» que 128, es 2^128 veces más.

La conclusión práctica es liberadora: el tamaño de clave no es el problema. Si usas AES-128 o AES-256, la fuerza bruta contra la clave está descartada para siempre con tecnología clásica. Cuando leas que «han roto un cifrado», casi siempre significa una de estas cinco cosas:

1. La clave se derivó de una contraseña débil (03-04).
2. La clave estaba guardada donde el atacante llegó (03-06).
3. Se usó un modo o algoritmo obsoleto (ECB, RC4, MD5).
4. Se repitió un nonce o se reutilizó material de clave (03-02).
5. Se rompió la implementación: canal lateral, validación desactivada, error de relleno.

¿Y AES-256 frente a AES-128? Elige 256 cuando el dato deba seguir siendo confidencial durante décadas o cuando una norma sectorial lo exija; el coste de rendimiento es pequeño. Para el uso general de Nimbus, cualquiera de los dos está fuera del alcance de cualquier adversario.

Toda la criptografía descansa en poder generar valores que el atacante no pueda predecir: claves, nonces, sales, identificadores de sesión, tokens de recuperación de contraseña. Si esos valores son adivinables, el algoritmo es irrelevante: el atacante no rompe nada, simplemente regenera tu secreto.

Python tiene dos generadores y elegir mal es un fallo de seguridad real:

Salida (distinta en cada ejecución, por definición):

Explicación de cada línea:

• random.choice usa el Mersenne Twister, un generador excelente para estadística y catastrófico para seguridad: es determinista y su estado interno se puede reconstruir observando suficientes salidas. Si Nimbus generase con él los tokens de «he olvidado mi contraseña», un atacante que pidiera unos cuantos tokens para su propia cuenta podría predecir el de Sara.
• secrets.token_urlsafe(32) pide 32 bytes al generador seguro del sistema operativo y los codifica en Base64 seguro para URLs. Ojo: los 32 son bytes de entropía, no caracteres de salida.
• secrets.token_bytes(32) devuelve bytes crudos: es la forma correcta de generar una clave simétrica de 256 bits desde cero.
• secrets.randbelow(1_000_000) da un entero uniforme sin el sesgo que introduciría un % 1000000 sobre un número aleatorio grande. El formateo :06d conserva los ceros a la izquierda: 048217 es un código válido.

Caso histórico. En 2013 se descubrió que un fallo en el generador de números aleatorios de determinadas aplicaciones Android hacía que las claves de firma de transacciones se repitieran. Con dos firmas que compartieran ese valor, la clave privada quedaba expuesta con álgebra elemental. El algoritmo era correcto y estaba bien implementado. La aleatoriedad no lo era, y eso bastó.

Regla operativa para Nimbus, sin excepciones: cualquier valor que el atacante no deba adivinar se genera con secrets (o con el equivalente de la plataforma: crypto.getRandomValues en el navegador, crypto/rand en Go). Nunca con random, nunca con la hora, nunca con un contador, nunca con un UUID versión 1.

Antes de entrar en los algoritmos, este es el recorrido y qué pieza aporta cada lección:

La lógica de la secuencia: lo simétrico resuelve la confidencialidad pero deja abierta la distribución de la clave; lo asimétrico resuelve la distribución pero es lento, lo que obliga a combinarlos; los hashes y los MAC aportan la integridad que el cifrado no da; los protocolos son la manera correcta de ensamblar todo eso; la PKI responde a «¿de quién es esta clave pública?»; y la última lección lo aplica de punta a punta al sistema de Nimbus.

Cierra la lección un inventario honesto: en dos módulos hemos apoyado defensas sobre criptografía sin explicarla. Esta tabla es la deuda que el módulo 3 viene a pagar.

La última fila es la más elocuente. En el caso de ransomware de Nimbus, ninguna primitiva criptográfica falló: falló que una clave estaba guardada donde no debía. Es la tesis que gobernará 03-06 y que conviene interiorizar desde hoy: la matemática aguanta; la gestión es lo que se rompe.

Errores conceptuales

1. Llamar «encriptado» a algo codificado en Base64. Es el error número uno. Base64 y hexadecimal son transporte, no protección. Aplica la prueba de bolsillo del apartado 2.
2. Creer que cifrar aporta integridad. No la aporta salvo que uses cifrado autenticado. Un atacante puede alterar el texto cifrado de forma controlada en modos antiguos.
3. Confundir hash con cifrado. «Ciframos las contraseñas» es una frase incorrecta y peligrosa: si se pudieran descifrar, el atacante que roba la clave las tendría todas. Las contraseñas se derivan con una función lenta y unidireccional (03-04).
4. Pensar que un algoritmo secreto es más seguro. Kerckhoffs dice justo lo contrario y la experiencia de un siglo lo confirma.
5. Obsesionarse con el tamaño de clave. Discutir AES-128 frente a AES-256 mientras la clave vive en un fichero .env del repositorio es optimizar la parte que no falla.
6. Suponer que la criptografía sustituye al control de acceso. Son capas distintas. El IDOR de 01-01 ocurría sobre una conexión TLS impecable.

Errores de implementación

7. Usar random para material de seguridad. Tokens, sales, nonces, claves: siempre secrets.
8. Comparar secretos con ==. Abre un canal lateral de temporización. Se usa hmac.compare_digest.
9. Escribir tu propia primitiva «porque es un XOR sencillo». No.
10. Copiar el primer fragmento que aparece en un buscador. Buena parte del código criptográfico que circula en foros es de 2011 y usa ECB, MD5 o IV fijos.

Consejos prácticos

• Antes de elegir algoritmo, escribe en una frase qué propiedad necesitas: ¿confidencialidad, integridad, autenticidad, no repudio o frescura? La tabla del apartado 1 te da la primitiva casi sola.
• Escribe también frente a quién proteges. Cifrar el disco de un servidor no defiende de una API comprometida, y saberlo evita comprar tranquilidad falsa.
• Mantén una regla de equipo: el código criptográfico se revisa siempre entre dos personas, aunque el cambio parezca trivial.
• Consulta fuentes vigentes para parámetros y tamaños (NIST SP 800-57, las guías del CCN-CERT y ENISA, la hoja de ruta de OWASP). Los valores concretos caducan; los principios no.

Para cada situación real de Nimbus, indica: (a) qué operación se está aplicando —codificar, cifrar, hashear u ofuscar—; (b) qué propiedad de seguridad aporta realmente; (c) si es adecuada para el fin declarado y, si no lo es, qué debería hacerse.

1. El token de sesión que la SPA guarda contiene el correo del usuario en Base64, «para que no se vea a simple vista».
2. Rubén envía a un cliente un fichero ZIP protegido con contraseña y le manda la contraseña por el mismo correo.
3. Iván guarda en la base de datos el resultado de sha256(contraseña).
4. El adjunto de una clínica se sube al bucket A-05 cifrado con AES-GCM y la clave está en un gestor de secretos.
5. Lucía publica junto a la copia de seguridad nocturna un fichero .sha256 con la huella del archivo.
6. El JavaScript de la SPA está minificado y con nombres de variable de una letra, «para que nadie entienda la lógica de precios».

Este es el código real que Nimbus usa para los enlaces de recuperación de contraseña:

Se pide: (a) identifica los tres problemas marcados y explica el ataque concreto que habilita cada uno; (b) estima cuántos intentos necesitaría un atacante que conoce el correo de Sara y el minuto aproximado en que pidió la recuperación; (c) reescribe la función correctamente, explicando cada decisión; (d) indica qué otras dos medidas, ajenas a la generación del token, debería tener este flujo.

Para cada requisito de Nimbus, di qué propiedad se necesita, qué primitiva la proporciona y en qué lección del módulo se estudia. No hace falta código.

1. Que la consultora externa (A-19) no pueda leer el contenido de las copias que custodia.
2. Que Nimbus pueda demostrar ante un cliente, meses después, que fue ese cliente quien canceló una reserva.
3. Que la API detecte si un webhook de la pasarela de pago fue fabricado por un tercero.
4. Que un atacante que grabe hoy el tráfico cifrado de la app móvil no pueda leerlo si dentro de dos años roba la clave privada del servidor.
5. Que un adjunto descargado del bucket no pueda reutilizarse mañana con la misma URL.
6. Que, si roban el volcado de la tabla de credenciales, las contraseñas no se puedan recuperar en un plazo útil.

Ejercicio 1

Ejercicio 2

(a) Los tres problemas:

1. random.seed(int(time.time())) — se siembra el generador con la hora en segundos. El espacio de semillas de un día entero son 86.400 valores. Un atacante que sepa el día reproduce todos los tokens posibles.
2. random.randint(100000, 999999) — dos fallos: usa random (predecible) y solo hay 900.000 valores posibles, unos 20 bits. Es fuerza bruta trivial incluso sin conocer la semilla.
3. base64.b64encode(...) — el token no está protegido: contiene el correo en claro para cualquiera y, además, revela el formato interno, lo que facilita fabricar candidatos.

(b) Estimación. Si el atacante conoce el correo y el minuto aproximado, tiene ~60 semillas candidatas. Cada semilla determina de forma determinista la primera salida de randint, así que produce ~60 tokens candidatos. Con reintentos automatizados, acierta en segundos. Ni siquiera hace falta explorar los 900.000: la siembra por tiempo destruye toda la entropía.

(c) Versión correcta:

Decisiones: entropía suficiente y de fuente segura; el token no contiene datos (es opaco, no revela el correo); se almacena hasheado; caduca en 15 minutos; es de un solo uso.

(d) Otras dos medidas: (1) respuesta idéntica exista o no la cuenta —«si el correo está registrado, recibirás un enlace»— para no permitir enumeración de usuarios; (2) límite de tasa por correo y por IP, más registro del evento para alerta (02-04). Una tercera deseable: invalidar todas las sesiones activas al completar el cambio.

Ejercicio 3

Has abierto la caja negra. Ahora tienes el mapa que faltaba: cada propiedad de seguridad tiene su primitiva —confidencialidad al cifrado, integridad al hash y al MAC, autenticidad y no repudio a la firma, frescura al nonce, y el acuerdo de clave al intercambio— y también sabes lo que la criptografía no hace: no protege de quien tiene la clave, no oculta metadatos, no da disponibilidad y no sustituye al control de acceso. Distingues con precisión codificar, cifrar, hashear y ofuscar, y tienes una prueba de bolsillo para no volver a confundirlas: ¿puedo deshacerlo sin ningún secreto? Has visto en Base64 que codificar no protege nada y en un César roto en 25 intentos qué significa un espacio de claves insuficiente.

De la historia te llevas tres lecciones que siguen intactas: el espacio de claves debe ser astronómico, el material de clave no se reutiliza jamás —volverá con los nonces en la próxima lección— y el atacante ataca el procedimiento y la implementación, no el álgebra. Sobre esa base has recuperado Kerckhoffs: el algoritmo es público y el secreto es solo la clave, de donde sale la regla que gobierna el módulo entero —nunca implementes criptografía a mano—. Sabes situar a un adversario en su modelo, distinguir un ataque de fuerza bruta de uno de canal lateral, y por qué 2^128 pone la fuerza bruta fuera del universo, lo que traslada el problema real a las cinco causas de siempre: contraseñas débiles, claves mal guardadas, algoritmos obsoletos, nonces repetidos e implementaciones defectuosas. Y has interiorizado el cimiento invisible: secrets, nunca random, porque una mala fuente de aleatoriedad rompe cualquier algoritmo por perfecto que sea.

Por último has puesto números a la deuda: once elementos de Nimbus que llevan dos módulos funcionando gracias a criptografía sin explicar, desde el HMAC del webhook hasta las URLs firmadas de 120 segundos, y una fila final que resume la tesis del módulo: en el ransomware de 02-06 no falló ninguna primitiva, falló dónde vivía una clave.

En Criptografía Simétrica (03-02) empezamos por la primitiva más antigua y más usada: una única clave compartida que cifra y descifra. Verás por qué AES es el estándar, qué es un modo de operación y por qué ECB está prohibido, qué papel juega el nonce y por qué repetirlo es catastrófico, y cómo se cifra correctamente un adjunto de Nimbus con AES-GCM ligándolo a su tenant_id. Y terminarás con el problema que lo simétrico no puede resolver solo —cómo hacer llegar la clave al otro extremo—, que es exactamente lo que motiva la lección siguiente.