La frase «está cifrado» parece cerrar una discusión. En realidad la abre. ¿Qué datos, frente a quién, durante cuánto tiempo, con qué clave, bajo qué protocolo y antes o después de qué endpoint? Un archivo cifrado puede aparecer en logs ya descifrado. Un canal TLS puede terminar en un servidor comprometido. Una firma válida puede corresponder a una clave robada. Un algoritmo excelente puede usarse con nonces repetidos.
La criptografía permite construir garantías extraordinariamente precisas. Esa precisión se pierde cuando una propiedad matemática se convierte en un adjetivo general: «seguro», «militar», «irrompible». El trabajo profesional consiste en conservar el alcance completo de la promesa desde el modelo de amenaza hasta el sistema observado.
Una promesa necesita cinco coordenadas
Una afirmación defendible completa al menos estas coordenadas:
- Objeto. ¿Qué bytes, mensaje, identidad, clave o sesión se protege?
- Propiedad. ¿Confidencialidad, integridad, autenticidad, frescura o alguna combinación?
- Adversario. ¿Puede observar, modificar, elegir entradas, repetir mensajes, comprometer una clave o controlar un endpoint?
- Frontera temporal. ¿Antes de la rotación, después de comprometer una clave, durante una sesión o también para sesiones pasadas?
- Condiciones. ¿Qué algoritmos, tamaños, nonces, validaciones, almacenamiento y comportamiento de endpoints se asumen?
«AES-256 protege la base» no contiene ninguna. «Los backups quedan confidenciales frente a quien obtiene el objeto almacenado, mientras la clave K permanezca secreta y separada, usando una construcción AEAD con nonces únicos y autenticando tenant, versión y objeto como datos asociados» sí permite buscar fallos.
La propiedad se formula contra capacidades, no contra una figura vaga llamada hacker. Un atacante pasivo sólo observa. Uno activo inserta, elimina, reordena y modifica. Un atacante con chosen-plaintext puede pedir cifrados de mensajes elegidos; con chosen-ciphertext puede observar respuestas a ciphertexts manipulados. Un insider puede leer claves o saltarse el mecanismo. Cambiar la capacidad cambia la promesa.
De la primitiva al sistema
Una primitiva es un componente con una interfaz y supuestos: una función hash, un cifrador por bloques, un MAC, una firma o un KEM. Una construcción combina primitivas y reglas, como un modo AEAD. Un protocolo ordena mensajes, roles, estados y errores. Una implementación traduce el diseño a código y hardware. Un sistema añade identidad, almacenamiento, autorización, operación y personas.
La seguridad no sube automáticamente por esas capas. Una primitiva puede satisfacer su definición y participar en una construcción incorrecta. Una construcción correcta puede recibir un nonce repetido. Un protocolo sólido puede validar mal certificados. Una biblioteca correcta puede usarse con una clave hardcodeada. Un canal impecable puede entregar plaintext a una aplicación vulnerable.
Vista adaptada. Toca el diagrama para ampliarlo.
La figura no representa una acumulación de sellos. Cada puerta puede invalidar el resultado: si falla la identidad del peer, el canal puede ser confidencial frente a terceros y terminar en el atacante; si falla el endpoint, el adversario lee el plaintext después de una decryption correcta.
Esta es la razón para usar protocolos y bibliotecas revisados. «No diseñes tu propia criptografía» no significa que integrar una biblioteca sea automático. Significa evitar inventar primitivas y construcciones, seguir perfiles interoperables, conservar parámetros seguros y revisar el contrato de la API.
Confidencialidad no es ocultarlo todo
La confidencialidad busca que un adversario no aprenda información protegida sobre el plaintext más allá de lo permitido por el modelo. El ciphertext no tiene que parecer una masa aleatoria a una persona; debe resistir una capacidad adversarial definida.
El cifrado normalmente no oculta longitud, momento, frecuencia, interlocutores ni patrón de acceso. TLS 1.3 reconoce ataques de análisis de tráfico basados en tamaño y timing. El padding puede reducir algunas señales a costa de ancho de banda y latencia, pero no elimina automáticamente todas las filtraciones.
Tampoco protege datos después de descifrarlos. Si una aplicación escribe el número de tarjeta en logs, el canal cumplió y el sistema falló. «Cifrado en reposo» puede proteger discos retirados sin proteger a un proceso con acceso a la clave, a un administrador autorizado o a una consulta inyectada que la aplicación ejecuta legítimamente.
La ubicación de la clave decide el límite. Si datos y clave viajan en el mismo backup, el cifrado puede ofrecer poco frente a su robo. Si el servicio obtiene la clave automáticamente bajo la misma identidad comprometida, el atacante del servicio también la obtiene. Separar key-encryption keys, data-encryption keys e identidades reduce alcance, pero añade dependencias operativas.
Integridad y autenticidad no son lo mismo que verdad
La integridad criptográfica permite detectar modificaciones no autorizadas bajo el mecanismo. Un MAC autentica datos frente a quienes no conocen la clave compartida; cualquiera con esa clave puede generar un tag. Una firma permite verificación con clave pública y atribuye la operación criptográfica a la clave privada correspondiente.
Ningún mecanismo demuestra que el contenido sea verdadero. Una fuente autorizada puede firmar una medición equivocada. Una base puede autenticar un estado obsoleto. Un operador puede firmar el archivo incorrecto. La criptografía conserva una relación entre datos y autoridad, no corrige semántica ni intención.
Una clave pública tampoco es identidad por sí sola. Hace falta un binding: certificado, pin, registro, cadena de confianza o distribución fuera de banda. Verificar la firma con la clave que venía dentro del mismo mensaje sólo prueba consistencia interna; un atacante puede generar su propio par.
FIPS 186-5 explica que una firma detecta modificaciones y autentica la identidad del signatario, y puede aportar evidencia a un tercero. Convertirla en no repudio operativo requiere más: protección y atribución de la clave, política de emisión, timestamps, revocación, evidencia de qué se presentó al firmante y reglas jurídicas. Si diez personas comparten una clave, la matemática no identifica cuál actuó.
Frescura, orden y replay son propiedades separadas
Un MAC o una firma válidos pueden repetirse. El receptor comprobará autenticidad de los mismos bytes y aun así ejecutará dos veces una transferencia. Evitar replay necesita estado o contexto: nonce de desafío, contador, número de secuencia, ventana temporal, identidad de operación o transición de dominio.
El timestamp firmado aporta una afirmación sobre tiempo, no garantiza que el reloj sea correcto ni que el mensaje no haya sido aceptado antes. Una ventana de cinco minutos permite replay durante cinco minutos salvo que el receptor recuerde identidades. Un contador requiere persistencia y reglas para resync. La propiedad debe vivir en el receptor que decide aceptar.
La frescura responde si el mensaje pertenece a esta ejecución o ventana. El orden responde si una secuencia respeta una relación. La unicidad de efecto pertenece al dominio. Pueden usar material criptográfico sin convertirse en la misma cosa.
TLS 1.3 ilustra el límite. Sus datos 1-RTT tienen protección de secuencia dentro de la conexión. Los datos 0-RTT reducen latencia, pero RFC 8446 declara que no son forward secret y no tienen garantía de non-replay entre conexiones. El servidor y la aplicación deben restringir 0-RTT a operaciones seguras frente a repetición o mantener mitigaciones adicionales.
AEAD: una interfaz precisa
Authenticated Encryption with Associated Data recibe clave, nonce, plaintext y datos asociados. Produce ciphertext y tag. Al abrir, devuelve plaintext sólo si la autenticación verifica; RFC 5116 exige devolver error sin plaintext parcial cuando falla.
El plaintext obtiene confidencialidad e integridad. Los datos asociados no se cifran, pero quedan autenticados: versión, tenant, tipo de registro o identificador de objeto pueden entrar allí para impedir que un ciphertext válido se mueva a otro contexto. La aplicación debe reconstruir exactamente el mismo AAD al descifrar.
Vista adaptada. Toca el diagrama para ampliarlo.
El nonce no necesita ser secreto, pero su requisito depende del algoritmo. En AES-GCM, repetir nonce con la misma clave puede revelar relaciones entre plaintexts y destruir autenticidad. «Usamos una UUID» no demuestra unicidad si se trunca, se restaura una VM o varias instancias no coordinan. El diseño necesita un generador y una regla frente a rollback y concurrencia.
AAD tampoco autoriza. Incluir tenant=7 impide cambiar ese campo sin detectar, pero no prueba que el caller pueda leer tenant 7. La política de acceso sigue en la aplicación. Del mismo modo, AEAD no impide borrar el registro, retenerlo, servir una versión vieja o negar servicio.
La API debe hacer difícil el uso parcial. Si el caller puede ignorar el error de autenticación, procesar plaintext antes de verificar o elegir tags demasiado cortos, la construcción pierde su contrato. El capítulo 65 estudiará modos y AEAD con mayor detalle; aquí importa reconocer que los parámetros son parte de la garantía.
Separación de dominios y propósito
Una clave no debería acumular significados. Usar el mismo material para cifrar backups, autenticar cookies y derivar tokens mezcla contextos: una debilidad, exposición o confusión de formato en uno afecta a todos. La separación de claves asigna material distinto por propósito; la separación de dominios incluye labels o contextos inequívocos en una KDF, MAC, hash o firma para que un valor válido en un dominio no se reinterprete en otro.
El tipo de mensaje forma parte del dominio. Si ApproveTransfer y DisplayReceipt aceptan la misma representación firmada, una firma obtenida para la acción inocua podría reutilizarse en la sensible. Protocolos maduros ligan rol, versión, algoritmo, transcript, dirección y contexto. Concatenar campos sin encoding no ambiguo puede hacer que dos tuplas produzcan los mismos bytes: ("ab","c") y ("a","bc").
La derivación tampoco crea aislamiento si todos los subkeys y la raíz viven bajo la misma autoridad comprometida. Sí limita errores accidentales, permite rotación por propósito y evita cross-protocol attacks bajo el modelo de la KDF. La documentación debe conservar qué label, salt, context y output length pertenecen a cada uso.
Fallar cerrado sin perder recuperabilidad
«Fail closed» significa que, ante evidencia criptográfica inválida o ausente, la operación protegida no continúa como si fuera válida. No significa detener indiscriminadamente todo el sistema. Un servicio puede rechazar sólo el objeto afectado, aislarlo, usar una copia verificada o degradar una función no crítica.
Los fallos de claves crean tensión entre confidencialidad y disponibilidad. Si KMS no responde, usar una clave cacheada puede ampliar exposición; negar toda lectura puede impedir recuperación. El contrato define duración de cache, identidad del workload, límites offline, break-glass y auditoría antes del incidente. Inventar el fallback durante una caída suele crear un bypass permanente.
Un error de verificación jamás debería transformarse en plaintext vacío, valor por defecto o «warning». Eso confunde ausencia con mensaje autenticado y permite que la aplicación continúe. A la vez, el sistema debe distinguir invalid, key unavailable, unsupported version y corrupt storage para operar, sin revelar al atacante un oráculo más preciso de lo necesario.
La recuperación necesita datos de prueba y claves de prueba separadas, restore drills y una ruta para formatos históricos. Eliminar algoritmos antiguos sin migrar ciphertext puede destruir información; conservarlos habilitados para nuevas escrituras prolonga riesgo. La solución habitual separa read-old temporal de write-new, mide el remanente y retira el lector cuando la migración se demuestra completa.
Hash no es cifrado, checksum ni firma
Una función hash transforma una entrada arbitraria en un digest fijo. No usa clave y no se descifra. Sus propiedades relevantes se formulan por resistencia a preimagen, segunda preimagen y colisión; ninguna implica autenticidad por sí sola.
Publicar SHA-256(file) por el mismo canal que el archivo detecta errores accidentales, pero un atacante que sustituye ambos no queda detenido. Añadir un secreto de forma improvisada —hash(key || message)— no equivale a un MAC seguro para toda función. HMAC es una construcción definida para ese propósito.
Las contraseñas requieren funciones de password hashing con salt, costo y memoria apropiados, no un hash rápido genérico. Las claves derivadas requieren KDF con inputs y dominios claros. Usar la misma palabra «hash» para todos esos contratos oculta diferencias decisivas que se desarrollarán en los capítulos 63 y 64.
Claves: el algoritmo no protege su propia autoridad
NIST SP 800-57 resume una dependencia fundamental: la seguridad depende de la fuerza de claves, mecanismos y protocolos, y de la protección de las claves. Una clave atraviesa generación, establecimiento, almacenamiento, activación, uso, rotación, recuperación, revocación y destrucción.
El control necesita responder:
- quién puede solicitar, usar, exportar, rotar y destruir;
- para qué algoritmo, propósito y entorno está autorizada;
- cuándo comienza y termina su cryptoperiod;
- qué copias, backups, replicas y caches existen;
- cómo se detecta uso inesperado;
- qué datos quedan expuestos si se compromete hoy;
- cómo se distribuye confianza en la clave sucesora.
Marcar una clave como non-exportable reduce una ruta, no vuelve invulnerable al servicio que puede pedir operaciones. Un HSM puede impedir leer material privado y aun firmar solicitudes maliciosas si el caller comprometido conserva autorización. Se limita con identidades, cuotas, approvals, separación de funciones y logs autenticados.
Rotar no significa generar K2. Hay que emitir, distribuir, comenzar a usar K2, verificar que consumidores la aceptan, retirar K1 para operaciones nuevas, conservarla sólo si hace falta abrir historia y finalmente destruirla. Para datos cifrados, retirar demasiado pronto pierde disponibilidad; conservar indefinidamente amplía exposición.
Secreto hacia adelante y compromiso posterior
Forward secrecy limita el daño de comprometer credenciales de largo plazo: las sesiones pasadas no deberían poder descifrarse sólo con esa clave, si los secretos efímeros fueron protegidos y destruidos. No significa que una sesión activa sobreviva al robo de su traffic secret.
TLS 1.3 explica además que no ofrece post-compromise security para una conexión cuando se compromete su traffic secret: un adversario puede derivar secrets futuros de esa conexión. Hace falta un handshake nuevo con nuevo intercambio (EC)DHE para recuperar esa propiedad. «TLS 1.3 tiene forward secrecy» no autoriza a afirmar «un compromiso actual no afecta nada pasado ni futuro».
Las propiedades temporales también dependen de captura. Un adversario puede almacenar ciphertext hoy y esperar una capacidad futura. La migración poscuántica considera este riesgo para datos de larga confidencialidad. NIST publicó FIPS 203 para ML-KEM y FIPS 204/205 para firmas; adoptar nombres nuevos no completa inventario, interoperabilidad, implementación, certificados, hardware, rollback ni transición.
El canal termina donde comienza otra amenaza
TLS 1.3 busca proporcionar un canal seguro entre peers: autenticación del servidor, autenticación opcional del cliente, confidencialidad e integridad del record layer bajo su configuración. La aplicación debe validar el nombre o identidad esperada y decidir qué autoridad concede a ese peer.
Vista adaptada. Toca el diagrama para ampliarlo.
El límite produce varias conclusiones:
- TLS no corrige una API que autoriza por ID controlado por el cliente.
- La autenticación del servidor no autentica automáticamente al usuario.
- mTLS autentica una credencial de cliente; el servidor aún mapea identidad y política.
- Un proxy que termina TLS es un endpoint y ve plaintext.
- Logs, traces, dumps y colas posteriores necesitan su propio tratamiento.
- Timing, volumen, IPs y parte de la metadata siguen observables.
- Un endpoint comprometido opera dentro del canal legítimo.
El indicador de candado del navegador dice algo sobre la conexión y validación, no sobre honestidad del sitio. El atacante puede controlar un dominio y obtener un certificado válido. La pregunta correcta es si el nombre autenticado es el que la política esperaba.
Side channels: cuando la ejecución revela el secreto
La prueba matemática suele modelar una interfaz ideal. El hardware y el software consumen tiempo, memoria, energía y caches. Diferencias dependientes del secreto pueden filtrar información aunque el ciphertext sea correcto.
Timing, branch prediction, caches, fallos inducidos, consumo y mensajes de error son canales. TLS 1.3 adopta AEAD y alertas uniformes para facilitar implementaciones resistentes, pero su RFC declara que las defensas completas de side channel pertenecen también a las primitivas y a la aplicación.
«Constant time» es una propiedad respecto de observaciones y plataforma, no un adjetivo que se demuestra porque no hay un if (secret). Compilador, microarquitectura, tablas y llamadas auxiliares importan. Por eso se prefieren implementaciones mantenidas, APIs de alto nivel y perfiles conocidos.
Los oráculos aparecen cuando errores distintos revelan validaciones parciales. Devolver «padding incorrecto» frente a «MAC incorrecto» puede permitir aprendizaje adaptativo. La regla general es autenticar antes de exponer plaintext, usar rutas de error uniformes donde corresponda y no registrar secretos bajo la excusa de depuración.
Validado no significa seguro en cualquier producto
FIPS 140-3 define requisitos para módulos criptográficos: fronteras, interfaces, roles, self-tests, protección de parámetros y otros controles. Es evidencia relevante cuando el entorno exige un módulo validado.
El CMVP aclara que la validación no asegura que un producto use correctamente un módulo embebido. Tampoco evalúa toda la aplicación, su autorización, protocolo, configuración o operación. Un certificado tiene módulo, versión, nivel, entorno y caveats; trasladarlo a otra build o plataforma puede quedar fuera.
De forma análoga, que un algoritmo aparezca en un registro no es endorsement universal. RFC 5116 advierte expresamente que registrar un AEAD no debe tomarse como aprobación de su seguridad. Hay que leer estado normativo, parámetros, análisis, límites de uso y transiciones vigentes.
La agilidad criptográfica no consiste en un dropdown para elegir cualquier algoritmo. Consiste en inventariar usos y datos, versionar formatos, negociar sin downgrade, desplegar lectores antes que escritores, rotar material, retirar opciones y probar recuperación. Flexibilidad no gobernada conserva algoritmos obsoletos para siempre.
Un inventario útil no registra sólo «AES» o «RSA». Une producto, protocolo, biblioteca, versión, parámetro, clave, certificado, datos protegidos, tiempo de confidencialidad requerido, propietario y ruta de actualización. Sin esa relación no puede priorizarse una transición ni saberse qué datos históricos deben recifrarse.
La negociación debe quedar autenticada por el transcript; de lo contrario, un atacante puede eliminar opciones fuertes y forzar una heredada. Mantener compatibilidad no debe significar aceptar cualquier oferta. Cliente y servidor aplican mínimos locales y abortan cuando no hay intersección permitida.
Caso trabajado: sobre cifrado de backups
Un equipo afirma: «Los backups están seguros porque usan AES-256». La revisión reconstruye el contrato.
El objeto es cada backup de base. El adversario inicial obtiene el bucket, no el proceso de producción. Se usa AEAD; cada objeto recibe nonce único bajo una data key. Como AAD entran tenant, database-id, schema-version y backup-id. La data key queda envuelta por una key-encryption key en un servicio separado.
La afirmación mejora: quien sólo obtiene el bucket no puede leer ni modificar silenciosamente el contenido mientras la key-encryption key y la identidad de unwrap no sean comprometidas. Aún observa tamaño, cadencia, tenant en metadata no protegida y borrado. Puede servir una versión vieja si el restore no conserva un catálogo monotónico.
El proceso de restore autentica operador y workload, autoriza objeto y tenant, verifica AAD/tag antes de usar plaintext y registra el digest restaurado. Una prueba periódica confirma que claves históricas necesarias siguen disponibles. La rotación de wrapping key no exige recifrar todos los datos si se reenvuelven data keys; cambiar una data key sí exige recifrar objetos que dependan de ella.
Luego aparece una amenaza adicional: compromiso del servicio de producción. Como esa identidad puede pedir unwrap, el atacante puede descifrar backups accesibles. Se limita el rol a versiones necesarias, se separa el restore masivo con approval, se monitorea volumen y se mantiene una copia offline con otra raíz de confianza. La criptografía no falló; cambió el adversario y con él la frontera.
Método de revisión
Ante cualquier frase «está protegido criptográficamente», completa:
- Objeto: ¿qué bytes o estado exacto?
- Propiedad: ¿confidencialidad, integridad, autenticidad, frescura, orden o otra?
- Adversario: ¿qué puede observar, modificar, consultar, repetir o comprometer?
- Tiempo: ¿qué ocurre con sesiones pasadas, activas y futuras tras un compromiso?
- Primitiva y construcción: ¿qué contrato y parámetros?
- Protocolo: ¿roles, transcript, negociación, downgrade y errores?
- Claves: ¿generación, binding, uso, rotación, revocación y destrucción?
- Nonces y estado: ¿cómo se conserva unicidad frente a concurrencia y rollback?
- Endpoints: ¿dónde existe plaintext y qué identidades tienen autoridad?
- Implementación: ¿biblioteca, versión, plataforma, side channels y validación real?
- Evidencia: ¿qué test, log, certificado o prueba demuestra el claim dentro de su alcance?
- No promesas: ¿qué metadata, disponibilidad, verdad y autorización quedan fuera?
Si una fila no puede completarse, no se rellena con «industry standard». Se reduce la afirmación o se obtiene evidencia.
Transferencia al capítulo 62
Este capítulo trató la aleatoriedad como una condición de claves, nonces y operaciones. El capítulo 62 examinará de dónde surge la entropía, cómo funciona un DRBG, por qué random no significa impredecible y cómo se evitan repetición y rollback.
Síntesis
La criptografía promete propiedades acotadas bajo supuestos. Confidencialidad no oculta toda metadata; integridad no demuestra verdad; autenticidad de clave no concede autorización; firma no identifica intención humana; frescura y replay necesitan estado del receptor.
Una primitiva no es una construcción, una construcción no es un protocolo y un protocolo no es un sistema. AEAD protege plaintext y AAD bajo requisitos de clave y nonce, pero no disponibilidad ni política. TLS protege un canal entre endpoints; no protege plaintext dentro de un endpoint comprometido ni corrige la aplicación.
Las claves, nonces, implementaciones, side channels, validaciones y transiciones son parte de la garantía. FIPS 140-3 aporta evidencia sobre un módulo dentro de un alcance, no un sello para todo el producto. La formulación profesional siempre nombra objeto, propiedad, adversario, tiempo, condiciones y evidencia.
Fuentes primarias y documentación técnica
- NIST, SP 800-57 Part 1 Rev. 5 — Recommendation for Key Management; CSRC, 2020.
- NIST, FIPS 140-3 — Security Requirements for Cryptographic Modules y CMVP FAQ; CSRC, consultados 2026-10-06.
- NIST, FIPS 186-5 — Digital Signature Standard; CSRC, 2023, con potential-updates notice de 2025.
- IETF, RFC 5116 — An Interface and Algorithms for Authenticated Encryption; RFC Editor, 2008.
- IETF, RFC 8446 — TLS 1.3, especialmente §§2.3, 5.5, 8 y Appendix E; RFC Editor, 2018.
- IETF, RFC 4086 — Randomness Requirements for Security; RFC Editor, 2005.
- NIST, FIPS 203, FIPS 204 y FIPS 205; PQC project, 2024, consultado 2026-10-06.