Ethereum übernahm Keccak, bevor NIST SHA-3 fertiggestellt hatte. FIPS 202 ergänzte danach das Padding der Nachricht um Bits zur Domain-Separation (das erste Padding-Byte ist 0x06 bei SHA3-256 und 0x01 bei Keccak-256), deshalb teilen beide Funktionen Permutation und Parameter, liefern aber völlig unterschiedliche Digests. Keccak-256 des leeren Strings ist c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470, SHA3-256 derselben Eingabe dagegen a7ffc6f8…f8434a.
Ethereum nutzt ihn für Adressen (die letzten 20 Byte des Hashes eines öffentlichen Schlüssels mit 64 Byte), ABI-Funktionsselektoren (die ersten 4 Byte des Hashes von transfer(address,uint256) sind a9059cbb), Event-Topics, Storage-Slots, die zu signierenden Hashes nach EIP-191 und EIP-712 sowie die Eingaben von ecrecover. keccak256 in Solidity und die RPC-Methode web3_sha3 berechnen beide Keccak-256, Letztere trotz ihres Namens.
Der klassische Fehler ist, die Funktion sha3_256 (FIPS) einer Bibliothek aufzurufen, wo Ethereum Keccak-256 erwartet: Jeder Digest, jede Adresse und jede Signaturprüfung fällt dann falsch aus, ohne dass eine Fehlermeldung erscheint. Nutze Funktionen namens keccak256 oder keccak_256.