The FHE community has spent two decades solving the confidentiality problem. Gentry's breakthrough in 2009 proved that computation on encrypted data was possible. Subsequent schemes, BFV, BGV, CKKS, TFHE, made it practical. Today, FHE can process biometric authentication at 2,293,766 operations per second at 38 microseconds each. The confidentiality problem is solved. But a harder problem remains: how do you know the encrypted computation was performed correctly?
This is the attestation problem, and it is fundamentally different from the encryption problem. Encryption asks: can the server read my data? Attestation asks: did the server actually process my data with the correct algorithm? These are independent security properties, and satisfying one does not satisfy the other.
A server that faithfully encrypts but silently skips computation is as dangerous as a server that skips encryption but faithfully computes. The first leaks nothing but produces garbage results. The second produces correct results but leaks everything. A secure system requires both properties: confidentiality from encryption and integrity from attestation.
The Attestation Gap
Consider a financial institution using FHE for credit scoring. The institution encrypts applicant data, sends it to a cloud service, and receives encrypted credit scores. The cloud service runs a machine learning model on the encrypted data and returns the encrypted inference result. The institution decrypts the scores and makes lending decisions.
Without attestation, the institution faces several risks that encryption does not address. The cloud service could run a different model than agreed upon, perhaps a simpler model that is cheaper to compute but less accurate. The cloud service could cache and replay previous results rather than computing fresh scores, returning stale results for new applicants. A compromised server could inject predetermined scores designed to approve specific applicants or deny others. Hardware failures could produce incorrect encrypted results that decrypt to plausible-looking but wrong scores.
In each case, the institution decrypts the result and gets a number that looks like a valid credit score. There is nothing in the decrypted value that indicates whether the computation was performed correctly, performed incorrectly, or not performed at all. The encryption is perfect, and the results are unreliable.
How H33-74 Attestation Works
H33 generates a cryptographic attestation for every encrypted computation. The attestation process has four steps that execute as part of the standard computation pipeline, adding approximately 29% overhead to the FHE computation time.
Step one: hash the computation trace. H33 computes a SHA3-256 hash over the input ciphertexts, the computation graph identifier, and the output ciphertexts. This hash uniquely identifies the specific computation that was performed on the specific inputs to produce the specific outputs. Any modification to any component changes the hash.
Step two: sign the hash with Dilithium. The SHA3-256 hash is signed using Dilithium (ML-DSA), a NIST-standardized post-quantum digital signature scheme based on lattice assumptions. The signature proves that H33 produced the hash, binding the computation trace to H33's identity.
Step three: generate a STARK proof. A zero-knowledge proof is generated (or looked up from cache) that the hash was computed correctly over the actual computation trace. This prevents a scenario where the signing key is available but the computation was not performed; the STARK proof ensures the hash corresponds to a real computation.
Step four: distill into H33-74. The full attestation (hash, signature, and proof reference) is distilled into a 74-byte token. This distillation uses three independent hardness assumptions: MLWE lattices (from Dilithium), NTRU lattices (from the second signature family), and stateless hash functions (from SHA3-256 and the STARK proof). The 74-byte token is the minimum representation that preserves all three security properties.
The client receives the encrypted computation result plus the 74-byte attestation. To verify, the client checks the attestation against the computation inputs and outputs. If the verification passes, the client has mathematical proof that the computation was performed correctly. If it fails, the client knows the result is untrustworthy.
Three Independent Hardness Assumptions
The security of H33-74 rests on three independent hardness assumptions: MLWE (Module Learning With Errors) lattice problems, NTRU lattice problems, and the collision resistance of stateless hash functions. These are three distinct mathematical problems from two different families of assumptions.
MLWE is the assumption underlying Dilithium signatures and Kyber encryption, both NIST-standardized post-quantum algorithms. Breaking MLWE would require solving structured lattice problems that resist both classical and quantum attacks based on current understanding.
NTRU is a different lattice problem with a different algebraic structure. While both MLWE and NTRU are lattice-based, a breakthrough against one does not automatically translate to a breakthrough against the other. They provide independent security guarantees within the lattice family.
Stateless hash functions (SHA3-256) derive security from the mathematical properties of the Keccak sponge construction. Hash function security is completely independent of lattice assumptions. A quantum computer that breaks lattice problems would not affect SHA3-256 security, and vice versa.
The three-assumption design means that forging an H33-74 attestation requires simultaneously breaking MLWE lattices, NTRU lattices, and SHA3-256. This is not a single computational problem but three independent problems, each of which is believed to be hard for both classical and quantum computers. The probability of all three being broken simultaneously is the product of three independent small probabilities, which is astronomically smaller than any individual probability.
Attestation Without Decryption
A critical property of H33's attestation is that it works on encrypted data without requiring decryption. The attestation proves that a specific computation was performed on specific ciphertexts, not on specific plaintexts. The verifier does not need to know what the encrypted data contains in order to verify that the computation was performed correctly.
This property is essential for multi-party scenarios where no single party should see the plaintext. In a consortium fraud detection system, five banks contribute encrypted transaction data. The attestation proves that the fraud detection algorithm was applied to all five banks' encrypted data. Each bank can verify this independently without decrypting the other banks' data.
The attestation also preserves forward secrecy. Even if a decryption key is compromised in the future, the attestations generated before the compromise remain valid. The attestation is bound to the ciphertexts, not to the plaintexts, so key compromise does not affect the integrity of historical attestations.
Why Not Just Use Digital Signatures?
Some readers may wonder why attestation needs to be more complex than a simple digital signature over the computation result. The answer is that a digital signature alone does not prove computation correctness; it only proves that a specific entity produced a specific output.
If H33's signing key is used to sign a fabricated result (because the signing system was compromised independently of the computation system), a digital signature would validate the fabricated result. The STARK proof layer prevents this by proving that the signed hash corresponds to an actual computation trace. The signature and the proof are complementary: the signature binds the attestation to H33's identity, and the proof binds the attestation to a real computation.
Additionally, classical digital signatures (RSA, ECDSA) are not quantum-resistant. Using them for attestation would create a system where the encryption layer survives quantum attacks but the verification layer does not. H33 uses Dilithium specifically because it is quantum-resistant, ensuring that attestations remain unforgeable even against quantum adversaries.
The Verification Experience
Verification is designed to be simple. The client SDK includes a verify function that takes the encrypted result, the attestation token, and the public verification key, and returns a boolean. Under the hood, it checks the Dilithium signature, verifies the SHA3-256 hash chain, and confirms the STARK proof reference. But the developer sees only a pass/fail result.
If verification fails, the SDK provides a diagnostic error indicating which component failed: signature verification, hash chain integrity, or proof reference validity. This helps distinguish between network corruption (hash chain failure), key compromise (signature failure), and computation fraud (proof failure).
The 74-byte attestation is small enough to include in any transport mechanism. It fits in an HTTP header, a database column, a blockchain transaction, or a QR code. This portability means attestations can be stored, forwarded, and verified independently of the encrypted data they attest. An auditor can verify a year's worth of attestations without ever accessing the encrypted data they correspond to.
Encryption without attestation is a half-measure. It protects data from being read but not from being misprocessed. H33-74 attestation completes the picture: data that cannot be read, computations that cannot be faked, and proofs that cannot be forged. That is the full stack of trust, and it fits in 74 bytes.
Real-World Attestation Scenarios
The value of attestation becomes concrete in specific scenarios where encrypted computation results must be trusted by parties other than the computing service.
In healthcare, encrypted diagnostic computations must be trusted by the treating physician, the patient, and the insurance company. The physician needs to know that the diagnostic model was actually run on the patient's data. The patient needs to know that their data was processed according to the agreed-upon protocol. The insurance company needs to know that the diagnostic result was produced by an approved model, not fabricated to justify a specific treatment. H33-74 attestation provides each party with independent verification of the computation's correctness, without any party needing to trust the others.
In legal proceedings, encrypted document analysis must be trusted by both parties and by the court. When encrypted documents are analyzed for relevance in discovery, the attestation proves that the analysis algorithm was applied to the specific documents. A party cannot claim that the analysis was rigged to hide relevant documents, because the attestation proves exactly which algorithm was applied to exactly which inputs. The 74-byte token becomes evidence, admissible and verifiable, that the encrypted computation was performed as claimed.
In financial auditing, encrypted computations on customer data must be verifiable by external auditors. The attestation provides auditors with a machine-checkable proof that specific computations were performed correctly, replacing the manual verification processes that currently require auditors to access sensitive customer data. The audit becomes faster, cheaper, and more secure because the auditor verifies cryptographic proofs rather than examining plaintext records.
In each scenario, the attestation transforms encrypted computation from a trust-me proposition into a verify-it-yourself proposition. The computing service does not ask for trust. It provides proof. And the proof is 74 bytes that anyone can verify, anytime, anywhere, using only a public verification key.