|
digestpp 1.0
C++11 header-only message digest library
|
Experimental C++11 header-only message digest library.
Derived from cppcrypto, this library aims to provide a more modern, flexible, and versatile C++ API for cryptographic hash functions.
Tested with g++ 6.4.0, clang 4.0.1 and Visual C++ 2017.
Just copy the digestpp folder to your project or include path and #include <digestpp/digestpp.hpp>.
Calculate SHA-256 digest of a string literal:
For algorithms supporting variable output lengths (like BLAKE2, SHA512, SHA-3, etc.), the size can be set either at runtime (constructor argument) or at compile-time (template parameter).
Runtime size (more flexible, allows values determined at runtime):
Compile-time size (static checking):
The .absorb() method accepts both string literals and std::string objects. Method chaining is supported:
Absorb data from standard containers (like std::vector) or raw C-arrays:
Read and hash a file directly using std::ifstream:
Retrieve the result as a hex string, raw bytes, or write directly to a stream.
Use squeeze() to generate outputs of arbitrary length.
Hasher is the main class template implementing the public API for hashing.
It has two template parameters:
Individual hash algorithms are defined by typedefs, e.g.
| Dynamic Size Variant | Static Size Variant | Description | Security | Supported output sizes | Optional parameters |
|---|---|---|---|---|---|
| N/A | digestpp::ascon_hash | Ascon (NIST SP 800-232) | ✅Secure | 256 | - |
| digestpp::blake | digestpp::static_size::blake | Original BLAKE algorithm | ✅Secure | 224, 256, 384, 512 | salt |
| digestpp::blake2b | digestpp::static_size::blake2b | BLAKE2b | ✅Secure | 8-512 | salt, personalization, key |
| digestpp::blake2s | digestpp::static_size::blake2s | BLAKE2s | ✅Secure | 8-256 | salt, personalization, key |
| digestpp::blake2bp | digestpp::static_size::blake2bp | BLAKE2bp | ✅Secure | 8-512 | salt, personalization, key |
| digestpp::blake2sp | digestpp::static_size::blake2sp | BLAKE2sp | ✅Secure | 8-256 | salt, personalization, key |
| digestpp::blake2xb | digestpp::static_size::blake2xb | BLAKE2xb | ✅Secure | arbitrary | salt, personalization, key |
| digestpp::blake2xs | digestpp::static_size::blake2xs | BLAKE2xs | ✅Secure | arbitrary | salt, personalization, key |
| digestpp::echo | digestpp::static_size::echo | Echo | ✅Secure | 8-512 | salt |
| digestpp::esch | digestpp::static_size::esch | Esch | ✅Secure | 256, 384 | - |
| digestpp::groestl | digestpp::static_size::groestl | Grøstl | ✅Secure | 8-512 | - |
| digestpp::jh | digestpp::static_size::jh | JH | ✅Secure | 8-512 | - |
| digestpp::kmac128 | digestpp::static_size::kmac128 | KMAC128 | ✅Secure | arbitrary | key, customization |
| digestpp::kmac256 | digestpp::static_size::kmac256 | KMAC256 | ✅Secure | arbitrary | key, customization |
| digestpp::kupyna | digestpp::static_size::kupyna | Kupyna | ✅Secure | 256, 512 | - |
| digestpp::lsh256 | digestpp::static_size::lsh256 | LSH-256 | ✅Secure | 8-256 | - |
| digestpp::lsh512 | digestpp::static_size::lsh512 | LSH-512 | ✅Secure | 8-512 | - |
| N/A | digestpp::md5 | MD5 | ❌Broken | 128 | - |
| N/A | digestpp::sha1 | SHA-1 | ❌Broken | 160 | - |
| N/A | digestpp::sha224 | SHA-224 | ✅Secure | 224 | - |
| N/A | digestpp::sha256 | SHA-256 | ✅Secure | 256 | - |
| N/A | digestpp::sha384 | SHA-384 | ✅Secure | 384 | - |
| digestpp::sha512 | digestpp::static_size::sha512 | SHA-512 | ✅Secure | 8-512 | - |
| digestpp::sha3 | digestpp::static_size::sha3 | SHA-3 | ✅Secure | 224, 256, 384, 512 | - |
| digestpp::skein256 | digestpp::static_size::skein256 | Skein256 | ✅Secure | arbitrary | personalization, key, nonce |
| digestpp::skein512 | digestpp::static_size::skein512 | Skein512 | ✅Secure | arbitrary | personalization, key, nonce |
| digestpp::skein1024 | digestpp::static_size::skein1024 | Skein1024 | ✅Secure | arbitrary | personalization, key, nonce |
| N/A | digestpp::sm3 | SM3 | ✅Secure | 256 | - |
| digestpp::streebog | digestpp::static_size::streebog | Streebog | ⚠️Backdoored | 256, 512 | - |
| N/A | digestpp::whirlpool | Whirlpool | ✅Secure | 512 | - |
| Typedef | Description | Security | Optional parameters |
|---|---|---|---|
| digestpp::ascon_xof | Ascon-XOF128 | ✅Secure | - |
| digestpp::ascon_cxof | Ascon-CXOF128 | ✅Secure | customization |
| digestpp::blake2xb_xof | BLAKE2xb in XOF mode | ✅Secure | salt, personalization, key |
| digestpp::blake2xs_xof | BLAKE2xs in XOF mode | ✅Secure | salt, personalization, key |
| digestpp::esch256_xof | XOEsch256 | ✅Secure | - |
| digestpp::esch384_xof | XOEsch384 | ✅Secure | - |
| digestpp::k12 | KangarooTwelve | ✅Secure | customization |
| digestpp::kt128 | KangarooTwelve (alias for k12) | ✅Secure | customization |
| digestpp::kt256 | 256bit KangarooTwelve | ✅Secure | customization |
| digestpp::m14 | MarsupilamiFourteen | ✅Secure | customization |
| digestpp::shake128 | SHAKE-128 | ✅Secure | - |
| digestpp::shake256 | SHAKE-256 | ✅Secure | - |
| digestpp::cshake128 | cSHAKE-128 | ✅Secure | function name, customization |
| digestpp::cshake256 | cSHAKE-256 | ✅Secure | function name, customization |
| digestpp::kmac128_xof | KMAC128 in XOF mode | ✅Secure | key, customization |
| digestpp::kmac256_xof | KMAC256 in XOF mode | ✅Secure | key, customization |
| digestpp::skein256_xof | Skein256 in XOF mode | ✅Secure | personalization, key, nonce |
| digestpp::skein512_xof | Skein512 in XOF mode | ✅Secure | personalization, key, nonce |
| digestpp::skein1024_xof | Skein1024 in XOF mode | ✅Secure | personalization, key, nonce |
Q: What is the difference between a hash function with variable output size and an extendable output function (XOF)?
A: Hash functions require the digest size to be known at the moment of initialization and normally produce unrelated outputs for different digest sizes. For example, blake2b(256) and blake2b(512) produce completely different digests. XOFs are functions that do not need to know the output size in advance and can produce outputs of arbitrary length. Bytes generated by XOFs depend only on the input data, not on the digest size. It is generally recommended to use hash functions instead of XOFs when the output size is known in advance.
Q: What is the difference between digest() and squeeze()?
A. digest() is used with hash functions; it retrieves a digest of a certain length (defined by the algorithm or specified in the constructor). Calling digest() or hexdigest() does not change the internal state, so these functions can be called more than once and will produce the same output. squeeze() is used with XOF functions; it can be called multiple times to squeeze an arbitrary number of output bytes. After each invocation of squeeze(), the internal state changes so that the next call to squeeze() will generate different (additional) output bytes.
Q: For hash functions with variable output size, why do you provide two options: with output size as a template parameter, e.g. digestpp::static_size::sha3<256>(), and with output size specified at runtime, e.g. digestpp::sha3(256)?
A: In some usage scenarios, the required digest size is not known at compile time. One simple example is the Argon2 password hashing algorithm, which requires us to hash its state using BLAKE2b with a dynamically calculated digest size. We can't just use the largest digest size and truncate the result because most hash functions (unlike XOFs) produce completely different digests depending on the requested output size.
Q: Why does hasher not support hashing non-byte types?
A: Cryptographic hash functions are always defined for a sequence of bytes. We support only those data types that can be unambiguously converted to bytes (sequences of char, signed char, or unsigned char). Other data types should be converted to a sequence of bytes in a non-ambiguous way before they can be hashed (e.g., wide strings could be encoded using UTF-8 or another encoding), which is beyond the scope of the library.
Q: Since the output size has to be provided to the constructor, why are there separate typedefs for sha256 and sha512 instead of one hasher with an output size parameter: sha2(256) / sha2(512)?
A: The SHA-2 family of hash functions is special because SHA-512 can produce an output of any size up to 512 bits (SHA-512/t); e.g., sha512(256) will calculate SHA-512/256. The resulting hash is different from SHA-256 but has the same length. Thus SHA-512 is an independent hash function supporting variable output sizes. On the other hand, the 32-bit version of SHA-2 is only defined for 224-bit and 256-bit outputs, and they are widely known as SHA-224 and SHA-256. We decided to use different typedefs for SHA-224 and SHA-256 because requiring users to use sha256(224) for getting SHA-224 digests would be confusing. Internally all SHA-2 functions are implemented using one template class.
Q: Why are there separate typedefs for skein256, skein512 and skein1024 instead of one hasher with an output size parameter: skein(256) / skein(512) / skein(1024)?
A: Skein256, Skein512, and Skein1024 are different algorithms. Each of them can produce digests of any size. The outputs are unrelated, e.g., skein256(256) != skein512(256) != skein1024(256). Internally all Skein variants are implemented using one template class.
Q: Why are there so many typedefs for the BLAKE2 hash function?
A: BLAKE2 has many variants that produce incompatible digests for the same output sizes. We support different variants via different typedefs. For the 512-bit version, blake2b is the oldest algorithm, which can produce digests of any size up to 512 bits. blake2xb can be used to produce larger digests but requires the output size to be known in advance; it can't be merged with blake2b because their outputs are different for the same digest sizes. blake2xb_xof can be used in XOF mode when the output size is not known in advance. Then there is a 256-bit version blake2s which supports all these variants as well. Internally all BLAKE2 variants are implemented using one template class.
The library follows standard C++ thread safety guarantees:
hasher instances from multiple threads simultaneously. No global mutable state is shared between instances.hasher instance from multiple threads concurrently. Methods that modify the internal state (such as absorb, squeeze, reset) require external synchronization (e.g., using std::mutex) if called from different threads on the same object.const methods (such as digest, hexdigest) from multiple threads, provided the object is not being modified by another thread at the same time.Reference documentation is here: https://kerukuro.github.io/digestpp/