PARTE XLI · Computación, datos e Internet
461
Criptografía: confidencialidad, integridad e identidad
Las primitivas transforman problemas de confianza en problemas de claves; los protocolos deciden si esa transformación funciona
En este capítulo
Una conexión muestra un candado. Eso no demuestra que el sitio sea honrado, que el dispositivo esté limpio ni que los datos se usarán bien. Sí puede demostrar algo más preciso: que el navegador estableció una conexión con quien controla cierta clave, que terceros en la ruta no pueden leer fácilmente el contenido y que una alteración será detectada.
La criptografía construye propiedades de información mediante algoritmos y secretos. No es sinónimo de esconder texto. Puede aportar confidencialidad, integridad, autenticidad y no repetición bajo supuestos concretos. Este capítulo pregunta: ¿qué garantiza cada mecanismo, cómo se enlazan las claves con identidades y dónde terminan esas garantías?
461.1. Cifrado simétrico y asimétrico#
El cifrado transforma texto claro en texto cifrado mediante una clave. Un algoritmo moderno se publica y analiza; el secreto reside en la clave. Ocultar el procedimiento dificulta revisión y no sustituye un espacio de claves resistente.
En el cifrado simétrico, la misma clave —o claves estrechamente relacionadas— cifra y descifra. Es eficiente para grandes volúmenes. AES procesa bloques de 128 bits con claves de 128, 192 o 256 bits, pero el algoritmo de bloque no basta: un modo de operación define cómo proteger mensajes de longitud arbitraria.
El cifrado autenticado, como AES-GCM, combina confidencialidad con una etiqueta de autenticación. Un número único o nonce debe cumplir las condiciones del esquema; reutilizarlo con una misma clave puede revelar relaciones o permitir falsificaciones. «Está cifrado» es insuficiente si no se especifican modo, nonce, etiqueta y tratamiento de errores.
En criptografía asimétrica hay una clave privada y otra pública relacionadas matemáticamente. La pública puede difundirse; la privada debe permanecer controlada. Esta separación facilita establecer secretos y verificar firmas sin compartir de antemano una misma clave con cada interlocutor.
Los sistemas reales suelen ser híbridos. Un intercambio asimétrico autentica participantes o deriva un secreto; después, cifrado simétrico protege la sesión. Así combina distribución de confianza con eficiencia. TLS 1.3 sigue esta arquitectura, pero además negocia parámetros, vincula mensajes del protocolo y comprueba autenticidad.
La seguridad depende del algoritmo, parámetros, implementación y entorno. Una clave larga no compensa un generador predecible, una filtración de memoria o un mensaje mostrado al destinatario equivocado.
461.2. Funciones hash e integridad#
Una función hash criptográfica convierte una entrada de cualquier longitud en una huella de longitud fija. Debe ser difícil recuperar una entrada desde la huella, hallar otra con la misma huella o producir cualquier colisión. «Difícil» significa coste computacional, no imposibilidad matemática: como hay más entradas que salidas, las colisiones existen.
Un hash detecta cambios sólo si la huella de referencia llega por una vía confiable. Si un atacante puede reemplazar archivo y hash, ambos coincidirán. Para autenticar mensajes con un secreto compartido se usa un código de autenticación, como HMAC; para atribuirlos a una clave privada, una firma digital.
Las contraseñas no deben almacenarse con un hash rápido sin más. Como las personas eligen secretos predecibles, un atacante que obtiene la base puede probar candidatos fuera de línea. Una sal única por contraseña impide reutilizar tablas precalculadas; una función deliberadamente costosa de derivación aumenta el precio de cada intento. No vuelve fuerte una contraseña trivial ni impide el fraude al usuario.
Los hashes también organizan estructuras verificables. Un árbol de Merkle permite comprobar que un fragmento pertenece a un conjunto mediante pocas huellas. Una cadena de hashes evidencia alteraciones posteriores, pero no prueba que el dato original fuera verdadero.
461.3. Firmas digitales y certificados#
Una firma digital se calcula con una clave privada sobre un mensaje o su representación y se verifica con la clave pública correspondiente. Puede demostrar que el mensaje fue firmado por quien controlaba esa clave y que no cambió después. No revela por sí sola quién era esa persona ni si comprendió lo firmado.
Firmar no es cifrar. Una firma puede ser pública; el cifrado busca ocultar contenido. Algunos diseños antiguos reutilizaron operaciones matemáticas parecidas, pero los protocolos seguros tratan las funciones y formatos como contratos distintos.
Un certificado digital vincula una clave pública con un nombre u otros atributos mediante la firma de una autoridad certificadora. El navegador confía en un conjunto de raíces; una cadena conduce desde el certificado del sitio hasta una raíz aceptada. Verifica nombre, vigencia, usos y firmas. La autoridad avala el vínculo bajo sus procedimientos, no la bondad del servicio.
La revocación intenta invalidar certificados antes de su vencimiento, pero consultar estado introduce disponibilidad y privacidad. La transparencia de certificados hace registrables emisiones para dominios y ayuda a detectar errores; tampoco impide todos los abusos.
En una conexión autenticada, el certificado y la firma deben quedar ligados al intercambio concreto. De lo contrario, un atacante podría copiar credenciales válidas fuera de contexto. Los protocolos maduros autentican una transcripción, no una pantalla de «éxito» aislada.
461.4. Gestión de claves y confianza#
Las claves deben generarse con entropía suficiente, almacenarse con controles adecuados, distribuirse, rotarse, revocarse, recuperarse cuando proceda y destruirse. Ese ciclo suele ser más frágil que la primitiva matemática.
Una clave privada exportable en un archivo tiene riesgos distintos de una confinada en hardware. El hardware reduce ciertas extracciones, pero añade firmware, cadena de suministro y disponibilidad. Las copias de recuperación evitan pérdida irreversible y amplían el número de lugares que proteger.
Rotar claves limita exposición futura, pero no borra copias antiguas ya descifradas. El secreto hacia adelante deriva claves de sesión efímeras: comprometer después una clave de identidad no debería revelar sesiones pasadas registradas, siempre que los secretos efímeros se hayan eliminado.
La confianza puede ser jerárquica, directa o distribuida. Una infraestructura de clave pública delega en autoridades; una aplicación puede fijar claves conocidas; personas pueden comparar huellas por otro canal. Cada modelo responde quién puede afirmar identidades, cómo se corrigen errores y qué ocurre si una raíz cae.
La ceremonia importa. Si una organización comparte la clave de firma entre muchas personas, la atribución se diluye. Si la recuperación permite saltar autenticación, ése es el control dominante. Inventariar claves sin identificar propietarios, usos y dependencias no basta.
461.5. Qué protege la criptografía y qué deja fuera#
El cifrado protege datos frente a observadores que no tienen la clave. Los extremos legítimos deben acceder al contenido; allí puede copiarse, filtrarse o mostrarse. El cifrado de extremo a extremo reduce intermediarios capaces de leer, pero no protege un extremo comprometido.
Los metadatos pueden permanecer visibles: quién se comunica, cuándo, cuánto y desde dónde. Ocultarlos exige diseños adicionales y suele costar latencia o ancho de banda. Un canal confidencial tampoco impide inferencias a partir de frecuencia y tamaño.
La criptografía no decide autorización. Una firma válida prueba control de clave, no derecho a aprobar un pago. Tampoco asegura disponibilidad: borrar el único secreto o saturar el servicio impide acceso aunque los algoritmos sean correctos.
Los fallos de protocolo convierten piezas fuertes en sistemas débiles: reutilización de nonce, validación incompleta, mensajes ambiguos, degradación de versión, errores distinguibles o claves compartidas sin necesidad. Por eso se prefieren protocolos analizados y bibliotecas mantenidas frente a combinaciones improvisadas.
La computación cuántica cambiaría la seguridad de algoritmos públicos ampliamente usados; no rompe de la misma forma todas las primitivas simétricas. La migración poscuántica requiere inventariar dependencias y datos que deban seguir secretos durante años. No es sólo sustituir nombres de algoritmos.
Síntesis#
El cifrado simétrico protege datos con eficiencia; la criptografía asimétrica ayuda a establecer secretos y verificar firmas. Los hashes resumen de forma resistente, pero necesitan una referencia autenticada. Certificados vinculan claves con nombres dentro de un modelo de confianza. La gestión de claves y el protocolo determinan si esas primitivas conservan sus garantías. Ninguna de ellas prueba honestidad, elimina metadatos, decide permisos ni repara extremos comprometidos.
Preguntas de transferencia#
1. Un archivo y su hash se descargan del mismo servidor comprometido. ¿La coincidencia prueba integridad?#
No. El atacante puede reemplazar ambos. La huella necesita una vía autenticada o una firma cuya clave de verificación sea confiable.
2. Un sitio tiene certificado válido. ¿Es legítimo su negocio?#
No. El certificado enlaza una clave con un nombre bajo ciertas reglas; no certifica intenciones, solvencia ni calidad.
3. Se cifra una base, pero la aplicación puede consultarla. ¿Desaparece el riesgo de filtración?#
No. Protege frente a actores sin la clave, especialmente en almacenamiento o tránsito; una aplicación comprometida puede pedir datos ya descifrados.
4. ¿Por qué no cifrar todo directamente con criptografía asimétrica?#
Porque es más costosa y tiene restricciones. Los protocolos híbridos la usan para autenticar o acordar claves y reservan el cifrado simétrico para el flujo de datos.

Clave de lectura. El certificado ayuda a autenticar el extremo; la clave de sesión protege el flujo. El observador aún puede aprender metadatos.
Fuentes y lecturas del capítulo#
- NIST. FIPS 197: Advanced Encryption Standard (AES). Actualización editorial, 2023.
- NIST. FIPS 180-4: Secure Hash Standard. 2015.
- NIST. FIPS 186-5: Digital Signature Standard. 2023.
- NIST. SP 800-57 Part 1 Rev. 5: Recommendation for Key Management. 2020.
- Eric Rescorla. RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3. IETF, 2018.
- Jonathan Katz y Yehuda Lindell. Introduction to Modern Cryptography. CRC Press, 2020.