Keccak-256 and SHA3-256 share one permutation, one 256-bit output size and one group of designers, yet they return different digests for every input you feed them. The Keccak Team specifications page lists the original Keccak design next to the NIST documents built on it, and the split between the two functions comes down to a single suffix byte. Keccak-256 pads with 0x01. SHA3-256 pads with 0x06. Ethereum kept the first, NIST standardized the second, and plenty of code has paid for that gap.

The bug is quiet. A developer calls a function named sha3, gets 64 hex characters back and sees no error. Then an address derives wrong, a signature check fails or a contract selector misses. On the empty string, Keccak-256 returns c5d24601...a470 while SHA3-256 returns a7ffc6f8...434a. Speed is no help in choosing, because the two do the same work per block. Readers who want the speed comparison for the NIST variant can start with the earlier look at SHA-256 against SHA3-256.

As of November 8, 2026, FIPS 202 still defines SHA3-256 as a final standard, and no replacement edition has been confirmed. NIST’s only live SHA-3 item is the October 8 draft of SP 800-185 Revision 1, with comments open through December 7, 2026. That draft covers derived functions such as cSHAKE and KMAC. It does not touch Keccak-256 or SHA3-256.

Don't miss new tech stories on Google

Add Shattered once in the Google app and our stories show up in your news suggestions.

What Keccak-256 and SHA3-256 Actually Are

Keccak is a family of sponge-based hash functions designed by the Keccak Team. Its site lists Guido Bertoni, Joan Daemen, Seth Hoffert, Silvia Mella, Michaël Peeters, Gilles Van Assche and Ronny Van Keer. NIST took the design through its SHA-3 process and published the result as FIPS 202 in August 2015. That standard specifies SHA3-224, SHA3-256, SHA3-384 and SHA3-512, plus the extendable-output functions SHAKE128 and SHAKE256.

Keccak-256 is not a NIST name. It is the community label for the original Keccak construction with a 256-bit output, using the padding from before standardization. No separately versioned Keccak-256 release exists, and no newer SHA3-256 version has been identified either. Both are algorithm definitions, so neither has a product tier, a subscription or a vendor price.

NIST changed one thing on the way to FIPS 202. It added domain-separation bits to the message before padding, so that a fixed-length hash and an extendable-output function could never produce related output for the same input. SHA3 functions append the bits 01. SHAKE and cSHAKE use their own suffixes. Those extra bits turn the first padding byte from 0x01 into 0x06 for SHA3-256, and that is the whole difference between the two hash functions compared here.

Ethereum went live in 2015, the same year NIST published FIPS 202. The protocol stayed with the variant it already used. Ethereum’s developer documentation states that the web3_sha3 JSON-RPC method returns Keccak-256, not standardized SHA3-256, and that an account address is the last 20 bytes of the Keccak-256 hash of the public key. The method name still says sha3, which is exactly why the confusion survives.

Three misreadings come up again and again. The first says Keccak-256 is weaker or broken, and nothing in the current sources supports that. The second says SHA3-256 replaced SHA-256 across the industry, which is also false, since SHA-256 stays the broadly deployed default and NIST has confirmed no migration from SHA-2 to SHA-3. The third treats the two names as aliases. They are not aliases, and a hash digest is a fingerprint rather than a cipher, a point the primer on hashing versus encryption lays out for newer readers.

One more naming trap: the phrase SHA-3 in casual speech often means the whole family, while SHA3-256 means one member. When a library function is called sha3 with no number, read its documentation before trusting it. Some tools mean FIPS 202, and some mean the Ethereum variant. A function named sha3 that returns 32 bytes tells you nothing about which padding it applies, and the only reliable check is a known test vector.

Keccak-256 vs SHA3-256 Specs Side by Side

Set beside SHA-256 as a reference point, the two sponge functions line up as follows. The structural constants come from the Keccak and SHA-2 definitions. The digest rows come from reference runs of the code shown later.

Read the table by columns two and three. Nearly every row matches, and the matching rows are the point. A reviewer comparing the two designs on security margin, state size or round count will find nothing to separate them. Only the suffix row and the digest rows differ, and the digest rows differ because of the suffix row.

Column four explains why the two sponge variants feel so different from SHA-256 in practice. The sponge hides 512 bits of capacity, so an attacker who sees a digest cannot continue the computation, which is the length-extension trick that plain SHA-256 permits. The SHA-2 route needs HMAC or a truncated variant to close that door. The wider head-to-head of SHA-256 and SHA-3 on speed and security goes deeper on that trade.

Security margins match because the permutation, rate and capacity match. A generic collision attack on a 256-bit output costs about 2^128 work, and a generic preimage attack costs about 2^256. Those figures are properties of the output size and capacity, so they apply to both variants equally. Anyone hoping to pick a winner from this table will not find one, because the table was never about strength. It is about which bytes go into the last block before the permutation runs.

The Padding Byte That Splits the Two Digests

How the sponge pads a message

A sponge absorbs input in blocks of the rate, which is 136 bytes for both functions here. The last block is rarely full, so the function fills the remainder with a fixed pattern. That pattern is a 1 bit, then zeros, then a closing 1 bit. In byte terms, the first padding byte is 0x01 and the last byte of the block gets 0x80 set.

SHA3-256 inserts its two suffix bits ahead of that pattern. The first padding byte therefore becomes 0x06, which is the bits 01 followed by the opening 1 of the padding rule. Everything else stays the same: same permutation, same rate, same 24 rounds, same squeeze of 32 bytes from the state. Because the permutation spreads every input bit across the state, one different byte in the final block changes about half the output bits.

Here is the final block for the three-byte message abc, with zero runs shortened:

Counting the two abc digests bit by bit shows 138 of 256 bits differ, or 54%. A random pair of 256-bit strings differs in about 128 bits on average, so the two outputs look unrelated, as they should.

The rate-boundary edge case

One input length deserves special care. When a message is exactly 135 bytes long, only one byte of room remains in the block. The suffix byte and the closing 0x80 bit then land in the same byte. Keccak-256 produces 0x81 there, and SHA3-256 produces 0x86. A message of exactly 136 bytes pushes the padding into an entirely new block.

Hand-rolled implementations break at these boundaries more than anywhere else. The reference code used here checks its SHA3-256 output against Python’s built-in implementation at 135, 136, 137 and 272 bytes, and all four lengths match. Anyone porting Keccak to a new language should test those four lengths first.

The suffix idea also explains why the SHA-3 family exists as a family. cSHAKE, KMAC, TupleHash and ParallelHash each carry their own domain separation, and the roundup of SHA-3 derived functions shows how those four build on the same permutation with different customization strings.

Verified Test Vectors for Keccak-256 vs SHA3-256

Test vectors catch this bug faster than any code review. The values here came from a pure-Python Keccak implementation written for these tests. Its SHA3-256 output was cross-checked against Python’s hashlib.sha3_256 on every input, and its Keccak-256 output for the empty string matches the widely published Ethereum constant that starts with c5d246.

The last row is the one Ethereum developers recognize. The first four bytes of the Keccak-256 digest, a9059cbb, are the selector for the ERC-20 transfer function. The first four bytes of the SHA3-256 digest are 4b40e901, which no deployed token contract answers to. A wallet that used the wrong function would encode calls that every token on the network rejects.

The full reference sponge is short enough to read in one sitting. It runs the 24-round permutation, absorbs 136-byte blocks and takes the suffix as a parameter, which makes the whole difference between the two functions a single argument:

Pure Python is far too slow for production, so treat this as a specification you can read rather than a library to ship. Its job is to prove, in about 40 lines, that the two functions differ by exactly one constant.

Benchmarks: Three Measurements, One Cost Class

No independent lab publishes a Keccak-256 against SHA3-256 speed test, and the reason is simple. The two share the Keccak-f[1600] permutation, the 1,088-bit rate and the 24 rounds, so the work per block is identical. What differs is the domain-separation padding, which is why the digests differ. The comparison with SHA-256 and the larger SHA-3 outputs depends on the hardware, so this article gives no benchmark figures for it.

Three conclusions follow. First, speed should not decide between SHA3-256 and SHA-256 here, since no fetched source gives benchmark figures for either. Hardware with dedicated SHA-256 instructions may change the picture, so measure on your own target before choosing.

Second, Keccak-256 and SHA3-256 should cost the same. Both use the Keccak sponge construction and differ only in the padding constant, so Keccak-256 does strictly the same work. They are still not interchangeable, because the different padding produces different digests for the same input.

Third, the larger output variants change the trade-off. SHA3-512 has a rate of 576 bits, so each permutation call absorbs fewer input bytes than it does for SHA3-256. Engineers who need raw speed from a non-NIST function can look at the BLAKE3 against SHA-3 comparison.

What does that mean for a workload that hashes constantly? Think of a Merkle tree builder, a blockchain node replaying blocks or an indexer fingerprinting millions of small records. Those jobs spend most of their time on inputs of 32 to 200 bytes, where the 64-byte row is the better guide than the 16 KB row. At that size the OpenSSL gap between SHA3-256 and SHA-256 is single digits, so switching functions for speed alone rarely pays for the migration effort. A node that needs Keccak-256 for compatibility loses nothing by using it, and a service that picks SHA3-256 for policy reasons will not feel the difference in a profiler.

Large-file hashing tells a different story. For backups, deduplication and download verification, the 16 KB and 1 MiB rows apply, and SHA-256 or SHA-512 deliver more throughput on this class of CPU. If speed on big inputs is the main concern and no standard binds you, a purpose-built function beats all of them. If a standard binds you, the NIST functions are the only options, and the 64-bit SHA-512 family often outruns SHA3-256 on 64-bit server chips.

To reproduce the OpenSSL and hashlib rows on your own hardware, run the commands below. Expect absolute numbers to move with your CPU, but the ratios between functions should stay in the same neighborhood unless your chip has SHA-256 hardware, in which case SHA-256 pulls ahead further.

Real-World Examples: Where Each Function Shows Up

Ethereum and its tooling

Ethereum supplies the first four examples, and all four come from its own documentation. Account addresses derive from the last 20 bytes of a Keccak-256 hash of the public key. The web3_sha3 JSON-RPC method returns Keccak-256, and the docs spell out that this is not standardized SHA3-256. EVM function selectors use Keccak hashing, which is how transfer(address,uint256) becomes a9059cbb. Transaction hashing uses the same function. Swapping any of these to SHA3-256 would change addresses, selectors and signatures, and the official materials confirm no migration plan.

Hardware wallets lean on this daily. A device that shows decoded transaction details has to hash function signatures with Keccak-256 and compare them against the four-byte selector in the calldata. The walkthrough on clear-signing checks with a Python calldata decoder uses exactly that mechanism, and a wrong hash there fails every lookup.

ERC-8441, a hybrid post-quantum stealth address scheme dated August 28, 2026, shows both functions living in one design. It uses SHA3-256 for an off-chain hybrid combiner while keeping Ethereum’s original Keccak-256 as a separate function. The authors treat the two as distinct tools, which is the habit every codebase should copy.

Contract-level conventions follow the same hash. Solidity developers derive function selectors, event identifiers and mapping storage locations with keccak256, so any off-chain tool that wants to read raw storage or decode logs has to reproduce those derivations bit for bit. A block explorer, an indexer and an audit script all depend on that one function name behaving identically across languages. When one of them silently uses the NIST function, it reports empty results instead of errors, which makes the fault hard to spot in review.

Libraries, databases and other protocols

Outside Ethereum, the confusion shows up in library documentation. The Query.Farm documentation for DuckDB’s Crypto extension reportedly says its keccak224, keccak256, keccak384 and keccak512 functions now compute the real original Keccak variants rather than SHA-3, and it points users who need SHA-3 to the sha3-256 family of names. Because this comes from a single documentation page, check your installed version before relying on it.

A pull request on the aws-lc-rs repository, opened in October 2026, proposes adding a Keccak-256 digest algorithm. It is a proposal and not a released feature, but it signals that mainstream crypto libraries now see demand for the legacy variant. The Parallax protocol documentation for XHash likewise states that Keccak-256 is not the same function as FIPS 202 SHA3-256, a warning that blockchain projects keep repeating.

Telecom gives a non-blockchain example. The Keccak Team page lists the 3GPP TUAK algorithm set specification among documents that build on the Keccak permutation. Standards bodies picked the permutation for its flexibility, and each one chose its own padding and customization rules on top of it.

Calling Keccak-256 and SHA3-256 in Python, Node.js, Go and Rust

Languages disagree on names, and that disagreement causes most production bugs. Python’s standard library offers hashlib.sha3_256 for the NIST function, which is not the same function as Ethereum’s Keccak-256. Check which of the two a library actually implements before trusting its name. Keccak-256 often needs a third-party package.

Go and Rust name the two variants explicitly, which makes review easy. Python and Node.js split the job between the standard library and an Ethereum-oriented package. Anyone building server code around the Node.js crypto module should note that its built-in sha3-256 is the NIST function, so Ethereum work needs an extra dependency.

Solidity exposes keccak256 as a built-in, and the name leaves no room for doubt. Older Solidity releases carried a sha3 alias that pointed at Keccak-256, and older web3.py releases had a sha3 helper with the same meaning. Old pysha3 packages also used the Keccak padding under sha3 names before the project split them. If you maintain a codebase from that era, search for bare sha3 calls first.

A safe house rule is to wrap each function once, in a single module, with a name that includes the spec: keccak256_ethereum and sha3_256_fips202. Then ban direct calls to the bare library names in code review. That one convention would have prevented most of the incidents developers describe on forums.

Security: Collisions, Preimages, Length Extension and Post-Quantum Plans

On pure cryptographic strength, the two functions are twins. Both offer 128 bits of generic collision resistance and 256 bits of generic preimage resistance at a 256-bit output, and both rest on a 512-bit capacity. The sources reviewed report no practical break of either. The only distinction that matters in security reviews is approval status: SHA3-256 sits inside NIST’s validated algorithm family, while Keccak-256 does not carry a NIST specification of its own.

That approval gap can still decide a project. A compliance checklist that requires a FIPS-approved hash accepts SHA3-256 and SHA-256 and rejects Keccak-256, even though the underlying security level is the same. If your product ships to government buyers, use the NIST function in every path that touches regulated data, and keep Keccak-256 confined to the blockchain compatibility layer.

Length extension is the other practical security topic. Sponge functions with a hidden capacity resist it, so keyed hashing can be as simple as hashing a key followed by the message under a clear domain tag. NIST built this into KMAC, which the comparison of HMAC and KMAC weighs against the older nested design. Plain SHA-256 needs HMAC for the same job.

Domain separation is the quieter security story here. Because SHA3-256 appends its own suffix bits, a SHA3-256 digest never equals a SHAKE256 output of the same length for the same message, even though both come from the same permutation. Keccak-256 offers no such guarantee against other Keccak-based functions that use the original padding. In a system that mixes several Keccak constructions, that difference can matter, and the safe habit is to add an explicit application tag to every hashed message so that outputs from different roles can never be confused.

Implementation security looks alike too. The permutation uses only XOR, AND, NOT and rotations on 64-bit lanes, with no lookup tables indexed by secret data, so a careful software version runs in constant time without extra effort. Both functions inherit that property. The practical risks sit above the hash, in how inputs are encoded and compared. A constant-time comparison of two digests still fails if one side hashed UTF-8 text and the other hashed a hex string.

On the quantum side, NIST has released IR 8547, the report on moving to post-quantum standards, and has since updated it. The report addresses quantum-vulnerable public-key algorithms, and nothing in the reviewed material indicates that SHA3-256 or Keccak-256 faces retirement. As a rule of thumb, a quantum attacker running Grover’s algorithm roughly halves the effective preimage security of a hash, so 256-bit outputs keep a comfortable margin. That is analysis, not a NIST figure, so treat it as a planning heuristic.

Ethereum’s own post-quantum work centers on signatures and consensus changes rather than on swapping the hash. The sources show no approved plan to replace Keccak-256 inside the protocol. A team that worries about quantum risk should audit its signature schemes first and its hash calls second.

Cost and Licensing: What Each Choice Costs You

Neither function has a price. FIPS 202 is a freely published government standard, and the Keccak design documents are public. No source reviewed identifies a license fee, subscription plan or commercial tier for either one. Ethereum network fees do not count as a price for Keccak-256, since they vary with transaction conditions and pay for block space rather than for the hash. The real costs are engineering time, audit scope and compliance exposure, summarized in this table.

The economics are plain. Choosing SHA3-256 outside Ethereum saves a dependency and a compliance conversation. Choosing Keccak-256 inside Ethereum saves the whole project. In both cases the hash itself costs nothing, and the money goes to the humans who debug mismatches.

Audit cost deserves a line of its own. Reviewers charge for the time they spend working out which variant each call site means, and a codebase that labels every call removes that time entirely. A one-day naming cleanup often costs less than a single afternoon of an auditor reading ambiguous sha3 calls.

Pros and Cons of Each Function

Keccak-256

  • Pro: It matches Ethereum addresses, selectors, web3_sha3 and every deployed contract that hashes with keccak256.
  • Pro: It costs exactly what SHA3-256 costs, with the same sponge, rate and rounds.
  • Pro: It keeps the sponge advantages, including no length-extension exposure.
  • Con: It carries no NIST approval, which can block it in regulated procurement.
  • Con: Python hashlib and the OpenSSL command line do not include it.
  • Con: Its name collides with sha3 in older tools, which invites silent bugs.

SHA3-256

  • Pro: It is a final NIST standard under FIPS 202 and remains approved as of November 2026.
  • Pro: It ships in Python hashlib, OpenSSL, Go and Rust standard or near-standard packages.
  • Pro: Its domain separation keeps its output unrelated to SHAKE and cSHAKE results for the same input.
  • Con: It is usually slower than SHA-256 in software on a CPU without SHA extensions, and the gap widens where SHA-256 has hardware help.
  • Con: It cannot reproduce any Ethereum value, so EVM tooling needs the other function.
  • Con: Adoption trails SHA-256, so some protocols and verifiers simply do not accept it.

Scan both lists and one pattern stands out. Every drawback of Keccak-256 is about standards and tooling, and every drawback of SHA3-256 is about ecosystem fit. Nobody lists a cryptographic weakness for either, because there is none to list.

Six Use Cases and the Function to Pick

1. Ethereum or EVM-chain development. Use Keccak-256 for addresses, selectors, event topics, storage slot derivation and anything a contract must verify on chain. The protocol expects it, and the documentation confirms no replacement plan.

2. Federal or regulated software. Use SHA3-256, or SHA-256 if the buyer’s profile prefers SHA-2. Both are approved, and Keccak-256 is not. Document the choice in your cryptographic inventory so auditors see a named standard.

3. A brand-new protocol with no Ethereum link. Pick SHA-256 as the default unless you have a reason for a sponge. When you do want a sponge, choose SHA3-256 or the SHAKE functions so every library on every platform can verify your hashes.

4. Keyed hashing and message authentication. Use KMAC from SP 800-185 where available, or HMAC with a SHA-2 or SHA-3 hash where it is not. Do not build a homemade prefix MAC on top of Keccak-256 when a standard construction exists.

5. Hybrid designs that mix Ethereum and standards-based parts. Follow the ERC-8441 pattern and name each function separately. Use SHA3-256 in off-chain combiners and Keccak-256 where the chain verifies the result.

6. Authenticated data structures. Both functions can serve as the node hash in a tree, and the choice follows the verifier. The comparison of Merkle and Verkle trees shows how proof sizes change with the tree design, but the hash underneath must still match what the verifying client uses. A tree committed with Keccak-256 and checked with SHA3-256 never validates.

These six cases cover the decisions most teams face. In five of them the answer follows from a fixed external requirement, and only the third gives you real freedom to choose.

Migration Guide: Fixing a Wrong Hash Call

Teams usually discover the problem when a value fails to match an external system. The repair is mechanical, but it needs discipline, because stored digests cannot be converted from one function to the other. A digest is a one-way fingerprint. You can only recompute it from the original input.

  1. Inventory every call site. Search for sha3, keccak, sha3_256 and SHA3-256 across code, scripts, smart contracts and configuration.
  2. Label each call by the spec it needs. Mark it Ethereum-compatible, FIPS 202 or undecided. Undecided calls get a ticket and an owner.
  3. Add the four test vectors above to CI. Assert the empty-string and abc digests for both functions so a library swap fails the build.
  4. Wrap the functions once. Create keccak256_ethereum and sha3_256_fips202 and route every call through them.
  5. Audit dependencies. Check old pysha3 pins, legacy web3.py sha3 helpers and Solidity code from the era of the sha3 alias.
  6. Recompute stored values from source data. Digests in databases, caches or on-chain registries must be regenerated from the original inputs, never transformed.
  7. Run both values in parallel for a short window. Write the old and new digest, compare reads, and log every mismatch.
  8. Remove the old path. Once mismatches reach zero across a full traffic cycle, delete the legacy function and its tests.

A small CI guard keeps the fix in place. This example assumes a project that exposes the two wrapper names from step four:

Even with the right function, four encoding mistakes keep producing mismatched digests. Check each one before you blame the library:

  • Text versus bytes. Hashing the string 0x68656c6c6f is not hashing the five bytes it spells. Decide whether the input is raw bytes or hex text and convert once, at the edge.
  • Character encoding. UTF-8 text with a byte-order mark or a trailing newline hashes differently from the clean string. Trim and normalize before hashing.
  • Packed encodings. Concatenating several fields without length prefixes lets different field splits produce the same bytes, which is a classic collision source in contract code. Use fixed-width or length-prefixed encodings.
  • Truncation. Selectors keep four bytes and addresses keep twenty. Truncate after hashing, never before, and compare the right slice.

Ethereum itself needs no such migration. The official material confirms continued Keccak-256 use and identifies no approved plan to replace it, so on-chain code written today should keep calling keccak256. The migration steps above apply to application code that picked the wrong function, not to the protocol.

Timeline: What Changed and What Is Still Moving in 2026

The timeline shows how little the two hashes themselves have moved. Every 2026 entry touches a neighbor, either a derived function, a public-key migration plan or an Ethereum upgrade, and none rewrites FIPS 202 or the Keccak-256 definition.

FIPS 202 has stayed at its August 2015 edition. NIST has not issued a newer version, and no retirement or rename is confirmed for SHA3-256 or Keccak-256. The December 2016 edition of SP 800-185 also remains the finished text until NIST completes a revision.

The live item is the October 8, 2026 initial public draft of SP 800-185 Revision 1, titled SHA-3 Derived Functions: cSHAKE, KMAC, TupleHash, and ParallelHash. It adds streaming interfaces for extendable-output-function computations, so an application can feed input and pull output in pieces without knowing either length ahead of time. Public comments run through December 7, 2026, which makes the document a draft, not a standard. It changes derived functions only, so SHA3-256 and Keccak-256 digests stay exactly as they are.

NIST also published its post-quantum transition report, IR 8547, on October 27, 2026. As noted earlier, it targets public-key algorithms and does not signal that either hash is going away. A separate NIST pre-draft call on key derivation from pseudorandom functions, dated November 4, 2026, belongs to another topic entirely.

On the Ethereum side, the Foundation announced the Hoodi testnet stage for Glamsterdam on October 16, 2026, after activation on the Sepolia testnet on October 6. The Glamsterdam Hoodi announcement describes enshrined proposer-builder separation and gas-pricing changes tied to state growth. Mainnet activation is not confirmed in the reviewed material. None of the described changes swaps the hash function, so Keccak-256 stays the protocol’s default.

The Keccak Team page also lists RFC 9861, dated October 2025, among the specifications that build on the Keccak permutation. Standards work around the permutation keeps going, but it extends the family rather than redefining the 256-bit hashes compared here. If a rumor claims NIST will rename or replace Keccak-256, treat it as unfounded, because the sources found no such announcement.

Verdict: Keccak-256 vs SHA3-256, Which One to Use

Pick by the system you must match, not by taste. The data leaves little room for debate: both functions run the same 24-round permutation at a 1,088-bit rate, both give 128-bit collision resistance, and both cost the same per hash. The deciding facts are a suffix of 0x01 against 0x06, a digest difference of 138 of 256 bits on abc, and an approval status that exists for one function and not the other.

When the table does not settle a case, three questions will. Does any part of the system have to match an Ethereum address, selector or on-chain hash? If yes, use Keccak-256 for that part. Does a buyer, regulator or standard require a NIST-approved hash? If yes, use SHA3-256 or SHA-256 for that part. Do neither of those apply? Then use whichever has the best library support in your stack, which is usually SHA-256, and write the choice down next to the code.

The takeaway: Keccak-256 wins wherever Ethereum compatibility is the requirement, and SHA3-256 wins everywhere a standard, a compliance review or a library default matters. Neither beats the other on security, and neither is losing support in 2026. The cost of confusing them is a failed lookup, a rejected transaction or a lost afternoon.

More hash and signature comparisons sit in the cryptography archive, and the habit that pays off most is small: name the function after its spec, test it against known vectors and never trust a bare sha3.

FAQ: Keccak-256 vs SHA3-256

Is Keccak-256 the same as SHA3-256?

No. They use the same Keccak sponge and the same 256-bit output size, but Keccak-256 pads with the original 0x01 byte and SHA3-256 pads with 0x06 after domain-separation bits. The digests differ for every input. For the empty string, Keccak-256 gives c5d246… and SHA3-256 gives a7ffc6…

Which one does Ethereum use?

Ethereum uses Keccak-256. Its documentation states that account addresses come from the last 20 bytes of the Keccak-256 hash of the public key and that web3_sha3 returns Keccak-256, not standardized SHA3-256. The sources show no approved migration plan.

Is Keccak-256 less secure than SHA3-256?

No. Both have the same permutation, rate and capacity, so both offer about 128 bits of generic collision resistance and 256 bits of preimage resistance. The difference is standards status, since SHA3-256 is NIST-approved and Keccak-256 is not.

Which is faster?

They cost the same per hash because the work per block is identical. Any small timing gap between the two in a simple test reflects noise rather than a real difference. Against SHA-256, SHA3-256 is usually slower on a CPU without SHA extensions.

Does Python’s hashlib include Keccak-256?

No. Python’s hashlib.algorithms_available lists only the NIST SHA-3 names. Use a package such as pycryptodome, or an Ethereum library, when you need the original Keccak padding.

Can I convert a Keccak-256 digest into a SHA3-256 digest?

No. A digest is a one-way fingerprint with no recoverable input. You must recompute the new digest from the original data with the other function.

Will the NIST SP 800-185 revision change either function?

No. The October 8, 2026 draft of SP 800-185 Revision 1 covers cSHAKE, KMAC, TupleHash and ParallelHash, adding streaming interfaces for extendable-output functions. Comments close December 7, 2026, and FIPS 202 itself stays as published in August 2015.

Does post-quantum migration retire these hashes?

Not according to the reviewed material. NIST released IR 8547 on October 27, 2026, and it concerns the move away from quantum-vulnerable public-key algorithms. Nothing in it indicates that SHA3-256 or Keccak-256 is being retired.

Laura Bennett edits and fact-checks shattered.io security and privacy coverage, making sure each piece is clear, current, and grounded in primary sources.