SHA-3

• 1. Introduction

  ›

  SHA-3 sits at the heart of nearly every secure digital transaction on the internet, yet most people have never heard its name. It is the latest member of the Secure Hash Algorithm family, and the National Institute of Standards and Technology released it as an official standard on the 5th of August, 2015. But the story of how it got there stretches back years further, through a public competition, a controversy that drew in some of the world's most respected cryptographers, and a mathematical structure so different from everything before it that its creators had to invent new vocabulary just to describe how it works. What exactly is a sponge? Why did experts publicly argue about whether NIST was weakening its own standard? And what does any of this have to do with a marsupial?

• 2. The Sponge Beneath

  ›

  At SHA-3's core is something its designers call a sponge construction. The name is literal in spirit: the algorithm absorbs input data of any length, just as a sponge soaks up water, and then squeezes out a fixed or variable-length result. Earlier hash algorithms like SHA-1 and SHA-2 used a structure closely related to MD5, a design that dates back decades. SHA-3 breaks with that lineage entirely. Its foundation is a permutation function called Keccak-f, and the main version used in SHA-3 operates on a state of 1,600 bits, arranged as a five-by-five array of 64-bit words. The absorbing phase works by taking chunks of the input message, applying an XOR operation against part of that 1,600-bit state, and then running the entire state through a permutation. The squeezing phase then reads output from the same portion of the state. The part of the state that the input and output actually touch is called the rate; the part that stays hidden is the capacity. The capacity determines the security level, with the maximum achievable security being half the capacity. This hidden buffer is precisely what prevents a class of vulnerability, known as length extension attacks, that affects SHA-2, SHA-1, and MD5.

• 3. From PANAMA to Keccak

  ›

  Keccak did not arrive fully formed. It descended from a line of earlier hash function experiments, beginning with PANAMA, a design created by Joan Daemen and Craig Clapp in 1998. Daemen is the same cryptographer who co-designed the Rijndael cipher alongside Vincent Rijmen; Rijndael later became the basis for the Advanced Encryption Standard. RadioGatun followed PANAMA as its successor, developed by Daemen alongside Michaël Peeters and Gilles Van Assche, and it was presented at a NIST Hash Workshop in 2006. Keccak itself was built by the same four-person team: Daemen, Peeters, Van Assche, and Guido Bertoni. When NIST launched its public hash function competition in 2006 to find a new standard, Keccak was one of 51 candidate algorithms accepted for consideration. By July 2009, the field had narrowed to 14 algorithms in the second round. Keccak reached the final round in December 2010, and on the 2nd of October, 2012, it was named the competition's winner. The reference implementation was released to the public domain from the start.

• 4. The Capacity Controversy

  ›

  Winning the competition did not end the debate. In early 2013, NIST announced it intended to adjust Keccak's capacity parameter for the final standard, effectively trading some security for speed. The original competition rules required hash functions to offer preimage resistance matching their SHA-2 counterparts, meaning a 256-bit hash should resist preimage attacks at the full 256-bit level. The proposed change would have cut preimage resistance in half for some variants, creating a vulnerability that quantum computing could exploit further. In September 2013, Daniel J. Bernstein raised the issue on the NIST hash-forum mailing list, arguing for restoring the 576-bit capacity originally proposed as Keccak's default. The Keccak team responded in late September, acknowledging the proposal and offering to raise the capacity to provide up to 256-bit security across all instances. They also stated directly that claiming or relying on security strength levels above 256 bits is meaningless. In early October 2013, Bruce Schneier publicly criticized the direction, warning that NIST risked publishing an algorithm no one would trust and no one except those forced would use. He later walked that back, clarifying that NIST had not altered the Keccak permutation itself but had proposed reducing the hash function's capacity in the name of performance. Paul Crowley, a cryptographer and senior developer at an independent software development company, took a different view, arguing that Keccak is tunable by design and there is no reason for uniform security levels within one primitive. In November 2013, John Kelsey of NIST proposed reverting to the original capacity for all SHA-2 drop-in replacement instances, and that reversion held through the final release.

• 5. Speed and Hardware Tradeoffs

  ›

  SHA-3 carries a well-documented reputation for being slower than SHA-2 on general-purpose processors. On an Intel Skylake processor clocked at 3.2 GHz, SHA2-512 runs more than twice as fast as SHA3-512, and SHA-1 runs more than three times as fast. The authors have suggested that SHAKE128 and SHAKE256, the extendable-output variants, can match SHA2-256 and SHA2-512 in performance at the cost of cutting preimage resistance in half. Hardware tells a different story. In hardware implementations, SHA-3 is notably faster than all other finalists from the competition, and faster than SHA-2 and SHA-1 as well. As of 2018, ARM's ARMv8 architecture added special instructions to accelerate Keccak, and IBM's z/Architecture included a complete SHA-3 and SHAKE implementation in a single instruction. The Apple A13 SoC's ARMv8 cores support SHA-3 acceleration through four specialized instructions: EOR3, RAX, XAR, and BCAX. On ARMv4 and above, handwritten scalar code delivers double to triple the performance of compiler output. The IBM z/Architecture has supported SHA-3 since 2017 through Message-Security-Assist Extension 6, running the full algorithm via KIMD and KLMD instructions through a hardware assist engine built into each processor core.

• 6. Beyond the Standard

  ›

  The Keccak team did not stop at SHA-3. In 2016, they introduced two faster reduced-round alternatives: KangarooTwelve and MarsupilamiFourteen. Both exploit parallel execution using tree hashing. KangarooTwelve cuts the number of permutation rounds from 24 down to 12 and claims 128-bit security, with performance reaching 0.55 cycles per byte on a Skylake CPU. It is now specified in IETF RFC 9861. MarsupilamiFourteen uses 14 rounds and claims 256-bit security, though the authors note that 256-bit security offers no practical advantage over 128 bits against current hardware. Neither algorithm is FIPS-compliant since they postdate the SHA-3 standard, but because they use the same Keccak permutation, they carry its security for as long as no practical attack exists on 12-round Keccak. Also in 2016, the team released the Farfalle construction and Kravatte, an instance using the Keccak-p permutation, along with two authenticated encryption algorithms, Kravatte-SANE and Kravatte-SANSE. In December 2016, NIST published SP 800-185, adding derived functions including KMAC, a keyed hash function based on Keccak, and TupleHash, designed specifically for hashing sequences of strings where both the content and the order of inputs matter. Ethereum uses the Keccak-256 hash function, drawn from version 3 of the original competition submission, which differs from the finalized SHA-3 specification.