In 2012, the cryptographic algorithm Keccak was declared the winner of the prestigious, multi-year SHA-3 competition held by the U.S. National Institute of Standards and Technology (NIST). It was a clear victory for an elegant and innovative design. But when NIST published the official standard as FIPS 202 SHA-3 in 2015, the cryptographic community noticed some small but deliberate changes had been made. This led to a natural and important question: is the official SHA-3 the same as the Keccak that won the competition?
The answer is both yes and no. While the powerful cryptographic engine at the core remains identical, NIST's final standard differs in subtle ways from the original submission. This article provides a comparative analysis of these changes and explores their cryptographic implications.
The Engine is the Same: Keccak-f[1600]
First, let's be clear: the fundamental cryptographic permutation, Keccak-f[1600] with its 24 rounds, is completely unchanged. The sponge construction, which defines how data is absorbed and squeezed, also remains the same. Anyone using an official SHA-3 library is absolutely getting the full security benefits of the Keccak design. The changes made by NIST were not to the core algorithm, but to the 'trim' around it.
The Main Difference: A New Padding Scheme
The most significant change between Keccak and FIPS 202 SHA-3 is the padding scheme. Before a message is hashed, it must be padded to a multiple of the rate's block size.
- Original Keccak Padding: The original submission used a simple and elegant padding scheme. A bit '1' is appended, followed by the minimum number of '0' bits, and finally a trailing '1' bit. This is often called the `10...1` padding.
- FIPS 202 SHA-3 Padding: NIST specified a new scheme. For the main SHA-3 hash functions (e.g., SHA3-256), a `01` bit suffix is appended to the message before the standard `10...1` padding is applied. For the extendable-output functions (SHAKEs), a `1111` suffix is used instead.
Why Did NIST Change It?
NIST's official justification was for 'domain separation'. This means ensuring that a message intended for one hash function (like SHA3-256) cannot be interpreted as a validly padded message for another function (like SHAKE128). This prevents potential cross-protocol attacks where a hash from one context could be maliciously used in another. While the Keccak team argued this was a non-issue that could be handled at a higher protocol layer, NIST opted for a conservative approach by enforcing it at the primitive level.
Other Minor Changes
A few other minor tweaks were made during standardization:
- Function Definitions: The Keccak submission was a broad family of functions. NIST standardized a specific, fixed subset: SHA3-224, SHA3-256, SHA3-384, SHA3-512, and the extendable-output functions (XOFs) SHAKE128 and SHAKE256.
- Capacity of SHA3-224: NIST tweaked the capacity of SHA3-224 to 576 bits to give it the same collision resistance strength as SHA3-256, providing a more consistent security profile.
The Cryptographic Implications
The cryptographic community largely agrees that **NIST's changes do not weaken the algorithm in any way**. The debate was never about security, but about necessity and design elegance. The Keccak team felt their original design was simpler and more flexible, while NIST prioritized a more rigid and foolproof standard to prevent potential misuse in complex protocols. The practical result of these changes is that a hash computed with an original Keccak implementation will not produce the same value as a hash computed with a FIPS 202 SHA-3 compliant library.
Conclusion: Two Dialects of the Same Language
Think of Keccak and SHA-3 as two dialects of the same secure language. They share the same grammar and vocabulary (the Keccak-f permutation) but have slightly different punctuation rules (the padding). For developers and users, the important takeaway is to be aware of which version is being used. When a protocol specifies 'SHA-3', it refers to the official NIST standard. When it specifies 'Keccak' (as is famously the case with Ethereum), it almost always refers to the original algorithm before NIST's changes.
FAQ (Frequently Asked Questions)
1. Will hashing the same file with Keccak and SHA-3 produce the same hash?
No. Because the padding is different, the input to the underlying permutation will be different, resulting in completely different hash outputs.
2. Which one is more secure, Keccak or the official SHA-3?
Neither is considered more secure than the other. Both are built on the same secure permutation and sponge construction. The debate is about design philosophy, not security strength.
3. What is Ethereum's `keccak256()`?
Ethereum's `keccak256()` function uses the original Keccak algorithm, not the FIPS 202 SHA-3 standard. This is a very common point of confusion for developers. The output of `keccak256('message')` will not be the same as `SHA3-256('message')`.
Post a Comment