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 fue publicado como defensa seis años antes del bloque génesis. Fuera de Bitcoin, la solución canónica es HMAC (RFC 2104). El algoritmo de Grover reduce SHA-256 de 2²⁵⁶ a 2¹²⁸, lo que sigue siendo efectivamente infinito.

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

Cada pocos meses un nuevo titular declara que SHA-256 ha sido roto. Los foros se disparan. Un hilo de Reddit en r/cryptography (hilo 15jpuzg) y una larga discusión 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 está en riesgo. Su suposición sobre cómo se usa SHA-256 en el resto de internet es la parte que debería preocuparles.

El ataque se llama ataque de length-extension. Es real. Es reproducible en menos de diez minutos en un portátil. Bitcoin lo neutraliza por diseño. Cada otra reclamación de "SHA-256 roto" en 2026 se reduce 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 un uso incorrecto de SHA-256 para el almacenamiento de contraseñas, que es un fallo de diseño y no un fallo del algoritmo.

El recorrido que sigue muestra qué hace realmente 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 es miembro de la familia SHA-2, que comparte el mismo diseño general llamado construcción de Merkle-Damgård. Entenderlo lleva aproximadamente un minuto, y ese minuto es lo que hace 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). Comienza 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 hash.

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

Eso es lo que 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 de esta manera. 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 funciona Bitcoin, no lo es.

Este es el hecho estructural detrás de cada titular de "SHA-256 está roto". Ahora 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 haya observado detenidamente las reglas de padding de Merkle-Damgård, que es 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, por lo que 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). Luego 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 SHA-256, 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ó la eliminación no autorizada de fotos a través de la API de Flickr. La técnica es más antigua (Daniel Bleichenbacher la discutió en los años 90) pero el caso de Flickr la convirtió en un elemento fijo de los programas de pruebas de penetración.

Solo necesitas 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 simplemente usó la construcción incorrecta.

Reproducir el ataque con hash_extender

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

La herramienta de ataque 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 por 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.

Luego 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 única 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 cómo la falsificación tiene éxito y luego ver cómo muere 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 puedes 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 de minería. IDs de transacciones. 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 los ataques de 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, lo que es un ataque de preimagen con aproximadamente 2²⁵⁶ operaciones. Esa es la garantía de seguridad.

Una respuesta ampliamente citada en crypto.stackexchange.com traza el razonamiento a través de Tahoe-LAFS (que adoptó SHA256d en 2006) hasta la adopción de 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 explícitamente SHA256d para neutralizar length-extension. Lo que sí 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 exactamente ese razonamiento, y que Bitcoin se lanzó con SHA256d desde el primer día. Saca tus propias conclusiones. El hecho técnico se sostiene de todas formas: 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 de software 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. Dado una función hash H (SHA-256, SHA-1, MD5, HMAC funciona para todos ellos), 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 a la salida interior con un derivado de clave diferente.

La construcción es similar a SHA256d pero 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. Ha sido el estándar IETF desde que RFC 2104 se publicó en 1997, y toda biblioteca criptográfica trata HMAC-SHA256 como una primitiva.

Los dos lugares donde más a menudo te encontrarás con él 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, que se firman 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 con HMAC. El coste es una invocación hash adicional. La ganancia de seguridad es 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), está construido sobre un diseño fundamentalmente diferente llamado construcción esponja, que es inmune a length-extension por construcción. No se necesita doble hash. No se necesita envoltorio HMAC. Los hashes SHA-3 pueden usarse directamente como MACs (a veces llamado KMAC) y siguen siendo seguros.

Bitcoin sigue funcionando sobre SHA-256 en 2026 por razones que son principalmente 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 de bloques, cada BIP, cada esquema de firma toca SHA-256 en algún punto. Una migración coordinada es técnicamente posible pero políticamente catastrófica. Existen decenas de miles de millones de dólares en hardware ASIC específicamente diseñado 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 también es más rápido que SHA-3 en las CPUs modernas y dramáticamente 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 solventaría. SHA-3 habría sido una elección defendible en 2009. El coste de la migración en 2026 supera con creces el 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 el algoritmo de Grover, que ofrece una aceleración cuadrática en la búsqueda no estructurada. Para SHA-256 esto reduce la resistencia a preimagen de 2²⁵⁶ operaciones clásicas a 2¹²⁸ operaciones cuánticas. 2¹²⁸ sigue siendo efectivamente infinito, muy por encima de cualquier hardware cuántico plausible proyectado para las próximas décadas.

El algoritmo de Shor es el que hay que temer realmente, y no toca SHA-256. Shor ofrece una 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 actual de 2026 para Bitcoin específicamente, incluyendo BIP-360, BIP-361 y el marco de migración PACTs, es el tema de 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. La versión corta: SHA-256 está bien. ECDSA necesita migración. Los plazos para ambos están separados por décadas.

La amenaza de harvest-now-decrypt-later se aplica solo a las firmas ECDSA de Bitcoin. No se aplica a SHA-256 de ninguna manera 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.

Esto 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 que sea deliberadamente lenta y con uso intensivo de memoria, de modo 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 más antigua.

Si encuentras SHA-256 usado para el almacenamiento de 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

Para Bitcoin específicamente, SHA-256 (casi siempre como SHA256d) aparece en varios roles distintos:

Cada uno de ellos 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 el algoritmo SHA-256 completo en ningún rol que importe en Bitcoin.

La comparación relevante es SHA-1, que fue 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 a corto plazo hacia él.

El veredicto de 2026, por caso de uso

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

Fuera de Bitcoin, en cualquier lugar 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 el direccionamiento por contenido, como pre-hash para firmas digitales o para comprobaciones de 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 y deberías corregirlos de inmediato. Los MACs caseros con la forma Hash(secret || message) se falsifican trivialmente mediante length-extension. Cámbialo por HMAC. El almacenamiento de contraseñas SHA-256 en crudo, con sal o sin ella, es fuerza-bruteado por una sola GPU porque SHA-256 es demasiado rápido. Cámbialo por Argon2id.

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

Lecturas adicionales

Este artículo forma parte de un pequeño conjunto en btc2h.com que examina las primitivas criptográficas de las que depende realmente Bitcoin, y qué significa la investigación actual para cada una de ellas. 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 el mundo real 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 de 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.