Six Ways to Tamper with a Substrate (and Why All Six Fail)

The first post in this series described the 74-byte substrate primitive: what it is, why it is 74 bytes, and what it enables. This post is about what happens when someone tries to break it. Not theoretically. We ran the tests. Six distinct tamper scenarios, each designed to probe a different surface of the substrate's integrity guarantees. All six failed. Not "failed most of the time" or "failed under certain conditions." Failed deterministically, instantly, and with a clear diagnostic indicating exactly what was tampered with.

This matters because tamper detection is not an abstract security property. It is the property that makes the substrate useful in litigation, in firmware integrity verification, in financial audit trails, and in every other domain where the question is not "can we encrypt this?" but "can we prove this has not been changed?" The substrate's answer to that question is yes, and this post shows the six ways we verified it.

The six scenarios

We designed the tamper test suite around six scenarios that cover the full attack surface of a substrate attestation. Each scenario targets a different component of the 74-byte structure or the document it binds to. Together, they cover every manipulation an adversary can attempt without forging a new three-family signature from scratch.

Scenario 1: Flip one bit in the document. Take a validly attested document, flip a single bit anywhere in its byte representation, and attempt to verify the substrate against the modified document. The substrate contains a 32-byte SHA3-256 hash of the original document's canonical encoding. The modified document produces a different SHA3-256 hash. The verifier re-derives the hash from the presented document, compares it against the hash in the substrate's signing message, finds a mismatch, and rejects. Detection is instant.

Scenario 2: Substitute an empty document. Replace the original attested document with an empty byte sequence. The SHA3-256 hash of zero bytes is a well-known constant (a]6, 3a, d0, ... — the Keccak sponge's output on the empty string). The substrate's content hash was computed over the original non-empty document. The hashes do not match. Rejected.

Scenario 3: Substitute a completely different document. Replace the original document with an entirely unrelated document of similar length. The SHA3-256 hashes diverge completely. This is the scenario that tests whether the substrate's binding to the original document is strong enough to survive wholesale replacement. It is. SHA3-256 is a cryptographic hash function, not a similarity metric. Two documents that differ in content produce unrelated hashes, regardless of how similar their lengths, structures, or surface-level byte patterns might be. Rejected.

Scenario 4: Flip one bit in the serialized substrate. Leave the document unchanged but modify the substrate itself — specifically, flip a single bit in the substrate's serialized byte representation. The compact receipt contains a 32-byte cryptographic commitment to the three-family signature bundle, computed over the substrate's canonical encoding. A single-bit flip in the substrate changes its canonical encoding, which changes the signing message, which invalidates all three signatures in the bundle. The verifier checks the signatures against the signing message derived from the presented substrate bytes, finds that none of the three signatures verify, and rejects. This scenario tests internal consistency: the substrate protects itself, not just the document.

Scenario 5: Flip the computation type byte. The substrate's 1-byte computation type field identifies the kind of computation being attested. Change it from, say, 0x0C (DocumentArchival) to 0x02 (FraudScore). This is a special case of Scenario 4, but worth calling out separately because it represents a semantic attack: the adversary is not trying to alter the document or the cryptographic binding, but rather to misrepresent what kind of attestation was performed. Even so, the computation type byte is part of the substrate's canonical encoding, which feeds into the signing message, which is bound by the three-family signature. Changing the computation type byte invalidates all three signatures. Rejected.

Scenario 6: Present a receipt against the wrong signing message. Take a valid substrate-receipt-signature triple from one attestation and present the receipt against a different substrate (produced for a different document, a different computation, a different time). The compact receipt's cryptographic commitment was computed over the original substrate's signing message. The new substrate has a different signing message. The commitment does not match. The verifier rejects without even needing to check the individual signatures, because the receipt's commitment to the signature bundle is itself bound to the specific signing message of the original substrate. This scenario tests cross-attestation replay and it fails cleanly.

Why single-bit sensitivity matters

Scenarios 1 and 4 are the most instructive, because they demonstrate the property that makes the substrate's tamper detection qualitatively different from checksum-based integrity checks: single-bit sensitivity with full avalanche.

SHA3-256, the hash function at the core of the substrate's content binding, exhibits full avalanche behavior. This means that changing a single bit in the input changes, on average, 50% of the output bits. Not one output bit. Not a few output bits. Half of them. The distribution of changed bits is indistinguishable from random coin flips.

The practical consequence is that there is no "close enough." A document that differs from the original by one byte — one bit, even — produces a SHA3-256 hash that is, for all practical purposes, a completely different 256-bit string. The verifier does not compute a distance metric between the expected hash and the actual hash. It checks for exact equality. Exact. If even one of the 256 bits differs, the substrate rejects. There is no threshold, no tolerance, no margin of error.

This is a stronger property than many people realize. Consider a CRC32 checksum, which detects most accidental errors but can be trivially forged: an adversary can compute a modified document that produces the same CRC32. Consider an MD5 hash, which is collision-resistant against accidental modification but not against deliberate attack: known collision-generation techniques can produce two documents with the same MD5 in seconds. SHA3-256 provides collision resistance at the 128-bit security level (birthday bound on 256 bits), which means that finding two inputs with the same SHA3-256 output requires approximately 2^128 operations — a number that is beyond the reach of any classical or near-term quantum computer.

But the substrate does not rely on collision resistance alone. The three-family signature over the signing message means that even if an adversary could find a SHA3-256 collision (which they cannot, but hypothetically), they would still need to forge signatures under ML-DSA-65, FALCON-512, and SLH-DSA-SHA2-128f simultaneously in order to produce a valid substrate for the colliding document. The hash collision gives the adversary a document that maps to the same content hash; the signature forgery requirement means they cannot produce a valid receipt for that content hash without the signing keys. Tamper detection in the substrate is a composition of hash binding and signature binding, not either one alone.

Practical use: Legal evidence integrity

Consider a concrete scenario. A company files a contract with a regulatory body. At the time of filing, the company runs the contract through the substrate pipeline: the document's bytes are hashed with SHA3-256, the hash is embedded in a substrate with computation type 0x0C (DocumentArchival), the substrate is signed under three post-quantum families, and the 32-byte signing message is anchored to a Bitcoin OP_RETURN output. The entire process takes milliseconds. The cost is $0.001 per mint. The persistent footprint is 74 bytes.

Eighteen months later, opposing counsel in litigation claims the contract was altered after filing. The company's response is mechanical: take the contract as it exists today, compute its SHA3-256 hash, and compare that hash to the signing message recorded in the Bitcoin OP_RETURN that was mined at the time of filing. If the hashes match, the document is byte-for-byte identical to what was attested. If they do not match, something changed — and the substrate tells you exactly when the original was attested, because the Bitcoin block has a timestamp, the substrate has a millisecond timestamp, and the OP_RETURN commitment binds the two together.

This is not a new idea. Timestamped hashing has been used in legal contexts for years. What the substrate adds is the three-family post-quantum signature over the attestation, which means the integrity proof does not degrade under quantum computing. A SHA-256 hash anchored to Bitcoin is only as durable as SHA-256's collision resistance. The substrate's SHA3-256 content hash, bound by ML-DSA-65, FALCON-512, and SLH-DSA-SHA2-128f signatures, is durable under three independent hardness assumptions. If your legal evidence needs to hold up in court in 2040, you want the attestation that survives the widest range of future cryptanalytic scenarios. That is what three-family signing provides.

The verifier-only Rust crate, published under Apache 2.0 at github.com/H33ai-postquantum/h33-substrate-verifier, means opposing counsel does not need to trust H33's infrastructure to check the attestation. They download the crate, compile it themselves, feed in the substrate bytes and the document, and get a boolean. The verification path depends on SHA3-256 and the three NIST reference signature implementations. Nothing else. No API call, no cloud dependency, no trust assumption beyond the mathematics.

Practical use: Firmware integrity

A medical device manufacturer ships firmware updates to devices deployed in hospitals. Each firmware binary is substrated at build time: the binary's SHA3-256 hash is embedded in a substrate with computation type 0x0A (MedicalPhi — or a custom computation type registered for firmware attestation), signed under three families, and the signing message is recorded in an immutable log.

Six months later, a security researcher discovers that several devices in a hospital network are running firmware that does not match any known release. The hospital's incident response team extracts the firmware binary from an affected device, computes its SHA3-256 hash, and compares it against the substrate attestations for every firmware version the manufacturer has released. None of them match. The firmware on the device is not any version the manufacturer attested. It has been modified.

This is supply chain attack detection. The substrate does not prevent the attack — it cannot stop someone from flashing modified firmware onto a device. What it does is make the attack detectable with mathematical certainty. The hash of what is on the device does not match the hash in the attestation. Full stop. There is no ambiguity, no "it might have been a benign update," no reliance on version strings or metadata that could themselves be spoofed. The SHA3-256 hash is computed over the actual bytes of the firmware binary. If the bytes differ, the hash differs, and the substrate rejects.

For medical devices specifically, this addresses a regulatory gap. The FDA's premarket cybersecurity guidance requires manufacturers to provide a Software Bill of Materials, but SBOMs describe what components are in the software — they do not cryptographically attest that the binary on the device is the same binary the manufacturer built. The substrate closes that gap. It provides a cryptographic receipt, anchored to an immutable ledger, proving that a specific binary was attested at a specific time by a specific signing authority. If the binary on the device does not match, the receipt proves it.

The production pipeline that generates these attestations runs at 2,216,488 authentications per second on production hardware. A firmware build that takes minutes to compile takes microseconds to substrate. The attestation step adds no meaningful overhead to the build pipeline. The distillation process — compressing the three-family signature bundle into the 42-byte compact receipt — happens at signing time. By the time the receipt is stored, the 74-byte footprint is final.

Practical use: Financial audit trails

The Sarbanes-Oxley Act requires that financial records cannot be altered after the reporting period closes. In practice, this is enforced by access controls, database audit logs, and the threat of criminal penalties. These are organizational controls, not cryptographic ones. They prove that the database says the records were not changed. They do not prove that the records were not changed.

The distinction matters because organizational controls can be circumvented by anyone with sufficient access to the systems that implement them. A database administrator can alter records and simultaneously alter the audit log. A backup administrator can restore from a modified backup. A cloud provider's employee can, in theory, modify storage at the infrastructure layer. These are not hypothetical scenarios; they are the scenarios that SOX was designed to prevent, and they are the scenarios that SOX's control-based approach can only mitigate, not eliminate.

Substrate attestation provides a different kind of guarantee. At the close of each reporting period, the financial records are hashed in their canonical form, the hash is embedded in a substrate, the substrate is signed under three post-quantum families, and the signing message is anchored to a Bitcoin OP_RETURN. From that point forward, the integrity of the records can be verified by anyone with access to the substrate and the original data, without trusting the database, the database administrator, the backup system, or the cloud provider. The verification is a pure mathematical function: hash the records, compare to the substrate, check the signatures.

If a regulator or auditor wants to verify that the records as of Q4 2026 are identical to the records that were attested at the close of Q4 2026, they compute the SHA3-256 hash of the current records and compare it to the hash in the substrate that was anchored to Bitcoin at the reporting-period close. If the hashes match, the records are intact. If they do not match, the records have been altered since attestation, and the Bitcoin block timestamp proves when the original attestation occurred.

This turns SOX compliance from a trust-based assertion ("our controls prevent unauthorized modification") into a cryptographic assertion ("the hash of the current records matches the hash attested at period-close, verifiable by anyone against the Bitcoin blockchain"). The former requires trusting the organization's internal controls. The latter requires trusting SHA3-256, ML-DSA-65, FALCON-512, and SLH-DSA-SHA2-128f — which is to say, trusting the mathematics.

Why three-family signing makes tamper detection post-quantum permanent

Everything described above — the six tamper scenarios, the legal evidence use case, the firmware integrity use case, the financial audit trail use case — works with any cryptographic hash function and any signature scheme. You could build a single-family version of this with Ed25519 and SHA-256 and it would detect all six tamper scenarios just as reliably, today.

The question is whether it will still work in 2040.

Classical hash-based tamper detection — Git's SHA-1 commits, PGP's SHA-256 signatures, TLS certificate chains — proves non-alteration under the assumption that the hash function is collision-resistant and the signature scheme is unforgeable. For SHA-1, that assumption has already partially failed: SHAttered demonstrated a practical collision in 2017. For SHA-256 and Ed25519, the assumptions hold today, but their durability against a large-scale quantum computer running Shor's algorithm (for Ed25519) or Grover's algorithm (for SHA-256, with a square-root speedup against pre-image resistance) is not guaranteed.

The substrate's three-family signing addresses this directly. The attestation itself is signed under three independent post-quantum hardness assumptions:

1. ML-DSA-65 is secure under the Module Learning With Errors problem over module lattices.

2. FALCON-512 is secure under the Short Integer Solution problem over NTRU lattices.

3. SLH-DSA-SHA2-128f is secure under the pre-image resistance of SHA2-256 — a purely hash-based assumption with no algebraic structure for a quantum algorithm to exploit.

These three assumptions are, to the best of current cryptanalytic knowledge, independent. A breakthrough against module lattices (breaking ML-DSA) does not automatically break NTRU lattices (FALCON) or hash pre-image resistance (SLH-DSA). A breakthrough against NTRU lattices does not automatically break module lattices or hash functions. A breakthrough against hash pre-image resistance — which would be the most surprising of the three, since it would require a fundamentally new quantum algorithm beyond Grover — does not automatically break either lattice family.

The consequence for tamper detection is that the substrate's attestation survives any single cryptanalytic catastrophe. If ML-DSA falls, the attestation is still protected by FALCON and SLH-DSA. If FALCON falls, the attestation is still protected by ML-DSA and SLH-DSA. If SLH-DSA falls (which would mean hash functions are broken in a way we do not currently understand), the attestation is still protected by two independent lattice families. An adversary who wants to forge a tampered substrate after one family falls must still break the remaining two — three independent mathematical bets, not one.

This is what makes the tamper detection post-quantum permanent. Not "post-quantum secure under current assumptions," which is what a single-family PQ scheme gives you. Permanent in the sense that the attestation degrades gracefully under cryptanalytic surprise: each broken family reduces the security by one layer, but does not eliminate it. The adversary has to succeed three times, against three different branches of mathematics, to forge a single attestation. That is the insurance policy that makes it safe to stake legal evidence, firmware integrity, and financial audit trails on a substrate produced today, with confidence that the attestation will hold up decades from now regardless of which specific cryptographic assumption turns out to be weaker than we thought.

What this means for the test suite

The six tamper scenarios we tested are now part of the substrate's permanent regression suite. Every release of the substrate crate runs these six scenarios against freshly generated substrates. If any scenario passes when it should fail — if a tampered document verifies, if a flipped bit goes undetected, if a cross-attestation replay is accepted — the build fails and the release does not ship.

This is not a heroic measure. It is basic cryptographic engineering hygiene. The six scenarios cover the attack surface. The tests enforce the coverage. The three-family signing ensures the coverage survives the transition to post-quantum computing. The production pipeline runs at 2,216,488 authentications per second, so there is no performance excuse for skipping attestation. The cost is $0.001 per mint, so there is no economic excuse either.

If you are building systems that need to answer the question "has this been changed?" — and you need that answer to hold up in court, in a regulatory audit, in a supply chain investigation, or against a quantum computer — the substrate gives you 74 bytes of permanent tamper detection. Patent pending — H33 substrate Claims 124-125.

The next post in this series examines batched Merkle aggregation: how to substrate a million documents under a single 74-byte root and verify any individual document's integrity with 20 hash operations. After that, a deep dive on the three-hardness-assumption argument and the specific independence claims we make about the three signature families.

Thanks for reading. See you in the next one.