Keccak-256 è uguale a SHA3-256?

No. Keccak-256 è ciò che Keccak ha sottomesso al NIST; SHA3-256 ha aggiunto due bit di padding prima della finalizzazione. Stesso input, output diverso. Ethereum ed EVM usano il Keccak-256 originale.

Dove appare in Ethereum?

Nei selector di funzione, nella derivazione degli storage slot, nei checksum EIP-55, negli indirizzi deterministici CREATE2 e in molti schemi di firma con digest a 256 bit.

L’output è deterministico per lo stesso input?

Sì. Keccak-256 è funzione pura. La stessa sequenza di byte UTF-8 produce lo stesso digest da 32 byte indipendentemente da browser o sessione.

Toova registra l’input?

No. L’hash è calcolato localmente in questa scheda. Stringa e digest non viaggiano mai verso un server.

Posso usarlo per ABI encoding?

Calcola Keccak-256 sulla firma canonica della funzione, ad es. transfer(address,uint256) — il prefisso a 4 byte che i selector attendono — e prendi i primi 4 byte del risultato.

Hash Keccak-256 — usato da Ethereum (EIP-55)

Hash Keccak-256

Privacy by design — tutto gira nel tuo browser

Inserisci una qualsiasi stringa UTF-8 nel campo d’input e leggi il digest Keccak-256 da 32 byte. È l’algoritmo che Ethereum usa ovunque: indirizzi checksum EIP-55, selector di funzione, derivazione degli storage slot e indirizzi di contratti via CREATE2.

Keccak-256 contro SHA3-256

Keccak-256 era la sottomissione di Keccak al NIST prima che diventasse SHA3. Lo standard SHA3 finale ha cambiato la regola di padding (il multi-rate padding ha guadagnato due bit extra), così SHA3-256 e Keccak-256 dello stesso input divergono. Ethereum è rimasto con il Keccak originale affinché gli hash on-chain combacino con wallet, indexer ed explorer che usano anch’essi Keccak-256.

Dove lo usa Ethereum

I selector di funzione sono i primi 4 byte di keccak256("transfer(address,uint256)") e firme canoniche simili. Gli storage slot per i mapping derivano da keccak256(abi.encode(key, slot)). EIP-55 alterna maiuscole/minuscole in base al keccak256 dell’indirizzo in minuscolo. Gli indirizzi dei contratti CREATE2 sono keccak256 sopra deployer, salt e bytecode.

Come gira l’implementazione

La pagina porta con sé una permutazione Keccak-f[1600] snella in JavaScript. Web Crypto non la espone. Puoi verificare confrontando con il digest noto della stringa vuota c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470. Input e output non escono dalla scheda.

Domande frequenti

Keccak-256 è uguale a SHA3-256?: No. Keccak-256 è ciò che Keccak ha sottomesso al NIST; SHA3-256 ha aggiunto due bit di padding prima della finalizzazione. Stesso input, output diverso. Ethereum ed EVM usano il Keccak-256 originale.
Dove appare in Ethereum?: Nei selector di funzione, nella derivazione degli storage slot, nei checksum EIP-55, negli indirizzi deterministici CREATE2 e in molti schemi di firma con digest a 256 bit.
Come verifico l’implementazione?: Hash della stringa vuota e confronto con c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470. Qualsiasi differenza indica padding o algoritmo errato.
L’output è deterministico per lo stesso input?: Sì. Keccak-256 è funzione pura. La stessa sequenza di byte UTF-8 produce lo stesso digest da 32 byte indipendentemente da browser o sessione.
Toova registra l’input?: No. L’hash è calcolato localmente in questa scheda. Stringa e digest non viaggiano mai verso un server.
Posso usarlo per ABI encoding?: Calcola Keccak-256 sulla firma canonica della funzione, ad es. transfer(address,uint256) — il prefisso a 4 byte che i selector attendono — e prendi i primi 4 byte del risultato.