Keccak-256 é igual ao SHA3-256?

Não. O Keccak-256 foi o algoritmo que o Keccak submeteu ao NIST; o SHA3-256 adicionou dois bits de padding antes da finalização. Mesmo input, output diferente. Ethereum e EVM usam o Keccak-256 original.

Onde no Ethereum aparece?

Em function selectors, derivação de storage slots, checksums EIP-55, endereços determinísticos via CREATE2 e na maioria dos esquemas de assinatura que exigem digest de 256 bits.

A saída é determinística para o mesmo input?

Sim. O Keccak-256 é função pura: a mesma sequência de bytes UTF-8 produz o mesmo digest de 32 bytes, independente do navegador ou da execução.

O Toova registra o input?

Não. O hash é calculado localmente nesta aba. A string e o digest nunca viajam para servidor.

Posso usar para ABI encoding?

Faça o Keccak-256 sobre a assinatura canônica da função, como transfer(address,uint256), exatamente o prefixo de quatro bytes que selectors esperam, e pegue os 4 primeiros bytes do resultado.

Hash Keccak-256 — usado pelo Ethereum (EIP-55, EVM)

Hash Keccak-256

Privado por design — roda inteiramente no seu navegador

Coloque qualquer texto UTF-8 no campo de entrada e leia o digest Keccak-256 de 32 bytes. É o algoritmo usado em toda parte no Ethereum: endereços checksum do EIP-55, function selectors, derivação de storage slot e endereços de contrato via CREATE2.

Keccak-256 versus SHA3-256

O Keccak-256 foi a submissão do Keccak ao NIST antes de virar SHA3. O padrão final SHA3 mudou a regra de padding (multi-rate padding ganhou dois bits extras), então SHA3-256 e Keccak-256 do mesmo input divergem. O Ethereum manteve o Keccak original para que os hashes on-chain casem com wallets, indexers e exploradores que também usam Keccak-256.

Onde o Ethereum usa

Function selectors são os primeiros 4 bytes de keccak256("transfer(address,uint256)") e assinaturas canônicas similares. Storage slots para mappings derivam de keccak256(abi.encode(key, slot)). O EIP-55 alterna maiúsculas/minúsculas com base no keccak256 do endereço em minúsculas. Endereços de contrato via CREATE2 são keccak256 sobre deployer, salt e bytecode.

Como a implementação roda

A página carrega uma permutação Keccak-f[1600] enxuta em JavaScript. Não há entrada para isso no Web Crypto. Você pode validar comparando com o digest conhecido de string vazia c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470. Inputs e outputs nunca saem desta aba.

Perguntas Frequentes

Keccak-256 é igual ao SHA3-256?: Não. O Keccak-256 foi o algoritmo que o Keccak submeteu ao NIST; o SHA3-256 adicionou dois bits de padding antes da finalização. Mesmo input, output diferente. Ethereum e EVM usam o Keccak-256 original.
Onde no Ethereum aparece?: Em function selectors, derivação de storage slots, checksums EIP-55, endereços determinísticos via CREATE2 e na maioria dos esquemas de assinatura que exigem digest de 256 bits.
Como validar a implementação?: Faça o hash da string vazia e compare com c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470. Qualquer divergência indica padding ou algoritmo errado.
A saída é determinística para o mesmo input?: Sim. O Keccak-256 é função pura: a mesma sequência de bytes UTF-8 produz o mesmo digest de 32 bytes, independente do navegador ou da execução.
O Toova registra o input?: Não. O hash é calculado localmente nesta aba. A string e o digest nunca viajam para servidor.
Posso usar para ABI encoding?: Faça o Keccak-256 sobre a assinatura canônica da função, como transfer(address,uint256), exatamente o prefixo de quatro bytes que selectors esperam, e pegue os 4 primeiros bytes do resultado.