Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
SHA3-256 and Keccak-256 both use the Keccak-f[1600] permutation and return 256-bit digests, but they are not the same hash function. Their finalization padding and domain-separation suffix differ, so the same input produces different bytes. Ethereum uses Keccak-256: choosing a standards-compliant SHA3-256 function instead can break function selectors and other values that must match Ethereum.
Why do SHA3-256 and Keccak-256 give different results?
They share a core permutation, not the complete definition of a hash function. Each processes input through a sponge construction: data is absorbed into an internal state, the Keccak-f[1600] permutation transforms that state, and output bytes are then read from it. The function’s parameters—including its rate, capacity, output length, and domain-separation and padding rules—determine the exact result.
The critical distinction is how the message is marked and padded before the final permutation. NIST’s SHA3-256 uses the SHA-3 domain-separation suffix 0x06. The original Keccak convention used by Ethereum has different finalization padding. Even with identical input bytes and the same underlying permutation, changing those finalization bits changes the state and therefore the digest.
This is why “same family” does not mean “interchangeable.” A hash algorithm is specified by more than its internal permutation and output size. The suffix and padding are part of the algorithm’s identity; using the wrong ones is not a cosmetic implementation choice.
#1 Best Overall
What “one-byte difference” means
The phrase describes the small change in the finalization convention that separates the outputs; it does not mean the digests differ in just one byte. A changed suffix affects the sponge’s final input block, and the permutation mixes that difference through the state. As a result, the resulting 256-bit digests are different across the output, not merely at the byte corresponding to the suffix.
Both functions return 32 bytes. That common length is what “256” identifies in their names; it does not promise matching results. Nor does the shared Keccak-f[1600] permutation make one function a drop-in replacement for the other.
What is different between SHA3-256 and Keccak-256?
The key differences are the finalization convention and the contexts that expect each function. The shared properties are useful for understanding their relationship, but they do not erase the difference in output.
| Property | SHA3-256 | Keccak-256 used by Ethereum |
|---|---|---|
| Core permutation | Keccak-f[1600] | Keccak-f[1600] |
| Output length | 256 bits (32 bytes) | 256 bits (32 bytes) |
| Rate and capacity | 1,088-bit rate; 512-bit capacity, according to the Keccak team’s parameter table | Not stated in the cited Ethereum materials |
| Domain separation and finalization | NIST SHA-3 domain-separation bits “01”; suffix 0x06 | Original Keccak convention; padding differs from finalized NIST SHA3-256 |
| Typical context | Applications specifying the NIST FIPS 202 SHA3-256 function | Ethereum protocol operations that specify Keccak-256 |
| Names to look for in an API | SHA3-256 or an explicitly documented SHA-3 function |
keccak256 or Keccak-256 |
| Empty-input vector | Not stated in the cited materials | c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470, as shown by eth-hash |
The Keccak team’s parameter table distinguishes SHA3-256 by its rate, capacity, output length, domain-separation bits, and suffix. Linux’s SHA-3 documentation likewise explains that variants are distinguished by parameters including rate, suffix, and output length. Selecting the right permutation alone is therefore not enough: an implementation must use the complete parameter set for the requested function.
Which hash does Ethereum use?
Ethereum uses Keccak-256 for the operations its protocol defines as Keccak hashing. The EVM opcode at 0x20 is named KECCAK256, and Ethereum’s developer documentation describes it as computing a Keccak-256 hash.
The historical naming is a source of confusion. Ethereum documentation explains that a late padding change occurred during the standards process. Ethereum’s earlier use of the Keccak convention predates the finalized NIST SHA3-256 definition, so older or informal references to Ethereum “sha3” can refer to Keccak-256 rather than the standardized SHA3-256 function.
That naming history does not make a generic SHA-3 library the right choice for Ethereum. Nethereum warns that Ethereum uses Keccak-256 and that standard SHA-3 libraries are not interchangeable for that purpose. The eth-hash project similarly identifies keccak256 as Ethereum’s hashing function and cautions that calling it “sha3” is erroneous.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →What does the EVM opcode tell you?
In EVM-level work, the opcode name is explicit: KECCAK256, at opcode value 0x20. That is a protocol-level signal about the required hash, not just a convenient label in one programming language. If your program must match the EVM’s output, use a library operation whose documentation says it implements Keccak-256.
Why can the wrong hash break Ethereum function selectors?
Ethereum-derived identifiers are often calculated by hashing a precisely defined byte sequence. A function selector, for example, is derived from a function’s canonical signature and uses the leading four bytes of the resulting hash. If your code hashes that signature with SHA3-256 instead of Keccak-256, it can produce a different selector. A call built with that incorrect selector will not identify the intended function.
The same kind of mismatch can affect address-related calculations, storage keys, and cross-system verification whenever the expected value is defined using Ethereum’s Keccak-256 bytes. The issue is not that SHA3-256 is weaker or malformed; it is that it computes a different specified function. A correct result from the wrong algorithm is still the wrong protocol value.
Check the input bytes as well as the algorithm
Choosing Keccak-256 resolves only the algorithm mismatch. The input must also be encoded exactly as the protocol or application expects. A string’s displayed characters are not automatically the same thing as its bytes: text encoding, capitalization, separators, prefixes, and serialization can all affect the message being hashed.
Recommended Free Tools
When two implementations disagree, verify the data supplied to the hash before assuming the permutation is broken. Compare the raw input bytes and the output bytes, not only their human-readable labels. For interoperability documentation, record the algorithm name, padding or domain-separation convention, byte encoding, and endianness assumptions.
Rank #4
How do I choose and verify the right implementation?
Choose by the specification your application must satisfy: use Keccak-256 for Ethereum protocol compatibility and SHA3-256 where the requirement explicitly calls for NIST FIPS 202 SHA3-256. Then check the library’s documented algorithm and test its output against known vectors.
- Identify the requirement. If the value must match Ethereum or an EVM operation, select an API explicitly named
keccak256orKeccak-256. If a standard or system requirement says FIPS 202 SHA3-256, select that exact function instead. - Inspect the API documentation. Do not infer the algorithm from a method called
sha3, a package description, or a 256-bit output. Confirm whether the implementation uses Ethereum’s Keccak convention or the finalized NIST SHA-3 convention. - Test a known vector. For Keccak-256, the eth-hash README provides the empty-input digest
c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470. Run the function on zero input bytes and compare all 32 output bytes with that vector. - Test a representative application input. Once the empty-input check passes, verify a protocol-relevant case—such as a known signature or identifier—against an authoritative expected value for that exact encoding. This catches mistakes in input construction that an algorithm-only test cannot detect.
- Document the contract. Record the function name, relevant padding/domain-separation convention, byte encoding, and endianness assumptions alongside the test vectors. That makes later library swaps and cross-language ports easier to review.
How to interpret a failed vector
- If the empty-input result differs from the Keccak-256 vector, first check whether the API is actually SHA3-256 rather than Keccak-256.
- If the empty-input vector matches but an application case does not, compare the exact input bytes, including text encoding and serialization, before changing hash implementations.
- If the library documentation uses ambiguous “SHA-3” or “sha3” wording, treat that label as insufficient evidence. Find an explicit algorithm definition or a vector that establishes which output it produces.
How did the naming split happen?
NIST announced its SHA-3 competition on November 2, 2007, and selected KECCAK on October 2, 2012, according to NIST’s project page. NIST later published FIPS 202 on August 4, 2015. The standardized SHA3-256 definition reflects the finalized SHA-3 padding convention, which differs from the original Keccak convention adopted in Ethereum.
That timeline explains why software and older documentation can use similar names for distinct functions. “Keccak” names the construction family and its original variants; “SHA3-256” names a specific standardized function. When code or documentation uses a loose name such as “sha3,” resolve the ambiguity from its specification, API behavior, or a known test vector rather than assuming it means the NIST standard.
Does SHA3-256 have a different security level?
NIST’s current hash-functions table lists SHA3-256 with 128-bit collision resistance and 256-bit preimage resistance. Those figures describe the security strengths NIST assigns to that standardized function; they are not a reason to substitute SHA3-256 where Ethereum specifies Keccak-256.
For an implementation decision, algorithm identity and protocol compatibility come first. The relevant question is not simply which function has “256” in its name or which one is newer, but which complete hash definition the consuming system expects. A cryptographic function can be sound and still be incompatible with an application that requires a different padding convention.
Frequently Asked Questions
Can I convert a SHA3-256 digest into the matching Keccak-256 digest?
No general conversion can recover the other function’s result from a digest alone. Hashing discards information about the input, so compute the required function from the original input bytes.
Why does a library expose a function named sha3 if Ethereum needs Keccak?
Some APIs preserve historical or informal naming, and the label alone may not identify the padding convention. Check the library’s documentation and verify its behavior with a known Ethereum Keccak-256 vector.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Does Keccak-256 return 256 bytes?
No. It returns 256 bits, which is 32 bytes. Hexadecimal text typically uses two characters to represent each byte, so the displayed digest is 64 hexadecimal characters.
Can I use SHA3-256 for passwords or file checksums?
That depends on the application’s specification and threat model; this comparison alone does not establish which hash is appropriate for every use. Follow the system’s required algorithm, and do not substitute either function for a password-hashing scheme when the application calls for one.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
