SHA-256 vs SHA-3: Merkle–Damgård ou esponja

SHA-256 vs SHA-3 compara o carro-chefe da família SHA-2 com o padrão baseado no Keccak que o NIST publicou em 2015. Nenhum dos dois está quebrado nem perto disso, e ambos oferecem a mesma segurança nominal com saída de 256 bits. Eles diferem no projeto interno, o que afeta a extensão de comprimento, a velocidade e o modo como são usados dentro de algoritmos mais recentes.

Visão geral

Vazão medida com openssl speed -evp em um núcleo de um Apple M4 Max, que tem suporte em hardware às duas famílias.

Diferenças de projeto

O SHA-256 processa a mensagem em blocos de 64 bytes e passa cada um por uma função de compressão junto com o estado anterior de 256 bits; o estado final é o digest. Como o digest é todo o estado interno, qualquer pessoa que conheça SHA-256(x) e o comprimento de x pode continuar calculando o hash e obter SHA-256(x ‖ padding ‖ y) sem conhecer x. Essa extensão de comprimento é inofensiva para assinaturas e para o HMAC, mas quebra MACs ingênuos como SHA-256(key ‖ message).

O SHA-3 é uma esponja: ele absorve a entrada em um estado de 1600 bits por meio da permutação Keccak-f e espreme a saída a partir de uma parte desse estado. No SHA3-256, 1088 bits do estado formam a taxa (rate) e 512 bits a capacidade, que nunca vai para a saída; por isso a extensão de comprimento é impossível e SHA3-256(key ‖ message) é um MAC sólido (o NIST padroniza o KMAC para isso). A mesma esponja gera as funções de saída extensível SHAKE128 e SHAKE256, que os algoritmos pós-quânticos usam para expandir sementes em matrizes e ruído.

O NIST escolheu o Keccak em 2012, depois de uma competição de cinco anos que começou quando ataques ao MD5 e ao SHA-1 levantaram temores sobre a estrutura semelhante do SHA-2. Esses temores não se confirmaram: os melhores ataques ao SHA-256 alcançam cerca de 31 das 64 etapas no caso de colisões, e a função completa não mostra nenhuma fraqueza. Por isso, o SHA-3 é uma salvaguarda, não um substituto.

Velocidade

No Apple M4 Max, as duas famílias contam com instruções próprias, mas o SHA-256 é quase três vezes mais rápido com entradas longas: cerca de 2,85 GB/s contra 1,01 GB/s do SHA3-256 no OpenSSL 3.6.5, com o SHA3-512 a 0,53 GB/s. Em CPUs x86 com extensões SHA, o quadro é parecido; em processadores sem instruções de hash, o SHA-3 e o SHA-256 ficam mais próximos, e o BLAKE2 ou o BLAKE3 são mais rápidos que os dois. Na maioria das aplicações, qualquer um deles é muito mais rápido do que a E/S ao redor; a diferença importa ao calcular o hash de arquivos muito grandes, em árvores de Merkle e em blockchains.

O SHA3-256 não é o Keccak-256

O Ethereum adotou o Keccak antes de o FIPS 202 ser finalizado, e o FIPS 202 depois mudou o padding (acrescentando bits de separação de domínio). As duas funções compartilham a permutação, mas geram digests sem nenhuma relação entre si. O keccak256 do Solidity, o RPC web3_sha3 e todo endereço Ethereum, seletor de função e digest EIP-712 usam o Keccak-256. Chamar o SHA3-256 de uma biblioteca em código Ethereum produz resultados errados sem nenhum erro.

import { createHash } from "node:crypto";
import { keccak_256 } from "@noble/hashes/sha3.js";

const input = Buffer.from("abc");
console.log("SHA-256   ", createHash("sha256").update(input).digest("hex"));
console.log("SHA3-256  ", createHash("sha3-256").update(input).digest("hex"));
console.log("Keccak-256", Buffer.from(keccak_256(input)).toString("hex"));

SHA-256    ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad
SHA3-256   3a985da74fe225b2045c172d6bd390bd855f086e3e9d525b46bfe24511431532
Keccak-256 4e03657aea45a94fc7d47ba826c8d667c0d1e6e33a64a036ec44f58fa12d6c45

Os valores de SHA-256 e SHA3-256 coincidem com os exemplos do FIPS 180-4 e do FIPS 202 para “abc”.

Quando escolher cada um

• Interoperabilidade de protocolos (TLS, certificados, JWT, SSH, Git, gerenciadores de pacotes, Bitcoin): SHA-256, porque é o que o outro lado calcula.
• Hash com chave: o HMAC (por exemplo, HMAC-SHA256) funciona com qualquer hash SHA-2; se você preferir uma construção simples com chave, o KMAC ou o SHA-3 com chave evitam a dupla passagem do HMAC.
• Expansão de sementes, fluxos aleatórios determinísticos, saída de comprimento variável: SHAKE256 ou SHAKE128.
• Algoritmos pós-quânticos: o que o padrão fixar internamente; o ML-KEM e o ML-DSA usam SHA3 e SHAKE, então as bibliotecas que os implementam já incluem o SHA-3.
• Ethereum: Keccak-256, nunca o SHA3-256 do FIPS.
• Um segundo hash, estruturalmente diferente, para defesa em profundidade (por exemplo, hash duplo em arquivamento de longo prazo): SHA-3 ao lado do SHA-256.
• Velocidade bruta sem exigência de FIPS: BLAKE2 ou BLAKE3 em CPUs sem instruções de hash.

Notas de migração

Trocar de função de hash muda todos os digests, então é uma mudança de formato, e não uma simples troca de biblioteca.

1. Versione o identificador: registre o algoritmo junto com cada digest (sha256:, sha3-256:, multihash, um OID), a exemplo de sistemas endereçados por conteúdo, como os registros de contêineres e o SRI.
2. Publique os dois durante a transição: calcule os dois digests, verifique aquele que o consumidor conhece e aposente o antigo quando os consumidores tiverem se atualizado.
3. Revise as suposições sobre extensão de comprimento: se o código monta MACs como hash(secret ‖ message), migrar para o SHA-3 resolve o problema, mas migrar para o HMAC também o resolve no SHA-256.
4. Cuidado com truncamento e codificações: os digests trafegam em hex, base64 ou base64url; codificações incompatíveis são mais comuns do que algoritmos incompatíveis.
5. Não migre apenas por causa da computação quântica: as duas funções mantêm pelo menos 128 bits de segurança de pré-imagem contra o algoritmo de Grover, e o plano preliminar de transição do NIST mantém as duas em uso.

Referências

• FIPS 180-4, padrão de hash seguro
• FIPS 202, padrão SHA-3
• NIST SP 800-185, cSHAKE, KMAC, TupleHash e ParallelHash
• NIST SP 800-107 Rev. 1, aplicações que usam algoritmos de hash aprovados
• NIST IR 8547 ipd, tabela 7 (níveis de segurança dos hashes)
• RFC 2104, HMAC