Puntos Esenciales
- BLAKE3 es una función hash criptográfica de 2020 que reparte el trabajo entre bloques de 1 KiB organizados en un árbol de Merkle.
- Ese árbol permite aprovechar varios núcleos y vectores SIMD, por eso su paper la mide hasta 12 veces más rápida que SHA-256.
- Con un solo algoritmo ofrece hash, hash con clave, derivación de claves y salida extensible, pero no es estándar de NIST ni vale para contraseñas.
- Se usa en OpenZFS o Chia, mientras que Bitcoin, Cardano y Zcash siguen con SHA-256 o BLAKE2b.
La función hash BLAKE3 convierte cualquier dato, desde un mensaje corto hasta un disco entero, en una huella de 256 bits por defecto, y lo hace mucho más deprisa que SHA-256 en los procesadores actuales. La diseñaron Jack O’Connor, Jean-Philippe Aumasson, Samuel Neves y Zooko Wilcox-O’Hearn, y la presentaron en enero de 2020 en la conferencia Real World Crypto como un único algoritmo, sin variantes, pensado para ir rápido en cualquier equipo.
El dato que mejor resume su ventaja sale del paper oficial de BLAKE3: en un servidor Intel de 2019, su velocidad máxima con un solo hilo es 12 veces la de SHA-256. Esa velocidad nace de cortar los datos en trozos pequeños y organizarlos en un árbol, de modo que muchos trozos se calculan a la vez en lugar de uno detrás de otro.
Conviene matizar desde el principio que rápida no significa mejor en todo. BLAKE3 no es un estándar de NIST ni una RFC del IETF, no sirve para guardar contraseñas y no ha sustituido a SHA-256 en Bitcoin, según su white paper. Verás cómo funciona por dentro, en qué se diferencia de SHA-256, SHA-3 y BLAKE2, y dónde se usa de verdad, con fuentes y fechas.
¿Qué es la función hash BLAKE3 y quién la creó?
Una función hash toma una entrada de cualquier tamaño y devuelve una huella de longitud fija: si cambias un solo bit de la entrada, la huella cambia por completo, y resulta inviable encontrar dos entradas con la misma huella. Con ella compruebas que un archivo no se ha alterado o enlazas los bloques de una blockchain. BLAKE3 cumple ese papel y, según su README oficial, también cubre usos como MAC y derivación de claves, que se explican más abajo.
Es la tercera generación de una familia. BLAKE2, anunciada en 2012 según el paper, ya estaba en OpenSSL y en las bibliotecas estándar de Python y Go, y la describe la RFC 7693, de noviembre de 2015 y de carácter informativo. BLAKE3 parte de una versión optimizada de BLAKE2 y del modo en árbol del proyecto Bao, y cambia la cadena secuencial por un árbol binario.
Sus cuatro diseñadores son Jack O’Connor, Samuel Neves, Jean-Philippe Aumasson y Zooko Wilcox-O’Hearn, y el repositorio oficial señala que Electric Coin Company patrocinó su desarrollo. O’Connor contó en enero de 2020 que él y Aumasson la anunciaron en las charlas relámpago de Real World Crypto y que el historial público de los repositorios arranca el 9 de enero de 2020.
El proyecto se publica en dominio público bajo CC0 1.0 o, a elección de quien lo use, bajo licencia Apache 2.0. Cuenta con una especificación en el proyecto C2SP, una biblioteca oficial en Rust, otra en C y la herramienta de línea de comandos b3sum, lo que facilita que cualquier programa la incorpore sin fricciones de licencia.
¿Cómo funciona el árbol de Merkle de BLAKE3 y por qué permite paralelizar?
Según el paper, BLAKE3 divide la entrada en chunks de 1024 bytes y cada chunk en bloques de 64 bytes. Cada chunk se comprime de forma independiente, con un contador que indica su posición, y da un valor de 256 bits que es una hoja del árbol. El último bloque de cada chunk lleva una marca que señala dónde termina.
Los valores de dos chunks vecinos se combinan en un nodo padre, mediante una única llamada a la función de compresión, y así se sube nivel a nivel hasta la raíz del árbol, cuyo valor es el hash final. Puedes repasar la idea en la guía de qué es un árbol de Merkle, la estructura que BLAKE3 aplica a un archivo y Bitcoin a las transacciones de un bloque.
El paper fija dos reglas para que todos los programas construyan el mismo árbol: los subárboles de la izquierda están siempre llenos, con un número de chunks que es potencia de 2, y no son menores que su hermano de la derecha. Así, un archivo de 4 KiB tiene 4 chunks y 3 nodos padre, uno menos.
La función de compresión es la de BLAKE2s, con palabras de 32 bits, pero con 7 rondas en lugar de las 10 de BLAKE2s. La raíz lleva una bandera propia, y el paper se apoya en ella para argumentar que BLAKE3 evita los ataques de extensión de longitud que afectan a SHA-2.
Como cada chunk se comprime sin depender de los demás, el paralelismo es igual al número de chunks y el paper lo describe como no acotado. Hay dos palancas: las instrucciones SIMD procesan varios chunks a la vez (4 con vectores de 128 bits y 8 con vectores de 256 bits) y los hilos reparten subárboles entre núcleos.
La biblioteca oficial en Rust incluye implementaciones para SSE2, SSE4.1, AVX2, AVX-512, NEON y WASM, con detección automática del procesador en x86, y su característica rayon activa el multihilo. La herramienta b3sum usa varios hilos por defecto, y el README afirma que es un orden de magnitud más rápida que sha256sum en equipos de escritorio típicos.
El paralelismo no es gratis. Con entradas de hasta 1 KiB solo hay un chunk, y con menos de 128 KiB el coste de coordinar hilos es alto. En la máquina de 48 núcleos del paper la velocidad crece casi de forma lineal hasta 16 hilos y después se estabiliza por el ancho de banda de la memoria.
Además, el árbol aporta dos capacidades que una función secuencial no tiene y que el paper detalla en su sección de aplicaciones, donde explica cómo aprovecharlas en programas reales con datos remotos o que cambian a menudo.
- Streaming verificado: si conoces el hash de un archivo, puedes descargarlo de un host no confiable y comprobar cada chunk según llega. El espacio extra de los nodos padre tiende a un 6,25 %.
- Actualizaciones incrementales: si editas unos bytes, solo recalculas los chunks modificados y sus nodos padre hasta la raíz, aunque insertar o borrar bytes en medio obliga a recalcular lo que queda a la derecha.

¿Qué son la salida extensible, el hash con clave y derive_key?
BLAKE3 define tres modos con el mismo algoritmo. El modo hash calcula la huella normal, el modo keyed_hash recibe una clave de 256 bits y cubre los usos de MAC y PRF, y el modo derive_key genera claves derivadas a partir de un texto de contexto y de material de clave. Los tres pueden producir una salida de cualquier longitud, no solo de 256 bits.
La salida extensible, o XOF por sus siglas en inglés, repite la última compresión con un contador que se incrementa y concatena los resultados. Por eso las salidas cortas son prefijos de las largas, se pueden calcular en paralelo y puedes saltar a cualquier punto. SHA-3 tiene SHAKE128 y SHAKE256 en la norma FIPS 202 del NIST, pero el paper señala que la de BLAKE3 es paralelizable y accesible por posición, a diferencia de SHA-3 o HKDF.
El modo con clave evita montar una construcción aparte como HMAC. Según el paper, BLAKE2 necesita una compresión extra para el bloque de la clave y HMAC necesita tres, mientras que keyed_hash no necesita ninguna, lo que se nota en mensajes cortos. La clave debe tener 32 bytes y tratarse como secreto, igual que con cualquier MAC.
El modo derive_key exige disciplina. El contexto debe estar escrito en el código, ser único en el mundo y específico de la aplicación, sin sales, identificadores ni la hora actual, y el paper propone un formato como «example.com 2019-12-25 16:18:03 session tokens v1». Un contexto dinámico rompe la garantía de aislar unos componentes de otros.
Los propios autores añaden un aviso: BLAKE3 no es una función para guardar contraseñas, porque está diseñada para ser rápida y eso favorece a quien intenta adivinarlas. Recomiendan Argon2 para ese fin.

¿En qué se diferencia BLAKE3 de SHA-256, SHA-3 y BLAKE2 y cuánto corre más?
SHA-256 pertenece a la familia SHA-2, que el NIST recoge en la norma FIPS 180-4, y SHA-3 se basa en Keccak y se normalizó en agosto de 2015 en la FIPS 202. BLAKE2 nació como alternativa rápida y BLAKE3 es su evolución en forma de árbol. La mayor diferencia es la estructura interna, aunque también cambian el estado de normalización y las funciones adicionales.
| Característica | BLAKE3 | SHA-256 | SHA3-256 | BLAKE2b y BLAKE2s |
|---|---|---|---|---|
| Documento de referencia | Paper y especificación C2SP | FIPS 180-4 | FIPS 202 | RFC 7693 (informativa) |
| Construcción interna | Árbol binario de Merkle | Bloques en secuencia | Esponja de Keccak | Bloques en secuencia |
| Aprobación de NIST | No figura entre las aprobadas | Aprobada | Aprobada | No figura entre las aprobadas |
| Salida por defecto | 256 bits, ampliable | 256 bits | 256 bits | Hasta 64 bytes (b) o 32 bytes (s) |
| Salida extensible | Integrada | No | No, pero SHAKE128 y SHAKE256 sí | Con la variante BLAKE2X |
| Rondas de compresión | 7 | Otro diseño, no comparable | Otro diseño, no comparable | 12 (BLAKE2b) y 10 (BLAKE2s) |
| Extensión de longitud | Resistente | Vulnerable | No comparado aquí | No comparado aquí |
Los datos proceden del paper de BLAKE3, del README del repositorio oficial, de la RFC 7693 y de las páginas del NIST sobre FIPS 180-4 y FIPS 202, consultadas el 1 de noviembre de 2026. La lista de funciones aprobadas por NIST incluye SHA-1, SHA-2 y las cuatro variantes fijas de SHA-3, y no menciona BLAKE.
SHA-256 y SHA-512 comprimen los bloques uno tras otro, y el paper explica que por eso no aprovechan las instrucciones vectoriales como BLAKE3. Para elegir importa más tu contexto que la velocidad en bruto: si tu proyecto exige algoritmos aprobados por NIST, SHA-256 o SHA-3 siguen siendo la opción que cumple. Si te interesa el hash de Bitcoin, la guía de SHA-256 y el algoritmo de Bitcoin lo explica paso a paso.
Las cifras de velocidad fiables salen del paper de los autores y hay que leerlas con su contexto. Son comparaciones del propio equipo de BLAKE3, hechas con una máquina concreta de Amazon Web Services y con SHA-2 de OpenSSL 1.1.1.d, y el paper precisa que el rendimiento depende de la plataforma y del tamaño de la entrada.
| Plataforma | Comparación con un solo hilo | Veces más rápida BLAKE3 |
|---|---|---|
| Intel Cascade Lake-SP (AWS c5.metal, con AVX-512) | Frente a BLAKE2b | 4 |
| Intel Cascade Lake-SP (AWS c5.metal, con AVX-512) | Frente a SHA-512 | 8 |
| Intel Cascade Lake-SP (AWS c5.metal, con AVX-512) | Frente a SHA-256 | 12 |
| ARM1176 de 32 bits (Raspberry Pi Zero) | Frente a SHA-256 | 1,3 |
| ARM1176 de 32 bits (Raspberry Pi Zero) | Frente a BLAKE2b y SHA-512 | 3 |
Son velocidades máximas, extraídas del resumen del paper en su versión 20211102173700, del 2 de noviembre de 2021. El README añade que su gráfico de ejemplo usa entradas de 16 KiB en una CPU Cascade Lake-SP 8275CL de 2019.
Dos matices evitan sobreinterpretar la tabla. La ventaja se concentra en entradas medianas y grandes, y el paper reconoce que BLAKE2bp y BLAKE2sp la superan en torno a 1-4 KiB. Además, las pruebas son del equipo que diseñó la función y de hardware de 2019, así que conviene medir con tus datos.
¿Es seguro BLAKE3?
El paper fija como objetivo 128 bits de seguridad frente a ataques de preimagen, de colisión y de diferenciabilidad, y usa claves de 256 bits como defensa extra contra claves mal elegidas. Apuntar a 128 bits significa que romperla exigiría del orden de 2^128 operaciones, algo fuera del alcance actual, aunque no es una garantía eterna.
La parte delicada es la reducción de rondas. BLAKE3 pasa de las 10 de BLAKE2s a 7, y los autores la justifican con diez años de criptoanálisis y con «Too Much Crypto», un estudio de Aumasson según el cual esas funciones serían igual de sólidas con menos rondas. Menos rondas implican, por definición, menos margen ante ataques desconocidos, y BLAKE3 se presentó en 2020, cinco años después de normalizarse SHA-3.
La literatura pública dice esto: el ePrint 2023/299, de febrero de 2023, afirma haber atacado por primera vez las 7 rondas completas de BLAKE3 con un ataque boomerang de complejidad 2^180. Apunta a la permutación con clave y no al hash completo, y su coste supera con mucho los 2^128 del diseño, así que no es práctico.
La afirmación honesta es que BLAKE3 está analizada públicamente y tiene un objetivo de seguridad claro, no que sea más segura que SHA-256 o SHA-3. Aumasson escribió el 7 de marzo de 2026 que no es estándar de NIST ni RFC del IETF, aunque la ve como gran opción por su velocidad.
¿Dónde se usa BLAKE3 en software y en cadenas de bloques?
El README del repositorio oficial lista proyectos que la han adoptado y, a 1 de noviembre de 2026, nombra entre otros a Bazel y a LLVM. Estos cuatro usos tienen una fuente que puedes comprobar por tu cuenta.
| Proyecto | Qué hace con BLAKE3 | Dato y fecha |
|---|---|---|
| OpenZFS | Ofrece blake3 como algoritmo de checksum | Versión 2.2.0, publicada el 13 de octubre de 2023, que lo recomienda como checksum seguro |
| Chia | Lo usa en la prueba de espacio en lugar de los métodos AES | Versión 1.0beta8, del 16 de julio de 2020 |
| IPFS | Tiene un código de multihash propio para BLAKE3 (0x1e) | Estado «draft» en la tabla de multicodec, a 1 de noviembre de 2026 |
| Solana | Ofrece funciones hash y hashv con BLAKE3 en su biblioteca | Crate solana-blake3-hasher 3.1.0, a 1 de noviembre de 2026 |
La guía sobre qué es IPFS explica cómo ese sistema identifica los contenidos por su hash. Las notas de OpenZFS 2.2.0 describen BLAKE3 como una función moderna centrada en el rendimiento y mucho más rápida que sha256 y sha512.
También es útil saber qué no usa BLAKE3, porque circulan atribuciones erróneas. No es el hash de Bitcoin, cuyo white paper habla de SHA-256 en la prueba de trabajo, ni el de Cardano ni el de Zcash. En el kernel de Linux y en WireGuard, la función que aparece es BLAKE2s, hermana de BLAKE3 pero distinta.
| Sistema | Función que usa | Fuente y fecha |
|---|---|---|
| Bitcoin | SHA-256 en la prueba de trabajo | White paper de Bitcoin |
| Cardano | BLAKE2b-224 en los hashes de claves de sus direcciones | CIP-19 de Cardano |
| Zcash | BLAKE2b-256 en la derivación de claves | ZIP 32 de Zcash |
| Linux 5.17 | BLAKE2s en el generador de números aleatorios, en lugar de SHA-1 | Publicado el 20 de marzo de 2022 |
| WireGuard | BLAKE2s para hashing y hashing con clave | Protocolo de WireGuard |
| Btrfs | crc32c, xxhash, sha256 y BLAKE2b, sin BLAKE3 | Documentación de Btrfs, a 1 de noviembre de 2026 |
Estado actual de BLAKE3 en noviembre de 2026
A 1 de noviembre de 2026 la última versión de la biblioteca oficial en Rust es la 1.8.7, publicada el 20 de agosto de 2026, que retiró la dependencia arrayref según sus notas. Antes llegó la 1.8.6, del 5 de agosto de 2026, con mejoras en la lectura de archivos con mmap.
| Aspecto | Estado a 1 de noviembre de 2026 |
|---|---|
| Última versión de la biblioteca Rust | 1.8.7, del 20 de agosto de 2026 |
| Especificación | Paper de los autores (versión del 2 de noviembre de 2021) y especificación C2SP |
| Normalización | No es estándar de NIST ni RFC del IETF, según Aumasson el 7 de marzo de 2026 |
| Contraseñas | Desaconsejada, se recomienda Argon2 |
Estos valores cambian con cada versión, así que el repositorio oficial y su página de lanzamientos son la fuente más fiable. No hay una cifra de adopción total, porque la lista del README solo recoge los proyectos que sus responsables han querido añadir.
Cuándo elegir BLAKE3 y cuándo quedarte con SHA-256
BLAKE3 encaja en tareas donde hay que hashear grandes volúmenes de datos con rapidez y sin una norma que lo impida, como sistemas de archivos, cachés de compilación o verificación de descargas. Para probar la función hash BLAKE3 en tu ordenador instala la herramienta oficial con cargo install b3sum, ejecuta b3sum archivo.iso, compara con sha256sum sobre el mismo archivo y mide el tiempo en tu equipo.
No encaja cuando necesitas una función aprobada por NIST, cuando el protocolo ya está fijado con otra función, como ocurre en Bitcoin, o cuando buscas guardar contraseñas. Recuerda además que ninguna función hash protege tus fondos por sí sola, porque cuentan también la custodia de tus claves y los riesgos propios de cada activo digital.



Autor


