The Blind Machine: Governed Computation on Encrypted Data with Certificate-Bound, Reproducible Verification

Abstract

The Blind Machine is a platform for governed computation on encrypted data with certificate-bound, reproducible verification. Plaintext data and secret keys stay on the user's machine while the hosted service computes on ciphertext only, and each run yields a machine-verifiable certificate binding the application, cohort, and result. Because the entire trust surface is the open-source Blind CLI, the confidentiality guarantee does not depend on hiding the server, and every result is independently reproducible. We evaluate the platform on six BFV genomic applications and four studies on real, openly consented public human genomes (IGSR/1000 Genomes); in every case the value decrypted from encrypted execution equals a plaintext oracle exactly. All of it can be reproduced — or handed to an AI agent to reproduce — from the open CLI, with no access to the hosted service and no private data.

Summary

We present The Blind Machine, a platform for running governed computations on encrypted data with certificate-bound, reproducible verification. Its central boundary is simple: plaintext data and secret keys stay on the user's machine, while the hosted service stores governance state and runs computation on ciphertext. A run cannot execute until the cohort is explicitly frozen and policy gates are satisfied. After execution, the platform issues a machine-verifiable certificate that binds the exact application, public context, committed cohort, encrypted result, and release-policy facts. The certificate proves that these artifacts are internally consistent and name the expected objects; it does not by itself prove that the hosted service evaluated the committed function correctly. Compute correctness is checked separately, by re-executing the committed application over the committed ciphertexts — fully public for synthetic or intentionally public cohorts, and authorized-only for private ones.

The platform follows Kerckhoffs's principle. The confidentiality claim does not depend on hiding the hosted implementation. The open-source Blind CLI performs key generation, encryption, decryption, and verification locally; the closed-source hosted service manages projects, storage, governance, and sandboxed ciphertext execution. Because the hosted service does not receive the secret key or plaintext under the intended protocol, it is outside the trusted computing base for raw-data confidentiality — conditional on an uncompromised local client, local key custody, and no server–keyholder collusion. Integrity is checked separately through content hashes, computation certificates, and scoped artifact re-execution when the necessary ciphertext artifacts are available.

We evaluate the platform on real cryptography over both synthetic and real data, using the BFV homomorphic-encryption scheme. Across six BFV genomic applications, the value decrypted from encrypted execution equals a plaintext oracle exactly, and four studies on openly consented public human genomes from the IGSR/1000 Genomes Phase 3 release run the same governed workflow end to end: an allele-frequency panel, a cross-population panel that recovers a simplified F_ST-like indicator of population structure from encrypted aggregates alone, a linkage-disequilibrium window over encrypted genotype products, and a release-policy study that replicates the K-versus-K+1 differencing attack on real genotypes and measures which release controls remove it. In every study the decrypted result matches its cleartext oracle exactly, and every committed output is an aggregate; the public-genome studies are workflow demonstrations on public reference data.

The platform is built to make studies easy to replicate and verify. Because the whole trust surface is the open-source Blind CLI, every result in this paper is independently reproducible: a reader installs the CLI, runs one command to regenerate both the synthetic evaluation and the public-genome studies on their own machine, and re-executes any committed computation to confirm its result — reproducing our numbers with no access to the hosted service and no private data. To make this automatic, the manuscript is published at https://blindmachine.org/papers/the-blind-machine, and to replicate the experiments independently a reader can simply tell an AI agent to run the replication skill at https://blindmachine.org/skills/replicate — an agent-executable recipe that installs the tools, reruns every experiment, and checks the results against ours end to end. A companion skill at https://blindmachine.org/skills/review lets an agent review this paper independently.

Keywords: governed computation; reproducibility; verifiable re-execution; computation certificates; cohort commitment; output privacy; threat model; homomorphic encryption; BFV.

1. Introduction

Many important scientific questions are blocked not by algorithmic limitations, but by data custody. The necessary data already exists, the statistic is known, and the desired output is often only an aggregate—for example, an allele-frequency vector, carrier count, histogram, public-weighted polygenic-score aggregate, variance term, or genotype-phenotype covariance. Yet the underlying records are sensitive and dispersed across people or institutions that cannot simply combine them into a single database.

Homomorphic encryption is a powerful answer to this problem. A server can evaluate a function on ciphertext and return an encrypted result without learning the plaintext input values. Prior work includes secure large-scale HE-GWAS [R6], secure genotype-phenotype storage and analysis [R7], full encrypted GWAS workflows [R8], secure and federated biobank-scale GWAS [R9], MPC-based GWAS [R10], multiparty homomorphic federated analytics [R11], homomorphic polygenic-risk-score computation [R12], and rare-disease FHE analysis [R13].

The Blind Machine works at the layer around those encrypted computations. It turns an approved computation into an end-to-end artifact workflow: contributors inspect an application, encrypt locally, upload ciphertext, wait for cohort freeze and release gates, receive an encrypted result, decrypt locally, and review a certificate for the run.

The key abstraction is the application. An application is a signed, content-addressed bundle with a pinned environment, local roles for key generation/encryption/decryption, a server-side ciphertext-only compute stage, result schemas, and release rules. This makes the platform repurposable: the same project, cohort, sandbox, certificate, and verification machinery can carry allele-frequency counts, histograms, public-weighted scores, variance, covariance, or future encrypted aggregate computations by changing the application bundle.

The local client is the confidentiality trust surface. Plaintext data and secret keys stay on the user's machine under the intended protocol. The hosted service coordinates projects and computes on ciphertext; it is still trusted for availability and governance execution. Output privacy is separate: a decrypted aggregate can leak even if the ciphertext computation was correct.

This is a systems and security design, and the paper validates it empirically by establishing that the platform's encrypted computations are exact and reproducible on both synthetic cohorts and real public genomes. Runtime-performance benchmarking, deployment-scale measurement, and biomedical validation build on this foundation in separate studies.

Every result in the paper is designed to be reproduced. The synthetic evaluation and the public-genome studies each regenerate from a single command against the open Blind CLI and the open, signed application bundles (Section 10, Section 11, Appendix B), so a reader can confirm the numbers independently rather than take them on trust.

The rest of the paper is organized as follows: our key contributions (Section 2), then HE cost controls, platform invariants, architecture, governance, certificates, threat analysis, the security analysis, the BFV evaluation on synthetic cohorts, the real-data studies on public human genomes, related work, discussion, future work, and conclusion.

2. Key Contributions

The paper makes four contributions.

First, an application-governed workflow for encrypted aggregate computation. The application bundle is the reviewable and reusable unit: it names the code, environment, local roles, server compute stage, result schema, release rules, and digest used by governance and certificates.

Second, a method for controlling the cost of encrypted computation. Rather than a new cryptographic technique, the platform shrinks the encrypted problem before the worker sees it — each contributor summarizes locally to the approved statistic instead of encrypting a whole record, and each application selects the weakest sufficient HE tier for its algebra. We quantify what one multiplication-supporting tier costs over the additive tier: a measured 5x and 10x ciphertext-payload premium across the evaluated applications.

Third, certificate-bound verification that any reader can replay. Offline verification checks schema, hashes, policy facts, and binding fields, establishing that the certificate is internally consistent and names the expected artifacts; compute correctness is then checked by scoped re-execution over the committed artifacts, complementing stronger proof systems and outcome-verification protocols [R22-R26]. Because the trust surface is the open-source Blind CLI, this re-execution is available to any reader, not only to the platform operator.

Fourth, an end-to-end evaluation on real cryptography and real public data. The verifier reports exact agreement between plaintext simulation and encrypted BFV execution for all six applications — four in an additive tier and two in a multiplication-supporting tier — and four studies on openly consented public IGSR/1000 Genomes Phase 3 genotypes [R35, R36] run the same governed workflow: an allele-frequency panel, a cross-population panel that recovers a simplified F_ST-like indicator of population structure from encrypted aggregates alone, a linkage-disequilibrium window over encrypted genotype products, and a release-policy study that replicates the K-vs-K+1 differencing attack on real genotypes and measures which release controls actually remove it [R27-R30]. Every encrypted output matches its cleartext oracle exactly, only aggregate outputs are committed, and no individual-level material leaves the local machine.

3. HE Cost Model and Cost Controls

Homomorphic encryption changes the cost model of scientific computation. Its promise is that a server can compute without seeing plaintext, but the price is ciphertext expansion, heavier arithmetic, parameter selection, and bounded operation depth. Additions and ciphertext-by-plaintext multiplications are usually much easier to support than encrypted-encrypted multiplications. Strict fully homomorphic evaluation supports arbitrary-depth circuits, but practical systems often use leveled HE for fixed-depth computations because bootstrapping remains expensive [R3]. The reviewer-facing point is therefore not that HE makes any computation cheap; it is that the platform must reduce the encrypted problem before the hosted worker sees it.

The Blind Machine uses two cost controls. First, the local CLI's encode step performs local, application-specific federated summarization before encryption. A contributor does not encrypt an entire record or database when the approved application only needs coordinates for allele counts, bucket indicators for a histogram, public-weighted fixed-point terms for score aggregation, or bounded sufficient statistics for variance and covariance. This does not remove HE overhead, but it shrinks the shape of the encrypted workload to the statistic being approved.

Second, applications choose the weakest sufficient HE tier for their algebra. If the hosted computation only needs encrypted additions, or encrypted values multiplied by public constants, an additive tier is enough. If the server must derive an encrypted square or product, the application moves to a multiplication-supporting tier. Whether additive HE is smaller or faster is not universal; it depends on the scheme, parameters, packing, implementation, security level, hardware, and workload [R3, R5]. The narrower claim is artifact-specific: in the current 128-bit BFV measurements later reported in Tables 5 and 6, the additive tier uses 262,282 serialized bytes per contribution, while the variance and covariance tiers use 1,310,882 and 2,621,791 bytes. That is a 5.0x and 10.0x payload premium. The same runs report higher worker compute time for the multiplication-supporting applications, 789 ms and 1,284 ms, than for the additive catalog applications, 194-272 ms. These measurements support the design rule used here: implement the approved statistic with the least expressive encrypted computation that is sufficient.

A seventh, draft application, genotype_pair_ld, is a third multiplication-supporting example — the server derives an encrypted genotype-by-genotype product for adjacent-variant linkage-disequilibrium moments. It has been validated so far only on the public-genome studies of Section 11 and is not part of the frozen synthetic taxonomy in Tables 5-7, so it carries no ciphertext-byte or premium measurement in the artifact matrix.

The application structure makes that choice reviewable. A researcher does not select an opaque "FHE mode" for the whole platform. Instead, each signed application states its encoding, encrypted server computation, result schema, release rules, and HE configuration. The platform can therefore remain the same while applications choose an HE configuration well matched to allele-frequency counts, histograms, public-weighted scores, variance, covariance, or later encrypted aggregate tasks.

4. Platform Invariants

The platform invariants are the contract the design must preserve. They are not marketing copy; each invariant has a boundary, and those boundaries define the threat model.

Table 1. Platform invariants.

The local/hosted trust boundary follows from these invariants. The local machine owns raw data, secret keys, key generation, encoding, encryption, decryption, and certificate verification. The hosted service owns governance metadata, public context, ciphertext contributions, cohort commitments, sandboxed ciphertext execution, encrypted results, and certificates.

This boundary is conditional, not magical. It fails if the local client is compromised, the secret key is uploaded, the server gains individual ciphertexts from the keyholder, or parties ignore aggregate-only release separation. In particular, the v1 design uses a single project key that can decrypt any ciphertext encrypted under the project public context, so the confidentiality boundary depends on that key never reaching the hosted service. Metadata privacy, contributor authenticity, malicious-keyholder resistance, public verification over private cohorts, and global query budgets are adjacent layers, not solved by v1.

5. Architecture

The architecture separates the component that must be trusted for secrecy from the component that makes collaboration convenient. The local CLI owns secret-bearing operations. The hosted service owns coordination. The application bundle defines the computation, making the system reusable across tasks.

The Blind CLI runs on the user's machine. It performs key generation, encoding, encryption, decryption, certificate verification, and local simulation. It is the confidentiality trust surface because it handles raw inputs and secret keys. The hosted service manages accounts, projects, invitations, governance state, artifact storage, job orchestration, and sandboxed encrypted execution. It sees public context, ciphertext, governance metadata, and encrypted results, but not plaintext or secret keys under the intended protocol. Application bundles define the computation itself. Each bundle is public, signed, content-addressed, and locked to a reproducible environment.

This split gives the system its end-to-end shape. A new computation does not require a new platform; it requires a new reviewed application that fits the same local-encrypt, hosted-compute, local-decrypt, certificate-verify loop.

Figure 1. Trust-zone diagram.

The diagram separates plaintext data, secret material, local operations, public context, ciphertext artifacts, hosted governance, and hosted compute with distinct styles so readers do not infer that raw data, secret keys, encryption operations, and encrypted artifacts have the same trust role.

The execution lifecycle has six steps. First, the application bundle is reviewed and identified by its digest. Second, contributors use the local CLI to encode and encrypt against the approved public context and coordinate definition. Third, the project freezes the accepted ciphertext cohort, producing a cohort commitment. Fourth, the hosted service runs the approved server-side compute stage over ciphertext inside the sandbox. Fifth, the encrypted result is released under the configured policy. Sixth, the certificate can be checked offline, and the computation can be re-executed when the necessary frozen artifacts are disclosed or authorized.

The application bundle is the reviewable scientific object and the portability unit. It contains a manifest, local role code, server compute code, result schema, release policy, and locked dependency environment. The manifest carries public definitions such as coordinate lists, bucket definitions, or public effect weights. Changing any signed file changes the bundle identity.

The public application registry exposes concrete examples of this structure. Readers can inspect the application structure guide at https://blindmachine.org/application-structure and browse every curated application at https://blindmachine.org/applications/. The v1 registry holds six signed applications: allele_frequency_count (per-variant alternate-allele counts), carrier_count (per-variant carrier counts), cohort_histogram (bucketed one-hot histograms), polygenic_score_aggregate (public-weighted fixed-point score sums), allele_frequency_with_variance (first and second allele-dosage moments), and genotype_phenotype_covariance (an encrypted genotype-phenotype product). Each application page shows the signed payload, README, version metadata, digest, and a browser-readable source tree, so a reviewer can read exactly what will run before trusting it.

The hosted worker treats build and run as separate phases. In the build phase, network access may be allowed while no data is present, so dependencies can be materialized from the locked environment. In the run phase, data is present and network access is forbidden. The server-side compute stage runs in a network-isolated, resource-limited sandbox as a non-root process. This gives the run phase a concrete containment boundary for malicious or buggy application code; formal sandbox proofs and stronger isolation mechanisms belong to future hardening.

The cryptographic libraries are ordinary bundle dependencies. The v1 catalog uses TenSEAL over Microsoft SEAL for BFV [R4, R5]. The bundle defines the exact encrypted computation; the hosted service supplies orchestration, storage, and sandboxed execution.

6. Governance Before Computation

Governance is part of the security argument because ciphertext computation and safe release are different jobs. Homomorphic encryption supplies the encrypted operation; The Blind Machine supplies the approval, cohort, and release controls around that operation.

The first governance step is cohort commitment. Before execution, the project freezes the accepted ciphertext contributions and computes a commitment over the sorted contribution digests, the project id, and the application digest. This commitment pins the exact cohort used for the run. A cohort of K contributors and a cohort of K+1 contributors are different committed cohorts, not two hidden variants of the same run.

Release gates are the second governance step. Applications specify a minimum cohort size, a release policy, and run controls. The platform blocks runs that do not satisfy these gates before dispatching compute. The certificate records the release-policy facts after execution. These gates are useful because repeated or under-quorum aggregates can leak sensitive information, especially in genomic settings [R27, R28].

The simplest attack is K-vs-K+1 differencing. If an attacker can run the same aggregate over a cohort of K contributors and then over the same cohort plus one additional contributor, subtracting the two outputs can reveal the added contributor. The experiment harness reproduces this exactly on an unfrozen synthetic cohort: the recovered vector equals the planted target vector. This demonstrates the threat and motivates the v1 governance design; it shows why release control must sit outside the encryption scheme, but it does not by itself demonstrate that the mitigation works.

A real-data replication supplies the missing positive result and distinguishes which controls matter. Section 11, Table 11, runs the identical adjacent-release comparison on public IGSR/1000 Genomes cohorts (N=25 versus an adjacent N=24 over 40 SNPs): exact adjacent aggregate counts recover a held-out public sample's dosage vector by subtraction. Crucially, a minimum-N floor helps only when it actually blocks the adjacent release — a minimum-N of 20 leaves the exact recovery rate at 1.000, while cohort freeze (single release) and a small query budget drive it to 0.000 and 0.125 respectively. This is the platform's first empirical evidence that release-governance controls, not the encryption scheme, remove the leak.

Figure 2. Output-leakage governance diagram.

The diagram contrasts two unfrozen runs over cohorts of K and K+1 contributors, shows that their aggregate difference isolates the added contributor, and lists the v1 mitigations (freeze before compute, minimum-N, run caps, certificate-bound release facts) alongside the acknowledged v1 limitation that overlapping-cohort differencing and global query accounting remain future work.

Cohort freeze, minimum cohort size, run caps, and aggregate-only release are therefore release-governance mitigations. They make unsafe patterns harder to hide and easier to audit. Formal release privacy requires the next layer: differential privacy, global query budgets, and reconstruction-aware release accounting [R29, R30].

7. Certificates and Verification

The computation certificate is the post-run object that connects the approved application, frozen cohort, encrypted result, and release policy. It gives offline integrity checks over named artifacts and policy facts, and it supports deterministic re-execution when the necessary artifacts are available.

Figure 3. Certificate binding.

The diagram shows the certificate payload fields (application digest, public context digest, project and run identity, cohort commitment, encrypted result digest, and release-policy facts) folding into a single canonical payload whose SHA-256 is the certificate hash.

Table 2. Certificate payload fields (bound by certificate_hash).

certificate_hash is the SHA-256 over the canonical JSON of the eleven payload fields above, with keys sorted. The certificate document also carries issued_at (issuance time) and certificate_hash itself; these two are wrapper fields carried alongside the payload but deliberately excluded from the hashed payload, so re-serialization and timestamping cannot change what the hash commits to.

Offline certificate verification checks schema, canonical hashing, required fields, and expected binding values. It can tell a reviewer whether the certificate document is internally consistent and whether it names the expected artifacts. Computation correctness is checked by the next verification surface: re-execution over the committed artifacts, a specialized verification protocol, or a cryptographic proof.

What the certificate does not prove. The certificate binds artifacts and policy facts; it is not, by itself, a proof of correct or private computation. Specifically: (1) it does not prove that the hosted service actually evaluated the committed function on the committed cohort — that requires re-execution or a stronger proof; (2) it does not prove correct decryption, and carries no zero-knowledge guarantee; (3) it does not prove contributor identity, distinctness, or truthfulness; and (4) it does not bound the output-privacy leakage of the released aggregate. These are the jobs of re-execution, release governance, and future proof systems, respectively.

The Blind Machine uses scoped artifact re-execution as its practical integrity surface. Public readers can verify certificates, public digests, signatures, and disclosed artifact hashes. Synthetic or intentionally public cohorts can be fully re-executed by anyone. Private real cohorts require an authorized artifact workflow because individual ciphertexts become sensitive when combined with the project secret key.

This operational surface complements non-interactive verifiable computation, verifiable HE analytics, and GWAS outcome-verification work [R22-R26]. A public explainer distinguishes this deterministic re-execution integrity surface from SNARK/STARK proof-carrying computation (blindmachine.org/blog). Stronger proof systems can attach to the same application model later.

8. Threat Model

The parties are contributors, the keyholder or project owner, the hosted service, the application reviewer or signer, the verifier or reviewer, and outside observers. Contributors hold raw records and encrypt locally. The keyholder holds the project secret key and decrypts the approved aggregate. The hosted service coordinates the project and computes on ciphertext. The application reviewer or signer approves bundles before use. The verifier checks certificates, artifacts, and, when authorized, re-execution. Outside observers may see public outputs, metadata, or published artifacts.

The assets are raw data, secret keys, public context, ciphertext contributions, cohort membership, encrypted result artifacts, decrypted aggregate outputs, certificates, application bundles, and metadata. These assets have different security properties. Raw-data confidentiality depends on local encryption and key custody. Result integrity depends on bundle signing, cohort commitment, certificate binding, and scoped re-execution. Output privacy depends on release policy, aggregation, and future DP-style controls.

The main adversaries are an honest-but-curious hosted service, a malicious hosted service, a malicious keyholder, a malicious contributor, a compromised bundle signer, an outside observer, and colluding parties. The hosted service can see ciphertexts, public context, timing, project metadata, application choice, and cohort size. Plaintext and secret keys stay local under the intended protocol. A malicious hosted service can try to substitute context, tamper with bundles, drop contributions, fabricate results, bypass governance, or deny service. A malicious keyholder can misuse a decrypted output and, if given individual ciphertexts, can decrypt them. A malicious contributor can poison inputs or attempt Sybil contribution. A compromised signer can approve malicious code. Collusion between the hosted service and keyholder breaks the v1 separation assumption.

The assumptions are explicit. The local client is correct and not compromised. The secret key remains local. Contributors authenticate the intended application and public context. Bundle signing keys are not compromised. The BFV library implements its intended semantics. The hosted service receives ciphertext and public context under the intended protocol. Individual contribution ciphertexts from private real cohorts stay outside arbitrary public verifiers. The synthetic harness supports correctness and reproducibility claims; real biomedical validation requires a separate study design. The public-genome studies in Section 11 are aggregate-only workflow evidence over openly consented public genotypes, and do not constitute biomedical validation.

Table 3. Trusted computing base by property.

9. Security Analysis

This section analyzes the threat model as a catalog of concrete attacks. It is organized so that every attack the platform reasons about has its own subsection and is described in the same shape, so a reader can compare defenses across attacks without re-reading prose. Table 4 is the at-a-glance coverage matrix; the per-attack catalog that follows it (Sections 9.1-9.5) gives each attack a structured entry.

Each entry uses the same seven fields:

• Adversary — which party mounts the attack.
• Attack — the concrete action taken.
• Assets at risk — the platform objects the attack targets.
• Platform control — the mechanism that resists it.
• Verification hook — what a participant or independent verifier can check.
• Status — the outcome under the stated assumptions, drawn from a fixed vocabulary: Prevented (removed under the stated assumptions), Detectable (a participant or verifier can tell it happened), Mitigated (the bar is raised but the class is not closed), Residual (a known v1 gap), or Out of scope (an explicit assumption boundary).
• Residual risk / evidence — what remains open, and the paper section or experiment that substantiates the entry.

The families group attacks by the property they target: confidentiality of raw data and keys (9.1), integrity of the computed result (9.2), privacy of the released aggregate (9.3), the party-trust boundary (9.4), and runtime and availability (9.5). Most output-privacy risks are Mitigated or Residual, not Prevented: cryptography protects the ciphertext computation, while release governance and future differential-privacy accounting protect the decrypted output.

Table 4. Threat coverage matrix.

9.1 Confidentiality attacks

These attacks target the raw records and the secret key — the assets the local/hosted boundary exists to protect.

9.1.1 Hosted service reads plaintext

• Adversary. Honest-but-curious or malicious hosted service.
• Attack. Read contributor plaintext from what the service stores or receives.
• Assets at risk. Raw records, encoded inputs.
• Platform control. Contributors encode and encrypt locally; the intended protocol has no plaintext upload path, so the server role is ciphertext-only (Table 1, invariants "Plaintext stays local" and "Server-side compute is ciphertext-only").
• Verification hook. The open CLI is the confidentiality trust surface; a reviewer can confirm that local stages emit only ciphertext and public context.
• Status. Prevented under the local-client trust assumption.
• Residual risk / evidence. Fails if the local client is compromised or a user uploads plaintext out of protocol. Substantiated by the architecture (Section 5) and the no-plaintext-upload invariant (Section 4).

9.1.2 Hosted service obtains the secret key

• Adversary. Malicious hosted service.
• Attack. Acquire the project secret key and decrypt ciphertext contributions or results.
• Assets at risk. Secret key, all ciphertext under the project public context.
• Platform control. Key generation and decryption are local; the server job spec and certificate schema contain no secret-key field (Table 1, "Secret key stays local").
• Verification hook. The certificate payload (Table 2) is auditable and carries no key material; the job-spec contract can be inspected for the absence of a secret-key parameter.
• Status. Prevented under the local-client trust assumption.
• Residual risk / evidence. The v1 single project key can decrypt any ciphertext under its public context, so the guarantee is exactly the guarantee that the key never reaches the server; threshold or multi-key FHE (Section 14) would weaken this dependency.

9.1.3 Public-context substitution

• Adversary. Malicious hosted service.
• Attack. Serve a public context for which the service owns the matching secret key, so contributors encrypt to the server's key instead of the legitimate keyholder's key.
• Assets at risk. Public context, public-context digest, contributor encryption stage, certificate binding fields.
• Platform control. The public context is hashed and pinned; contributors can authenticate the intended public-context digest before encryption, and the certificate records the public-context digest used for the run.
• Verification hook. A verifier compares the certificate's public_context_digest against the digest expected by the project or disclosed in a signed invitation; substitution changes the digest.
• Status. Prevented only when contributors authenticate the context digest; otherwise Residual.
• Residual risk / evidence. This control is only as strong as context authentication. Strong signed invitations or an equivalent out-of-band digest channel are required for strong malicious-server resistance (Section 7, Table 2).

9.1.4 Malicious application exfiltrates local data

• Adversary. Malicious or compromised application author.
• Attack. Ship local role code (encode/encrypt) that leaks raw inputs from the contributor's machine before encryption.
• Assets at risk. Raw records on the contributor device, local role execution.
• Platform control. v1 ships six curated, Blind-Machine-authored, signed applications; the CLI verifies the application digest and signature before running, and the bundle is public and reviewable (Table 1, "Computation code is public, pinned, and signed").
• Verification hook. Contributors and reviewers can read the signed bundle and its browser-readable source tree before running it (Section 5, Appendix C).
• Status. Mitigated by review and signing.
• Residual risk / evidence. Review can miss bugs, and a user who runs unreviewed local code can leak their own data. Third-party submission needs stricter local sandboxing, static checks, and signing policy; this is why v1 curates and signs rather than accepting arbitrary applications.

9.2 Integrity attacks

These attacks target the computed result: the adversary tries to make the platform certify an output that was not produced by the approved computation over the approved cohort.

9.2.1 Tampered application bundle

• Adversary. Malicious hosted service or man-in-the-middle.
• Attack. Alter a signed application bundle so a different computation runs.
• Assets at risk. Application bundle bytes, application digest, signature.
• Platform control. Bundle identity is a SHA-256 digest with a signature; changing any signed file changes the digest, and unsigned or tampered bundles are rejected before compute.
• Verification hook. The CLI and worker verify digest and signature; a reviewer can recompute the digest of the disclosed bundle.
• Status. Detectable unless the signing key is compromised.
• Residual risk / evidence. A compromised signer can approve malicious code; signing-key custody and (future) transparency logs bound this (Section 5).

9.2.2 Cohort substitution

• Adversary. Malicious hosted service.
• Attack. Compute over a different set of ciphertexts than the project approved or the contributors expected.
• Assets at risk. Accepted contribution digests, frozen cohort manifest, project id, application digest, cohort commitment, encrypted result, certificate.
• Platform control. The cohort commitment hashes the frozen set of accepted ciphertext digests together with the project and application identity; the certificate binds the commitment to the result.
• Verification hook. A verifier with the frozen cohort manifest recomputes the commitment and compares it with the certificate; a different cohort changes the commitment and, in general, the result digest.
• Status. Detectable; recomputable when the manifest is available.
• Residual risk / evidence. Public readers cannot recompute a private real-cohort commitment unless the manifest is disclosed or authorized; for private cohorts, public verification is limited to the certificate and public digest layer (Section 7, Table 2).

9.2.3 Dropped or corrupted contribution

• Adversary. Malicious hosted service.
• Attack. Silently omit or alter individual contributions before the cohort is frozen.
• Assets at risk. Contribution digests, cohort membership, cohort commitment.
• Platform control. Contributions are digest-bound and enter the commitment; supported application checks validate contribution shape.
• Verification hook. A contributor can confirm that their contribution digest appears in the frozen cohort; the commitment fixes the accepted set.
• Status. Detectable for supported checks.
• Residual risk / evidence. Sentinels and digests are not message-authentication codes and do not prove contributor identity, distinctness, or truthfulness; identity attestation is separate (Section 9.4.3).

9.2.4 Fabricated result

• Adversary. Malicious hosted service.
• Attack. Return an encrypted result that was not produced by evaluating the committed application over the committed ciphertext cohort.
• Assets at risk. Signed server compute code, frozen ciphertext artifacts, public context, encrypted result digest, certificate payload.
• Platform control. The certificate binds the result digest, application digest, public-context digest, and cohort commitment; when frozen artifacts are available, an independent verifier re-executes the same application over the same ciphertexts and compares the resulting digest.
• Verification hook. Public synthetic experiments can be re-run by anyone with the disclosed artifacts; real private-cohort runs can be re-executed only by authorized parties.
• Status. Detectable when artifacts are disclosed or authorized.
• Residual risk / evidence. Certificate binding alone does not prove compute correctness; re-execution proves deterministic recomputation, not zero-knowledge correctness of decryption, and is unavailable to public readers when private artifacts are withheld (Section 7; the boxed "What the certificate does not prove"). Deterministic re-execution is exercised end-to-end on real data in Section 11, where every encrypted output matches its cleartext oracle exactly.

9.2.5 Governance bypass

• Adversary. Malicious hosted service.
• Attack. Dispatch compute or release a result without satisfying the application's freeze, minimum-N, or run-cap gates.
• Assets at risk. Dispatch gates, release policy, certificate policy fields.
• Platform control. Dispatch gates precede compute, and the certificate records the release-policy facts (min_contributors, min_n_satisfied, run_count, release_policy) after execution (Table 2).
• Verification hook. A verifier checks the recorded policy facts against the application's declared floor and the cohort size.
• Status. Detectable; the service can still deny service.
• Residual risk / evidence. A malicious service can refuse to issue a certificate, and cross-project governance is not solved by a per-project gate (Section 6; Sections 9.3.2 and 9.5.2).

9.3 Output-privacy attacks

These attacks accept that the ciphertext computation was correct and instead target the decrypted aggregate. They are the paper's largest residual class, and Section 11 measures them on real genotypes.

9.3.1 K-versus-K+1 differencing

• Adversary. A releasee (keyholder, project member, or downstream reader) who can obtain two adjacent aggregates.
• Attack. Obtain one aggregate over cohort K and another over K+1, then subtract to recover the added individual's contribution.
• Assets at risk. Decrypted aggregate outputs, cohort commitments, run-count policy, minimum cohort threshold, release decision.
• Platform control. Cohorts are frozen before compute, so K and K+1 are distinct committed cohorts rather than silent variants of one run; minimum cohort size blocks small releases, run caps reduce repeated queries, and a query budget caps adjacent comparisons.
• Verification hook. The synthetic harness reproduces the attack directly: on an unfrozen add-one comparison, the delta exactly recovers the planted contributor. Section 11 replicates it on public IGSR data (Table 11): exact adjacent aggregate counts recover a held-out public sample by subtraction, and cohort freeze plus a query budget — not a minimum-N floor alone — remove the recovery (min-N=20 leaves recovery at 1.000; freeze and a query budget of 5 give 0.000 and 0.125).
• Status. Mitigated, not solved.
• Residual risk / evidence. Overlapping cohorts, repeated studies, outlier aggregates, and adversarial project design need stronger global release controls, contributor-authenticity checks, and differential-privacy accounting. Evidence: synthetic experiment E4 (Section 10) and real-data experiment E7 (Section 11, Tables 11-12).

9.3.2 Overlapping-cohort differencing

• Adversary. A releasee who commissions or observes multiple studies with overlapping membership.
• Attack. Combine aggregates over overlapping (not strictly add-one) cohorts to isolate contributors, defeating per-cohort freeze.
• Assets at risk. Decrypted aggregates across projects, global membership structure.
• Platform control. Per-project freeze and run caps; v1 has no cross-project query accounting.
• Verification hook. Per-project certificates record each cohort commitment, so overlap is auditable in principle when commitments are disclosed.
• Status. Residual v1 release risk.
• Residual risk / evidence. Closing this needs global query budgets and cohort-overlap accounting across projects (Sections 6 and 14 [R29, R30]).

9.3.3 Small-cohort and outlier leakage

• Adversary. A releasee reading a single aggregate.
• Attack. Infer an individual from an aggregate over a very small cohort, or from an outlier-dominated statistic, without any differencing.
• Assets at risk. Decrypted aggregate output, small-cell group statistics.
• Platform control. Minimum-N gate and application review; the real-data panels in Section 11 additionally suppress small-cell group fields (E6 suppresses 624 group rows with n<10).
• Verification hook. The certificate records min_contributors and min_n_satisfied; suppression is visible in the committed aggregate.
• Status. Mitigated; differential privacy is the stronger release layer.
• Residual risk / evidence. A fixed min-N does not bound outlier influence or guarantee a formal privacy loss; DP-style noise is future work (Section 14). Small-cell suppression is demonstrated on real data in Section 11 (E5, E6).

9.3.4 Metadata leakage

• Adversary. Honest-but-curious hosted service or outside observer.
• Attack. Infer sensitive facts from project metadata, timing, application choice, cohort size, or traffic patterns, without decrypting anything.
• Assets at risk. Project metadata, timing, application identity, cohort size.
• Platform control. Limited v1 controls; the server legitimately sees ciphertext, public context, timing, and cohort size to do its coordination job.
• Verification hook. Metadata that enters certificates (e.g., cohort size) is auditable, but most side-channel metadata is not controlled in v1.
• Status. Residual v1 privacy risk.
• Residual risk / evidence. Traffic shaping, padding, and metadata-minimizing protocols are future work (Section 14).

9.4 Trust-boundary attacks

These attacks exploit the party model itself rather than any single mechanism.

9.4.1 Malicious keyholder misuses decryption

• Adversary. The project keyholder.
• Attack. Use the decrypted aggregate outside its intended purpose, or — if given individual ciphertexts — decrypt them.
• Assets at risk. Decrypted aggregates, any disclosed individual ciphertexts.
• Platform control. Aggregate-only release and governance; individual ciphertexts are not publicly released (Table 1, "Individual ciphertexts are not publicly released").
• Verification hook. Release policy and certificate facts record that the released object is an aggregate, not per-contributor ciphertext.
• Status. Residual v1 trust risk (the keyholder is trusted in v1).
• Residual risk / evidence. In a single-keyholder design, whoever holds the key can decrypt any disclosed ciphertext under the public context; threshold or multi-key FHE and separate decryption authorities are the relevant directions (Section 14 [R8, R11, R13, R21]).

9.4.2 Server-keyholder collusion

• Adversary. The hosted service colluding with the keyholder (or a verifier colluding with the keyholder).
• Attack. Combine the server's individual ciphertexts with the keyholder's key to decrypt individual contributions, breaking the v1 separation.
• Assets at risk. Individual ciphertext contributions, secret key.
• Platform control. The v1 design separates key custody (local) from individual ciphertext access (server); the guarantee rests on that separation not being jointly violated.
• Verification hook. None within v1: collusion is an assumption boundary, not a mechanism the platform can check.
• Status. Out of scope — an explicit assumption boundary.
• Residual risk / evidence. This is the boundary condition attached to the confidentiality claim throughout (Abstract; Section 4); multi-party decryption authorities are the future mitigation (Section 14).

9.4.3 Contributor Sybil or poisoning

• Adversary. A malicious contributor.
• Attack. Submit many fake identities (Sybil) or poisoned inputs to skew or deanonymize the aggregate.
• Assets at risk. Cohort authenticity, aggregate correctness.
• Platform control. Contribution shape checks and digest binding; v1 does not attest contributor identity.
• Verification hook. Digests bind what was contributed, not who contributed or whether the value is truthful.
• Status. Residual v1 authenticity risk.
• Residual risk / evidence. Identity attestation, contributor authentication, and input validation are future work (Section 14); this interacts with differencing, since authentic distinct contributors are assumed by min-N.

9.5 Runtime and availability attacks

These attacks target execution and service continuity rather than the data or the result binding.

9.5.1 Sandbox escape or runtime exfiltration

• Adversary. Malicious or buggy server-side compute code.
• Attack. Escape the sandbox, read host secrets, reach the network, consume excessive resources, or exfiltrate artifacts.
• Assets at risk. Worker container, filesystem mounts, network access, public context, ciphertext artifacts, result artifact, logs, host environment.
• Platform control. In the production Docker worker, the run phase is network-disabled, resource-limited, non-root, and restricted to expected input and output artifacts; build and run are separated so dependency fetching does not occur while data is present, and the worker verifies bundle identity before execution.
• Verification hook. Worker configuration, bundle tests, and run logs demonstrate the intended sandbox settings; because the run receives only ciphertext and public context, sandboxing is defense in depth for confidentiality.
• Status. Mitigated.
• Residual risk / evidence. Sandbox bugs are possible; stronger isolation (microVMs, gVisor, nsjail, dedicated hosts) or stricter third-party review may be appropriate for untrusted authors (Section 5; Section 14).

9.5.2 Denial of service

• Adversary. Malicious hosted service or external attacker.
• Attack. Withhold compute, refuse to issue certificates, or exhaust service capacity.
• Assets at risk. Availability of coordination, compute, and certification.
• Platform control. The hosted service is in the trusted computing base for availability; detection and re-execution make withholding visible when artifacts are available.
• Verification hook. Missing or delayed certificates are observable; disclosed artifacts allow re-execution elsewhere.
• Status. Residual operational availability risk.
• Residual risk / evidence. Availability is operational, not cryptographic; redundancy and escrowed artifacts bound it (Section 8, Table 3).

9.5.3 Replay or stale-artifact use

• Adversary. Malicious hosted service or a careless releaser.
• Attack. Present an old or superseded certificate/result as current.
• Assets at risk. Certificate hashes, issuance metadata, released artifacts.
• Platform control. Certificates carry a content hash and issuance metadata, so each certificate names a specific run.
• Verification hook. A verifier checks the certificate hash and issued_at against expected issuance records.
• Status. Detectable with proper artifact records.
• Residual risk / evidence. Policy must decide whether an old artifact is acceptable; revocation and transparency logs are operational extensions for v1 (Section 14).

10. BFV Correctness Demonstration

The empirical claim is specific: for six evaluated integer applications, decrypted BFV execution matches plaintext simulation on seeded synthetic inputs, which establishes correctness and reproducibility for the platform's application catalog under the current harness. The difference this paper argues for is architectural — a governed, reusable application layer — and a head-to-head performance comparison against prior secure-GWAS systems, biomedical validation, and BFV implementation-security analysis build on this foundation in separate studies.

BFV is used because the v1 computations are exact integer computations: coordinate-wise counts, sums, one-hot histograms, fixed-point public-weighted aggregates, and bounded-depth products. BFV and its parameter/security literature are standard [R1-R3], and the implementation substrate is TenSEAL over Microsoft SEAL [R4, R5].

The method has two paths. The plaintext path generates seeded synthetic inputs and evaluates the application logic in cleartext. The encrypted path encodes and encrypts the same synthetic inputs, runs the server-side BFV compute stage, decrypts locally, decodes, and compares against the plaintext result.

Figure 4. BFV correctness experiment.

The diagram shows seeded synthetic inputs fanning into a plaintext evaluator and an encrypt/BFV-compute/decrypt path, joined by an exact comparison that must report zero error for the run to pass.

The current verifier reports all machine-independent invariants passing (61 checks on the full experiment profile). It asserts bit-exactness, the two-tier taxonomy, the payload-premium ordering, the differencing recovery, and — for the deterministic columns — equality against the committed reference values under results/expected/. It also regenerates the paper-facing CSV files under docs/paper/experiments/results/.

Table 5. BFV exactness taxonomy over six applications.

The table supports the two-tier taxonomy. Four applications are exact in the additive tier, including polygenic_score_aggregate, where all multiplications are by public weights and therefore remain ciphertext-by-plaintext operations. Two applications use multiplication-supporting BFV because the server derives a product under encryption: variance computes an encrypted square, and covariance computes an encrypted genotype-phenotype product. The four additive applications share an identical ciphertext size and differ only in compute time, so the breadth argument of the paper belongs to the reusable application abstraction (Section 5), not to this arithmetic taxonomy.

A seventh application, genotype_pair_ld, is a draft multiplication-supporting application validated to date only on the public-genome studies of Section 11; it is deliberately not part of this frozen synthetic taxonomy and does not appear as a row in Tables 5-7.

Table 6. Payload premium at the current 128-bit artifact setting.

The payload premium is deterministic under the current artifacts. These values are the byte-size evidence used in Section 3's cost-control argument. Multiplication-supporting BFV is still valuable when server-derived products matter. When multiplication can be performed locally or by public-scalar multiplication, the additive tier is the lower-payload catalog choice in this artifact.

Table 7. Security-level matrix.

At fixed ring degree, stronger security settings in the current artifacts use smaller coefficient-modulus bands, which is why ciphertext bytes shrink from 128-bit to 256-bit in this table. The important paper claim is exactness across the matrix, not final performance dominance. Only the 128-bit ciphertext sizes are byte-deterministic and are asserted against committed reference values; the 192-bit and 256-bit sizes shown are representative single-run measurements that vary by a few tens of bytes across TenSEAL builds, so the reproducible claim at those levels is exactness and the shrinking-size trend, not the exact byte counts. Runtime, CPU, RAM, and cloud-cost numbers remain development-machine measurements until a camera-ready benchmark rerun is performed on a pinned environment.

The feasibility sweep currently covers allele_frequency_count at N in {20, 100} and length in {10, 100}; all four checked cells are bit-exact. The experiment harness also writes the table sources used above. These results are machine-independent correctness artifacts because they check exact equality and deterministic ciphertext-size outputs. They are not real cohort runs.

Every number in this section is reproducible from the open Blind CLI with no hosted service, no network, and no real data. Each application bundle seals its own environment (TenSEAL over Microsoft SEAL) with uv, so a reader runs one command and regenerates the tables above — in roughly ninety seconds on a laptop — driving the same signed bundles the platform runs, through the six numbered stages (00_keygen … 50_decode) under real BFV on seeded synthetic cohorts:

cd docs/paper/experiments
bash run_all.sh            # seals the six application environments, drives
                           # `blind bench` / `blind simulate` under real BFV,
                           # and asserts every machine-independent invariant

To re-check only the machine-independent invariants against the committed reference values:

python3 docs/paper/experiments/verify.py

Readers can also check the public paper evidence package on The Blind Machine platform:

https://blindmachine.org/verify/paper/bfv-v1

The draft package hash is:

1c329eeb1c705d6c81f47dc6bd1b741fa6aae0963c4a7c78b9ca511c40dfb030

This package is intentionally separate from a real-cohort Computation Certificate. It binds the synthetic BFV claims to the signed application bundle digests, environment-lock digests, reproducer scripts, reference artifacts, paper-table sources, and caveats for the current draft. The hash above is computed over the current working tree; before circulation it must be re-verified against a clean tagged checkout and footnoted with that source commit or tag.

Before submission, the project should also capture a clean run transcript, artifact hashes, source tag, application bundle digests, verifier version, seeds, coordinate definitions, hardware/runtime environment, and any final timing/cost tables from a pinned benchmark machine.

11. Real-Data Studies on Public Human Genomes

Section 10 established exactness on seeded synthetic cohorts. This section shows that the same governed workflow — local encode/encrypt, ciphertext-only hosted compute, local decrypt, cleartext-oracle comparison, and aggregate-only release — runs unchanged on real human genotypes, and that the analyses it produces are the kinds of population-genetic summaries a researcher would actually want. All four studies draw from the same public source: the IGSR/1000 Genomes Project Phase 3 integrated callset, release 20130502, GRCh37, chromosome 22 [R35, R36]. Each study queries a bounded chromosome-22 interval with bcftools, runs the signed BlindMachine applications locally under real TenSEAL BFV, and checks every decrypted output against a cleartext oracle. In every study, the decrypted encrypted output matched the oracle exactly.

Interpretation and data-use boundary. These studies use only public, openly consented, redistributable IGSR/1000 Genomes reference genotypes [R35, R36]; no private, identifiable, or clinical records are used, and no IRB or data-use agreement is required, so the work remains within bioRxiv scope. They are small workflow demonstrations, not clinical results and not population-genetics estimates: the FST-like and LD r2 values are simplified equal-weight contrasts over small selected panels. Only aggregate outputs are committed; individual VCF slices, selected-sample lists, and per-sample genotype vectors remain under ignored work/ directories. The public /verify/paper/... pages are paper evidence packages; the hosted `/verify/:certificatehashstatus is not_published` for these local runs, because they were not submitted to the hosted computation service.

Reproducing these studies. Each study is a committed, re-runnable script over the open Blind CLI. With the CLI and its toolchain installed (Appendix B), a reader regenerates every table and figure in this section by running the study scripts under docs/paper/experiments/ — e5_real_human_dna_igsr.sh, e6_public_af_fst_panel.sh, e7_beacon_release_policy.sh, and e8_public_ld_window.sh — and then python3 summarize_public_real_dna.py to rebuild the summary tables and figure sources. Each script fetches only the bounded public IGSR interval it needs, runs the signed applications locally under real BFV, checks the decrypted output against a cleartext oracle, and writes aggregate-only results; individual-level material never leaves the machine.

Figure 6. Public-data experiment scope. The figure summarizes sample, variant, query, and pair counts across the four studies.

Table 8. Real-data studies on public human genomes.

11.1 Allele-frequency panel (E5)

The first study is the direct real-data analogue of the additive tier. Ten public samples (two per super-population, in panel order) over twelve complete-call biallelic SNPs in 22:16050000-17000000 are encoded, encrypted, and aggregated by allele_frequency_count (first moment) and allele_frequency_with_variance (first and second moments). The decrypted allele counts and both moments matched the cleartext oracle exactly for all twelve variants.

Table 9. E5 per-variant allele frequency and genotype distribution (10 public samples).

The panel allele frequencies track the IGSR global frequencies with the sampling noise expected from ten samples: the mean absolute deviation from the IGSR global AF is 0.0609, and the largest single deviations (variants 6 and 11) are exactly where the ten-sample panel over- or under-represents a common variant. The genotype distribution is a useful cross-check that the encrypted second moment is doing real work: the mean heterozygote rate is 0.3083 and the mean dosage variance recovered from allele_frequency_with_variance is 0.2542. Variant 6 (22:16053659:A:C) is the informative case — five heterozygotes and five homozygous-alternate samples give it a 0.75 panel AF and the panel's highest dosage variance — and the encrypted first and second moments reproduce it exactly.

11.2 Cross-population differentiation (E6)

The second study asks whether the platform can surface population structure — not just a single pooled frequency — from encrypted aggregates alone. Fifty public samples (ten per super-population, AFR/AMR/EAS/EUR/SAS) over twenty-four SNPs were selected to have a source super-population AF range of at least 0.15 and at least 200 bp of spacing. The same additive and multiplication-supporting allele applications produced the pooled panel frequencies and second moments (exact against the oracle), and a per-variant FST-like statistic was computed after decryption as the equal-weight heterozygosity contrast `(HT - means HS) / HT` across the five super-populations. This is a simplified stand-in for the standard Weir-Cockerham FST estimator [R37], not the estimator itself; we use it only to show that a differentiation signal is recoverable from the governed aggregates.

Table 10. E6 top cross-population differentiation variants (50 public samples, 5 super-populations).

The panel mean FST-like value is 0.0611 and the maximum is 0.1363, at 22:16067208:C:G, where the East-Asian super-population frequency (0.90) is double the admixed-American frequency (0.45). The ranking of the most-differentiated variants agrees with the direction of the IGSR whole-cohort FST-like column even though the panel values are inflated by the ten-per-group sample size, which is the expected behavior of a differentiation statistic on small groups. The study also exercises the release-governance suppression rule: group-level count and frequency fields are withheld whenever a group has fewer than ten samples, which suppressed 624 small-cell group rows across the panel. The full twenty-four-variant panel is given in Appendix D, Table 16. This is the paper's clearest demonstration that a governed encrypted aggregate can carry a genuine population-structure signal while still applying small-cell output governance.

11.3 Release-policy and the differencing attack on real genotypes (E7)

The third study is the security headline: it moves the K-versus-K+1 differencing attack of Sections 6 and 9.3.1 from a synthetic cohort onto real public genotypes, and then measures which release controls actually remove it. A frozen public cohort of N=25 is compared against an adjacent N=24 cohort (one held-out sample) over 40 complete-call biallelic SNPs; the held-out sample carries a nonzero alternate dosage at 6 of the 40 positions. Under exact adjacent releases, subtracting the two allele_frequency_count outputs recovers the held-out sample's full dosage vector by construction. Both encrypted aggregates matched the cleartext counts exactly, and the exact-count difference matched the held-out target vector exactly.

Figure 7. Beacon release-policy recovery.

Table 11. E7 release-policy recovery on adjacent public cohorts (N=25 vs N=24, 40 SNPs).

The result is precise about which control does the work. A minimum-N floor helps only when it actually blocks the adjacent release: a floor of 20 is satisfied by both the N=25 and N=24 cohorts and leaves exact recovery at 1.000, whereas a floor of 25 that suppresses the N=24 base, or a single-release cohort freeze, drives recovery to 0.000. A query budget degrades the attack gracefully rather than blocking it — the recovery rate is exactly the fraction of the 40 positions the budget lets the attacker probe.

Table 12. E7 query-budget recovery curve.

Rounding counts to the nearest five is instructive as a negative control: it drops exact-vector recovery to a nonzero rate of 0.000, but exact-position recovery stays at 0.850, so the released counts still leak approximate information — coarsening is not the same as governance. The overall lesson is the one the paper's threat model predicts: these are release-governance controls, not cryptographic features, and cohort freeze plus query accounting — not a minimum-N floor alone — are what remove the leak. The held-out sample is a public reference genotype and its individual dosage trace is never published; it is kept under ignored work/ and identified only by a committed SHA-256.

11.4 Linkage-disequilibrium window (E8, draft application)

The fourth study exercises the draft genotype_pair_ld application, a third multiplication-supporting example in which the hosted worker derives an encrypted genotype-by-genotype product for adjacent-variant pairs and releases the aggregate moments sum_a, sum_b, sum_a2, sum_b2, sum_ab. Over 25 public samples and 11 adjacent variant pairs in 22:16050000-16900000, the decrypted product moments matched the cleartext oracle exactly for all five moment vectors, and covariance and r2 were computed from those moments after decryption.

Figure 8. Top adjacent-pair LD r2.

Table 13. E8 adjacent-pair LD on public genotypes (draft genotype_pair_ld, 25 samples).

† Small-count artifact: both variants carry only three alternate alleles across the 25 samples and those alleles perfectly co-occur, so the perfect r2 is spurious small-panel LD, not a population-scale signal.

The strongest signal, pair 4 with r2 = 1.0000, is honestly a small-count artifact: both variants carry only three alternate alleles across the 25 samples and those alleles perfectly co-occur, which is exactly the kind of spurious perfect-LD pair a small panel produces and a real LD reference panel would not report. The value of E8 is not the LD estimates but the compute path: it shows the encrypted-product tier running end-to-end on real genotypes with bit-exact moments. Consistent with that framing, this is a below-quorum correctness demonstration — it ran on 25 samples while the genotype_pair_ld manifest declares a floor of min_contributors: 30, so under production governance this cohort would be blocked by the minimum-N gate (Sections 6 and 9.3.3). The manifest floor is deliberately left at 30 rather than lowered to match the demonstration, and genotype_pair_ld is intentionally excluded from the six curated, signed, registry applications and from the frozen synthetic taxonomy of Section 10.

12. Previous Work and Novelty

The Blind Machine sits at the intersection of encrypted computation, verifiability, reproducible artifacts, and release governance. The related work therefore has two jobs: identify the substrate the system builds on, and show why the paper's contribution belongs at the governed artifact layer.

BFV, the homomorphic-encryption security standard, TenSEAL, and Microsoft SEAL provide the implementation substrate [R1-R5]. The system contribution begins where that substrate is packaged: the cryptographic environment is locked inside a signed application bundle whose digest is reused through governance and verification.

Secure genomic and biomedical computation is a mature adjacent field. HE-GWAS, TrustGWAS, SF-GWAS, MPC GWAS, FAMHE, HEPRS, PRISM, HEALER, private-genome HE, SQuID, SIG-DB, Sequre, sPLINK, sfkit, and related secure/federated systems show that encrypted, multiparty, database-oriented, and federated biomedical workflows are practical [R6-R21]. The Blind Machine addresses a different unit of trust: the approved computation artifact, its committed cohort, its release policy, its certificate, and its replayable evidence.

Verifiability and reproducibility are separate traditions. Non-interactive verifiable computation, verifiable encodings for homomorphic analytics, and GWAS outcome-verification work address ways to check outsourced computation [R22-R26]. Provenance and reproducible environment systems such as ReproZip and Nix show how computational artifacts can be pinned and replayed [R31, R32]. OCI image descriptors and bioinformatics registries provide useful artifact and distribution precedents [R33, R34]. The Blind Machine draws from this systems lineage. Its certificate is a practical record that binds computation, cohort, result, and release policy.

Output privacy has its own literature and cannot be reduced to encryption. Homer-style mixture membership inference, Beacon privacy attacks, statistical database reconstruction, and NIST differential-privacy guidance all point to the same design requirement: input confidentiality and release privacy need separate controls [R27-R30]. The Blind Machine's freeze, min-N, run caps, and certificate-bound policy facts are the v1 release-governance layer, and Section 11 measures on real public genotypes which of these controls actually removes a differencing leak; formal privacy budgets belong to the next layer.

Table 14. Prior-work and novelty positioning.

The difference is the unit of integration. Prior work supplies primitives, protocols, and reproducibility tools; The Blind Machine turns an approved encrypted computation into a reusable application artifact that carries the same end-to-end governance and verification workflow across tasks.

13. Discussion

The main result is architectural. Encrypted computation becomes easier to audit when it is treated as an end-to-end application workflow rather than as an opaque server feature. Local key custody, signed code, cohort commitment, release gates, content-addressed artifacts, sandboxed execution, certificates, scoped re-execution, and simulation form one loop.

The application boundary also makes the system repurposable. The platform does not hard-code allele frequency, carrier count, histogram, public-weighted score, variance, or covariance as special cases. Each is an application that brings its own local roles, server compute stage, schema, environment, and release rules. A seventh, draft application for adjacent-variant linkage disequilibrium reuses the same loop with a third multiplication-supporting example. Future encrypted aggregate tasks can use the same surrounding platform if they can be expressed as reviewed applications.

The open-client and closed-hosted-service split is compatible with a Kerckhoffs-style argument only because secrecy-critical operations happen locally. Reviewers can inspect the local client, application bundle, cryptographic library choices, certificate schema, and verification path. The proprietary hosted service coordinates the workflow; it is not part of the raw-data confidentiality boundary under the intended protocol.

Output privacy is the largest residual risk. The K-vs-K+1 demonstration shows that an aggregate can reveal an individual when the query pattern is unsafe, and the public-data replication shows that a minimum-N floor alone does not close it. Minimum cohort size and run caps make some unsafe releases harder, while global release governance and differential privacy are the appropriate next layer when an application can tolerate them.

Verification depends on artifact access. Synthetic paper artifacts can be public and reproducible. Real private-cohort artifacts are different: in a single-keyholder design, individual ciphertexts become sensitive if combined with the project secret key. "Scoped artifact re-execution" names that boundary, and the certificate is explicit about what it does and does not prove.

The BFV tier result has a practical engineering meaning. Additive BFV suffices whenever the encrypted computation is addition, addition plus public-scalar multiplication, or addition over values that each contributor can precompute locally before encryption. Multiplication-supporting BFV is justified when the server must derive a product under encryption, either for integrity, payload minimality, or future cross-party computation. This is a measured decision rule for the v1 catalog.

14. Open Questions and Future Directions

The first open question is private-cohort verifiability. The current design gives public readers certificate and hash verification, gives everyone full re-execution for synthetic or intentionally public artifacts, and limits private real-cohort re-execution to authorized workflows. Future versions should make these verifier roles explicit in the product and certificate policy.

The second direction is threshold or multi-key FHE. V1 has a single keyholder. That is simple and usable, but it means one party can decrypt any ciphertext under the project public context if the ciphertext is disclosed. Multiparty or multi-key designs can reduce this trust assumption, as shown by prior systems [R8, R11, R13, R21], but they change setup, recovery, availability, and institutional responsibility.

The third direction is stronger verifiable computation. A future system could prove that the encrypted result was obtained by evaluating the committed application on the committed cohort, possibly without revealing individual ciphertexts or relying on artifact re-execution. Verifiable computation and HE-verification work provide the relevant research context [R22-R26], and a public explainer contrasts the current re-execution surface with SNARK/STARK proof-carrying computation.

The fourth direction is formal release privacy. Per-project freeze, min-N, and run caps leave overlapping cohorts, repeated related studies, and outlier aggregates as higher-level release risks. The real-data beacon study (Section 11, Table 12) shows that a query budget already changes the recovery rate measurably; a stronger platform needs global query budgets, cohort-overlap accounting, and differential privacy where appropriate [R29, R30].

The fifth direction is transparency and authenticity. Append-only logs could publish application digests, public-context digests, cohort commitments, certificate hashes, release-policy states, and verifier-access events without publishing individual ciphertexts. Stronger contributor authentication and context authentication would reduce Sybil and substitution risks. These are systems controls, but they matter because governance is part of the security boundary.

Hybrid designs are also possible. MPC or HE-MPC hybrids can reduce reliance on a single decryptor. TEEs might support scoped private re-execution, but they add hardware trust and side-channel assumptions. These alternatives should be evaluated as changes to the trust model rather than as simple upgrades.

15. Conclusion

The Blind Machine presents a reusable, certificate-producing workflow around standard encrypted computation. Plaintext data and secret keys stay local; the hosted service coordinates cohorts and computes on ciphertext; the certificate binds the approved application, public context, committed cohort, encrypted result, and release-policy facts, and states plainly what it does and does not prove.

The current evaluation supports a precise empirical claim. Six BFV applications match plaintext simulation exactly on seeded synthetic inputs. Four fit additive BFV and two use multiplication-supporting BFV, with 5x and 10x payload premiums at the current 128-bit artifact setting. The differencing demonstration, reproduced on public IGSR/1000 Genomes data, shows why output governance must accompany encrypted compute — and that a minimum-N floor alone does not close the leak while cohort freeze and query budgets do.

The useful unit is not only a cryptographic operation but an approved application run: inspectable before encryption, executable over ciphertext, certified after execution, and reproducible when artifacts are disclosed or authorized. That model can be repurposed for new encrypted aggregate computations without pooling sensitive raw data.

Appendix A. Figures and Tables

Appendix B. Reproducibility Notes

The Blind Machine is designed so that a reader can reproduce every result in this paper and independently verify any computation, using only open components: the open-source Blind CLI, the open signed application bundles, and the public experiment scripts. None of this requires the hosted service or any private data.

Getting the tools. The prerequisites are Python 3.11+ and uv (https://docs.astral.sh/uv/), the toolchain the application bundles seal their environments with. The Blind CLI is open source at https://github.com/blindmachine/blind-cli and is invoked as blind (for example, uv run blind from the CLI directory); the six curated applications are open and browsable at https://blindmachine.org/applications/. On first run the harness seals each application environment once — downloading TenSEAL over Microsoft SEAL — and reuses it thereafter.

Reproduce the synthetic evaluation (Section 10) with no network and no real data, in about ninety seconds:

cd docs/paper/experiments
bash run_all.sh                           # regenerate Tables 5-7 and assert invariants
python3 docs/paper/experiments/verify.py  # re-check machine-independent invariants only

Reproduce the real-genome studies (Section 11), which fetch only the bounded public IGSR intervals they need and commit aggregate-only outputs:

cd docs/paper/experiments
bash e5_real_human_dna_igsr.sh            # Table 9
bash e6_public_af_fst_panel.sh            # Tables 10, 16
bash e7_beacon_release_policy.sh          # Tables 11, 12
bash e8_public_ld_window.sh               # Table 13
python3 summarize_public_real_dna.py      # rebuild Table 8 and Figures 6-8

Verify a computation you did not run. The CLI re-checks any Computation Certificate offline (blind certificates verify), installs and verifies a signed application against its digest and signature before use (blind applications install), and prints a readable account of what an application computes (blind explain). For synthetic or intentionally public cohorts, the committed ciphertext artifacts let anyone re-execute the computation and confirm the result digest; for private cohorts, re-execution is limited to authorized parties, and a public reader still verifies the certificate and public digests.

Agent-driven replication and review. This paper and its reproduction workflow are also published as agent-executable surfaces, so a reader can delegate the whole process to an AI agent. The manuscript is hosted at https://blindmachine.org/papers/the-blind-machine; the replication skill at https://blindmachine.org/skills/replicate is a self-contained recipe an agent fetches and runs to install the tools, rerun the synthetic and real-genome experiments, and diff its outputs against our committed results; and the review skill at https://blindmachine.org/skills/review guides an agent through an independent, evidence-checked review of the manuscript. Both skills follow the repository's shared skill template and are listed at https://blindmachine.org/skills and in /llms.txt.

verify.py asserts only machine-independent invariants and exits non-zero on any regression. It asserts bit-exactness (max_error == 0), the two-tier taxonomy, the payload-premium ordering, the differencing recovery, and equality of the deterministic columns against the committed reference values under results/expected/, so the cited absolute byte counts are asserted invariants and not merely documentation. Wall-clock, RAM, and cost are recorded but never asserted, because they vary by hardware.

The public synthetic-evidence package for the current draft is:

https://blindmachine.org/verify/paper/bfv-v1

Package hash:

1c329eeb1c705d6c81f47dc6bd1b741fa6aae0963c4a7c78b9ca511c40dfb030

The final release package should include the exact source tag, application bundle digests, certificate schema version, verifier version, seeds, coordinate definitions, artifact SHA-256s, hardware/runtime environment, and a clean run transcript. The package hash must be re-verified against a clean tagged checkout and footnoted with its source commit or tag before circulation; a working-tree hash is not citable. Timing, RAM, CPU, and cost claims should be rerun on a pinned benchmark machine before camera-ready submission.

Appendix C. Writing an Application

An application is the plug-in unit that lets the platform run a new encrypted aggregate without changing the surrounding governance loop. The author supplies the computation-specific pieces: a manifest, local role functions, one server compute function, a locked Python environment, support documentation, and tests. The platform supplies the registry, content addressing, signing, shimmed stage lifecycle, local CLI execution, hosted sandbox, cohort freeze, certificates, and verification surfaces.

The paper-facing documentation page for this contract is https://blindmachine.org/application-structure, and every curated application is browsable at https://blindmachine.org/applications/ (the six v1 applications are listed with their computations in Section 5). Each application page lets readers inspect real signed-payload boundaries, README files, version metadata, digests, and browser-readable source trees. The draft genotype_pair_ld application is not yet a hosted, signed, curated application and is therefore intentionally absent from this registry list.

The current v1 contract is intentionally small. The signed payload contains only manifest.yml, server.py, local_project_owner.py, local_data_owner.py, and signed/env/. Root-level README.md, SECURITY.md, optional benchmark notes, and tests/ are public support artifacts but do not enter the application digest. The six numbered lifecycle scripts are kit-owned shims. They are materialized by the CLI or worker at run time and call the author's pure functions.

Figure 5. Application authoring and execution loop.

The diagram traces the author's signed payload through registry ingest, local project-owner and data-owner roles, hosted governance and sandboxed worker execution, and result-and-verification, showing where each numbered shim is materialized at run time around the author's pure functions.

Table 15. Application bundle surfaces and how they plug into the loop.

This structure is why the application layer is reusable. To add a new encrypted aggregate, the author changes the signed manifest, local role functions, server function, environment lock, and support tests. The project model, cohort commitment, run dispatch, worker stages, sandbox policy, certificate schema, and offline verifier remain the surrounding loop. The scientific review question therefore becomes concrete: does this signed bundle encode the right inputs, compute only the approved ciphertext function, release the intended aggregate, and pass the declared local-loop and encrypted-loop tests?

Appendix D. Extended Real-Data Tables

This appendix holds the full per-variant listing behind the summarized real-data studies of Section 11. The study design, data provenance, validation, and interpretation boundary are stated in Section 11 and are not repeated here; these tables are aggregate-only and are derived entirely from the committed results/ outputs of each study. The full E5 allele-frequency panel (Table 9) and the full E8 linkage-disequilibrium window (Table 13) already appear in Section 11; only the E6 cross-population panel is abridged there (to its eight most-differentiated variants, Table 10) and is given in full below. The Section 11 real-data figures (Figures 6-8) and the study summary tables are regenerated by python3 docs/paper/experiments/summarize_public_real_dna.py.

Table 16. E6 full cross-population differentiation panel (50 public samples, 24 SNPs, 5 super-populations).

Across the twenty-four variants the panel mean F_ST-like value is 0.0611 and the maximum is 0.1363; the mean absolute deviation of the panel allele frequency from the IGSR global frequency is 0.0311. Group-level count and frequency fields are withheld whenever a super-population or population group has fewer than ten samples, which suppressed 624 small-cell group rows across the panel. The eight most-differentiated variants are reproduced in Section 11, Table 10, and the decrypted panel counts and second moments matched the cleartext oracle exactly for all twenty-four variants.

References

[R1] Z. Brakerski. "Fully Homomorphic Encryption without Modulus Switching from Classical GapSVP." CRYPTO/IACR ePrint, 2012. https://eprint.iacr.org/2012/078

[R2] J. Fan and F. Vercauteren. "Somewhat Practical Fully Homomorphic Encryption." IACR ePrint, 2012. https://eprint.iacr.org/2012/144

[R3] M. Albrecht et al. "Homomorphic Encryption Security Standard." HomomorphicEncryption.org/IACR ePrint, 2018/2019. https://homomorphicencryption.org/security-guidelines/

[R4] A. Benaissa, B. Retiat, B. Cebere, and A. E. Belfedhal. "TenSEAL: A Library for Encrypted Tensor Operations Using Homomorphic Encryption." arXiv, 2021. https://arxiv.org/abs/2104.03152

[R5] Microsoft Research. "Microsoft SEAL." https://github.com/microsoft/SEAL

[R6] M. Blatt, A. Gusev, Y. Polyakov, and S. Goldwasser. "Secure large-scale genome-wide association studies using homomorphic encryption." PNAS, 2020. https://www.pnas.org/doi/10.1073/pnas.1918257117

[R7] J. Blindenbach, J. Kang, S. Hong, C. Karam, T. Lehner, and G. Gursoy. "SQUiD: ultra-secure storage and analysis of genetic data for the advancement of precision medicine." Genome Biology, 2024. https://link.springer.com/article/10.1186/s13059-024-03447-9

[R8] M. Yang et al. "TrustGWAS: A full-process workflow for encrypted GWAS using multi-key homomorphic encryption and pseudorandom number perturbation." Cell Systems, 2022. https://www.sciencedirect.com/science/article/pii/S2405471222003143

[R9] H. Cho, D. Froelicher, J. Chen, M. Edupalli, A. Pyrgelis, J. R. Troncoso-Pastoriza, J.-P. Hubaux, and B. Berger. "Secure and federated genome-wide association studies for biobank-scale datasets." Nature Genetics, 2025. https://www.nature.com/articles/s41588-025-02109-1

[R10] K. Cho, D. J. Wu, and B. Berger. "Secure genome-wide association analysis using multiparty computation." Nature Biotechnology, 2018. https://doi.org/10.1038/nbt.4108

[R11] D. Froelicher et al. "Truly privacy-preserving federated analytics for precision medicine with multiparty homomorphic encryption." Nature Communications,

1. https://www.nature.com/articles/s41467-021-25972-y

[R12] E. Knight, J. Li, M. Jensen, I. Yolou, C. Kockan, and M. Gerstein. "Homomorphic encryption enables privacy preserving polygenic risk scores." Cell Reports Methods, 2026. https://www.cell.com/cell-reports-methods/fulltext/S2667-2375(25)00307-8

[R13] G. Akkaya et al. "PRISM: privacy-preserving rare disease analysis using fully homomorphic encryption." Bioinformatics, 2025. https://academic.oup.com/bioinformatics/article/41/10/btaf468/8240325

[R14] S. Wang et al. "HEALER: homomorphic computation of ExAct Logistic rEgRession for secure rare disease variants analysis in GWAS." Bioinformatics, 2016. https://academic.oup.com/bioinformatics/article/32/2/211/1744166

[R15] M. Kim and K. Lauter. "Private genome analysis through homomorphic encryption." BMC Medical Informatics and Decision Making, 2015. https://link.springer.com/article/10.1186/1472-6947-15-S5-S3

[R16] A. J. Titus et al. "SIG-DB: Leveraging homomorphic encryption to securely interrogate privately held genomic databases." PLOS Computational Biology, 2018. https://doi.org/10.1371/journal.pcbi.1006454

[R17] H. Smajlovic, A. Shajii, B. Berger, H. Cho, and I. Numanagic. "Sequre: a high-performance framework for secure multiparty computation enables biomedical data sharing." Genome Biology, 2023. https://link.springer.com/article/10.1186/s13059-022-02841-5

[R18] A. Nasirigerdeh et al. "sPLINK: a hybrid federated tool as a robust alternative to meta-analysis in genome-wide association studies." Genome Biology,

1. https://link.springer.com/article/10.1186/s13059-021-02562-1

[R19] S. Mendelsohn et al. "sfkit: a web-based toolkit for secure and federated genomic analysis." Nucleic Acids Research, 2023. https://academic.oup.com/nar/article/51/W1/W535/7184156

[R20] W. Zhou et al. "Secure bioinformatics: privacy-preserving federated analytics using homomorphic encryption." Bioinformatics, 2026. https://academic.oup.com/bioinformatics/article/42/5/btag081/8493202

[R21] M. Namazi, M. Farahpoor, E. Ayday, and F. Perez-Gonzalez. "Privacy-preserving framework for genomic computations via multi-key homomorphic encryption." Bioinformatics, 2025. https://academic.oup.com/bioinformatics/article/41/3/btae754/7994464

[R22] R. Gennaro, C. Gentry, and B. Parno. "Non-Interactive Verifiable Computing: Outsourcing Computation to Untrusted Workers." CRYPTO, 2010. https://link.springer.com/chapter/10.1007/978-3-642-14623-7_25

[R23] S. Chatel, C. Knabenhans, A. Pyrgelis, C. Troncoso, and J.-P. Hubaux. "Verifiable Encodings for Secure Homomorphic Analytics." arXiv, 2022. https://arxiv.org/abs/2207.14071

[R24] X. Wang, Y. Jiang, and J. Vaidya. "Efficient verification for outsourced genome-wide association studies." Journal of Biomedical Informatics, 2021. https://www.sciencedirect.com/science/article/pii/S1532046421000435

[R25] A. Halimi et al. "Privacy-Preserving and Efficient Verification of the Outcome in Genome-Wide Association Studies." Proceedings on Privacy Enhancing Technologies,

1. https://pmc.ncbi.nlm.nih.gov/articles/PMC9536480/

[R26] Y. Jiang, T. Ji, and E. Ayday. "PROVGEN: A Privacy-Preserving Approach for Outcome Validation in Genomic Research." PoPETs, 2026. https://petsymposium.org/popets/2026/popets-2026-0064.php

[R27] N. Homer et al. "Resolving Individuals Contributing Trace Amounts of DNA to Highly Complex Mixtures Using High-Density SNP Genotyping Microarrays." PLOS Genetics, 2008. https://journals.plos.org/plosgenetics/article?id=10.1371/journal.pgen.1000167

[R28] S. S. Shringarpure and C. D. Bustamante. "Privacy Risks from Genomic Data-Sharing Beacons." American Journal of Human Genetics, 2015. https://www.sciencedirect.com/science/article/pii/S0002929715003742

[R29] I. Dinur and K. Nissim. "Revealing information while preserving privacy." PODS, 2003. https://doi.org/10.1145/773153.773173

[R30] J. P. Near, D. Darais, N. Lefkovitz, and G. S. Howarth. "Guidelines for Evaluating Differential Privacy Guarantees." NIST SP 800-226, 2025. https://csrc.nist.gov/pubs/sp/800/226/final

[R31] F. Chirigati, D. Shasha, and J. Freire. "Using Provenance to Support Computational Reproducibility." TaPP, 2013. https://www.usenix.org/conference/tapp13/technical-sessions/presentation/chirigati

[R32] E. Dolstra, M. de Jonge, and E. Visser. "Nix: A Safe and Policy-Free System for Software Deployment." LISA, 2004. https://nixos.org/research/

[R33] Open Container Initiative. "Image Descriptor Specification." https://github.com/opencontainers/image-spec/blob/main/descriptor.md

[R34] Bioconductor. "Open source software for bioinformatics." https://www.bioconductor.org/

[R35] 1000 Genomes Project Consortium (A. Auton et al.). "A global reference for human genetic variation." Nature, 526:68-74, 2015. https://doi.org/10.1038/nature15393

[R36] S. Fairley, E. Lowy-Gallego, E. Perry, and P. Flicek. "The International Genome Sample Resource (IGSR) collection of open human genomic variation resources." Nucleic Acids Research, 48:D941-D947, 2020. https://doi.org/10.1093/nar/gkz836

[R37] B. S. Weir and C. C. Cockerham. "Estimating F-Statistics for the Analysis of Population Structure." Evolution, 38(6):1358-1370, 1984. https://doi.org/10.2307/2408641