SequenceHash: multihashing for the rest of us

What it is

SequenceHash/SequenceMAC, hash-agnostic multihashing from Trail of Bits. The summary already covers the mechanism's goals and language support; what it omits is the construction's technical internals and concrete sizing rules an implementer would need.

How it works

SequenceHash uses length-suffix encoding (not length-prefix like TupleHash): each input is followed by its byte count encoded as a fixed-length 128-bit integer, rather than a variable-length bit count. This suffix placement, unlike TupleHash's prefix approach, lets implementers build streaming APIs for inputs whose length isn't known in advance. Length-extension resistance and the MAC mode both come from a double-hash (HMAC-style) construction. Customization strings are mixed in only at the outer hash layer, so the inner hash of the same data can be reused across multiple customization-string variants without recomputing it — useful if you need several domain-separated hashes of the same payload.

SequenceMAC closes HMAC's key-pseudocollision gap by folding key length into a header block that's part of the hash itself, so a raw key and its hashed-down "equivalent" (for long keys) no longer collide, and trailing zero-padding on a key is treated as semantically significant (unlike HMAC, where a key and its zero-extended version are equivalent).

Preconditions / Affected

• SequenceMAC enforces a hard minimum key size of 32 bytes (256 bits); there's no analogous HMAC-style short-key fallback.
• Security level is capped by the underlying hash's output size: ~128-bit forgery resistance with a 256-bit hash, but only ~112 bits with SHA224 and ~80 bits with RIPEMD160 — the spec permits these smaller-output hashes but "strongly discourages" them.
• Using keys longer than the hash's output length provides no extra security.
• No SequenceXOF variant exists yet; XOF support is unspecified/under consideration.

What to do

Reference implementations (Rust, Go, Python) and the spec with test vectors (including intermediate values for debugging) are available via the C2SP project page. The API contract to design against: all writes to a SequenceHash/SequenceMAC object are atomic and independently length-encoded — writing two values sequentially is deliberately not equivalent to writing their concatenation, unlike Go's io.Writer or Python's PEP 247 update() semantics that the APIs otherwise resemble.

Caveats

The page stresses this only prevents input-mixing/length-extension/replay — it doesn't guarantee two systems encode the same logical value identically (e.g., JSON/XML field-ordering mismatches, ASCII-vs-other string encoding). For Fiat-Shamir use, the author still requires manually including all protocol-relevant values (group descriptor, generator element) and choosing hash output size large enough to avoid modulo bias.