Hash Functions & Checksums

Hash functions are one-way functions, which map data of arbitrary size to a fixed output length. Most of the hash functions in crypto3 are designed to be cryptographically secure, which means that it is computationally infeasible to create a collision (finding two inputs with the same hash) or preimages (given a hash output, generating an arbitrary input with the same hash). But note that not all such hash functions meet their goals, in particular MD4 and MD5 are trivially broken. However they are still included due to their wide adoption in various protocols. More...

Modules

 Algorithms
 Algorithms are meant to provide hashing interface similar to STL algorithms' one.
 

Classes

struct  nil::crypto3::hash::adler< Bits >
 Adler. Non-cryptographically secure checksum. Adler32 checksum is used in the zlib format. 32 bit output. More...
 
class  nil::crypto3::hash::blake2b< DigestBits >
 Blake2b. A recently designed hash function. Very fast on 64-bit processors. Can output a hash of any length between 1 and 64 bytes, this is specified by passing a value to the constructor with the desired length. More...
 
class  nil::crypto3::Comb4P
 Comb4P scheme. Combines two hash functions using a Feistel scheme. Described in "On the Security of Hash Function Combiners", Anja Lehmann. More...
 
class  nil::crypto3::hash::crc< Bits, TruncPoly, InitRem, FinalXor, ReflectIn, ReflectRem >
 CRC. Non-cryptographically secure checksum. More...
 
class  nil::crypto3::hash::cubehash< r, b, h >
 Cubehash. Cubehash 16/32 modification was a SHA-3 competitor submitted to NIST. More...
 
class  nil::crypto3::Keccak_1600
 Keccaak[1600]. SHA-3 competitor. More...
 
class  nil::crypto3::hash::md4
 MD4. Non-cryptographically secure checksum. More...
 
struct  nil::crypto3::hash::md5
 MD5. Non-cryptographically secure checksum. More...
 
class  nil::crypto3::hash::ripemd< DigestBits >
 Ripemd. Family of configurable hashes, developed as an open alternative to SHA. More...
 
class  nil::crypto3::hash::sha
 SHA. Initial SHA hash construction. Not considered to b a cryptographically secure primitive lately. More...
 
class  nil::crypto3::hash::sha1
 SHA1. Widely adopted NSA designed hash function. Starting to show significant signs of weakness, and collisions can now be generated. Avoid in new designs. More...
 
class  nil::crypto3::hash::sha2< Version >
 
class  nil::crypto3::SHA_3
 SHA3. The new NIST standard hash. Fairly slow. More...
 
class  nil::crypto3::SHAKE_128
 Shake. These are actually XOFs (extensible output functions) based on SHA-3, which can output a value of any length. More...
 
class  nil::crypto3::hash::skein< DigestBits >
 Skein. A contender for the NIST SHA-3 competition. Considered to be a cryptographically secure Merkle-Damg√•rd construction over threefish block cipher. Very fast on 64-bit systems. Can output a hash of any length between 1 and 64 bytes. It also accepts a "personalization string" which can create variants of the hash. This is useful for domain separation. More...
 
class  nil::crypto3::hash::streebog< DigestBits >
 Streebog (GOST R 34.11-2012). RFC 6986. Newly designed Russian national hash function. Due to use of input-dependent table lookups, it is vulnerable to side channels. There is no reason to use it unless compatibility is needed. More...
 
class  nil::crypto3::hash::tiger< DigestBits, Passes >
 Tiger. An older 192-bit hash function, optimized for 64-bit systems. Possibly vulnerable to side channels due to its use of table lookups. Prefer Skein-512 or BLAKE2b in new code. More...
 
class  nil::crypto3::hash::whirlpool
 Whirlpool. A 512-bit hash function standardized by ISO and NESSIE. Relatively slow, and due to the table based implementation it is (unlike almost all other hashes) potentially vulnerable to cache based side channels. Prefer Skein-512 or BLAKE2b in new code. More...
 

Detailed Description

Hash functions are one-way functions, which map data of arbitrary size to a fixed output length. Most of the hash functions in crypto3 are designed to be cryptographically secure, which means that it is computationally infeasible to create a collision (finding two inputs with the same hash) or preimages (given a hash output, generating an arbitrary input with the same hash). But note that not all such hash functions meet their goals, in particular MD4 and MD5 are trivially broken. However they are still included due to their wide adoption in various protocols.

Using a hash function is typically split into three stages: initialization, update, and finalization (often referred to as a IUF interface). The initialization stage is implicit: after creating a hash function object, it is ready to process data. Then update is called one or more times. Calling update several times is equivalent to calling it once with all of the arguments concatenated. After completing a hash computation (eg using final), the internal state is reset to begin hashing a new message.