- Trail of Bits published SequenceHash, an open specification for hashing several values together so their boundaries stay clear. It reports no independent review or adoption yet.
- Hash inputs that are simply joined can be read more than one way, which matters for proofs and commitments.
- Ask your team where multiple values are hashed together, and whether each input carries its own length.
When two different inputs look identical
Security depends on a simple promise: different data produces a different fingerprint. That promise can weaken when software fingerprints several values at once. Trail of Bits calls this task multihashing, meaning hashing a bunch of values together.
Here is the problem. A common shortcut is to join the values into one long string and hash the result. The hash function cannot see where one value ended and the next began. As an illustration, "12" followed by "3" and "1" followed by "23" become the same string. Trail of Bits warns that this shortcut can create security problems.
The lesson is that a hash proves what was fed in, not what was meant. If the boundaries between values are fuzzy, one fingerprint may fit more than one reading of the data.
What Trail of Bits released
On October 2, 2026, Trail of Bits introduced SequenceHash and a keyed sibling, SequenceMAC. A MAC is a fingerprint that also needs a secret key to produce. The design is public, and C2SP, the Community Cryptography Specification Project, now hosts the specification.
The firm also released three implementations, in Rust, Go and Python. A large body of test vectors spans several hash functions. They list the steps in between, so a developer writing a new version can see where their own diverges.
Why the problem persists
Trail of Bits says no single, agreed answer exists. Across the open-source ecosystem and in its private audits, its engineers see developers solving the problem "in wildly different ways."
Some use separator characters that can also appear inside the data. Others encode everything so the separators are clear, but the encoding is complex and can introduce subtle timing risks. Trail of Bits also reports cases where some inputs are length-encoded and others are not.
The stakes vary by use. In zero-knowledge proofs, the firm says a multihashing mistake can introduce a risk of forgeries. It adds that such errors are sometimes measured in millions of dollars in cryptocurrency.
Commitments are another case. A party hashes a secret together with a random "blinding" value and shares the result. When the line between the two is unclear, one commitment can sometimes be opened in more than one way.
How SequenceHash works
The core idea is to attach a length to every input. Each value is written with its size, so the boundary cannot be shifted. The specification states that no other sequence of inputs, of any length, produces the same input to the underlying hash.
TupleHash, defined by NIST, already does this with Keccak, the function behind SHA3. Trail of Bits calls TupleHash "great". Its limit is that it is defined only for Keccak. Swap in another hash and protections such as resistance to length extension can go away. The firm says this leaves many teams without an option. It points to government contracting, where CNSA 2.0 mandates SHA384 and SHA512 for nearly everything.
SequenceHash works with nearly any secure hash function, including the SHA2 family, BLAKE and RIPEMD. It encodes each length as a fixed 128-bit number placed after the data. That suffix lets software hash data streams whose size is not known in advance.
It adds three more protections. A double-hash design blocks length extension, an attack on SHA256 and SHA512 where someone who sees a hash can compute a longer one without knowing the secret. Optional customization strings tie a hash to one purpose, which helps stop values being replayed in another context. SequenceMAC also records key length inside the hash. This addresses a known HMAC quirk: HMAC treats the key 0xff and the key 0xff00 as the same key.
What the announcement does not settle
This is the authors' own description of their design. The source reports no independent review or measured adoption. The specification is new, with three implementations.
Trail of Bits states the limit plainly. SequenceHash depends on the strength of the hash underneath it, and it cannot make a broken function such as MD4 secure again.
The programming interface also differs by design from the usual ones. Every update is atomic, so writing two values is not the same as writing their concatenation. Go's hash.Hash interface guarantees the opposite. Teams should expect to adapt code rather than drop it in.
Questions to put to your team
Ask where your products or vendors hash more than one value together. Trail of Bits names several cases: authenticating the files in an archive, grouping multiple cryptocurrency transactions into one hash, generating commitments, and hashing something as simple as a person's name. Ask whether each input carries its own length, or whether values are simply joined with a separator.
Ask whether the answer is the same everywhere. Trail of Bits found mixed approaches across ecosystems, and your codebase may show the same mix. Ask your auditors whether they check for ambiguous encodings, and whether a mandated hash choice such as SHA384 rules out TupleHash for you.
The broader point is that a recurring mistake calls for a shared, reviewed specification rather than another reminder to be careful. Trail of Bits describes its goal as "fix software, not bugs." Whether SequenceHash earns that role will depend on review and use. The question it raises for any team is already clear: does your fingerprint know where each piece of data ends?
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Trail of Bits.
