Struct winter_crypto::hashers::Rp62_248

pub struct Rp62_248();

Implementation of Hasher trait for Rescue Prime hash function with 248-bit output.

The hash function is implemented according to the Rescue Prime specifications with the following exception:

• We set the number of rounds to 7, which implies a 40% security margin instead of the 50% margin used in the specifications (a 50% margin rounds up to 8 rounds). The primary motivation for this is that having the number of rounds be one less than a power of two simplifies AIR design for computations involving the hash function.
• When hashing a sequence of elements, we do not append Fp(1) followed by Fp(0) elements to the end of the sequence as padding. Instead, we initialize one of the capacity elements to the number of elements to be hashed, and pad the sequence with Fp(0) elements only. This ensures consistency of hash outputs between different hashing methods (see section below). However, it also means that our instantiation of Rescue Prime cannot be used in a stream mode as the number of elements to be hashed must be known upfront.

The parameters used to instantiate the function are:

• Field: 62-bit prime field with modulus 2^62 - 111 * 2^39 + 1.
• State width: 12 field elements.
• Capacity size: 4 field elements.
• Number of founds: 7.
• S-Box degree: 3.

The above parameters target 124-bit security level. The digest consists of four field elements and it can be serialized into 31 bytes (248 bits).

Hash output consistency

Functions hash_elements(), merge(), and merge_with_int() are internally consistent. That is, computing a hash for the same set of elements using these functions will always produce the same result. For example, merging two digests using merge() will produce the same result as hashing 8 elements which make up these digests using hash_elements() function.

However, hash() function is not consistent with functions mentioned above. For example, if we take two field elements, serialize them to bytes and hash them using hash(), the result will differ from the result obtained by hashing these elements directly using hash_elements() function. The reason for this difference is that hash() function needs to be able to handle arbitrary binary strings, which may or may not encode valid field elements - and thus, deserialization procedure used by this function is different from the procedure used to deserialize valid field elements.

Thus, if the underlying data consists of valid field elements, it might make more sense to deserialize them into field elements and then hash them using hash_elements() function rather then hashing the serialized bytes using hash() function.

Trait Implementations

impl ElementHasher for Rp62_248

type BaseField = BaseElement

Specifies a base field for elements which can be hashed with this hasher.

fn hash_elements<E: FieldElement<BaseField = Self::BaseField>>( elements: &[E] ) -> Self::Digest

Returns a hash of the provided field elements.

impl Hasher for Rp62_248

type Digest = ElementDigest

Specifies a digest type returned by this hasher.

const COLLISION_RESISTANCE: u32 = 124u32

Collision resistance of the hash function measured in bits.

fn hash(bytes: &[u8]) -> Self::Digest

Returns a hash of the provided sequence of bytes.

fn merge(values: &[Self::Digest; 2]) -> Self::Digest

Returns a hash of two digests. This method is intended for use in construction of Merkle trees.

fn merge_with_int(seed: Self::Digest, value: u64) -> Self::Digest

Returns hash(seed || value). This method is intended for use in PRNG and PoW contexts.