Ethereum a adopté Keccak avant que le NIST ne finalise SHA-3. FIPS 202 a ensuite ajouté des bits de séparation de domaine au remplissage du message (le premier octet de remplissage vaut 0x06 dans SHA3-256 et 0x01 dans Keccak-256) : les deux fonctions partagent donc la permutation et les paramètres, mais produisent des condensats sans rapport entre eux. Le Keccak-256 de la chaîne vide est c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470, tandis que le SHA3-256 de la même entrée est a7ffc6f8…f8434a.
Ethereum l’utilise pour les adresses (les 20 derniers octets du condensat d’une clé publique de 64 octets), les sélecteurs de fonctions ABI (les 4 premiers octets du condensat de transfer(address,uint256) sont a9059cbb), les topics d’événements, les emplacements de stockage (storage slots), les condensats signés EIP-191 et EIP-712 et les entrées passées à ecrecover. Le keccak256 de Solidity et la méthode RPC web3_sha3 calculent tous deux Keccak-256, malgré le nom de cette dernière.
Le bogue classique consiste à appeler la fonction sha3_256 (FIPS) d’une bibliothèque là où Ethereum attend Keccak-256 : tous les condensats, adresses et vérifications de signature sont alors faux, sans aucune erreur signalée. Utilisez des fonctions nommées keccak256 ou keccak_256.