Prove your FHE engine computes correctly — without ever decrypting customer data.
When you deploy an FHE chip or cloud FHE engine, how do you demonstrate it is correct? Random testing cannot catch fabrication errors or consistently-wrong-engine bugs. OFC is the industry-first conformance certification that answers this — using the algebraic structure of FHE ciphertexts themselves, no oracle or decryption required.
FHE engines — chips, FPGAs, cloud accelerators — can produce plausible but wrong ciphertexts. A fabrication defect, a subtle implementation error, or a rounding-regime mismatch in the NTT can cause results that decrypt to incorrect values. The catch: you cannot verify correctness by decrypting customer data, and golden-vector testing only catches deviations from the specific test vectors, not systematic failure modes across the full operational domain.
A chip that computes slightly wrong arithmetic across all operations — not detectable by random sampling, because the error is consistent and systematic.
An FHE library that applies a wrong parameter during key-switch always produces a plausible ciphertext — one that decrypts to a wrong answer — and no test vector catches it without the secret key.
Cloud FHE providers currently operate on a trust-the-vendor model. Regulated deployments (GDPR, EU AI Act, healthcare) cannot accept unverifiable correctness claims.
Without a shared conformance layer, ciphertexts produced on one FHE engine are not guaranteed to be compatible with another — even when both claim to implement the same scheme.
OFC defines two independent protocol tiers, each targeting a different assurance level. Both are patent-pending with international PCT applications filed. Both produce independently verifiable Ed25519-signed certificates.
Algebraic ψ-fingerprint self-consistency certification. TRACE derives a set of algebraic invariants from the ciphertext ring structure itself — relationships that hold in any correct FHE computation, regardless of the plaintext values. The engine under test evaluates a signed challenge; TRACE verifies that the ciphertext output satisfies the expected invariants. No oracle. No decryption. Works black-box against any engine that exposes a ciphertext output.
Attested Known-Answer Conformance with hardware-rooted attestation. The VaultBytes CA issues a fresh seed; the device-under-test derives challenge probes, encrypts them under the AKAC parameters, evaluates, and decrypts. The CA re-derives from the same seed and scores the answers. The resulting certificate binds the result to the device's hardware identity — TPM attestation or HSM-signed device pubkey. Closes the fabrication and consistently-wrong-engine gaps that TRACE cannot address.
attestation_mode field: hardware_rooted, measured_execution, or software_identity_boundThe AKAC protocol runs a seeded challenge-response across five steps. The CA never receives plaintext; the device proves correctness by re-deriving from the same seed.
VaultBytes CA generates a fresh, cryptographically random seed and issues it to the device under test. The seed determines all challenge probes for this session.
The device derives probe inputs from the seed, encrypts them under AKAC parameters, evaluates the required FHE operations, and decrypts results. The secret key never leaves the device.
The CA re-derives the expected answers independently from the same seed and scores each operation — bits of agreement, equality fraction, or Hamming distance depending on scheme.
The device signs the session transcript with its TPM attestation key or HSM-bound device key. This binds the correctness result to the specific physical device.
VaultBytes CA issues an Ed25519-signed certificate containing the per-operation scores, session transcript digest, device pubkey fingerprint, attestation mode, and validity period.
Each OFC certificate is a signed JSON document verifiable by any party holding the VaultBytes CA public key. Certificates are scheme-agnostic and reference the specific protocol version and operation set evaluated.
CKKS score = bits of agreement above floor. BGV/BFV score = exact equality fraction. TFHE/FHEW score = zero Hamming distance fraction.
OFC covers all major production FHE schemes. Per-scheme scoring reflects the correct notion of correctness for each: approximate arithmetic for CKKS, exact arithmetic for BGV/BFV, and Boolean correctness for TFHE/FHEW.
| Scheme | Correctness metric | Operations evaluated | Notes |
|---|---|---|---|
| CKKS | bits of agreement | KeySwitch, Add, Mul, Rescale, Bootstrap (EvalMod) | Minimum floor enforced; precision collapse flagged |
| BGV / BFV | exact equality fraction | Add, Mul, Relinearisation, ModSwitch, Rotate | Any deviation from exact equality is a FAIL |
| TFHE / FHEW | zero Hamming distance | Bootstrap, AND, OR, XOR, NOT, MUX | Single-bit correctness; gate-level accuracy required |
Any organisation that deploys or procures an FHE engine and cannot verify correctness by decrypting customer data.
| FHE chip vendors | Certify silicon before customer shipment. Demonstrate correctness without requiring customers to hold or share secret keys. Differentiate on an independently verified conformance certificate. |
|---|---|
| Cloud FHE providers | Move beyond trust-the-vendor assurances. Provide tenants with a third-party certificate they can pass to their own auditors. Annual renewal certificates support continuous assurance. |
| Regulated AI deployments | GDPR Article 25 (data protection by design), EU AI Act Article 9 (risk management), and sector-specific regulations increasingly require evidence that private computation infrastructure operates correctly. OFC certificates are audit-ready artifacts. |
| FHE library maintainers | Continuous TRACE certification across scheme versions and parameter sets catches regressions that unit tests miss. Suitable for OpenFHE, Microsoft SEAL, Concrete ML, TenSEAL, and custom implementations. |
| Enterprise NRE / custom ASIC | Bespoke integration of OFC into a proprietary chip verification flow, with custom scheme support, tapeout-ready test vectors, and sign-off documentation. |
OFC is offered as a service and a licensable SDK. All tiers produce independently verifiable Ed25519-signed certificates. Pricing is on application; contact us for a quote.
One-time TRACE or AKAC certification run for a single FHE engine instance. Produces a signed certificate valid for 12 months. Suitable for product launches, vendor audits, and customer-facing assurance.
Recurring annual re-certification covering updated firmware, parameter changes, or new scheme versions. Maintains a continuous certificate chain for compliance reporting.
Hosted AKAC challenge authority. The VaultBytes CA issues seeds, scores returned answers, and signs certificates on a subscription basis. Suitable for cloud providers running repeated engine certifications.
Embed algebraic self-consistency checks directly in your FHE engine or test harness. Licence the TRACE protocol implementation for continuous integration and pre-shipment testing.
Custom scheme support, ASIC-integration guidance, tapeout-ready test vectors, and bespoke sign-off documentation. Engagement under NDA with dedicated engineering support.
Common questions about how OFC works, what it covers, and how it differs from existing testing approaches.
attestation_mode field describes how strongly the result is bound to the specific device:
hardware_rooted — result signed by a TPM attestation key or HSM device key; strongest bindingmeasured_execution — result accompanied by a measured boot / TEE attestation reportsoftware_identity_bound — result signed by a software identity key; weakest binding, suitable for library certificationTell us about your engine, the scheme, and the assurance level you need. We reply within one business day. All inquiries are treated in confidence; we are happy to sign an NDA before the first call.
IP notice: TRACE and AKAC are patent-pending (PCT applications filed). The OFC protocol specifications and test vectors are proprietary. SDK licences and NRE engagements are available under commercial agreement.