Keccak-256: Ethereum's Hash and Why It Is Not SHA3-256
Keccak-256 is the original, pre-standardisation Keccak function with 256 bit output. It differs from SHA3-256 by a single padding byte, which makes every digest different, and it is the hash used throughout Ethereum.
At a glance
- Digest size
- 256 bits
- Hex characters
- 64
- Rate and capacity
- Rate 1088 bits, capacity 512 bits, identical to SHA3-256
- Standard
- Not a NIST standard. The original Keccak submission, kept by Ethereum after FIPS 202 changed the padding
- Difference from SHA3-256
- Domain separation byte 0x01 instead of 0x06. Same permutation, entirely different digests
- Safe for password storage
- No. Use a memory-hard password hash such as Argon2id, scrypt or bcrypt
- Available in the generator
- Yes, listed separately from SHA3-256 so the two can be compared side by side
In detail
Keccak won the SHA-3 competition in 2012. When NIST finalised FIPS 202 in 2015 it added a domain separation suffix to the padding, changing the byte appended before the padding rule from 0x01 to 0x06. Everything else, including the 1600 bit permutation and the 1088 bit rate, is identical. That one byte means SHA3-256 and Keccak-256 produce completely different output for every input.
Ethereum had already shipped against the original. Its address derivation, transaction hashes, storage slot addressing, the Merkle Patricia trie and the ABI function selectors were all built on pre-standard Keccak-256, so it stayed. This is why Ethereum documentation and libraries usually say keccak256 rather than sha3, and why a library function literally named sha3 in some older packages actually computes Keccak.
The most visible use is the function selector. The first four bytes of the Keccak-256 digest of a function's canonical signature identify it in calldata. The digest of the whole signature also becomes the first topic of an event log. Getting the algorithm wrong here does not produce a subtle bug, it produces a call that no contract recognises.
It is not weaker than SHA3-256. The security argument rests on the permutation and the capacity, both of which are unchanged, and no attack distinguishes the two. The choice between them is purely about which ecosystem you are talking to: Ethereum and everything around it wants Keccak-256, and NIST profiles and general purpose cryptography want SHA3-256.
For password storage it is as unsuitable as every other algorithm here. It is fast, it uses fixed small memory, and there is no cost parameter to raise. Passwords need Argon2id, scrypt or bcrypt. ToolBox does not offer a password hashing tool, and computing a Keccak-256 digest in this generator is not a step toward one.
Examples
input "":
Keccak-256 c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470
SHA3-256 a7ffc6f8bf1ed76651c14756a061d662f580ff4de43b49fa82d80a4b80f8434a
input "abc":
Keccak-256 4e03657aea45a94fc7d47ba826c8d667c0d1e6e33a64a036ec44f58fa12d6c45
SHA3-256 3a985da74fe225b2045c172d6bd390bd855f086e3e9d525b46bfe24511431532c5d24601... is the Keccak-256 of zero bytes and appears throughout Ethereum as the hash of empty account code.
Keccak-256("transfer(address,uint256)")
= a9059cbb2ab09eb219583f4a59a5d0623ade346d962bcd4e46b11da047c9049b
First 4 bytes -> selector 0xa9059cbb
Using SHA3-256 here gives a different value and the call
will not match any function on the contract.Things that catch people out
- A library function named sha3 may be Keccak, standard SHA-3, or configurable. Always check it against the empty string digest before wiring it into anything that has to interoperate.
- The signature you hash must be canonical: no spaces, no parameter names, and the fully expanded type names such as uint256 rather than uint. transfer(address, uint256) with a space gives a different selector from transfer(address,uint256).
- Keccak-256 and SHA3-256 both produce 64 hex characters, so the Verify tab's length based guess cannot separate them. Compute both and compare, which is what the generator does by default.
- Keccak-256 is not the hash used by Bitcoin. Bitcoin uses SHA-256, twice, in most places, which is a different family entirely.
Try it: Hash Generator
Paste text or drop a file and get every digest at once, in hex or Base64, with a verify tab for comparing an expected value against what you actually have.
Hash Generator
LOCAL · Browser-OnlyGenerate MD5, SHA-1, SHA-256, SHA-384, SHA-512, SHA3-256, SHA3-512, Keccak-256, CRC32, and HMAC hashes from text or files
MD5 is cryptographically broken and should not be used for security purposes. Use SHA-256 or SHA-512 instead.
Related Hash algorithms
All hash algorithms →SHA3-256: The Sponge Construction and How It Differs From SHA-256
SHA3-256 gives the same 64 hex characters as SHA-256 from a completely different construction. No length extension, different failure modes, FIPS 202.
SHA-256: The Default Choice and How It Is Used
SHA-256 gives a 64 character hex digest with no practical collision or preimage attack. Where it belongs, where it does not, and its length extension flaw.
SHA3-512: Maximum Sponge Capacity and When to Choose It
SHA3-512 outputs 128 hex characters and holds back 1024 bits of capacity, halving throughput versus SHA3-256. What that buys and when it is worth it.
HMAC-SHA-1: Still Sound Even Though SHA-1 Collisions Are Not
HMAC-SHA-1 produces a 40 character tag and is not affected by the SHA-1 collision attacks. Why that is true, and where it is still deployed today.
HMAC-SHA-256: Signing and Verifying Payloads Correctly
HMAC-SHA-256 gives a 64 character authentication tag. Why it replaces hash(secret + body), how webhook signatures use it, and how verification goes wrong.
HMAC-SHA-384: 384 Bit Tags and the 128 Byte Block Size
HMAC-SHA-384 gives a 96 character tag over a 128 byte block. Where JWT HS384 and TLS use it, and why the key length threshold is different.
Tools for this
- Hash Generator Free online hash generator - generate MD5, SHA-1, SHA-256 hashes from any input text
- Hex Dump Viewer View hex dumps of files and text online - color-coded bytes, search, and ASCII representation