Razões para Preferir Blake3 em vez de Sha256

Artigo original ↗ Discussão no Hacker News ↗

Defensores da função hash BLAKE3 argumentam que ela oferece grandes vantagens de velocidade e paralelismo sobre SHA-256, especialmente para entradas grandes e sistemas multicore, ao mesmo tempo em que fornece propriedades criptográficas fortes, como resistência a ataques de extensão de comprimento e saída estendida flexível. Outros contrapõem que SHA-256 ainda é rápido o suficiente em hardware moderno — muitas vezes beneficiando-se de instruções dedicadas de CPU — muito mais amplamente implantado, melhor estudado e exigido por padrões como FIPS, o que o mantém como a escolha padrão para muitas aplicações. Vários comentaristas observam que a escolha do algoritmo, em última análise, depende do contexto: BLAKE3 pode entregar ganhos dramáticos de desempenho em cargas de trabalho intensivas em dados ou deduplicação, mas SHA-2 e SHA-3 ainda se destacam onde certificação, suporte de ecossistema e criptoanálise de longo prazo importam mais.

Desempenho vs SHA-256 (software, hardware e tamanho de entrada)

  • Vários benchmarks mostram BLAKE3 significativamente mais rápido que SHA-256 em software: ~2,5x em thread única vs SHA-256 otimizado, e muito mais rápido vs implementações sem extensões SHA.
  • Alguns relatam que, em plataformas com SHA-256 fortemente acelerado por hardware (por exemplo, certos núcleos Apple/ARM), o BLAKE3 em C em thread única pode ser ligeiramente mais lento.
  • Outros observam que muitos CPUs em uso ainda não têm extensões SHA, onde o BLAKE3 pode ser decisivamente mais rápido.
  • A vantagem do BLAKE3 cresce com entradas grandes; para entradas pequenas (~≤1 KB), a diferença de velocidade diminui e pode ser irrelevante diante de I/O ou overhead de protocolo.

Paralelismo e escalabilidade

  • A estrutura em árvore do BLAKE3 permite multithreading automático e paralelismo SIMD, com acelerações quase lineares até um limite de núcleos/largura de banda de memória.
  • O mesmo resultado de hash independentemente do número de threads, simplificando o uso em ferramentas e protocolos.
  • Alguns alertam que consumir todos os núcleos para hashing pode interferir com outras cargas de trabalho.

Uso de energia e recursos de CPU

  • Uma visão: “2,5x mais rápido ≈ 2,5x menos energia.”
  • Contraponto: unidades SIMD e instruções especiais podem ter perfis de energia muito diferentes; terminar antes não garante menor energia total.
  • SHA-256 frequentemente se beneficia de instruções dedicadas; BLAKE3 depende de SIMD de propósito geral, sem uma ISA dedicada ainda.

Pegada de memória e dispositivos pequenos

  • O estado interno do BLAKE3 é ligeiramente maior que o de hashes mais antigos por causa de sua árvore e da “pilha CV”, até ~2 KiB.
  • A especificação permite um estado menor para entradas sabidamente curtas, mas bibliotecas comuns não expõem isso; microcontroladores extremamente restritos podem se importar.

Recursos de design: modo em árvore, contador de blocos, XOF

  • Saída estendida (XOF) reutiliza os valores de encadeamento internos de 256 bits para gerar saída de comprimento arbitrário, útil para KDFs, uso semelhante a PRNG e protocolos que precisam de strings >256 bits.
  • O “contador de blocos” faz de propósito com que blocos idênticos em offsets diferentes mapearam para nós Merkle diferentes, fortalecendo ferramentas de verificação em streaming.
  • Isso entra em conflito com designs que esperavam reutilizar diretamente a árvore interna do BLAKE3 para deduplicação endereçável por conteúdo em diferentes offsets; comentaristas sugerem usar chunking separado (rolling hashes/CDC) e então nomear os chunks com BLAKE3.

Casos de uso e ecossistema / padrões

  • BLAKE3 é atraente para cargas de trabalho de alto throughput: ferramentas de deduplicação, sistemas de backup, VCS de arquivos grandes, árvores Merkle, verificação de grandes artefatos e verificação incremental por meio de ferramentas externas.
  • SHA-256 continua favorecido onde FIPS, aceleração por hardware e ferramentas onipresentes importam; muitos sistemas operacionais e linguagens incluem SHA-256 por padrão, não BLAKE3.
  • Alguns preferem SHA-3/Keccak por sua padronização e estrutura simples; outros observam forte confiança e extensa criptoanálise para SHA-2, argumentando que tanto SHA-2 quanto BLAKE3 são boas escolhas dependendo das restrições.