Security1 publisher2 min readPublished
Trail of Bits offers SHA-2 and BLAKE users a TupleHash-style fix for multi-input hashing
Trail of Bits has published SequenceHash and SequenceMAC, open C2SP specs for hashing several inputs together with SHA-2, BLAKE or RIPEMD. Protocols that hash concatenated inputs into commitments or proofs now have a written fix that does not require Keccak.
The Watch · Security desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- Hashing inputs through separate SHA256 update calls still concatenates them, so the function cannot see where one input ends and the next begins.
- The new constructions behave like NIST's TupleHash but are not tied to Keccak and avoid computations that are not byte-aligned.
- Initial implementations ship in Rust, Go and Python, with test vectors across several hash functions that include intermediate values.
Compiled by The WatchSomething wrong?How this is made
Why it matters
- exposure Any protocol that builds Fiat-Shamir challenges from concatenated inputs carries a forgery risk in its proofs, and in cryptocurrency Trail of Bits puts that error in the millions of dollars.
- decision Teams on SHA-2, BLAKE or RIPEMD no longer have to pick between moving to Keccak for TupleHash and designing their own boundary encoding.
- constraint The fix covers encoding ambiguity only, so a protocol still built on MD4, SHA0 or a checksum like CRC32 stays broken after adopting it.
- constraint Systems using MAC keys shorter than 32 bytes would have to move to longer keys before SequenceMAC could replace their current construction.
The flaw starts with a hash call that looks safe. Feed SHA256 three values through three separate calls and the function still sees one concatenated byte string, according to Trail of Bits [9]. The boundaries between the inputs are lost [9]. In a commitment scheme, one party hashes a secret value together with a random blinding value and broadcasts the digest [11]. When the boundary between the two is unclear, the firm wrote, the commitment "can sometimes be opened several different ways" [12]. The party that committed can then reveal whichever opening suits it [12].
Zero-knowledge proofs have the same exposure. Multihashing is a core step in the Fiat-Shamir transform, and getting it wrong introduces the risk of forged proofs [10]. Trail of Bits wrote that because such proofs now play a major role in cryptocurrency, the mistake is sometimes measured in millions of dollars [10]. The post does not name affected projects, cite a specific loss or report exploitation in the wild.
The fixes in circulation vary in quality [13]. Trail of Bits wrote that "nobody seems to have landed on a consistent, standard solution to this problem" [14]. In open-source code and its private audits, the firm finds separator characters that can also appear inside the inputs, which it calls insecure [13]. It also finds encodings that are unambiguous but complex enough to introduce subtle timing risks [13].
NIST's TupleHash already covers this for Keccak users [1][3]. SequenceHash behaves similarly, according to Trail of Bits, but is not tied to one hash function and avoids computations that are not byte-aligned [3]. It works with SHA256, SHA384, SHA512, BLAKE and RIPEMD, among others [4]. A team already on TupleHash gets no new protection from the release [3]. A team on SHA-2 with hand-rolled separators now has an open specification in C2SP to adopt [2]. It comes with reference code in Rust, Go and Python and test vectors that include intermediate values for debugging [8].
Security rests on the underlying hash [6]. "SequenceHash and SequenceMAC can't magically make MD4 or SHA0 secure again," Trail of Bits wrote [7]. SequenceMAC requires keys of at least 32 bytes, or 256 bits, and accepts keys up to 2^128-1 bytes [5][1].
What to watch
- Whether zero-knowledge proof libraries replace ad hoc concatenation in their Fiat-Shamir code with SequenceHash.
- Independent implementations beyond Trail of Bits' Rust, Go and Python code that verify against the published test vectors.
- Any move by NIST or another standards body to cover multihashing for non-Keccak hash functions.