Keccak-256 est-il identique à SHA3-256 ?

Non. Keccak-256 est ce que Keccak a soumis au NIST ; SHA3-256 a ajouté deux bits de padding avant la finalisation. Même entrée, sortie différente. Ethereum et l’EVM utilisent l’original.

Où apparaît-il dans Ethereum ?

Dans les function selectors, la dérivation des storage slots, les checksums EIP-55, les adresses déterministes CREATE2 et la plupart des schémas de signature exigeant un digest 256 bits.

La sortie est-elle déterministe ?

Oui. Keccak-256 est une fonction pure : la même séquence UTF-8 produit toujours le même digest de 32 octets, peu importe le navigateur ou la session.

Toova journalise-t-il mon entrée ?

Non. Le hash est calculé localement dans cet onglet. La chaîne et le digest ne partent jamais vers un serveur.

Puis-je l’utiliser pour l’encodage ABI ?

Hashez la signature canonique de la fonction, par exemple transfer(address,uint256) — c’est exactement le préfixe attendu par les selectors —, puis prenez les 4 premiers octets.

Hash Keccak-256 — utilisé par Ethereum (EIP-55)

Hash Keccak-256

Conçu pour la confidentialité — fonctionne entièrement dans votre navigateur

Mettez n’importe quelle chaîne UTF-8 dans la zone d’entrée et obtenez le digest Keccak-256 de 32 octets. C’est l’algorithme utilisé partout dans Ethereum : adresses checksum EIP-55, function selectors, dérivation des storage slots et adresses de contrats via CREATE2.

Keccak-256 versus SHA3-256

Keccak-256 fut la soumission de Keccak au NIST avant qu’il ne devienne SHA3. Le standard SHA3 a modifié la règle de padding (deux bits supplémentaires en multi-rate padding), de sorte que SHA3-256 et Keccak-256 d’une même entrée diffèrent. Ethereum a conservé le Keccak original afin que ses hashes on-chain correspondent aux wallets, indexeurs et explorateurs qui utilisent eux aussi Keccak-256.

Où Ethereum l’utilise

Les function selectors sont les 4 premiers octets de keccak256("transfer(address,uint256)") et signatures canoniques similaires. Les storage slots pour les mappings dérivent de keccak256(abi.encode(key, slot)). EIP-55 alterne la casse selon keccak256 de l’adresse en minuscules. Les adresses de contrats CREATE2 sont keccak256 du déployeur, du sel et du bytecode.

Comment tourne l’implémentation

La page embarque une permutation Keccak-f[1600] compacte en JavaScript. Web Crypto ne l’expose pas. Vous pouvez vérifier en comparant au digest connu de la chaîne vide c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470. Entrées et sorties ne quittent pas l’onglet.

Questions fréquentes

Keccak-256 est-il identique à SHA3-256 ?: Non. Keccak-256 est ce que Keccak a soumis au NIST ; SHA3-256 a ajouté deux bits de padding avant la finalisation. Même entrée, sortie différente. Ethereum et l’EVM utilisent l’original.
Où apparaît-il dans Ethereum ?: Dans les function selectors, la dérivation des storage slots, les checksums EIP-55, les adresses déterministes CREATE2 et la plupart des schémas de signature exigeant un digest 256 bits.
Comment vérifier l’implémentation ?: Hashez la chaîne vide et comparez à c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470. Tout écart révèle un padding ou un algorithme incorrect.
La sortie est-elle déterministe ?: Oui. Keccak-256 est une fonction pure : la même séquence UTF-8 produit toujours le même digest de 32 octets, peu importe le navigateur ou la session.
Toova journalise-t-il mon entrée ?: Non. Le hash est calculé localement dans cet onglet. La chaîne et le digest ne partent jamais vers un serveur.
Puis-je l’utiliser pour l’encodage ABI ?: Hashez la signature canonique de la fonction, par exemple transfer(address,uint256) — c’est exactement le préfixe attendu par les selectors —, puis prenez les 4 premiers octets.