---
title: "The Blind Machine: Governed Computation on Encrypted Data with Certificate-Bound, Reproducible Verification"
slug: the-blind-machine
authors: The Blind Machine
date: 2026-07-09
venue: Preprint
summary: A platform for governed computation on encrypted data with certificate-bound, reproducible verification, evaluated on six BFV applications and four studies on real public human genomes. Every experiment is independently replicable from an open command-line client.
replicate_skill: replicate
review_skill: review
---

## 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.**

| Invariant | Meaning | Enforced by |
| --- | --- | --- |
| Plaintext stays local | Raw data is encoded and encrypted locally before upload | Blind CLI local stages; no plaintext server upload path in the intended protocol |
| Secret key stays local | Key generation and decryption happen locally | Blind CLI; no secret-key field in server job specs or certificate schema |
| Server-side compute is ciphertext-only | The hosted run phase receives public context and ciphertexts | Application bundle contract; worker job spec; sandbox staging |
| Computation requires cohort commitment | The accepted encrypted cohort is frozen before execution | Commitment over sorted ciphertext digests, project id, and application digest |
| Governance gates precede execution | Under-quorum or over-query runs are blocked before compute | Minimum contributor gate, run cap, release policy, dispatch checks |
| Immutable artifacts are content-addressed | Code, public context, cohort, result, and certificates are named by hashes | SHA-256 digests and certificate binding |
| Computation code is public, pinned, and signed | Contributors and reviewers can inspect what will run | Application bundle digest and signature verification |
| Results are certifiable | A completed run produces a machine-verifiable record | Certificate schema and offline verifier |
| Re-execution is scoped by artifact access | Integrity can be checked when the frozen artifacts are disclosed or authorized | Reference worker and deterministic BFV execution |
| Individual ciphertexts are not publicly released | The v1 secret key can decrypt any project ciphertext | Aggregate-only release; no arbitrary contribution-ciphertext download surface |

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.**

Rendered figure source: `docs/paper/figures/figure-1-trust-zones.tex`. 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.**

Rendered figure source: `docs/paper/figures/figure-2-output-governance.tex`. 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.**

Rendered figure source: `docs/paper/figures/figure-3-certificate-binding.tex`.
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`).**

| Field | Purpose |
| --- | --- |
| `application_digest` | Names the approved signed application bundle |
| `public_context_digest` | Names the public encryption context contributors used |
| `project_id` | Names the project the run belongs to |
| `computation_run_id` | Names the specific computation run |
| `cohort_commitment` | Binds the frozen encrypted cohort |
| `cohort_size` | Records the included contributor count |
| `result_digest` | Names the encrypted result artifact |
| `min_contributors` | Records the application release floor |
| `min_n_satisfied` | Records whether the release floor was met |
| `run_count` | Records the run-control state |
| `release_policy` | Records release rules such as aggregate-only release |

`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.**

| Property | Trusted components | Outside that trust boundary | Boundary |
| --- | --- | --- | --- |
| Raw-data confidentiality from hosted service | Local CLI, local runtime, cryptographic library, user's device | Hosted service | Fails if local client is compromised or key is uploaded |
| Computation integrity | Signed bundle, digest checks, certificate schema, verifier, reference worker when artifacts are available | Hosted service | Full integrity requires artifact access or stronger proofs |
| Release governance | Hosted dispatch gates, certificate fields, application policy, audit artifacts | Cryptography alone | Mitigates output leakage; DP is a future release layer |
| Output privacy | Release policy, min-N, run caps, future DP/query budgets | HE alone | Decrypted aggregates can leak |
| Availability | Hosted service and operational infrastructure | Cryptographic checks | DoS is detectable; availability is operational |

## 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.**

| Threat | Covered by | Status |
| --- | --- | --- |
| Hosted service reads plaintext | Local encryption; ciphertext-only server role | Prevented under local-client trust assumption |
| Hosted service obtains secret key | Local key custody; no secret-key server/certificate field | Prevented under local-client trust assumption |
| Public context substitution | Context digest pinning; certificate binding | Prevented only when contributors authenticate the context digest |
| Malicious application exfiltrates local data | Public reviewed signed bundles; CLI digest verification | Mitigated by review and signing; local sandboxing and static checks are future work |
| Tampered application bundle | Digest and signature verification | Detectable unless signing key compromised |
| Cohort substitution | Cohort commitment | Detectable; recomputable when manifest is available |
| Dropped or corrupted contribution | Contribution digests and application checks | Detectable for supported checks; identity remains separate |
| Fabricated result | Certificate plus scoped re-execution | Detectable when artifacts are disclosed or authorized |
| Governance bypass | Dispatch gates and certificate fields | Detectable; service can still deny service |
| K-vs-K+1 differencing | Freeze, min-N, run caps; query budget | Mitigated; reproduced on real public data (Section 11) |
| Overlapping-cohort differencing | Per-project governance | Residual v1 release risk |
| Small-cohort or outlier output leakage | Min-N and application review | Mitigated; DP is the stronger release layer |
| Metadata leakage | Limited v1 controls | Residual v1 privacy risk |
| Malicious keyholder misuses decryption | Aggregate-only release and governance | Residual v1 trust risk |
| Server-keyholder or verifier-keyholder collusion | Separation of key custody from individual ciphertext access | Out-of-scope assumption boundary |
| Contributor Sybil or poisoning | Shape checks and digest binding | Residual v1 authenticity risk |
| Sandbox escape or runtime exfiltration | Network-disabled, resource-limited sandbox | Mitigated |
| Denial of service | Detection and possible rerun when artifacts are available | Residual operational availability risk |
| Replay or stale artifact use | Certificate hashes and issuance metadata | Detectable with proper artifact records |

### 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.**

Rendered figure source: `docs/paper/figures/figure-4-bfv-correctness.tex`. 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.**

| Application | Tier | Crypto | N | Length | Security | Ciphertext bytes/contribution | Compute ms | Max error | Exact |
| --- | --- | --- | ---: | ---: | ---: | ---: | ---: | ---: | --- |
| `allele_frequency_count` | additive-BFV-exact | bfv-add | 20 | 10 | 128 | 262,282 | 272 | 0 | yes |
| `carrier_count` | additive-BFV-exact | bfv-add | 20 | 10 | 128 | 262,282 | 219 | 0 | yes |
| `cohort_histogram` | additive-BFV-exact | bfv-add | 20 | 10 | 128 | 262,282 | 242 | 0 | yes |
| `polygenic_score_aggregate` | additive-BFV-exact | bfv-add | 20 | 10 | 128 | 262,282 | 194 | 0 | yes |
| `allele_frequency_with_variance` | mult-supporting-BFV-exact | bfv-mul | 20 | 10 | 128 | 1,310,882 | 789 | 0 | yes |
| `genotype_phenotype_covariance` | mult-supporting-BFV-exact | bfv-mul | 20 | 10 | 128 | 2,621,791 | 1,284 | 0 | yes |

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.**

| Arm | Ciphertext bytes/contribution | Premium vs additive |
| --- | ---: | ---: |
| additive (`allele_frequency_count`) | 262,282 | 1.0x |
| multiplicative (`allele_frequency_with_variance`) | 1,310,882 | 5.0x |
| multiplicative (`genotype_phenotype_covariance`) | 2,621,791 | 10.0x |

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.**

| Application | Crypto | 128-bit | 192-bit | 256-bit | Exact across levels |
| --- | --- | ---: | ---: | ---: | --- |
| `allele_frequency_count` | bfv-add | 262,282 | 235,708 | 220,294 | yes |
| `carrier_count` | bfv-add | 262,282 | 235,725 | 220,326 | yes |
| `cohort_histogram` | bfv-add | 262,282 | 235,706 | 220,324 | yes |
| `polygenic_score_aggregate` | bfv-add | 262,282 | 235,719 | 220,322 | yes |
| `allele_frequency_with_variance` | bfv-mul | 1,310,882 | 786,582 | 657,718 | yes |
| `genotype_phenotype_covariance` | bfv-mul | 2,621,791 | 1,573,191 | 1,315,325 | yes |

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:

```bash
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:

```bash
python3 docs/paper/experiments/verify.py
```

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

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

The draft package hash is:

```text
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 F_ST-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/:certificate_hash` status 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.** Rendered figure source:
`docs/paper/experiments/public_real_dna_summary_2026_07_09/results/figure_public_real_dna_scope.svg`.
The figure summarizes sample, variant, query, and pair counts across the four
studies.

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

| Study | Region (chr22) | Samples | Variants / pairs | Application(s) | Headline result | Evidence page |
| --- | --- | ---: | ---: | --- | --- | --- |
| E5 Allele-frequency panel | 16.05-17.00 Mb | 10 | 12 SNPs | `allele_frequency_count`; `allele_frequency_with_variance` | exact first/second moments; mean absolute AF delta vs IGSR global 0.0609 | (local) |
| E6 Cross-population differentiation | 16.05-17.00 Mb | 50 | 24 SNPs | `allele_frequency_count`; `allele_frequency_with_variance` | max F_ST-like 0.1363; 624 small-cell rows suppressed; exact moments | `/verify/paper/public-genomics-e6-af-fst` |
| E7 Release-policy differencing | 16.05-17.25 Mb | 25 vs 24 | 40 SNPs | `allele_frequency_count` + release-policy harness | min-N alone leaves recovery 1.000; freeze / query budget drive it to 0.000 / 0.125 | `/verify/paper/public-genomics-e7-beacon-policy` |
| E8 LD window (draft) | 16.05-16.90 Mb | 25 | 11 pairs | `genotype_pair_ld` (draft) | exact product moments; max `r2` 1.0000 | `/verify/paper/public-genomics-e8-ld-window` |

### 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).**

| # | Coordinate | Alt count | Panel AF | IGSR global AF | Abs Δ | Heterozygote rate | Hom-alt rate |
| ---: | --- | ---: | ---: | ---: | ---: | ---: | ---: |
| 1 | `22:16051249:T:C` | 4 | 0.2000 | 0.1124 | 0.0876 | 0.40 | 0.00 |
| 2 | `22:16052080:G:A` | 3 | 0.1500 | 0.1412 | 0.0088 | 0.30 | 0.00 |
| 3 | `22:16052962:C:T` | 3 | 0.1500 | 0.0938 | 0.0562 | 0.30 | 0.00 |
| 4 | `22:16052986:C:A` | 1 | 0.0500 | 0.0741 | 0.0241 | 0.10 | 0.00 |
| 5 | `22:16053444:A:T` | 1 | 0.0500 | 0.0719 | 0.0219 | 0.10 | 0.00 |
| 6 | `22:16053659:A:C` | 15 | 0.7500 | 0.8576 | 0.1076 | 0.50 | 0.50 |
| 7 | `22:16053791:C:A` | 5 | 0.2500 | 0.1659 | 0.0841 | 0.30 | 0.10 |
| 8 | `22:16053862:C:T` | 4 | 0.2000 | 0.1146 | 0.0854 | 0.40 | 0.00 |
| 9 | `22:16053863:G:A` | 3 | 0.1500 | 0.1404 | 0.0096 | 0.30 | 0.00 |
| 10 | `22:16054454:C:T` | 4 | 0.2000 | 0.1158 | 0.0842 | 0.40 | 0.00 |
| 11 | `22:16054740:A:G` | 7 | 0.3500 | 0.4956 | 0.1456 | 0.30 | 0.20 |
| 12 | `22:16055070:G:A` | 3 | 0.1500 | 0.1348 | 0.0152 | 0.30 | 0.00 |

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 F_ST-like statistic was computed after
decryption as the equal-weight heterozygosity contrast
`(H_T - mean_s H_S) / H_T` across the five super-populations. This is a simplified
stand-in for the standard Weir-Cockerham F_ST 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).**

| # | Coordinate | Panel AF | Max pairwise Δ | Min group | Max group | F_ST-like | IGSR F_ST-like |
| ---: | --- | ---: | ---: | --- | --- | ---: | ---: |
| 19 | `22:16067208:C:G` | 0.6500 | 0.4500 | AMR 0.4500 | EAS 0.9000 | 0.1363 | 0.0604 |
| 2 | `22:16052080:G:A` | 0.1600 | 0.3000 | AFR 0.0500 | EAS 0.3500 | 0.1071 | 0.0440 |
| 8 | `22:16055070:G:A` | 0.1500 | 0.3000 | AFR 0.0500 | EAS 0.3500 | 0.1020 | 0.0475 |
| 4 | `22:16053659:A:C` | 0.8000 | 0.3000 | EUR 0.6500 | AFR 0.9500 | 0.1000 | 0.0371 |
| 22 | `22:16069141:C:G` | 0.6600 | 0.4000 | AMR 0.5000 | EAS 0.9000 | 0.0998 | 0.0640 |
| 17 | `22:16063369:C:T` | 0.1100 | 0.2500 | EUR 0.0000 | SAS 0.2500 | 0.0960 | 0.0712 |
| 1 | `22:16051249:T:C` | 0.1200 | 0.2500 | AFR 0.0000 | SAS 0.2500 | 0.0814 | 0.0766 |
| 20 | `22:16067411:T:C` | 0.1300 | 0.2500 | AFR 0.0000 | EAS 0.2500 | 0.0760 | 0.0874 |

The panel mean F_ST-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 F_ST-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.** Rendered figure source:
`docs/paper/experiments/public_real_dna_summary_2026_07_09/results/figure_beacon_policy_recovery.svg`.

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

| Release policy | Adjacent releases available | Query budget | Exact vector recovery | Nonzero recovery |
| --- | --- | ---: | ---: | ---: |
| No policy (exact adjacent counts) | yes | 40 | 1.000 | 1.000 |
| Minimum-N = 20 only | yes | 40 | 1.000 | 1.000 |
| Minimum-N = 25 blocks adjacent base | no | 0 | 0.000 | 0.000 |
| Cohort freeze, single release | no | 0 | 0.000 | 0.000 |
| Query budget = 5 | yes | 5 | 0.125 | 0.167 |
| Counts rounded to nearest 5 | yes | 40 | 0.850 | 0.000 |

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.**

| Query budget | Positions compared | Exact positions recovered | Exact recovery rate |
| ---: | ---: | ---: | ---: |
| 0 | 0 | 0 | 0.000 |
| 1 | 1 | 1 | 0.025 |
| 2 | 2 | 2 | 0.050 |
| 3 | 3 | 3 | 0.075 |
| 5 | 5 | 5 | 0.125 |
| 10 | 10 | 10 | 0.250 |
| 20 | 20 | 20 | 0.500 |
| 40 | 40 | 40 | 1.000 |

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`.** Rendered figure source:
`docs/paper/experiments/public_real_dna_summary_2026_07_09/results/figure_ld_top_r2.svg`.

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

| Pair | Coordinate A | Coordinate B | Σa | Σb | Σab | Covariance | `r2` |
| ---: | --- | --- | ---: | ---: | ---: | ---: | ---: |
| 1 | `22:16051249:T:C` | `22:16052080:G:A` | 9 | 5 | 0 | -0.0720 | 0.1406 |
| 2 | `22:16052080:G:A` | `22:16052962:C:T` | 5 | 7 | 0 | -0.0560 | 0.0972 |
| 3 | `22:16052962:C:T` | `22:16052986:C:A` | 7 | 3 | 1 | 0.0064 | 0.0019 |
| 4 | `22:16052986:C:A` | `22:16053444:A:T` | 3 | 3 | 3 | 0.1056 | 1.0000† |
| 5 | `22:16053444:A:T` | `22:16053659:A:C` | 3 | 40 | 6 | 0.0480 | 0.0909 |
| 6 | `22:16053659:A:C` | `22:16053791:C:A` | 40 | 11 | 21 | 0.1360 | 0.1896 |
| 7 | `22:16053791:C:A` | `22:16053862:C:T` | 11 | 9 | 3 | -0.0384 | 0.0157 |
| 8 | `22:16053862:C:T` | `22:16053863:G:A` | 9 | 5 | 0 | -0.0720 | 0.1406 |
| 9 | `22:16053863:G:A` | `22:16054454:C:T` | 5 | 9 | 0 | -0.0720 | 0.1406 |
| 10 | `22:16054454:C:T` | `22:16054740:A:G` | 9 | 21 | 3 | -0.1824 | 0.2702 |
| 11 | `22:16054740:A:G` | `22:16055070:G:A` | 21 | 5 | 7 | 0.1120 | 0.1467 |

† 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.**

| System family | Examples | Computes on encrypted data | Governs cohort/release | Issues certificate | Scoped re-execution | Gap relative to The Blind Machine |
| --- | --- | --- | --- | --- | --- | --- |
| FHE libraries and standards | BFV, HE Standard, TenSEAL, SEAL | yes | no | no | library-level only | Cryptographic substrate, not governed platform |
| Secure/federated biomedical systems | SQuID, FAMHE, SF-GWAS, Sequre, sPLINK, sfkit | yes/varies | varies | rarely | varies | Strong analysis systems, not centered on signed bundles and certificate-bound release |
| Verification work | Verifiable computation, verifiable encodings, GWAS verification | sometimes | no | yes/varies | yes/varies | Verifies computation, not the cohort-governed encrypted release workflow |
| Reproducible artifact systems | ReproZip, Nix, OCI, Bioconductor | no | no | artifact metadata | yes | Reproducible software artifacts without encrypted cohort governance |
| Output privacy controls | DP guidance, genomic leakage literature | no/varies | yes/varies | no/varies | no | Release privacy, not ciphertext execution |
| The Blind Machine | this paper | yes | yes | yes | yes, when artifacts are disclosed or authorized | v1 still has metadata, output leakage, keyholder trust, and private-cohort artifact-access limits |

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

| ID | Title | Location | Source |
| --- | --- | --- | --- |
| Figure 1 | Trust-zone diagram | Section 5 | `figures/figure-1-trust-zones.tex` |
| Figure 2 | Output-leakage governance diagram | Section 6 | `figures/figure-2-output-governance.tex` |
| Figure 3 | Certificate binding diagram | Section 7 | `figures/figure-3-certificate-binding.tex` |
| Figure 4 | BFV correctness experiment | Section 10 | `figures/figure-4-bfv-correctness.tex` |
| Figure 5 | Application authoring and execution loop | Appendix C | `figures/figure-5-application-loop.tex` |
| Figure 6 | Public-data experiment scope | Section 11 | `public_real_dna_summary_2026_07_09/results/figure_public_real_dna_scope.svg` |
| Figure 7 | Beacon release-policy recovery | Section 11 | `public_real_dna_summary_2026_07_09/results/figure_beacon_policy_recovery.svg` |
| Figure 8 | Top adjacent-pair LD `r2` | Section 11 | `public_real_dna_summary_2026_07_09/results/figure_ld_top_r2.svg` |
| Table 1 | Platform invariants | Section 4 | Requirements, domain, application, and certificate docs |
| Table 2 | Certificate payload fields | Section 7 | `ComputationCertificate` canonical payload |
| Table 3 | Trusted computing base by property | Section 8 | Threat model and system docs |
| Table 4 | Threat coverage matrix | Section 9 | Threat model and the Section 9 per-attack catalog |
| Table 5 | BFV exactness taxonomy | Section 10 | `results/table_b_exactness.csv` |
| Table 6 | Payload premium | Section 10 | `results/table_c_premium.csv` |
| Table 7 | Security-level matrix | Section 10 | `results/security_matrix.csv` |
| Table 8 | Real-data studies on public human genomes | Section 11 | `summarize_public_real_dna.py`; IGSR/1000 Genomes Phase 3 |
| Table 9 | E5 per-variant allele frequency and genotype distribution | Section 11 | `real_human_dna_igsr_2026_07_09/results/allele_frequencies.csv`, `genotype_distribution.csv` |
| Table 10 | E6 top cross-population differentiation variants | Section 11 | `public_af_fst_2026_07_09/results/fst_summary.csv` |
| Table 11 | E7 release-policy recovery | Section 11 | `beacon_release_policy_2026_07_09/results/policy_risk_summary.csv` |
| Table 12 | E7 query-budget recovery curve | Section 11 | `beacon_release_policy_2026_07_09/results/query_budget_curve.csv` |
| Table 13 | E8 adjacent-pair LD | Section 11 | `public_ld_window_2026_07_09/results/ld_pairs.csv` |
| Table 14 | Prior-work and novelty positioning | Section 12 | Approved Stage 2 references |
| Table 15 | Application bundle surfaces | Appendix C | Application structure, manifest, worker, CLI, and test files |
| Table 16 | E6 full cross-population differentiation panel | Appendix D | `public_af_fst_2026_07_09/results/fst_summary.csv` |

## 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:

```bash
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:

```bash
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:

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

Package hash:

```text
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.**

Rendered figure source: `docs/paper/figures/figure-5-application-loop.tex`. 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.**

| Surface | Author writes | Platform uses it for | Plug-in boundary |
| --- | --- | --- | --- |
| Manifest | Application name, version, input/output shape, release policy, resources, role mapping, and display crypto hint | Registry listing, governance gates, resource limits, certificate fields, and review surface | Changing a signed manifest byte changes the application digest |
| Local project-owner role | `keygen`, `decrypt`, and `decode` pure functions | Local key generation, local result decryption, and final result interpretation | Secret-bearing operations stay outside the hosted service |
| Local data-owner role | `encode` and `encrypt` pure functions | Contributor-side validation, summarization, and ciphertext creation | Raw inputs are transformed locally before upload |
| Server role | `compute(inputs, public_context) -> bytes` | The only author function run by the hosted worker | The function has no secret-key parameter and receives ciphertexts plus public context |
| Locked environment | `env/pyproject.toml`, `env/uv.lock`, and `.python-version` | Reproducible build, environment sealing, `env_lock` digest, and benchmark provenance | Dependencies are application-owned rather than platform backends |
| Public tests | Vectors, expected aggregates, and local-loop equivalence tests | Review support, CI checks, and paper artifact validation | Tests can change without changing the application digest, but they support trust in the signed payload |
| Kit-owned shims | Nothing; the author does not write numbered stage scripts | Stable CLI/worker lifecycle for keygen, encode, encrypt, compute, decrypt, and decode | Framework code maps file/argv stages onto pure functions |
| Signature and digest | The curator signs the canonical digest | Ingest, worker verification, certificate binding, and offline review | Unsigned or tampered signed payloads are rejected before compute |

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).**

| # | Coordinate | Panel AF | Max pairwise Δ | Min group | Max group | F_ST-like | IGSR F_ST-like |
| ---: | --- | ---: | ---: | --- | --- | ---: | ---: |
| 1 | `22:16051249:T:C` | 0.1200 | 0.2500 | AFR 0.0000 | SAS 0.2500 | 0.0814 | 0.0766 |
| 2 | `22:16052080:G:A` | 0.1600 | 0.3000 | AFR 0.0500 | EAS 0.3500 | 0.1071 | 0.0440 |
| 3 | `22:16052962:C:T` | 0.1200 | 0.2000 | AFR 0.0500 | SAS 0.2500 | 0.0530 | 0.0750 |
| 4 | `22:16053659:A:C` | 0.8000 | 0.3000 | EUR 0.6500 | AFR 0.9500 | 0.1000 | 0.0371 |
| 5 | `22:16053862:C:T` | 0.1300 | 0.2000 | AFR 0.0500 | SAS 0.2500 | 0.0584 | 0.0787 |
| 6 | `22:16054454:C:T` | 0.1300 | 0.2000 | AFR 0.0500 | SAS 0.2500 | 0.0584 | 0.0764 |
| 7 | `22:16054740:A:G` | 0.4400 | 0.2000 | SAS 0.3500 | EAS 0.5500 | 0.0179 | 0.0318 |
| 8 | `22:16055070:G:A` | 0.1500 | 0.3000 | AFR 0.0500 | EAS 0.3500 | 0.1020 | 0.0475 |
| 9 | `22:16055942:C:T` | 0.7600 | 0.3000 | EUR 0.6500 | EAS 0.9500 | 0.0570 | 0.0368 |
| 10 | `22:16057417:C:T` | 0.1300 | 0.2000 | AFR 0.0500 | SAS 0.2500 | 0.0584 | 0.0797 |
| 11 | `22:16058758:C:A` | 0.1400 | 0.1000 | AFR 0.1000 | SAS 0.2000 | 0.0116 | 0.0389 |
| 12 | `22:16060513:T:C` | 0.5700 | 0.3000 | AFR 0.4500 | AMR 0.7500 | 0.0514 | 0.0284 |
| 13 | `22:16060797:A:C` | 0.7600 | 0.3500 | EUR 0.6000 | EAS 0.9500 | 0.0735 | 0.0369 |
| 14 | `22:16061016:T:C` | 0.1700 | 0.1500 | AMR 0.0500 | AFR 0.2000 | 0.0255 | 0.0294 |
| 15 | `22:16061992:A:C` | 0.4600 | 0.3000 | SAS 0.3000 | AMR 0.6000 | 0.0459 | 0.0331 |
| 16 | `22:16062988:C:T` | 0.1300 | 0.2000 | AFR 0.0500 | SAS 0.2500 | 0.0584 | 0.0722 |
| 17 | `22:16063369:C:T` | 0.1100 | 0.2500 | EUR 0.0000 | SAS 0.2500 | 0.0960 | 0.0712 |
| 18 | `22:16064992:G:A` | 0.1700 | 0.1500 | AMR 0.0500 | AFR 0.2000 | 0.0255 | 0.0337 |
| 19 | `22:16067208:C:G` | 0.6500 | 0.4500 | AMR 0.4500 | EAS 0.9000 | 0.1363 | 0.0604 |
| 20 | `22:16067411:T:C` | 0.1300 | 0.2500 | AFR 0.0000 | EAS 0.2500 | 0.0760 | 0.0874 |
| 21 | `22:16067693:C:T` | 0.3200 | 0.1500 | AMR 0.2500 | EAS 0.4000 | 0.0165 | 0.0485 |
| 22 | `22:16069141:C:G` | 0.6600 | 0.4000 | AMR 0.5000 | EAS 0.9000 | 0.0998 | 0.0640 |
| 23 | `22:16069707:C:G` | 0.4100 | 0.2500 | EUR 0.3000 | EAS 0.5500 | 0.0389 | 0.0514 |
| 24 | `22:16070003:C:T` | 0.1700 | 0.1500 | AMR 0.1000 | EAS 0.2500 | 0.0184 | 0.0292 |

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,
2021. 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,
2022. 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,
2022. 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