Al cerrar el Módulo 2 dejamos tres preguntas en el aire: cómo comprobar que un fichero no ha cambiado sin descifrarlo, cómo autenticar un mensaje entre dos partes que comparten una clave, y cómo guardar las contraseñas de los usuarios del portal de MediNube. Las tres respuestas se construyen sobre una misma primitiva que llevamos usando de contrabando desde el Módulo 2 (dentro de HMAC-SHA256 en PBKDF2, dentro de HKDF-SHA256): la función hash criptográfica. Esta lección la saca por fin a primer plano: qué propiedades tiene que cumplir, por qué la resistencia a colisiones "vale la mitad de bits" (la promesa pendiente del Módulo 1), qué algoritmos están vivos y cuáles están rotos, y para qué sirve — y para qué no sirve — un hash a secas. Es la base sobre la que en 03-02 construiremos HMAC y en 03-03 el almacenamiento de contraseñas: si esta pieza se entiende bien, las otras dos caen solas.

1. Qué es una función hash criptográfica
2. Las tres resistencias: preimagen, segunda preimagen y colisiones
3. La paradoja del cumpleaños: por qué las colisiones valen la mitad de bits
4. El zoo de algoritmos: SHA-2, SHA-3, BLAKE2... y los muertos (MD5, SHA-1)
5. Usos legítimos del hash a secas
6. Caso práctico: huella de historiales exportados en MediNube
7. Hashing por streaming de ficheros grandes
8. Qué NO es un hash a secas

Una función hash criptográfica toma una entrada de cualquier longitud (un byte, un historial médico, un disco entero) y produce una salida de longitud fija llamada hash, digest o huella digital. Para SHA-256, esa salida son siempre 32 bytes (256 bits), pese lo que pese la entrada.

Desglose del código:

• hashlib es el módulo de la biblioteca estándar de Python para funciones hash. No necesita instalación.
• hashlib.sha256(...) crea un objeto hash y procesa los bytes que le pases. Fíjate en que la entrada son bytes (b"..."), no texto: como con el cifrado en el Módulo 2, si tienes un str primero debes codificarlo con .encode("utf-8").
• .hexdigest() devuelve la huella como cadena hexadecimal (64 caracteres = 32 bytes). Su hermano .digest() devuelve los 32 bytes crudos, que es lo que usarás cuando el hash sea entrada de otra operación.

Propiedades que debe cumplir para llamarse criptográfica:

• Determinista. La misma entrada produce siempre la misma salida. Hoy, mañana y en otra máquina. Sin esto no serviría para verificar nada.
• Salida de longitud fija. 256 bits para SHA-256, 512 para SHA-512. La consecuencia inmediata: como hay infinitas entradas posibles y solo 2^256 salidas, las colisiones existen por definición (dos entradas distintas con el mismo hash). La seguridad no consiste en que no existan, sino en que sea computacionalmente inviable encontrarlas.
• Rápida de calcular. Cientos de MB/s en un portátil normal. Esto es una virtud para verificar ficheros... y, como veremos en 03-03, un desastre para contraseñas.
• Efecto avalancha. Cambiar un solo bit de la entrada cambia, de media, la mitad de los bits de la salida, de forma impredecible:

Las dos huellas no se parecen en nada. Esto es lo que hace útil al hash como detector de cambios: no hay forma de hacer una modificación "pequeña" que pase desapercibida, ni de deducir de la huella cuánto o dónde cambió la entrada.

Un modelo mental útil: una función hash criptográfica ideal se comporta como un oráculo aleatorio — una máquina que, para cada entrada nueva, elige una salida perfectamente aleatoria y la recuerda para siempre. Toda la criptografía construida sobre hashes (HMAC, firmas, KDFs) asume que el hash real se parece lo bastante a esa máquina ideal.

Que las colisiones existan pero no se puedan encontrar se formaliza en tres propiedades, ordenadas de la más fuerte a la más fácil de romper:

Detalles que conviene interiorizar:

• En la preimagen, el atacante va "hacia atrás": del hash a la entrada. Para SHA-256 cuesta del orden de 2^256 intentos — inviable para siempre, a efectos prácticos. Ojo: esto asume que la entrada es impredecible. Si la entrada tiene poca entropía (un DNI, una contraseña), el atacante no invierte el hash: prueba todas las entradas posibles y compara. Este matiz será el corazón de 03-03.
• En la segunda preimagen, el mensaje objetivo está fijado de antemano; el atacante no puede elegirlo. También cuesta ~2^256.
• En la colisión, el atacante tiene la máxima libertad: le vale cualquier par. Y esa libertad tiene un precio para el defensor, cuantificado por la paradoja del cumpleaños.

En el Módulo 1 dijimos que "128 bits es el mínimo, 256 el estándar" (regla de oro 5) y prometimos explicar por qué en los hashes la cuenta sale distinta. Aquí está.

La paradoja: ¿cuántas personas hacen falta en una sala para que sea probable (>50 %) que dos de ellas compartan cumpleaños? La intuición dice ~183 (la mitad de 365). La respuesta real es 23. La razón: no buscamos a alguien que cumpla años un día concreto (eso sí requeriría ~183 personas), sino cualquier pareja coincidente — y con 23 personas ya hay 253 parejas posibles, muchas oportunidades de colisión.

Trasladado a hashes: con salidas de n bits hay 2^n huellas posibles, pero un atacante que genere mensajes al azar espera encontrar una colisión cualquiera tras ~2^(n/2) intentos, no 2^n. Es exactamente la diferencia entre las filas de la tabla anterior:

• Atacar la preimagen o la segunda preimagen de SHA-256 cuesta ~2^256: el objetivo está fijado.
• Atacar las colisiones de SHA-256 cuesta ~2^128: el atacante acumula huellas y espera a que dos choquen.

Consecuencias prácticas:

• SHA-256 ofrece 128 bits de resistencia a colisiones — justo el mínimo aceptable de la regla de oro 5. Por eso es hoy el estándar por defecto y por eso para sistemas de muy larga vida se considera SHA-384 o SHA-512 (192 y 256 bits de resistencia a colisiones).
• Un hash de 128 bits (como MD5, incluso si no estuviera roto) solo ofrecería 2^64 de resistencia a colisiones: al alcance de un atacante bien financiado desde hace años. Ningún hash de 128 bits de salida es aceptable donde importen las colisiones.
• ¿Y te suena el 2^(n/2) de algo? Es el mismo fenómeno que limitaba los nonces en 02-03: con nonces de 96 bits de AES-GCM esperábamos una repetición hacia los 2^48 mensajes. Paradoja del cumpleaños otra vez — es una constante en criptografía.

SHA-2 es una familia diseñada por la NSA y estandarizada por el NIST en 2001: SHA-224, SHA-256, SHA-384, SHA-512 (el número es el tamaño de la salida en bits). Internamente funciona con la construcción Merkle–Damgård: trocea el mensaje en bloques y los va "comprimiendo" en un estado interno, encadenados como en una picadora. Dos apuntes prácticos:

• SHA-256 es la opción por defecto del ecosistema: TLS, Bitcoin, firmas, HMAC... Es la que usa MediNube en HKDF y la que usaremos en 03-02.
• SHA-512 es, curiosamente, más rápido que SHA-256 en CPUs de 64 bits (trabaja con palabras de 64 bits), además de más resistente. SHA-384 es SHA-512 truncado — y ese truncado lo protege de un defecto estructural de Merkle–Damgård llamado length extension que veremos en 03-02, porque es la razón histórica de que HMAC exista tal y como es.

Cuando SHA-1 empezó a tambalearse (ahora vamos), el NIST convocó un concurso público — al estilo del que dio lugar a AES — para tener un sustituto listo por si SHA-2 caía también. El ganador (2015) fue Keccak, estandarizado como SHA-3. Lo importante para ti es el panorama, no las tripas:

• SHA-3 usa una construcción interna completamente distinta, la esponja (sponge): el mensaje se "absorbe" en un estado interno grande y luego la salida se "exprime" de él. Al no ser Merkle–Damgård, es inmune por diseño al length extension.
• No es un reemplazo urgente: SHA-2 sigue sano. SHA-3 es el plan B de la criptoagilidad (regla de oro 8) — existe para que, si algún día aparece una grieta en SHA-2, el mundo tenga a dónde migrar. Está en hashlib como hashlib.sha3_256().

BLAKE2 desciende de un finalista del concurso SHA-3 y su propuesta es simple: seguridad comparable a SHA-3, pero más rápido que SHA-2 en software. Está en hashlib (blake2b para 64 bits, blake2s para 32) y tiene extras integrados como salida de tamaño configurable y modo con clave. Es una elección excelente para checksums internos de alto volumen; para todo lo interoperable, SHA-256 sigue siendo la lengua franca.

Aquí es donde la teoría de las colisiones se vuelve historia real:

• MD5 (1992, salida de 128 bits): roto en la práctica desde 2004 — generar colisiones cuesta segundos en un portátil. No fue académico: el malware estatal Flame (2012) usó una colisión de MD5 para fabricarse un certificado que parecía firmado por Microsoft, y con él se hacía pasar por una actualización legítima de Windows.
• SHA-1 (1995, salida de 160 bits): el ataque SHAttered (Google/CWI, 2017) publicó dos PDFs distintos con el mismo SHA-1. Costó ~2^63 operaciones — enorme pero pagable. Desde 2020 el ataque es de prefijo elegido (mucho más flexible) y su coste ronda las decenas de miles de dólares. Los navegadores rechazan certificados SHA-1 desde 2017.

Fíjate en el patrón: en ambos casos cayó primero la resistencia a colisiones (la propiedad "barata", 2^(n/2)); las preimágenes de MD5 y SHA-1 siguen sin estar rotas. Por eso verás sistemas antiguos usando MD5 "solo como checksum contra corrupción accidental" — técnicamente aún detecta bits volteados por un disco, pero es una pésima idea mantenerlo: invita a confundir usos y a que un auditor (con razón) te lo marque.

Un hash a secas — sin clave, sin salt, sin nada más — resuelve una familia concreta de problemas: dar una huella corta y fiable de un contenido. Usos canónicos:

• Integridad de descargas y ficheros (checksums). El proveedor publica el SHA-256 de un instalador; tú lo descargas, calculas el hash y comparas. Si coinciden, el fichero llegó intacto. (Matiz importante en el apartado final: esto solo protege si obtuviste la huella por un canal fiable.)
• Deduplicación. Si dos ficheros tienen el mismo SHA-256, son el mismo fichero: un sistema de backup puede guardar una sola copia. La resistencia a colisiones es justo lo que hace legítimo este "si el hash coincide, el contenido coincide".
• Identificadores de contenido. git identifica cada commit, fichero y árbol por su hash (SHA-1 histórico, en migración a SHA-256 precisamente por SHAttered). La dirección es la huella del contenido: si el contenido cambia, la dirección cambia. Docker hace lo mismo con las capas de las imágenes (sha256:...).
• Huella de documentos para detectar cambios — nuestro caso práctico.

Contexto: el módulo medinube.crypto ya exporta backups cifrados (02-04). Pero hay otro flujo: cuando un paciente como Ana Pérez ejerce su derecho de portabilidad (RGPD), MediNube genera un export en claro (un ZIP con PDFs) que la clínica entrega al paciente. Meses después, Ana vuelve con "su" export y hay que responder: ¿es exactamente el fichero que generamos, o alguien lo ha modificado? — recordatorio habitual: datos ficticios; un flujo real con datos sanitarios exige revisión de seguridad y compliance (RGPD) antes de desplegarse.

La solución: al generar el export, calcular su SHA-256 y guardar la huella en la base de datos de MediNube, junto al registro de la exportación.

¿Por qué aquí == y no secrets.compare_digest, con lo que insistimos en la regla de oro 6? Porque la huella no es un secreto: el atacante que quiere colar un export falso ya sabe qué hash necesita igualar (o le da igual); no hay información que filtrar por timing. La comparación en tiempo constante es para secretos (tokens, MACs — en 03-02 volverá a ser obligatoria). Distinguir cuándo aplica cada cosa es señal de que entiendes la regla, no solo la recitas.

Y la pregunta incómoda que prepara la siguiente lección: esto funciona porque la huella vive en nuestra base de datos, fuera del alcance del atacante. ¿Y si tuviéramos que enviar huella y fichero juntos por el mismo canal? Aguanta la pregunta dos apartados.

hashlib.sha256(datos) exige tener todos los bytes en memoria. Un export de imágenes médicas puede ocupar gigabytes; cargarlo entero es inviable. Para eso los objetos hash tienen update(): puedes darles el contenido por trozos y el resultado es idéntico.

Puntos clave del código:

• hashlib.sha256() sin argumentos crea el estado inicial; cada h.update(trozo) lo hace avanzar. Es la picadora de Merkle–Damgård en acción: el estado interno resume todo lo visto hasta ahora usando memoria constante (unas decenas de bytes), da igual que el fichero pese 10 GB.
• update(a); update(b) equivale exactamente a update(a + b): la huella depende solo de la concatenación total, no de cómo la trocees.
• "rb" es imprescindible: en modo texto Python tocaría los saltos de línea y la huella no coincidiría entre sistemas.
• En Python 3.11+ existe el atajo hashlib.file_digest(f, "sha256"), que hace este bucle por ti.

Cerramos con la parte que más incidentes evita. El hash a secas da integridad frente a errores, no frente a enemigos, y no protege secretos de baja entropía. Dos límites concretos:

1. Un hash no autentica. Cualquiera puede calcular el SHA-256 de cualquier cosa: la función es pública (Kerckhoffs) y no requiere ninguna clave. Si MediNube enviara a Clínica Sol un mensaje acompañado de su hash, un atacante en medio podría sustituir el mensaje y recalcular el hash del mensaje falso; la verificación de la clínica saldría correcta. El hash dice "estos bytes son estos bytes", nunca "estos bytes vienen de MediNube". Para autenticar hace falta mezclar una clave secreta en el cálculo — eso es un MAC, y es exactamente la lección 03-02.

2. Un hash no sirve para contraseñas. Guardar sha256(contraseña) parece razonable ("es unidireccional, ¿no?") y es un error clásico. La preimagen es irrompible cuando la entrada es impredecible, pero una contraseña humana no lo es: el atacante prueba diccionarios enteros a la velocidad del hash — y el hash está diseñado para ser rápido, miles de millones de intentos por segundo en GPUs. La virtud se convierte en vulnerabilidad. Las contraseñas requieren funciones deliberadamente lentas (las conociste como KDFs en 02-04, y en 03-03 las usaremos como verificadores con Argon2id).

• Usar MD5 o SHA-1 en código nuevo "porque solo es un checksum". Están rotos en colisiones y su presencia contamina auditorías. SHA-256 es igual de fácil de escribir y no exige justificaciones.
• Confundir "el hash coincide" con "el fichero es auténtico". Coincidir solo prueba integridad respecto a la huella que tienes; si la huella viajó por el mismo canal que el fichero, no prueba nada. Pregúntate siempre: ¿de dónde salió la huella y quién pudo tocarla?
• Hashear str sin fijar la codificación. hashlib exige bytes; usa siempre .encode("utf-8") explícito. Y si hasheas estructuras (JSON), serialízalas de forma canónica (claves ordenadas, sin espacios variables) o la misma información dará huellas distintas.
• Comparar todo con compare_digest "por si acaso" o, al revés, no usarlo nunca. El criterio: ¿el valor comparado es secreto o permite adivinar un secreto? Huella pública de fichero → == vale; token o MAC → tiempo constante obligatorio (03-02).
• Truncar hashes alegremente (quedarse con los primeros 8 hex "para abreviar"). Cada bit que quitas reduce la resistencia; recuerda que las colisiones ya solo valen n/2 bits. Si necesitas IDs cortos, asume y documenta el riesgo de colisión resultante.
• Consejo: interioriza la pregunta de la regla de oro 7 (objetivo antes que herramienta): "¿quién es el adversario?". ¿Un disco que corrompe bits? Hash. ¿Un atacante activo? Como mínimo, MAC.

Ejercicio 1. Sin ejecutarlo, predice qué imprime este código y explica qué propiedad(es) de las funciones hash lo justifican:

Ejercicio 2. Un compañero propone identificar los documentos adjuntos de los historiales de MediNube por su MD5 "porque es más corto y las preimágenes de MD5 no están rotas". Un paciente malicioso puede subir documentos. Explica el ataque concreto que esto permite y qué propiedad (y qué coste, en potencias de 2) lo hace viable en MD5 pero no en SHA-256.

Ejercicio 3. Escribe verificar_descarga(ruta, huella_esperada) que calcule el SHA-256 de un fichero por bloques (sin cargarlo entero) y devuelva True/False comparándolo con huella_esperada (hex, con posibles mayúsculas y espacios alrededor). Indica razonadamente si necesitas secrets.compare_digest.

Solución 1. Imprime True False True (el False con probabilidad abrumadora). h1 == h2 es True por determinismo: misma entrada, misma salida. h1[:8] == h3[:8] es False por el efecto avalancha: un bit distinto en la entrada cambia ~la mitad de los bits de salida de forma impredecible, así que ni siquiera los primeros 8 hex coinciden (la probabilidad de que coincidieran por azar es 16^-8, una entre ~4.300 millones). len(h1) == len(h3) es True por la salida de longitud fija: 64 caracteres hex siempre.

Solución 2. El paciente ejecuta un ataque de colisión (no de preimagen): genera en su ordenador dos documentos distintos con el mismo MD5 — por ejemplo, un consentimiento inocuo y otro con cláusulas alteradas; los ataques de colisión de MD5 con prefijo elegido permiten exactamente esto en segundos/minutos. Sube el inocuo, que queda registrado por su huella, y más tarde presenta el malicioso: el sistema, que identifica por MD5, los considera el mismo documento. Es viable porque la resistencia a colisiones vale ~2^(n/2) — para MD5, 2^64 en teoría y casi gratis en la práctica porque además el algoritmo está roto estructuralmente. En SHA-256 costaría ~2^128, inviable. La clave: cuando el atacante puede elegir el contenido que entra al sistema, la propiedad que te protege es la resistencia a colisiones, no la de preimagen.

Solución 3.

strip().lower() normaliza la huella pegada del exterior (los hex de hexdigest() van en minúsculas). No hace falta compare_digest: la huella de una descarga pública no es un secreto — el atacante ya la conoce —, así que no hay nada que un timing attack pueda filtrar. (Usarlo tampoco sería un error, solo innecesario.)

Ya tienes la primitiva desnuda: una función determinista, de salida fija, con efecto avalancha y resistente a preimágenes (~2^n) y a colisiones (~2^(n/2), por la paradoja del cumpleaños — promesa del Módulo 1 saldada). Sabes qué usar (SHA-256 por defecto, SHA-512/BLAKE2 cuando el rendimiento importe, SHA-3 como plan B) y qué está muerto (MD5 por Flame, SHA-1 por SHAttered). Y sabes su territorio: huellas de contenido — checksums, deduplicación, git, los exports de MediNube — siempre que la huella viva en un lugar que el atacante no controle.

Pero dejamos una pregunta abierta a propósito: si huella y mensaje viajan juntos, el atacante sustituye ambos y nadie se entera — un hash a secas no autentica, porque no tiene ningún secreto dentro. La solución es mezclar una clave compartida en el cálculo, y hacerlo bien, porque el atajo intuitivo hash(clave + mensaje) está roto de una forma muy instructiva. Eso es la lección 03-02: Autenticación de Mensajes con HMAC, donde además saldaremos dos deudas: firmar los webhooks salientes de MediNube y dejar de guardar en claro el token de recuperación de 01-03. Nos vemos allí.