SHA-3

• 1. Origins And Design Philosophy

  ›

  On the 5th of August 2015, the National Institute of Standards and Technology released SHA-3 as a new cryptographic standard. This release marked the end of a multi-year competition to find an alternative to existing hash functions like SHA-1 and MD5. The winning algorithm was Keccak, designed by Guido Bertoni, Joan Daemen, Michaël Peeters, and Gilles Van Assche. These four researchers built upon their earlier work on RadioGatún, which itself evolved from the PANAMA design created in 1998. The team submitted Keccak to NIST's Hash Function Competition in late 2008. It emerged as one of fifty-one initial candidates competing for the top spot. By July 2009, fourteen algorithms advanced to the second round of evaluation. Keccak survived this filter and reached the final round in December 2010. During the competition process, entrants were allowed to tweak their designs based on discovered vulnerabilities. The Keccak team increased the number of rounds from twelve to twenty-four to ensure greater security margins. They also simplified the message padding scheme to a straightforward pattern known as 10*1. The rate parameter r was adjusted upward to meet the maximum security limit rather than rounding down to powers of two. On the 2nd of October 2012, judges selected Keccak as the winner of the entire competition. This selection paved the way for official standardization under FIPS 202.

• 2. The Sponge Construction Mechanism

  ›

  SHA-3 relies on a novel architecture called the sponge construction. This method allows any amount of data to be absorbed into an internal state before being squeezed out as output. The process begins by initializing a state S consisting of b zero bits. For SHA-3, the total state size is fixed at 1600 bits arranged as a 5x5 array of words. Input messages are padded using the 10...01 pattern to fit evenly into blocks of size r. Each block gets XORed into the first part of the state while the remaining c bits stay untouched. A permutation function f transforms the entire state after every absorption step. In the squeezing phase, output blocks are read from the same subset of the state alternating with further applications of f. The capacity c determines the overall security level since it holds information hidden from direct observation. Maximum resistance against collisions or preimage attacks equals half the value of c. This design prevents length extension attacks that plague older Merkle-Damgård based systems like SHA-2 and MD5. The rate r defines how many bits can be processed per iteration without applying the expensive permutation function. Smaller values of r increase efficiency but reduce security margins proportionally.

• 3. NIST Standardization Process

  ›

  The journey toward official adoption began when NIST launched its hash function competition in 2006. Submissions were accepted until the end of 2008, yielding fifty-one candidates for review. Fourteen algorithms advanced to the second round by July 2009. Keccak progressed through subsequent rounds and reached the final stage in December 2010. Judges evaluated each entry against strict criteria including performance across platforms and resistance to known cryptographic attacks. On the 2nd of October 2012, NIST announced Keccak as the winner of the competition. Draft standards appeared in 2014 under document number FIPS 202 titled SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions. Final approval came on the 5th of August 2015, making SHA-3 an official federal standard. Unlike previous iterations such as SHA-1 or SHA-2, this new algorithm uses a completely different internal structure based on permutations rather than iterative compression functions. NIST explicitly stated that SHA-2 would remain active alongside SHA-3 without withdrawal plans. The goal was to provide organizations with an alternative option should future vulnerabilities emerge in existing systems. This dual-standard approach strengthened the overall robustness of government cryptographic toolkits.

• 4. Security Controversies And Adjustments

  ›

  In early 2013, NIST announced changes to the capacity parameter c compared to the original Keccak submission. These modifications sparked significant debate among cryptographers regarding long-term security implications. The competition required hash functions offering at least d/2-bit resistance for collision attacks and d-bit resistance for preimage attacks. Original Keccak proposals included varying levels of capacity depending on desired output lengths. Daniel J. Bernstein raised concerns on the NIST hash-forum mailing list about reduced security margins. He advocated retaining the larger 576-bit capacity originally proposed by the designers. Bruce Schneier initially criticized the decision but later retracted his comments after further discussion. Paul Crowley supported the final choice arguing that tunability allowed flexibility across use cases. In November 2013, John Kelsey from NIST proposed reverting back to the original capacity proposal for all drop-in replacement instances. Subsequent drafts confirmed this reversal before the final release. The controversy centered around balancing speed against quantum computing threats which could halve effective security levels again. Authors argued claiming strengths above 256 bits offered no practical benefit given current hardware capabilities. Despite initial confusion over internal changes, the team clarified that NIST's version remained a subset of their broader family.

• 5. Performance Benchmarks And Hardware

  ›

  Software implementations of SHA-3 vary significantly depending on processor architecture and instruction set availability. On IA-32 systems using Pentium 3 processors, benchmarks showed speeds ranging from 41 cycles per byte with MMX extensions down to 57.4 cpb without optimizations. Modern x86-64 machines achieve approximately 12.6 cycles per byte while specialized SIMD instructions push performance closer to six or seven cycles. ARMv8 architectures introduced dedicated instructions enabling faster execution through hardware acceleration features like EOR3 and RAX operations. Apple A13 chips support these extensions starting with ARMv8.2-SHA crypto sets. IBM z/Architecture added full SHA-3 support in 2017 via Message-Security-Assist Extension 6. Hardware accelerators implement complete algorithms directly within CPU cores rather than relying solely on software loops. Parallel variants such as ParallelHash128 exploit multi-core environments more effectively than traditional sequential hashing methods. Some older CPUs struggle reaching twenty-five to forty cycles per byte due to lack of optimized code paths. OpenSSL provides multiple assembly-language versions tailored for specific platforms including AVX2 and AVX-512VL configurations. These optimizations yield fifty percent improvements over generic compiler outputs on Skylake-X processors.

• 6. Derived Functions And Extensions

  ›

  Beyond the core SHA-3 specification, researchers developed additional functions extending Keccak's capabilities. KangarooTwelve emerged in 2016 using reduced rounds from twelve to fourteen instead of the standard twenty-four used in official standards. This approach exploits parallel execution capabilities available on modern processors while maintaining claimed security levels around one hundred二十八 bits. MarsupilamiFourteen represents another variation offering two hundred fifty-six bit resistance though practical advantages remain limited compared to lower thresholds. Both algorithms utilize tree hashing techniques enabling faster processing for small messages compared to ParallelHash implementations. NIST published document SP.800-185 in December 2016 introducing derived functions like cSHAKE, KMAC, TupleHash, and ParallelHash. cSHAKE supports explicit domain separation through customization parameters allowing users to define unique variants via string S. KMAC adds keyed hashing functionality suitable for authentication scenarios without sacrificing regular hash properties. TupleHash handles sequences where order matters ensuring different permutations produce distinct outputs. ParallelHash accelerates computation by dividing workloads across multiple threads or cores simultaneously. These extensions demonstrate how the original Keccak design continues evolving beyond initial FIPS requirements into specialized applications requiring higher throughput or enhanced flexibility.