SequenceHash: multihashing for the rest of us

SequenceHash and SequenceMAC are introduced as a set of hash constructions designed to provide secure multihashing capabilities independent of a single underlying hash function, addressing common stumbling points in cryptographic usage. They offer features like unambiguous input encoding, length-extension prevention via double-hashing, built-in customization strings, and a keyed variant, SequenceMAC, structurally similar to HMAC. The system is hash-agnostic, supporting various functions like SHA256, BLAKE, and RIPEMD, and is implemented in Rust, Go, and Python with associated test vectors.
The core innovation addresses the security risks associated with concatenating inputs for hashing, which can lead to ambiguous encodings and length-extension vulnerabilities, particularly relevant in contexts like zero-knowledge proofs. SequenceHash achieves semantic distinctness between hashed values and prevents length extension attacks through a double-hash mechanism. SequenceMAC extends these features to keyed operations, incorporating key metadata to mitigate HMAC-related pseudocollision issues.
The system utilizes a simplified length-suffix encoding based on a 128-bit integer for inputs, which offers streaming API potential, and allows customization strings to be integrated into the outer hash layer for domain separation. While SequenceHash is powerful, it relies on the security of the underlying hash function, and practitioners must remain mindful of input consistency and the semantic implications of key lengths in SequenceMAC.

* SequenceHash and SequenceMAC are introduced by Trail of Bits to provide secure multihashing using hash functions other than Keccak.
* The constructions are hash-agnostic, working with various functions including SHA256/384/512, BLAKE, and RIPEMD.
* SequenceHash guarantees unambiguous input encoding, ensuring hashed values are semantically distinct.
* SequenceHash prevents length extension attacks using a double-hash construction.
* SequenceHash includes built-in customization strings to bind hashes to protocol steps or instances.
* SequenceMAC is the keyed mode of SequenceHash and is structurally similar to HMAC, supporting keys up to $2^{128}-1$ bytes.
* SequenceHash uses a length-suffix encoding based on a 128-bit integer for input lengths.
* SequenceMAC key size has a minimum of 32 bytes (256 bits).
* The API ensures atomic updates, where each write results in an independent, length-encoded object being added to the hash.
* The system provides implementations in Rust, Go, and Python along with test vectors.

The narrative positions SequenceHash as a standardized solution for multihashing problems that currently lack consistent, secure, and practical solutions across the ecosystem. The underlying pattern is one of developer frustration stemming from ambiguity, implementation complexity, and fragmentation when applying hashing concepts outside of the standard (like TupleHash). This sets up a claim that by providing an open, hash-agnostic specification, a deficiency in cryptographic tooling can be remedied through engineering rigor.
The tension lies between the promise of generalized utility—working across multiple hash functions without reimplementing complex logic—and the necessary caveats regarding underlying security assumptions and potential pitfalls, such as key pseudocollisions and subtleties in length encoding implementation. The inclusion of concepts like Fiat-Shamir transforms frames the discussion around high-stakes applications (zero-knowledge proofs), implicitly raising the standard for what constitutes an acceptable cryptographic solution.
The implicit implication is that the current state of multihashing tools forces developers into insecure or overly complex ad-hoc solutions, creating a vulnerability space where subtle errors can lead to significant security failures. The framework attempts to mitigate this by focusing on semantic guarantees (input encoding) and structural security (length extension resistance), suggesting that clarity in formal specification is a necessary prerequisite for robust cryptographic advancement rather than just an academic pursuit.
What assumptions drive the need for hash-agnosticism? Does the standardization effort risk creating new, subtle forms of vendor lock-in if adherence to the SequenceHash model becomes the de facto standard against established standards like TupleHash or SHA3? How does the emphasis on key length vs. actual security capacity influence the adoption trajectory for protocols heavily reliant on fixed-output hash functions versus those that might benefit from more flexible constructions?