Hubbry Logo
NIST hash function competitionNIST hash function competitionMain
Open search
NIST hash function competition
Community hub
NIST hash function competition
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
NIST hash function competition
NIST hash function competition
NIST hash function competition
View on Wikipedia
from Wikipedia

The NIST hash function competition was an open competition held by the US National Institute of Standards and Technology (NIST) to develop a new hash function called SHA-3 to complement the older SHA-1 and SHA-2. The competition was formally announced in the Federal Register on November 2, 2007.[1] "NIST is initiating an effort to develop one or more additional hash algorithms through a public competition, similar to the development process for the Advanced Encryption Standard (AES)."[2] The competition ended on October 2, 2012, when NIST announced that Keccak would be the new SHA-3 hash algorithm.[3]

The winning hash function has been published as NIST FIPS 202 the "SHA-3 Standard", to complement FIPS 180-4, the Secure Hash Standard.

The NIST competition has inspired other competitions such as the Password Hashing Competition.

Process

[edit]

Submissions were due October 31, 2008 and the list of candidates accepted for the first round was published on December 9, 2008.[4] NIST held a conference in late February 2009 where submitters presented their algorithms and NIST officials discussed criteria for narrowing down the field of candidates for Round 2.[5] The list of 14 candidates accepted to Round 2 was published on July 24, 2009.[6] Another conference was held on August 23–24, 2010 (after CRYPTO 2010) at the University of California, Santa Barbara, where the second-round candidates were discussed.[7] The announcement of the final round candidates occurred on December 10, 2010.[8] On October 2, 2012, NIST announced its winner, choosing Keccak, created by Guido Bertoni, Joan Daemen, and Gilles Van Assche of STMicroelectronics and Michaël Peeters of NXP.[3]

Entrants

[edit]

This is an incomplete list of known submissions. NIST selected 51 entries for round 1.[4] 14 of them advanced to round 2,[6] from which 5 finalists were selected.

Winner

[edit]

The winner was announced to be Keccak on October 2, 2012.[9]

Finalists

[edit]

NIST selected five SHA-3 candidate algorithms to advance to the third (and final) round:[10]

NIST noted some factors that figured into its selection as it announced the finalists:[11]

  • Performance: "A couple of algorithms were wounded or eliminated by very large [hardware gate] area requirement – it seemed that the area they required precluded their use in too much of the potential application space."
  • Security: "We preferred to be conservative about security, and in some cases did not select algorithms with exceptional performance, largely because something about them made us 'nervous,' even though we knew of no clear attack against the full algorithm."
  • Analysis: "NIST eliminated several algorithms because of the extent of their second-round tweaks or because of a relative lack of reported cryptanalysis – either tended to create the suspicion that the design might not yet be fully tested and mature."
  • Diversity: The finalists included hashes based on different modes of operation, including the HAIFA and sponge function constructions, and with different internal structures, including ones based on AES, bitslicing, and alternating XOR with addition.

NIST has released a report explaining its evaluation algorithm-by-algorithm.[12][13][14]

Did not pass to final round

[edit]

The following hash function submissions were accepted for round two, but did not make it to the final round. As noted in the announcement of the finalists, "none of these candidates was clearly broken".

Did not pass to round two

[edit]

The following hash function submissions were accepted for round one but did not pass to round two. They have neither been conceded by the submitters nor have had substantial cryptographic weaknesses. However, most of them have some weaknesses in the design components, or performance issues.

Entrants with substantial weaknesses

[edit]

The following non-conceded round one entrants have had substantial cryptographic weaknesses announced:

Conceded entrants

[edit]

The following round one entrants have been officially retracted from the competition by their submitters; they are considered broken according to the NIST official round one candidates web site.[54] As such, they are withdrawn from the competition.

Rejected entrants

[edit]

Several submissions received by NIST were not accepted as first-round candidates, following an internal review by NIST.[4] In general, NIST gave no details as to why each was rejected. NIST also has not given a comprehensive list of rejected algorithms; there are known to be 13,[4][68] but only the following are public.

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

NIST hash function competition

View on Grokipedia
from Grokipedia
The NIST Cryptographic Hash Algorithm Competition, commonly referred to as the competition, was a public contest organized by the National Institute of Standards and Technology (NIST) to develop and standardize a new family of cryptographic hash functions in response to emerging vulnerabilities in prior standards like and SHA-1. Announced on November 2, 2007, the competition solicited algorithm submissions from the global cryptographic community to ensure robust security for applications such as digital signatures, message authentication, and verification. The competition process spanned five years and involved multiple evaluation rounds, beginning with a submission deadline of October 31, 2008, which yielded 64 candidate algorithms from 21 countries. In the first round, NIST advanced 51 candidates on December 10, 2008, for further scrutiny based on initial analyses and assessments; this was narrowed to 14 in the second round on July 24, 2009. The third and final round, announced on December 9, 2010, featured five finalists: BLAKE, Grøstl, JH, Keccak, and Skein, selected after extensive , hardware/software , and public feedback at workshops. prioritized security against collision, preimage, and second-preimage attacks, followed by performance metrics like speed and across platforms, as well as design qualities such as and flexibility. On October 2, 2012, NIST selected Keccak—designed by a team including Guido Bertoni, , Michaël Peeters, and Gilles Van Assche—as the winner, citing its sponge construction's strong security margins and hardware-friendly design. Keccak was subsequently standardized as in Federal Information Processing Standard (FIPS) 202, published in August 2015, defining variants like SHA3-224, SHA3-256, SHA3-384, and SHA3-512, alongside extendable-output functions (XOFs) SHAKE128 and SHAKE256. This complemented the existing family without replacing it, providing diversified options for federal and broader use. The competition's transparent, open process fostered international collaboration and advanced research, influencing subsequent cryptographic standards.

Introduction and Background

Motivation for the Competition

The development of secure hash functions has been critical to cryptographic systems, but early algorithms like faced significant vulnerabilities. Proposed in 1991, was compromised in 1996 when Hans Dobbertin demonstrated a collision in its compression function, revealing weaknesses that undermined its . Similarly, , standardized by NIST in FIPS 180-1 in 1995, suffered a major blow in 2005 when Xiaoyun Wang and colleagues published a practical requiring approximately 2^63 operations, far fewer than the expected 2^80 for its 160-bit output. In response, NIST assessed the attack as feasible for well-resourced adversaries and, by 2007 in SP 800-57, recommended against using for new applications due to its reduced security margin, urging a transition to stronger alternatives. While the family—introduced in FIPS 180-2 in 2002 with variants like SHA-256 and SHA-512—offered improved security through larger output sizes and refined designs, it inherited the Merkle-Damgård construction from , making it susceptible to similar generic attacks such as length extensions and multicollisions. This shared structure raised concerns about potential future cryptanalytic breakthroughs that could propagate vulnerabilities across the family, compounded by 's fixed output lengths, which limited adaptability for emerging applications requiring variable security levels. As the authority for federal cryptographic standards under the FIPS 180 series, NIST recognized the need for a diverse, next-generation to complement rather than immediately replace , ensuring long-term robustness without disrupting existing deployments. These vulnerabilities heightened broader concerns over integrity in critical protocols, including digital signatures for certificates, message authentication codes for data integrity, and random oracle models in security proofs, where a single collision could enable or protocol breaks with catastrophic consequences. To address this, NIST sought innovative designs beyond traditional constructions, such as the sponge paradigm, to foster greater resilience against unforeseen attacks.

Announcement and Goals

On November 2, 2007, the National Institute of Standards and Technology (NIST) officially announced a public competition to solicit candidate algorithms for a new cryptographic hash algorithm family, designated , through a notice in the . This initiative aimed to develop one or more royalty-free, unclassified hash algorithms to augment the existing SHA-2 family, ensuring they could serve as secure drop-in replacements in federal applications without requiring modifications to protocols or software. The primary goals included producing hash functions with fixed output sizes of 224, 256, 384, and 512 bits, capable of processing messages up to at least 2^64 - 1 bits in length, while also supporting optional extendable-output functions (XOFs) for generating variable-length outputs beyond these fixed sizes. NIST emphasized the need for design diversity to mitigate risks associated with shared structural weaknesses in prior hash functions, explicitly encouraging submissions that deviated from the traditional Merkle-Damgård construction—such as sponge constructions or HAIFA (HAsh Iterated Framework with Applications)—to explore alternative chaining modes, padding rules, and input processing methods. Submissions were required to include detailed security analyses, including reduction-based proofs where applicable, demonstrating resistance to key attacks like collisions, preimages, and second preimages, with a focus on providing at least the same security levels as SHA-2. Additionally, NIST promoted efficiency in both hardware and software implementations across diverse platforms, including resource-constrained environments like 8-bit processors, though candidates were not required to outperform SHA-2 in raw speed. The competition's scope prioritized long-term security robustness to ensure resilience against future attacks and viability well into the foreseeable future. This focus stemmed from recent vulnerabilities exposed in earlier hash functions like and , which had prompted NIST to seek fundamentally different designs capable of withstanding future cryptanalytic advances.

Process and Methodology

Timeline of Events

The NIST SHA-3 Cryptographic Hash Algorithm Competition was initiated to develop a new hash function family to complement SHA-2, following concerns over potential weaknesses in earlier SHA algorithms. The process spanned approximately five years, from November 2007 to October 2012, exceeding the duration of the AES competition (which lasted about three years from 1997 to 2000) due to the extensive cryptanalysis required for hash functions. Throughout the competition, NIST organized public comment periods after each round to gather feedback on candidate algorithms and provided iterative reports highlighting identified weaknesses, enabling ongoing refinement by the cryptographic community. Public workshops facilitated discussions among researchers, with key events including the First SHA-3 Candidate Conference in Leuven, Belgium (February 25–28, 2009), the Second SHA-3 Candidate Conference at the University of California, Santa Barbara (August 23–24, 2010), and the Third SHA-3 Candidate Conference in Washington, D.C. (March 22–23, 2012). The following table summarizes the key chronological milestones:
DateEvent
November 2, 2007 notice launching the competition with a call for candidate nominations.
October 31, 2008Submission deadline; NIST received 64 complete candidate packages.
December 10, 2008Announcement of 51 first-round candidates meeting minimum acceptability criteria; start of first-round public review.
July 24, 2009Announcement of 14 second-round candidates following first-round analysis; end of first round and start of second-round public review on September 28, 2009.
December 9, 2010Announcement of 5 finalists (BLAKE, Grøstl, JH, Keccak, and Skein) advancing to the third round; end of second round and start of third-round public review on January 31, 2011.
October 2, 2012Announcement of Keccak as the winner of the competition, concluding the selection process.

Submission and Round Structure

The NIST hash function competition was open to submissions from the public, inviting cryptographers worldwide to propose new hash algorithms. To qualify, each submission was required to include a detailed specification document outlining the algorithm's design, reference and optimized implementations in C code, known-answer tests for verification, and a comprehensive security analysis demonstrating resistance to known attacks. Intellectual property statements were also mandatory to ensure non-restrictive licensing for federal use. By the deadline of October 31, 2008, NIST received 64 complete submissions meeting these criteria. In Round 1, NIST conducted an initial automated and manual screening to filter submissions for completeness and compliance with the basic requirements. This process focused on verifying the presence of all mandatory components, such as documentation quality and preliminary assessments through basic implementations. On December 10, 2008, 51 candidates were advanced to full Round 1 evaluation, as they satisfied these minimum acceptance criteria without major deficiencies. The round emphasized documentation clarity and initial feasibility, allowing the cryptographic community to begin public analysis via workshops and online forums. Round 2 involved deeper scrutiny of the 51 candidates, incorporating feedback from the first SHA-3 Candidate Conference and ongoing community cryptanalysis. NIST evaluated aspects such as through testing reduced-round versions for distinguishers and partial attacks, alongside implementation simplicity to assess ease of software and hardware deployment. Submitters were encouraged to address identified issues, such as potential weaknesses or optimization opportunities. On July 24, 2009, 14 algorithms were selected to advance, based on their ability to withstand initial attacks and demonstrate balanced characteristics. The final round, often referred to as Round 3, featured intensive evaluation of the 14 candidates, culminating in the selection of 5 finalists—BLAKE, Grøstl, JH, Keccak, and Skein—on December 9, 2010. These finalists underwent rigorous third-party from the global research community, including attempts to find practical breaks in security properties. NIST requested specific tweaks to strengthen designs, such as adjustments to Keccak's capacity parameter to improve its security-performance trade-off while maintaining its sponge construction integrity. The process included the second SHA-3 Candidate Conference and extensive benchmarking, with the round concluding on October 2, 2012, when Keccak was announced as the winner. Advancement through each round was not based on a predetermined number of candidates but rather on qualitative and quantitative assessments of their resilience. Key factors included surviving cryptanalytic attacks without practical vulnerabilities emerging, positive community feedback from forums and publications, and overall suitability for diverse applications. This flexible, iterative approach allowed NIST to refine the field progressively while incorporating expert input.

Security and Performance Criteria

The NIST SHA-3 competition established rigorous security requirements for candidate hash functions, aiming to ensure robust protection against fundamental cryptographic threats. For the SHA-3 family, was mandated at a minimum of 112 bits for the 224-bit variant, scaling to 256 bits for the 512-bit variant, reflecting the general expectation of approximately n/2-bit security for an n-bit output. Preimage resistance was required at the full output , such as 224 bits for SHA3-224 and 512 bits for SHA3-512, while second preimage resistance matched preimage levels for up to the block size. Additionally, candidates needed to demonstrate resistance to length-extension attacks, where an adversary cannot exploit knowledge of a hash and its input to forge a valid hash for a modified , a vulnerability present in Merkle-Damgård constructions like SHA-2. Beyond basic properties, NIST evaluated resistance to advanced cryptanalytic techniques, including differential attacks that exploit differences in input pairs to find collisions or preimages, seeking linear approximations of the function, and algebraic attacks modeling the algorithm as a for efficient solving. These analyses focused on the practicality of any weaknesses, their impact on applications like digital signatures and message authentication codes, and the overall security margin, such as the fraction of rounds unbroken by known attacks. Performance criteria balanced cryptographic strength with practical deployment, measuring software efficiency through metrics like cycles per byte on general-purpose CPUs, such as the Intel Core 2 Duo reference platform, to assess speed for digest computation and initialization. Hardware efficiency was gauged by gate equivalents for ASIC implementations and throughput on FPGAs, alongside considerations for energy consumption per bit processed, particularly for resource-constrained environments like embedded devices. Other evaluation factors included flexibility for extendable-output functions (XOFs), such as SHAKE, allowing arbitrary-length outputs while maintaining security bounds like 128 bits for SHAKE128, and inherent resistance to side-channel attacks, including timing variations, , and , though distinctions among finalists were limited. NIST also valued diversity in design paradigms, such as constructions versus permutation-based approaches, to mitigate risks from shared vulnerabilities across similar structures. The assessment combined NIST-led testing with extensive public , submitted by the community during each round, without any single criterion dominating; instead, trade-offs in security, performance, and characteristics were weighed holistically to select candidates advancing to subsequent rounds.

Participants

Overview of Submissions

The NIST hash function competition attracted 64 submissions from more than 24 countries, reflecting broad international interest in advancing cryptographic hash technology. Of these, 51 advanced to the first round following an initial review, while 13 were rejected for failing to meet minimum submission requirements, such as providing incomplete documentation, , or disclosures. Additionally, a few teams voluntarily withdrew their entries early in the process after discovering prior cryptanalytic breaks or other disqualifying issues, including first-round candidates and Boole, which exhibited obvious structural weaknesses like inadequate diffusion properties. The accepted submissions demonstrated considerable design diversity, with a substantial portion relying on AES-based primitives for their compression functions, alongside notable examples employing sponge constructions (such as Keccak and Luffa), HAIFA modes (such as BLAKE and SHAvite-3), and various custom permutations or Merkle-Damgård variants. Contributors spanned academia (with strong representation from European institutions), industry (including teams from IBM), and independent researchers, fostering a rich exchange of innovative approaches. From the first-round pool of 51 candidates, 14 progressed to the second round, leaving 37 that did not advance due to relatively minor performance or security concerns relative to stronger alternatives, as determined by public feedback and NIST's internal analysis.

Finalists and Selection

On December 9, 2010, NIST announced the five finalists advancing to the final round of the SHA-3 competition: BLAKE, Grøstl, JH, Keccak, and Skein. These algorithms were selected from the 14 second-round candidates based on a combination of public , performance evaluations, and internal NIST review. BLAKE, developed by a Swiss team led by Jean-Philippe Aumasson, Luca Henzen, Willi Meier, and Raphael C.-W. Phan, is based on the ChaCha stream cipher core combined with the iteration mode. Its design relies on ARX (Addition-Rotation-XOR) operations, which provide resistance to linear and differential cryptanalysis. Grøstl, proposed by an international team including Austrian researchers from such as Florian Mendel and Martin Schläffer, employs an AES-like structure with the same and a wide-trail strategy to ensure diffusion across rounds. JH, designed by Hongjun Wu, uses simple nonlinear on a large state, emphasizing compactness and efficiency through a straightforward iterative mode. Keccak, created by a Belgian team of Bertoni, Joan Daemen, Michaël Peeters, and Gilles Van Assche, adopts construction, which absorbs input into a fixed-width state via a and squeezes output as needed. Skein, developed by a team including and Niels Ferguson with affiliations, builds on the tweakable and the Unique Block Iteration (UBI) chaining mode for flexible message processing. The selection rationale centered on each finalist's demonstrated strong security margins against known attacks, with no practical breaks identified after extensive third-party analysis. For instance, BLAKE's ARX primitives resisted linear attacks up to beyond the required security levels, while Grøstl's wide-trail design mitigated differential paths effectively. They also exhibited balanced performance across platforms, such as Skein's high software speed on general-purpose processors and JH's compact hardware implementations suitable for resource-constrained devices. NIST's feedback during the competition prompted optimizations, including round reductions in some candidates to improve efficiency without compromising margins. The finalists achieved diversity in design paradigms, with Keccak representing the sponge approach and Grøstl and JH relying on permutation-based iterations, while BLAKE and Skein used block-cipher-like structures. This variety ensured broad resistance profiles, as extensive revealed no exploitable weaknesses in any, reinforcing their suitability for standardization. In contrast, second-round candidates like SIMD and were eliminated due to emerging weaknesses uncovered during analysis. For example, faced multidimensional attacks that reduced its claimed security margin, prompting concerns over long-term robustness. Similarly, SIMD exhibited vulnerabilities to differential attacks that NIST deemed too risky for further advancement.

The Winner: Keccak

Keccak was designed by Guido Bertoni, Joan Daemen, Michaël Peeters, and Gilles Van Assche, affiliated with and . The core of Keccak is a family of sponge functions built around the Keccak-f , which operates on a 1600-bit state divided into 25 lanes of 64 bits each. This applies 24 rounds, each consisting of five step mappings: (for diffusion across lanes), rho (bit rotations within lanes), pi (lane repositioning), chi (nonlinear local transformations), and (XOR with round constants for asymmetry). The sponge construction absorbs input message blocks by XORing them into the rate portion (r bits) of the state and then applying the full to the entire state (r + c bits, where c is the capacity); after absorption, it squeezes output by XORing portions of the state without further input. The sponge function can be formally described as follows. Let the state be S∈{0,1}1600S \in \{0,1\}^{1600}, divided into rate RR (first r bits) and capacity CC (remaining c bits, with r + c = 1600). For absorption of a padded message block PP (length ≤ r): S←(R⊕P)∥C;S←f(S)S \leftarrow (R \oplus P) \| C; \quad S \leftarrow f(S) where ff denotes the Keccak-f permutation. For squeezing d bits of output ZZ: Z←XOR of first d bits of R;S←f(S)(repeat if d > r)Z \leftarrow \text{XOR of first d bits of } R; \quad S \leftarrow f(S) \quad (\text{repeat if d > r}) The capacity c controls the security level, providing resistance up to 2c/22^{c/2} operations against generic attacks like preimages or collisions. For instance, in the SHA-3-256 variant, c = 512 bits ensures 256-bit , with r = 1088 bits for efficient processing. This design enables extendable-output functions (XOFs) by continuing the squeezing phase arbitrarily, offering versatility beyond fixed-length hashes. NIST selected Keccak as the SHA-3 winner due to its superior performance characteristics, particularly in hardware implementations, where it achieves a small footprint (around 2-3 kgates for the ) and high throughput (up to several gigabits per second on FPGAs). In software, it performs competitively on 8-bit microcontrollers and 64-bit processors, often matching or exceeding speeds while using less memory. Security-wise, Keccak demonstrated strong diffusion properties through extensive , with no practical weaknesses identified after years of scrutiny, including resistance to differential, linear, and algebraic attacks. Its construction fundamentally differs from the Merkle-Damgård structure of , providing confidence in long-term robustness even if MD-style vulnerabilities emerge. Additionally, the -based approach supports flexible security-speed trade-offs and native XOF capability, aligning with NIST's goals for future-proof cryptography. Following selection, NIST modified aspects of the original Keccak submission to finalize parameters in FIPS 202, including a simplified scheme that appends a two-bit (01 for hash functions) to the message for domain separation from XOFs and other modes. Capacities were adjusted for balanced and ; for example, the SHA-3-256 instance uses c = 512 bits (r = 1088), providing exact 256-bit margins, whereas the original proposal offered options like c = 576 bits for slightly higher theoretical resistance at the cost of reduced throughput. These changes prioritized practical efficiency while maintaining the core construction and permutation intact.

Results and Aftermath

Standardization of SHA-3

On October 2, 2012, the National Institute of Standards and Technology (NIST) announced the selection of Keccak as the basis for the new , marking the conclusion of the cryptographic hash function competition. This decision initiated the formal standardization process, which involved refining Keccak's parameters and specifications to meet federal security requirements. NIST released a draft of Federal Information Processing Standard (FIPS) 202 in May 2014, soliciting public comments to refine the proposed standard. Feedback from the cryptographic community was incorporated, addressing aspects such as domain separation and compatibility features, leading to the final version. The process proceeded without significant controversies, though teams behind other finalist algorithms expressed some disappointment over the outcome. FIPS 202 was officially published on August 5, 2015, specifying the family of hash functions—SHA3-224, SHA3-256, SHA3-384, and SHA3-512—with fixed output lengths of 224, 256, 384, and 512 bits, respectively, alongside two extendable-output functions (XOFs), SHAKE128 and SHAKE256. These functions are built on the Keccak sponge construction, which supports multi-rate absorption and squeezing for varying input and output sizes, enhancing efficiency in diverse applications. NIST adopted key parameters from the original Keccak proposal, such as setting the capacity c=512c = 512 bits and rate r=1088r = 1088 bits for SHA3-256 (where the state width b=r+c=[1600](/page/1600)b = r + c = [1600](/page/1600) bits), providing strong security margins while maintaining the permutation-based . Additionally, FIPS 202 includes optional support for tree hashing modes using the Sakura encoding scheme, allowing parallel computation for large inputs via SHAKE functions. The standard aligns with international efforts in cryptographic specifications, including aspects of the ISO/IEC 29192 series for lightweight cryptography where applicable, though targets broader use cases. NIST positioned as an optional complement to the existing family, with no mandated deprecation or transition timeline for , emphasizing coexistence to support gradual adoption in federal systems.

Adoption Challenges and Usage

Following its standardization in 2015, SHA-3 saw initial integration into major cryptographic libraries, enabling early adoption in software ecosystems. OpenSSL included support for SHA-3 with the release of version 1.1.0 in August 2016, allowing developers to implement it in applications requiring FIPS-compliant hashing. Similarly, the Bouncy Castle library, a widely used Java cryptography provider, incorporated SHA-3 functionality around the same period, facilitating its use in enterprise Java environments and Android applications. In protocol contexts, SHA-3 found application in extensions to TLS 1.3 for signature algorithms and key derivation, where it can replace SHA-2 variants in hybrid configurations, and in IPsec implementations via emerging IETF drafts specifying its use with HMAC for integrity protection. Despite these integrations, SHA-3 faced significant adoption challenges, primarily stemming from performance disparities and ecosystem inertia. In software implementations, particularly on x86 architectures, SHA-3 exhibits slower throughput compared to SHA-256 due to its sponge construction, which prioritizes security over optimized bitwise operations common in SHA-2. Hardware acceleration lagged behind, with widespread CPU support only emerging in the ; for instance, ARMv8.6 introduced native Keccak instructions in , but earlier platforms relied on software emulation, exacerbating the speed gap. Additionally, the entrenched use of SHA-256 in legacy systems, such as web servers and VPNs, created resistance to migration, as updating protocols often required minimal security gains without immediate performance benefits. By 2025, SHA-3 has become a standard component in NIST-approved cryptographic modules, serving as a recommended alternative to in FIPS 140-validated systems for applications demanding enhanced . Its role has expanded in quantum-resistant contexts, where it pairs with post-quantum algorithms in hybrid schemes, such as NIST's PQC standards for key encapsulation and digital signatures, leveraging its resilience to attacks on hash preimages. In ecosystems, SHA-3 variants appear in experimental quantum-secure ledgers and alternatives to mining, with ASICs developed for high-throughput Keccak-based hashing to support energy-efficient proof-of-work. , while primarily using the related Keccak-256 function, has explored SHA-3 integrations for future upgrades to bolster post-quantum compatibility. Performance optimizations continue via dedicated hardware, including FPGA and ASIC implementations that achieve multi-gigabit-per-second rates, closing the gap with in specialized deployments. In March 2025, NIST announced plans to update FIPS 202 and revise SP 800-185 to incorporate additional Keccak-based functions and refinements based on public feedback. Adoption metrics indicate steady but gradual progress: as of 2025, many newly published cryptographic protocols, such as those from the IETF and ISO, recommend alongside for forward-looking designs. Full-scale migration remains projected post-2030, aligned with NIST's ongoing evaluation of longevity amid quantum threats, though no formal phase-out for has been announced. The sponge construction's inherent flexibility has aided this uptake by enabling variable output lengths and extendable-output functions like SHAKE, suitable for diverse use cases without redesign.

Broader Impact

The NIST hash function competition significantly advanced cryptographic research by popularizing the sponge construction, a permutation-based design paradigm exemplified by the winning Keccak . This approach, which absorbs input data into a state and squeezes out fixed or variable-length outputs, has since influenced subsequent standards, including the Ascon family selected in the 2023 NIST Lightweight Cryptography (LWC) standardization process. The competition also refined key techniques, such as rebound attacks—a variant of differential that merges internal differentials across rounds—which were developed and improved during evaluations of candidate functions like Grøstl. The competition's open evaluation model directly inspired later standardization efforts, including the (PHC) from 2013 to 2015, which adopted a similar multi-round public review process and selected as its winner for memory-hard password hashing. It further informed the design of lightweight cryptographic primitives in the NIST LWC initiative, where sponge-based hashes like Ascon-Hash were prioritized for resource-constrained environments. Additionally, the competition contributed to post-quantum hash designs by highlighting the resilience of permutation-based structures, which underpin quantum-resistant hash-based signature schemes standardized in NIST's (PQC) project. The competition's transparent process fostered unprecedented global collaboration among cryptographers, drawing submissions from international teams across 21 countries and spurring the publication of over 200 papers and reports on the 64 candidate algorithms. This scrutiny elevated awareness of diversity, shifting research away from traditional Merkle-Damgård constructions toward more varied paradigms like sponges to mitigate shared vulnerabilities. By 2025, the competition's multi-round, community-driven model had been widely adopted for NIST's PQC standardization, which began in 2016 and produced initial standards in 2024, demonstrating its effectiveness in selecting robust algorithms through iterative . Despite some critiques regarding NIST's adjustments to Keccak's capacity rate in the final FIPS 202 specification—which the original designers argued reduced the margin—the process overall bolstered trust in NIST's cryptographic standardization procedures.

References

  1. https://csrc.nist.gov/pubs/ir/7896/final
  2. https://csrc.nist.gov/projects/hash-functions/sha-3-project
  3. https://csrc.nist.gov/pubs/fips/202/final
  4. https://www.nist.gov/programs-projects/cryptographic-hash-algorithm-competition
  5. https://csrc.nist.gov/pubs/sp/800/57/pt1/r2/final
  6. https://csrc.nist.gov/pubs/fips/180-2/final
  7. https://www.federalregister.gov/documents/2007/11/02/E7-21581/announcing-request-for-candidate-algorithm-nominations-for-a-new-cryptographic-hash-algorithm-sha-3
  8. https://www.federalregister.gov/documents/2007/01/23/E7-927/announcing-the-development-of-new-hash-algorithms-for-the-revision-of-federal-information-processing
  9. https://nvlpubs.nist.gov/nistpubs/ir/2012/NIST.IR.7896.pdf
  10. https://nvlpubs.nist.gov/nistpubs/legacy/ir/nistir7620.pdf
  11. https://csrc.nist.gov/pubs/ir/7764/final
  12. https://www.nist.gov/news-events/news/2012/10/nist-selects-winner-secure-hash-algorithm-sha-3-competition
  13. https://nvlpubs.nist.gov/nistpubs/legacy/ir/nistir7764.pdf
  14. https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.202.pdf
  15. https://csrc.nist.gov/CSRC/media/Presentations/The-NIST-Standardization-Approach-on-Cryptography/images-media/chen-lily-threshold-crypto-workshop-March-2019.pdf
  16. https://competitions.cr.yp.to/sha3.html
  17. https://keccak.team/keccak.html
  18. https://www.tandfonline.com/doi/abs/10.1080/01611194.2013.856818
  19. https://keccak.team/files/Keccak-submission-3.pdf
  20. https://keccak.team/keccak_specs_summary.html
  21. https://doi.org/10.6028/NIST.IR.7896
  22. https://keccak.team/2013/yes_this_is_keccak.html
  23. https://www.federalregister.gov/documents/2014/05/28/2014-12336/announcing-draft-federal-information-processing-standard-fips-202-sha-3-standard-permutation-based
  24. https://www.nist.gov/news-events/news/2014/05/nist-requests-public-comment-proposed-sha-3-cryptographic-standard
  25. https://keccak.team/2012/sha3decision.html
  26. https://www.nist.gov/news-events/news/2015/08/nist-releases-sha-3-cryptographic-hash-standard
  27. https://csrc.nist.gov/CSRC/media/Presentations/nist-lwc-standardization/images-media/session1-turan-update-on-nist-lwc-standardization.pdf
  28. https://www.csoonline.com/article/564619/why-arent-we-using-sha3.html
  29. https://www.nccoe.nist.gov/sites/default/files/2023-12/pqc-migration-nist-sp-1800-38c-preliminary-draft.pdf
  30. https://datatracker.ietf.org/doc/draft-salter-ipsecme-sha3/
  31. https://www.researchgate.net/publication/262070733_Performance_Analysis_of_SHA-2_and_SHA-3_Finalists
  32. https://crypto.stackexchange.com/questions/72507/why-isn-t-sha-3-in-wider-use
  33. https://csrc.nist.gov/projects/hash-functions/nist-policy-on-hash-functions
  34. https://www.isaca.org/resources/news-and-trends/industry-news/2025/post-quantum-cryptography-a-call-to-action
  35. https://www.worldscientific.com/doi/10.1142/S2196888825500204
  36. https://www.preprints.org/manuscript/202508.1672
  37. https://ieeexplore.ieee.org/document/9700252/
  38. https://www.nist.gov/news-events/news/2025/03/sha-3-nist-update-fips-202-and-revise-special-publication-800-185
  39. https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.pdf?__blob=publicationFile&v=10
  40. https://www.nist.gov/news-events/news/2022/12/nist-retires-sha-1-cryptographic-algorithm
  41. https://nvlpubs.nist.gov/nistpubs/ir/2023/NIST.IR.8454.pdf
  42. https://eprint.iacr.org/2010/607.pdf
  43. https://www.password-hashing.net/
  44. https://csrc.nist.gov/projects/post-quantum-cryptography
Add your contribution
Related Hubs
User Avatar
No comments yet.