A custom weaker variant of SipHash-1-3 without padding, and supporting "jumbo" inputs.
More...
|
| | SipHasher13UJ (uint64_t k0, uint64_t k1) noexcept |
| | Construct a SipHash-1-3-UJ calculator initialized with 128-bit key (k0, k1). More...
|
| |
| SipHasher13UJ & | Write (uint64_t data) noexcept |
| | Hash a normal 64-bit value. More...
|
| |
| SipHasher13UJ & | WriteJumbo (const uint256 &hash) noexcept |
| | Hash a 256-bit value as a jumbo block. More...
|
| |
| uint64_t | Finalize () const noexcept |
| | Compute the 64-bit SipHash-1-3-UJ of the data written so far. More...
|
| |
| ALWAYS_INLINE uint64_t | Hash (const uint256 &hash) const noexcept |
| | Hash a jumbo block after the data written so far and finalize without modifying the object. More...
|
| |
| ALWAYS_INLINE uint64_t | Hash (const uint256 &hash, uint64_t extra) const noexcept |
| | Hash a jumbo block followed by a normal block after the data written so far, and finalize without modifying the object. More...
|
| |
A custom weaker variant of SipHash-1-3 without padding, and supporting "jumbo" inputs.
Compared to the traditional SipHash-2-4, this incorporates 3 changes:
- Use SipHash-1-3: This common variant reduces the number of rounds between input blocks from 2 to 1, and the number of finalization rounds at the end from 4 to 3. It is a standard faster choice with weaker security guarantees. It is considered strong enough for use in hash tables and other applications with only weak security requirements, in particular when attackers cannot directly observe the hash function output, and cannot control k0 and k1.
- Remove padding: Standard SipHash operates on byte-oriented inputs, which are converted into 8-byte blocks internally by adding a padding of 1-8 bytes to obtain a multiple of 8 bytes. In this variant, the input is a sequence of blocks instead, which are used without padding. This saves 1 round for inputs that are a multiple of 8 bytes already. The padding normally adds a commitment to the input's byte length, but since our input is block oriented, and there is one round per input, the function of that commitment is directly fulfilled by the number of rounds. The empty input is permitted; it yields the result of finalizing the initialization directly. Out of an abundance of caution the finalizing v2 ^= 0xff is changed to v2 ^= 0x6465646461706e75 ("unpadded" in LE64), to avoid collisions between standard SipHash-1-3 and this variant.
- Jumbo blocks: We generalize the input to consist of a sequence of blocks which are each either exactly 8 bytes (normal blocks) or 32 bytes (jumbo blocks), and may be arbitrarily mixed. For hash-table use, cryptographic hash outputs must make up all but a small bounded number of retained jumbo blocks. Note that the block structure matters: hashing one jumbo block is not the same as hashing the same data split up into four normal blocks. Jumbo blocks are interpreted as 4 LE64 integers (d0,d1,d2,d3), and XOR'ed into the state before a round as (v0,v1,v2,v3) ^= (d1,d2,d3,d0), and XOR'ed into the state after a round as (v0,v1,v2,v3) ^= (d0,d1,d2,d3). This is a strict generalization of normal block processing, in the sense that if d1..d3=0, it is identical to processing a normal block d0 (a single LE64 integer). Of course, making d1..d3=0 should be impossible in the output of a cryptographic hash function. These jumbo blocks are acceptable because even though they may give the attacker more control within a single round, that control is limited by the cryptographic hash in between.
Other components are unchanged: initialization constants, SipRound, and 64-bit output. This interface serves as an executable specification for fixed-width implementations. The Hash overloads optimize fixed-width inputs without modifying the accumulated state.
Definition at line 160 of file siphash.h.
1.9.4