A partir del lanzamiento de FreeBSD pkg 2.8.0, SHA-256 será eliminado gradualmente y Blake2b se utilizará para sumas de verificación (¿medida contra la computación cuántica?)

Hola, soy un incompetente.
Cuando el lanzamiento de freebsd/pkg apareció en mi línea de tiempo de Github, me encontré con la palabra Blake2b.

https://github.com/freebsd/pkg/releases#release-2.8.0

• Blake2b se utiliza siempre que es posible para las sumas de comprobación; los repositorios utilizan blake2 en lugar de sha256

Parece que este Blake2b en sí mismo ya estaba incluido y lanzado en GNU coreutils en 2016.

¿Qué es Blake2b en primer lugar?

Solo lo había investigado un poco antes y solo lo reconocía como uno de los algoritmos de hash, así que lo verifiqué brevemente.

Implementé Blake2 (Blake2b) en Rust #Security - Qiita

Hay dos tipos de Blake2: la versión normal Blake2b y la versión reducida Blake2s. Blake2b es para 64 bits y Blake2s es para 8~32 bits.

Ya veo.

RFC:
RFC 7693 - The BLAKE2 Cryptographic Hash and Message Authentication Code (MAC)

Es algo que también se utiliza en el hash de contraseñas de Argon2. ¿Se convertirá en un diseño moderno reemplazar las implementaciones que actualmente usan bcrypt por Argon2 para el hash de contraseñas, y las que usan SHA-256 por Blake2 para el hash criptográfico? Pensé que podría ser posible, ya que ya se ven implementaciones que utilizan Argon2 recientemente. Dicho esto, md5sum y similares todavía se utilizan como hashes ligeros y rápidos, y son convenientes si solo se trata de verificar la integridad de forma sencilla. Incluso WebSocket, aunque el RFC establece que se utiliza SHA-1 para el WebSocket Handshake, también menciona que no tiene sentido cambiarlo en el caso de las implementaciones de WS.

El handshake de WebSocket descrito en este documento no depende de las propiedades de seguridad de SHA-1 (como la resistencia a colisiones o la resistencia a ataques de segunda preimagen) (descrito en [RFC4270]).

RFC 6455 - The WebSocket Protocol

Como ya puedo consultar esta duda, se lo pregunté a ChatGPT (GPT 5.6).
La conclusión es que la migración a Argon2 es adecuada como modernización, pero para el hash criptográfico, parece que simplemente ha aumentado una opción más.
Sin embargo, el hecho de que FreeBSD haya cambiado el uso de checksum en pkg fue bastante sorprendente, así que ¿podría convertirse en algo estándar en un futuro no muy lejano?

A continuación, la pregunta a GPT 5.6

P. ¿Se convertirá en un diseño moderno reemplazar las implementaciones que actualmente usan bcrypt por Argon2 para el hash de contraseñas, y las que usan SHA-256 por Blake2 para el hash criptográfico?

R. Sí, se puede decir que el paso de bcrypt a Argon2id para el almacenamiento de contraseñas es una verdadera "modernización". Por otro lado, el paso de SHA-256 a BLAKE2 para hashes criptográficos de propósito general no es necesariamente un simple relevo generacional.

Para contraseñas, actualmente el orden de prioridad es más o menos el siguiente.

OWASP también posiciona a Argon2id como la primera opción para nuevos sistemas, y a bcrypt principalmente para sistemas existentes. Dado que Argon2id es una KDF memory-hard que puede incorporar el uso de memoria como costo de ataque, además de la carga de CPU, es superior a bcrypt por diseño contra ataques de fuerza bruta de contraseñas que utilizan GPU/ASIC a gran escala. (OWASP Cheat Sheet Series)

Por ejemplo, en una nueva implementación, una configuración como la siguiente es natural:

password
   ↓
Argon2id(
    salt = random 128bit,
    memory = 64 MiB,
    iterations = 3,
    parallelism = según corresponda
)
   ↓
$argon2id$v=19$m=65536,t=3,p=...

El RFC 9106 también recomienda Argon2id. (Editor RFC)

Por otro lado,

SHA-256 → BLAKE2

es un poco diferente.

No es que SHA-256 se haya vuelto antiguo y peligroso.

Actualmente no se conocen ataques prácticos de colisión o de preimagen para SHA-256, y sigue siendo lo suficientemente fuerte para usos criptográficos normales.

Las ventajas de BLAKE2 son principalmente:

Rápido
+
Alta seguridad
+
Tiene keyed hashing como estándar
+
Fácil de implementar

Por lo tanto,

Antiguo                  Moderno
bcrypt      ───────→ Argon2id
                 ↑Bastante claro
SHA-256     ───────→ BLAKE2
                 ↑
          No es necesariamente un reemplazo

es una forma cercana de entenderlo.

Más bien, en el diseño actual,

Password
 └─ Argon2id
Cryptographic digest
 ├─ SHA-256
 ├─ SHA-3
 ├─ BLAKE2
 └─ BLAKE3
Message authentication
 ├─ HMAC-SHA256
 └─ keyed BLAKE2

es moderno elegir según el propósito, como se muestra arriba.

En particular, para software nuevo que diseñes tú mismo, si no hay restricciones como la compatibilidad de protocolos, creo que es bueno pensar en términos de:

Password hashing
→ Argon2id
Hash rápido general
→ BLAKE2b / BLAKE3
Prioridad de compatibilidad con estándares/protocolos externos
→ SHA-256
MAC
→ HMAC-SHA256
  o keyed BLAKE2

Y lo importante son BLAKE2 y BLAKE3. Si el objetivo al diseñar algo nuevo es "quiero usar un hash más rápido que SHA-256", para el año 2026 deberías considerar no solo BLAKE2, sino también BLAKE3. BLAKE3 es extremadamente rápido para paralelización, SIMD y hashing de datos grandes.

Sin embargo,

SHA-256 → BLAKE3

no es tanto "descartar SHA-256 por seguridad", sino más bien:

una elección para obtener beneficios en rendimiento y diseño de API

es.

En otras palabras, las dos preguntas no están al mismo nivel, sino que existe esta diferencia:

bcrypt → Argon2id

Una dirección para modernizar claramente el diseño de seguridad.

SHA-256 → BLAKE2/BLAKE3

No es una migración obligatoria por seguridad, sino una elección basada en el rendimiento y la facilidad de uso en nuevos diseños.

Si extendemos esto a "qué elegir si diseñaras desde cero en 2026 una API que incluya autenticación, firmas, cifrado y hash de archivos", basarse en Argon2id / BLAKE3 / XChaCha20-Poly1305 / Ed25519 / X25519 resultaría en una configuración bastante moderna.