A partir do lançamento do FreeBSD pkg 2.8.0, o SHA-256 será gradualmente descontinuado e o Blake2b será usado para checksums (medida pós-quântica?)

Olá, sou um incompetente.
Ao ver o lançamento do freebsd/pkg na linha do tempo do Github, deparei-me com o caractere Blake2b.

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

• Blake2b usado sempre que possível para checksums; os repositórios usam blake2 em vez de sha256

O próprio Blake2b parece ter sido incluído e lançado no GNU coreutils em 2016.

O que é o Blake2b afinal?

Como só tinha pesquisado brevemente antes e apenas o reconhecia como um algoritmo de hash, verifiquei rapidamente.

Implementei o Blake2 (Blake2b) em Rust #Security - Qiita

Existem dois tipos de Blake2: a versão normal Blake2b e a versão reduzida Blake2s. O Blake2b é para 64 bits e o Blake2s é para 8~32 bits.

Entendi.

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

É também o que é usado para o hash de senha do Argon2. Será que a substituição futura por aqui será usar Argon2 para implementações que atualmente usam bcrypt para hash de senha, e usar Blake2 para implementações que atualmente usam SHA-256 para hash criptográfico, tornando-se o design moderno? Como já existem implementações que substituíram cada um deles, e implementações que usam Argon2 recentemente são bastante comuns, acho que é possível. Dito isto, md5sum e similares ainda são usados como hashes rápidos e leves, e são convenientes apenas para verificar a integridade de forma simples. Na verdade, até o WebSocket menciona o uso de SHA-1 no handshake do WebSocket na RFC, mas como não faz sentido mudar isso na implementação do WS, também está documentado.

O handshake do WebSocket descrito neste documento não depende das propriedades de segurança do SHA-1 (como resistência a colisões ou resistência a ataques de segunda pré-imagem) (conforme descrito em [RFC4270]).

RFC 6455 - The WebSocket Protocol

Como já posso discutir essa dúvida, perguntei ao ChatGPT (GPT 5.6).
Em conclusão, a migração para Argon2 é apropriada como modernização, mas como hash criptográfico, parece que apenas mais um meio foi adicionado.
No entanto, o fato de o FreeBSD ter mudado o uso de checksum no pkg foi algo bastante surpreendente, então talvez se torne um padrão em um futuro não tão distante?

Abaixo, a pergunta para o GPT 5.6

---

P. A transição de implementações que atualmente usam bcrypt para Argon2 para hash de senha, e de implementações que usam SHA-256 para Blake2 para hash criptográfico, está se tornando um design moderno?

R. Sim, para armazenamento de senhas, bcrypt → Argon2id pode ser considerado uma "modernização". Por outro lado, a transição de SHA-256 → BLAKE2 para hashes criptográficos de uso geral não é necessariamente uma simples substituição geracional.

Para senhas, a prioridade atual é geralmente a seguinte:

Uso	Tradicional	Recomendação Atual
Armazenamento de senha	bcrypt	Argon2id
Alternativa para armazenamento de senha	PBKDF2 / scrypt	Argon2id / scrypt
Hash geral	SHA-256	SHA-256 / SHA-3 / BLAKE2 / BLAKE3
MAC	HMAC-SHA256	HMAC-SHA256 / keyed BLAKE2
Verificação rápida de integridade	SHA-256	BLAKE2 / BLAKE3

A OWASP também coloca o Argon2id como a primeira escolha para novos sistemas, e posiciona o bcrypt principalmente para sistemas existentes. O Argon2id é um memory-hard KDF que pode incorporar o uso de memória como custo de ataque, além da carga da CPU, por isso é vantajoso em relação ao bcrypt contra ataques de força bruta de senha que tentam muitas vezes usando GPU/ASIC. (OWASP Cheat Sheet Series)

Por exemplo, em uma nova implementação, uma configuração como:

password
   ↓
Argon2id(
    salt = random 128bit,
    memory = 64 MiB,
    iterations = 3,
    parallelism = conforme necessário
)
   ↓
$argon2id$v=19$m=65536,t=3,p=...

é natural. A RFC 9106 também recomenda o Argon2id. (Editor RFC)

Por outro lado,

SHA-256 → BLAKE2

é um pouco diferente.

Isso não significa que o SHA-256 ficou antigo e perigoso.

Atualmente, não se conhecem ataques práticos de colisão ou de pré-imagem para o SHA-256, e ele continua sendo suficientemente forte para usos criptográficos comuns.

As vantagens do BLAKE2 são principalmente:

Rápido
+
Alta segurança
+
Possui keyed hashing como padrão
+
Fácil de implementar

Portanto,

Antigo                  Moderno
bcrypt      ───────→ Argon2id
                 ↑

Bastante claro SHA-256 ───────→ BLAKE2 ↑ Não é necessariamente uma substituição

é a forma mais próxima de entender.

Na verdade, no design atual, o moderno é escolher de acordo com o propósito, como mostrado abaixo:

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

Especialmente em softwares novos que você mesmo projeta, se não houver restrições como compatibilidade de protocolo, eu acho que é bom pensar da seguinte forma:

Password hashing
→ Argon2id
Hash rápido geral
→ BLAKE2b / BLAKE3
Foco em compatibilidade com padrões/protocolos externos
→ SHA-256
MAC
→ HMAC-SHA256
  ou keyed BLAKE2

Além disso, o importante são o BLAKE2 e o BLAKE3. Se o objetivo de um novo design for "querer usar um hash rápido mais novo que o SHA-256", em 2026, você deve incluir não apenas o BLAKE2, mas também o BLAKE3 como candidatos. O BLAKE3 é extremamente rápido para paralelização, SIMD e hashing de grandes volumes de dados.

No entanto,

SHA-256 → BLAKE3

também não é sobre "descartar o SHA-256 por segurança", mas sim uma escolha para obter benefícios de desempenho e design de API.

Em suma, as duas perguntas não estão no mesmo nível:

bcrypt → Argon2id

Uma direção para modernizar claramente o design de segurança.

SHA-256 → BLAKE2/BLAKE3

Não é uma migração obrigatória por segurança, mas uma escolha feita em novos designs considerando desempenho e facilidade de uso.

Existe essa diferença. Se expandirmos para "o que escolher se for projetar uma API do zero em 2026, incluindo autenticação, assinatura, criptografia e hash de arquivos", focar em Argon2id / BLAKE3 / XChaCha20-Poly1305 / Ed25519 / X25519 resultará em uma configuração bastante moderna.