Romper SHA-256 Bitcoin con Length Extension

TL;DR

Existe un ataque funcional contra SHA-256. Lo reproduje en una VM desechable en menos de diez minutos. No toca Bitcoin. El ataque es length-extension contra la construcción de Merkle-Damgård, y el doble-SHA256 de Bitcoin se publicó como defensa seis años antes del bloque génesis. Fuera de Bitcoin, la solución canónica es HMAC (RFC 2104). Grover reduce SHA-256 de 2²⁵⁶ a 2¹²⁸, todavía irrecuperable.

Qué significa realmente "SHA-256 ha sido roto"

Cada pocos meses un nuevo titular declara que SHA-256 está roto. Los foros se disparan. Un hilo de Reddit en r/cryptography (hilo 15jpuzg) y una discusión larga en Hacker News (item 36058754) giran en torno al mismo malentendido. Existe un ataque específico contra SHA-256 en un contexto específico, y el resto de internet lo aplana como "Bitcoin está en peligro."

No lo está. Trabajo en el espacio de la auto-custodia cripto, y cada vez que este titular circula, alguien me reenvía el hilo preguntando si su cold storage está en riesgo. Su cold storage no lo está. La suposición sobre cómo se usa SHA-256 en el resto de internet sí debería preocuparles.

El ataque se llama length-extension. Es real. Se reproduce en menos de diez minutos en un portátil. Bitcoin lo neutraliza por diseño. El resto de afirmaciones de "SHA-256 roto" en 2026 se reducen a length-extension (que Bitcoin maneja), a criptoanálisis académico de rondas parciales (que no ha producido un exploit práctico sobre SHA-256 completo), o a usar SHA-256 para almacenar contraseñas, un fallo de diseño y no del algoritmo.

El recorrido que sigue muestra qué hace length-extension, por qué la construcción SHA256d de Bitcoin lo hace imposible contra la cadena de hashes de Bitcoin, cómo luce la mitigación canónica en código no Bitcoin (HMAC), y el único caso de uso donde SHA-256 es genuinamente inseguro: el almacenamiento de contraseñas. Al final reproducirás el ataque contra un servidor demo deliberadamente vulnerable con una herramienta Python, y luego verás cómo ese mismo ataque falla cuando el servidor cambia a la construcción de Bitcoin.

Cómo funciona Merkle-Damgård

SHA-256 pertenece a la familia SHA-2, que comparte el mismo diseño general llamado construcción de Merkle-Damgård. Entenderlo lleva un minuto, y ese minuto vuelve obvio length-extension.

Un hash de Merkle-Damgård toma un mensaje largo y lo trocea en bloques de tamaño fijo (64 bytes para SHA-256). Arranca con un estado inicial fijo (el IV), luego ejecuta una función de compresión en cada bloque que mezcla el bloque en el estado. Tras el bloque final, el algoritmo emite el estado directamente como el digest.

Esa última frase es todo el problema. El digest final es el estado interno al cierre del cálculo. Si conoces Hash(message), conoces el estado interno de la función de compresión tras procesar message. Puedes reanudar desde ahí.

Eso explota length-extension. Dado Hash(secret || message), posees el estado al que llegó la función de compresión tras consumir secret || message. Reanudas el cálculo desde ese estado, añades cualquier dato extra que quieras, y produces un hash válido. Nunca conoces secret.

SHA-3 (Keccak) no funciona así. Su construcción esponja solo emite un truncado del estado interno, no el estado en sí. SHA-512/256, BLAKE2 y BLAKE3 usan trucos de truncamiento similares. Esos algoritmos son inmunes a length-extension por diseño. SHA-256, el algoritmo sobre el que corre Bitcoin, no lo es.

Este es el hecho estructural detrás de cada titular de "SHA-256 está roto". El ataque en código.

Cómo funciona length-extension

El ejemplo motivador canónico, usado en la entrada de Wikipedia sobre ataques de length-extension y reproducido en todos los libros de texto de criptografía desde 2009, es el siguiente.

Un servidor web firma las peticiones API calculando SHA-256(secret || params). Publica la firma junto a la petición:

GET /api?user=alice&role=user&sig=a3f1...

El servidor valida recalculando SHA-256(secret || "user=alice&role=user") y comparando con sig. La construcción parece correcta a cualquiera que no se haya parado a leer las reglas de padding de Merkle-Damgård, la mayoría de desarrolladores que escriben código en 2026.

El atacante captura un par válido (params, sig). Adivina la longitud en bytes de secret (típicamente 16, 32 o 64, recorre las tres). Calcula los bytes de padding de Merkle-Damgård que SHA-256 habría añadido a secret || params antes del paso final de compresión. El padding es determinístico (RFC 6234 §4.1). Inicializa un estado SHA-256 nuevo a partir del sig capturado, porque la firma capturada ES el estado interno de la función de compresión tras consumir secret || params || (auto-padding). Desde ese estado continúa el cálculo, introduciendo &role=admin o cualquier extensión elegida, y emite el nuevo estado como la firma falsificada.

El atacante envía:

GET /api?user=alice&role=user[bytes de padding]&role=admin&sig=<falsificado>

El servidor recalcula SHA-256(secret || "user=alice&role=user[padding]&role=admin") y llega exactamente a la firma falsificada, porque la construcción conmuta con la extensión del atacante. El atacante ahora es admin.

El exploit público más famoso de este patrón es la falsificación de la API de Flickr en 2009 por Thai Duong y Juliano Rizzo, donde la misma construcción permitió eliminar fotos sin autorización vía la API de Flickr. La técnica es más antigua (Daniel Bleichenbacher la discutió en los años 90) pero el caso Flickr la convirtió en parte fija de los programas de pentest.

Basta un par válido (params, sig) y la longitud en bytes del secreto. Esa es toda la superficie de ataque. SHA-256 no está roto en ningún sentido algorítmico. El desarrollador usó la construcción incorrecta.

Reproducir el ataque con hash_extender

Puedes reproducir el ataque en tu máquina en menos de diez minutos. El recorrido paso a paso completo está en el bloque de datos estructurados HowTo al inicio de la página. La versión resumida, con repositorios de fuente primaria.

La herramienta Python eid3t1c/Hash_Extender automatiza la falsificación de length-extension para MD5, SHA-1, SHA-256 y SHA-512. La implementación canónica anterior en C de iagox86/hash_extender (la versión original de 2014) hace el mismo trabajo y es la herramienta citada en la mayoría de tutoriales de length-extension desde 2014. Cualquiera sirve.

Combínala con magodo/sha256-length-extension-attack-demo, un servidor Flask deliberadamente vulnerable que firma cadenas de consulta con SHA-256(secret || params). Arranca el servidor, captura un token, ejecuta hash_extender, envía la falsificación. El servidor la acepta. Ahora eres admin en un servidor web cuyo secreto nunca conociste.

Cambia una línea del servidor demo. Reemplaza SHA-256(secret || params) con SHA-256(SHA-256(secret || params)) y vuelve a ejecutar el ataque. La falsificación falla. El segundo hash toma la salida completa de 256 bits como entrada, y el atacante no tiene estado interno desde el que extender. Esa edición reproduce lo que hace Bitcoin en cada hash de bloque, cada TXID, cada raíz de Merkle.

Una implementación de referencia en Rust del mismo ataque está en el análisis de Sylvain Kerkour de 2026, útil si quieres seguir la lógica de recuperación de estado a nivel de byte en un lenguaje tipado. Para la reproducción más simple, las herramientas Python anteriores son más rápidas.

Ejecuté esto de principio a fin la primera vez que trabajé en el artículo. Ver la falsificación tener éxito y luego morir contra SHA-256(SHA-256(...)) es más convincente que cualquier explicación de Merkle-Damgård en la página. Si buscas intuición criptográfica en lugar de vocabulario criptográfico, este es el ataque más barato que vas a ejecutar.

Por qué SHA256d hace a Bitcoin inmune a length-extension

Bitcoin calcula SHA-256(SHA-256(x)), llamado SHA256d, en cada lugar donde aparece un hash en el protocolo crítico de consenso. Cabeceras de bloque que alimentan la prueba de trabajo. TXIDs. Raíces de Merkle que agregan transacciones dentro de un bloque. El hash de bloque que los mineros buscan, un SHA256d que debe estar por debajo del objetivo de dificultad.

Ferguson y Schneier propusieron la construcción de doble hash en Practical Cryptography (2003) como la defensa canónica contra length-extension en SHA-2. El argumento es breve. El SHA-256 exterior se calcula sobre la salida completa de 256 bits del SHA-256 interior. Un atacante que conoce SHA256d(secret || params) no conoce el estado interno de la función de compresión exterior de ninguna forma utilizable. Para recuperar ese estado tendría que invertir el SHA-256 exterior, un ataque de preimagen con ~2²⁵⁶ operaciones. Esa es la garantía.

Una respuesta muy citada en crypto.stackexchange.com traza el razonamiento a través de Tahoe-LAFS (que adoptó SHA256d en 2006) hasta Bitcoin en 2009. El whitepaper solo dice "SHA-256" y la lista de correo de criptografía no se pronuncia sobre la elección de la construcción, por lo que no podemos probar que Satoshi eligiera SHA256d explícitamente para neutralizar length-extension. Lo que sabemos es que Ferguson-Schneier había publicado la construcción seis años antes, que Tahoe-LAFS ya la usaba para hashes de capacidad del sistema de archivos con ese mismo razonamiento, y que Bitcoin lanzó con SHA256d desde el primer día. Saca tus conclusiones. El hecho técnico se sostiene: la cadena de hashes de Bitcoin es inmune a length-extension, y el ataque que genera los titulares de "SHA-256 roto" no aplica a ninguna capa del protocolo Bitcoin.

HMAC, la solución para todos los demás

La mayoría de desarrolladores nunca escribirán SHA256d. Escribirán HMAC.

HMAC (RFC 2104) es el envoltorio universal inmune a length-extension para cualquier hash de Merkle-Damgård. Dada una función hash H (SHA-256, SHA-1, MD5, HMAC funciona para todos), HMAC se define como:

HMAC(key, message) = H( (key ⊕ opad) || H( (key ⊕ ipad) || message ) )

opad e ipad son patrones de bytes fijos (0x5c5c5c... y 0x363636...). El hash interior absorbe el mensaje. El hash exterior aplica hash sobre la salida interior con un derivado de clave distinto.

La construcción se parece a SHA256d pero es más flexible. HMAC toma una clave como parámetro de primer orden, soporta cualquier hash subyacente, y se integra limpiamente con pilas de funciones de derivación de claves. Es el estándar IETF desde RFC 2104 en 1997, y toda biblioteca criptográfica trata HMAC-SHA256 como una primitiva.

Los dos lugares donde más te lo vas a encontrar en producción son TLS 1.3, que usa HMAC-SHA256 dentro de su planificación de claves HKDF (RFC 8446 §7.1), y los tokens JWT con el algoritmo HS256, firmados como HMAC-SHA256(secret, header.payload). AWS SigV4 y WebAuthn tiran de la misma primitiva por la misma razón.

Si tu código calcula hash(secret + message) en cualquier lugar fuera de Bitcoin, reemplázalo por HMAC. Cuesta una invocación hash extra. Compras inmunidad total a length-extension.

Por qué Bitcoin se quedó con SHA-256 y no SHA-3

SHA-3 (Keccak), estandarizado por NIST en 2015 (FIPS-202), se construye sobre un diseño distinto llamado construcción esponja, inmune a length-extension por construcción. No hace falta doble hash. No hace falta envoltorio HMAC. Los hashes SHA-3 pueden usarse directamente como MACs (a veces llamado KMAC) y siguen siendo seguros.

Bitcoin sigue corriendo sobre SHA-256 en 2026 por razones de dependencia del camino más que criptográficas. Cambiar el algoritmo hash requiere un hard fork. Cada nodo completo, cada minero, cada wallet, cada explorador, cada BIP, cada esquema de firma toca SHA-256 en algún punto. La migración es técnicamente posible y políticamente catastrófica. Existen decenas de miles de millones de dólares en ASICs diseñados para calcular SHA-256 al máximo rendimiento, y reemplazar el algoritmo vuelve obsoleta toda la base de minería de la noche a la mañana. SHA-256 es más rápido que SHA-3 en CPUs modernas y mucho más rápido en ASICs, lo que importa para la verificación en cada nodo completo.

El argumento criptográfico para quedarse es más simple. SHA256d ya resuelve la única debilidad estructural de SHA-256 que importa en el modelo de amenazas de Bitcoin. No hay ningún problema activo que la migración resolviera. SHA-3 habría sido una elección defendible en 2009. El coste de migrar en 2026 supera al beneficio.

Cuántica, Grover y SHA-256

Los ordenadores cuánticos no rompen SHA-256.

El algoritmo cuántico relevante contra una función hash es Grover, que ofrece una aceleración cuadrática en búsqueda no estructurada. Para SHA-256 esto reduce la resistencia a preimagen de 2²⁵⁶ operaciones clásicas a 2¹²⁸ operaciones cuánticas. 2¹²⁸ queda fuera del alcance del hardware cuántico plausible proyectado para las próximas décadas.

El algoritmo de Shor es el que hay que temer, y no toca SHA-256. Shor ofrece aceleración exponencial en el problema del logaritmo discreto, lo que rompe ECDSA (el esquema de firma de Bitcoin) en tiempo polinomial en un ordenador cuántico suficientemente grande. El riesgo cuántico de Bitcoin vive en las firmas, no en el hash.

El panorama cuántico de 2026 para Bitcoin, incluyendo BIP-360, BIP-361 y el marco de migración PACTs, ocupa dos artículos separados en este sitio. Ver BIP-360/361: Bitcoin Resistente a la Cuántica y Computación Cuántica, Bitcoin y el Anuncio de Google en 2026. Versión corta: SHA-256 está bien. ECDSA necesita migración. Los plazos están separados por décadas.

La amenaza harvest-now-decrypt-later aplica solo a las firmas ECDSA de Bitcoin. No aplica a SHA-256 de forma significativa, porque una primitiva con resistencia 2¹²⁸ es irrecuperable se coseche o no.

Dónde falla SHA-256 con las contraseñas

El único contexto donde "SHA-256 es inseguro" es justo es el almacenamiento de contraseñas.

No tiene nada que ver con length-extension. SHA-256 es demasiado rápido. Una GPU de consumo moderna calcula miles de millones de hashes SHA-256 por segundo, y Hashcat publica los benchmarks abiertamente. Para una contraseña SHA-256 sin sal de menos de unos 15 caracteres aleatorios, un atacante con una GPU de consumo fuerza bruta el espacio completo en horas.

El almacenamiento de contraseñas requiere una función hash deliberadamente lenta y con uso intensivo de memoria, para que una GPU no tenga ventaja sobre una CPU. Usa Argon2id (RFC 9106, recomendado por OWASP en 2026), o scrypt o bcrypt si estás atrapado con una pila antigua.

Si encuentras SHA-256 usado para almacenar contraseñas en código de 2026, la solución es migrar toda la base de usuarios (típicamente volviendo a aplicar hash en el siguiente inicio de sesión). No añadas defensas de length-extension. El problema real es la velocidad de fuerza bruta, y length-extension no tiene relación con eso.

Dónde vive SHA-256 dentro de Bitcoin

En Bitcoin, SHA-256 (casi siempre como SHA256d) aparece en varios roles distintos:

Cada uno supondría una pérdida catastrófica de integridad si SHA-256 se rompiera. Ninguno está en riesgo práctico en 2026. Los ataques prácticos conocidos (length-extension, colisiones de rondas parciales en 31-de-64 rondas, fuerza bruta GPU rápida en espacios de entrada pequeños) no alcanzan al SHA-256 completo en ningún rol que importe en Bitcoin.

La comparación relevante es SHA-1, roto en la práctica por el ataque de colisión SHAttered de Google en 2017 contra SHA-1 completo. SHA-256 no está en ese estado y no tiene ninguna trayectoria criptanalítica de corto plazo hacia él.

SHA-256 en 2026, por caso de uso

La cadena aguanta. Cada uso de SHA-256 crítico para el consenso en Bitcoin pasa por SHA256d, ya mostré que es inmune a length-extension. No existe ataque práctico de preimagen sobre SHA-256 completo en 2026, ni ataque de colisión práctico, ni nada en el horizonte criptanalítico que se aproxime. Minería Bitcoin, TXIDs, raíces de Merkle, direcciones P2PKH y P2WPKH, derivación de semilla BIP-39 vía PBKDF2-HMAC-SHA512: todo seguro.

Fuera de Bitcoin, donde SHA-256 esté detrás de un envoltorio HMAC (firma de registros TLS 1.3, JWT-HS256, AWS SigV4) también es seguro. SHA-256 en crudo usado para direccionamiento por contenido, como pre-hash para firmas digitales o para integridad de archivos a largo plazo está bien, porque length-extension es irrelevante cuando no hay secreto ni MAC.

Dos patrones siguen fallando en 2026, corrígelos ya. Los MACs caseros con forma Hash(secret || message) se falsifican trivialmente vía length-extension. Cámbialo por HMAC. El almacenamiento de contraseñas SHA-256 en crudo, con sal o sin ella, lo fuerza-brutea una sola GPU porque SHA-256 es demasiado rápido. Cámbialo por Argon2id.

Ambos son fallos de construcción, no del algoritmo. SHA-256 sigue haciendo el trabajo que ha venido haciendo desde 2001.

Lecturas adicionales

Este artículo forma parte de un conjunto en www.btc2h.com sobre las primitivas criptográficas de las que depende Bitcoin, y qué significa la investigación actual para cada una. Tres lecturas complementarias:

• BIP-360 / BIP-361: El Plan de Migración de Bitcoin Resistente a la Cuántica cubre el panorama cuántico del lado de las firmas, donde vive el riesgo real a largo plazo.
• Computación Cuántica, Bitcoin y el Anuncio de Google en 2026 pone el ciclo de noticias sobre hardware cuántico de 2026 en contexto.
• Tutorial de btcrecover 2026 muestra por qué la velocidad de fuerza bruta GPU de SHA-256 es la respuesta correcta para la recuperación de contraseñas de wallets y la respuesta equivocada para el almacenamiento de contraseñas.

Bibliografía de fuentes primarias para este artículo (verificado accesible 2026-05-12 salvo indicación):

• Wikipedia, Ataque de extensión de longitud
• Wikipedia, SHA-2
• RFC 6234, US Secure Hash Algorithms (especificación de padding SHA-256)
• RFC 2104, HMAC Keyed-Hashing for Message Authentication
• crypto.stackexchange.com Q779, ¿Por qué Bitcoin usa SHA-256 doble?
• Reddit r/cryptography, hilo de length-extension SHA-256
• Hacker News hilo 36058754
• arXiv 2406.20072, criptoanálisis SHA-256 de rondas parciales (afirmación: resultados de rondas parciales, sin ataque práctico de ronda completa. Verificar con el resumen del artículo antes de citar límites numéricos.)
• Kerkour, Breaking SHA-2 length extension attacks in practice with Rust
• eid3t1c/Hash_Extender (herramienta de ataque Python)
• magodo/sha256-length-extension-attack-demo (servidor Flask vulnerable)
• sjlombardo length-extension gist (2012)
• Ferguson & Schneier, Practical Cryptography (2003), la publicación canónica de SHA256d

Aviso legal

Este artículo es contenido educativo para titulares y desarrolladores de Bitcoin. No constituye asesoramiento legal, financiero ni de ingeniería criptográfica. Los despliegues criptográficos en producción requieren revisión formal por especialistas cualificados. No implementes código crítico para la seguridad a partir de una entrada de blog. Para sistemas en producción que manejen secretos, usa bibliotecas probadas en batalla (libsodium, OpenSSL, Bouncy Castle) en lugar de crear tus propias primitivas. Para preguntas legales o de cumplimiento sobre agilidad criptográfica bajo FINMA, GDPR o NIS2, consulta a asesores cualificados.