The Skein Hash Function Family
By Niels Ferguson - Stefan Lucks - Bruce Schneier - Doug Whiting - Mihir Bellare - Tadayoshi Kohno - Jon Callas - Jesse Walker
Submitted to NIST for their cryptographic hash algorithm competition.
The Skein team (l to r): Mihir, Jesse, Jon, Doug, Stefan, Niels, Bruce, Yoshi.
Skein is a new family of cryptographic hash functions. Its design combines speed, security, simplicity, and a great deal of flexibility in a modular package that is easy to analyze.
Skein is fast. Skein-512—our primary proposal—hashes data at 6.1 clock cycles per byte on a 64-bit CPU. This means that on a 3.1 GHz x64 Core 2 Duo CPU, Skein hashes data at 500 MBytes/second per core—almost twice as fast as SHA-512 and three times faster than SHA-256. An optional hash-tree mode speeds up parallelizable implementations even more. Skein is fast for short messages, too; Skein-512 hashes short messages in about 1000 clock cycles.
Skein is secure. Its conservative design is based on the Threefish block cipher. Our current best attack on Threefish-512 is on 25 of 72 rounds, for a safety factor of 2.9. For comparison, at a similar stage in the standardization process, the AES encryption algorithm had an attack on 6 of 10 rounds, for a safety factor of only 1.7. Additionally, Skein has a number of provably secure properties, greatly increasing confidence in the algorithm.
Skein is simple. Using only three primitive operations, the Skein compression function can be easily understood and remembered. The rest of the algorithm is a straightforward iteration of this function.
Skein is flexible. Skein is defined for three different internal state sizes—256 bits, 512 bits, and 1024 bits—and any output size. This allows Skein to be a drop-in replacement for the entire SHA family of hash functions. A completely optional and extendable argument system makes Skein an efficient tool to use for a very large number of functions: a PRNG, a stream cipher, a key derivation function, authentication without the overhead of HMAC, and a personalization capability. All these features can be implemented with very low overhead. Together with the Threefish large-block cipher at Skein's core, this design provides a full set of symmetric cryptographic primitives suitable for most modern applications.
Skein is efficient on a variety of platforms, both hardware and software. Skein-512 can be implemented in about 200 bytes of state. Small devices, such as 8-bit smart cards, can implement Skein-256 using about 100 bytes of memory. Larger devices can implement the larger versions of Skein to achieve faster speeds.
Skein was designed by a team of highly experienced cryptographic experts from academia and industry, with expertise in cryptography, security analysis, software, chip design, and implementation of real-world cryptographic systems. This breadth of knowledge allowed them to create a balanced design that works well in all environments.
Skein Paper, Version 1.3, 1 Oct 2010 (includes description of Threefish)
NIST Round 3 Tweak Description, 25 Oct 2010
Skein Proofs of Security, Version 1.0, 29 Apr 2009
Source code and test vectors for Skein and Threefish (12 MB)
Version 1.1 of the paper, reference, and optimized code corrects an error in which the length of the configuration string was passed in as the size of the internal block (256 bits for Skein-256, 512 for Skein-512, and 1024 for Skein-1024), instead of a constant 256 bits for all three sizes. This error has no cryptographic significance, but affected the test vectors and the initialization values. Version 1.1 of the code also fixes a bug in the MAC mode key processing. This bug does not affect the NIST submission in any way.
Version 1.2 of the paper, reference, and optimized code include a "tweak" as permitted by NIST; we revised the rotation constants. This change does not affect Skein's performance in any way. All existing and future implementations of Skein must now use these new rotation constants to be compliant. The revised paper explains why we updated the rotation constants (Appendix D), how the new rotation constants were derived (Section 8.3), and new cryptanalysis (Sections 9.3.1, 9.3.2, 9.5, 9.6, and 9.7).
Version 1.3 of the paper, reference, and optimized code include a "tweak" as permitted by NIST: the key schedule constant in Threefish. This change does not affect Skein's performance in any measurable way, but it does dramatically decrease the efficiency of the rotational distinguisher "attacks." While we were not convinced that these distinguishers would have any real-world implications, it was so simple to address by just changing one constant that we felt it was a prudent step to take. The revised paper explains why we updated the key-schedule constant (Appendix E), and how the new constant was derived (Section 8.3).
Skein is optionally used for authentication tags in the ZRTP protocol.
Java implementation of Skein by Maarten Bodewes
Cryptol implementation of Skein
C# implementation of Skein and Threefish by Alberto Fajardo
.NET implementation of Skein by Sriram Krishnan
Threefish test vectors and Java implementation by Bartosz Malkowski
AVR 8-bit implementation of Threefish and Skein by Jörg Walter
Managed C# implementation of Skein and ThreeFish (SkeinLibManaged)
Skein and Threefish functions for Java, C, and Go (Skein3Fish)
Skein-Bash by Matt Tomasello
Perl implementation of Skein by Radoslaw Zielinski (Digest::Skein)
Ruby implementation of Skein by Markus Hahn
Photo of Bruce Schneier by Per Ervland.
Schneier on Security is a personal website. Opinions expressed are not necessarily those of Resilient Systems, Inc..