Federated genomic analytics requires computing population-level statistics across multiple data holders without sharing raw genotypes. We evaluate whether Paillier additive homomorphic encryption (HE) can faithfully compute a pooled allele frequency across genomic cohorts by testing correctness and measuring overhead. Using publicly available 1000 Genomes phase-3 allele frequency data from the APOE region (chr19:44905000–44910000), we treat the five super-population cohorts (AFR, AMR, EAS, EUR, SAS) as proxy data holders, encrypt their allele counts under a 1024-bit Paillier scheme, homomorphically sum the ciphertexts, and decrypt the pooled result. The HE-computed pooled alt-allele frequency of 0.423522 exactly matched the plaintext pooled frequency (max absolute error = 0.0), confirming that additive HE is lossless for this aggregation. The ciphertext expanded 128× relative to plaintext, and the per-query secure aggregation (encrypt + homomorphic add + decrypt) completed in 184 ms, with one-time key generation adding 159 ms. This demonstration validates HE correctness for allele-frequency pooling on a public proxy dataset; genuine privacy gains would require deployment with truly private cohort-level genotype data.

Introduction

Federated genomic analytics aims to compute population-level statistics across multiple institutions without sharing individual-level genotypes. Homomorphic encryption (HE) allows computation on encrypted data, making it a candidate for privacy-preserving secure aggregation in genomics. The key question is whether additive HE schemes like Paillier can faithfully aggregate allele counts across cohorts — that is, whether the decrypted pooled result is bit-exact with the plaintext pooled frequency.

This study tests that correctness claim using the five 1000 Genomes super-populations (AFR, AMR, EAS, EUR, SAS) as proxy data holders. For the most population-differentiated variant in a genomic region, each cohort's allele counts are encrypted; an untrusted aggregator homomorphically sums the ciphertexts; and only the pooled ciphertexts are decrypted. We note that the 1000 Genomes allele frequencies are publicly available aggregate statistics, so this analysis is a correctness and overhead demonstration, not a genuine privacy-preserving computation on sensitive data. Real privacy benefits would emerge when the same HE scheme is applied to truly private cohort-level genotype data held by separate institutions.

Methods

Data Source

We fetched a tabix-indexed region slice from the 1000 Genomes phase-3 VCF (chr19:44905000–44910000, GRCh37) via zero-auth HTTP range requests. The slice contained 163 variants with per-super-population allele frequencies (EASAF, AMRAF, AFRAF, EURAF, SAS_AF). The 1000 Genomes panel provides aggregate allele frequencies, not individual genotypes. These frequencies are publicly available, making them suitable as a correctness testbed but not as genuinely private data.

Lead Variant Selection

From variants with complete population AF data, we selected the lead variant as the one with the largest spread (max AF − min AF) across the five super-populations. The selected variant is at chr19:44908967 (CA→C), with a spread of 0.6567 across populations (AFR: 0.1127, AMR: 0.5202, EAS: 0.2500, EUR: 0.7694, SAS: 0.5982).

Paillier Homomorphic Encryption

We implemented a minimal, dependency-free Paillier cryptosystem using pure-Python big-integer modular arithmetic. The scheme uses:

• Key generation: two random primes p, q of half the key size; modulus n = pq; generator g = n+1 for efficient encryption.
• Encryption: for plaintext m, ciphertext = (1 + m·n) · rⁿ mod n², where r is a random blinding factor.
• Homomorphic addition: E(a) · E(b) mod n² = E(a + b).
• Decryption: standard Paillier decryption using the private key.

For each of the five super-populations, the party's data consists of (altallelecount, totalallelecount) for the lead variant. Counts are derived from the published allele frequencies using fixed panel sizes (2N haplotypes per super-population: AFR=1322, AMR=694, EAS=1008, EUR=1006, SAS=978).

Correctness Verification

The HE-computed pooled alt-allele count and total-allele count were compared against the plaintext pooled values. The primary outcome is exactmatch: whether both counts are bit-identical, and consequently maxabs_error = 0.

Overhead Measurement

We measured: (1) ciphertext expansion (ciphertextbytes / plaintextbytes); (2) wall-clock latency for keygen, encryption of all parties, homomorphic aggregation, and decryption. The per-query cost (encrypt + homomorphic add + decrypt) is separated from the one-time keygen cost.

Seed and Reproducibility

A fixed seed (1234) was used for all prime generation and blinding to ensure bit-for-bit reproducibility.

Results

The analysis completed successfully (outcome: success). For the lead variant at chr19:44908967 (CA→C) in the APOE region:

Per-cohort alt-allele contributions: AFR: 149, AMR: 361, EAS: 252, EUR: 774, SAS: 585.

The figure shows the per-cohort alt-allele contributions and the verified pooled allele frequency computed via Paillier homomorphic encryption.

Discussion

The analysis confirms that Paillier additive homomorphic encryption computes a pooled allele frequency across five genomic cohorts that is bit-exact with the plaintext pooled frequency. This is the core scientific finding: additive HE is lossless for this aggregation task. The max absolute error is 0.0, which means no rounding, wrapping, or precision loss occurs under 1024-bit keys.

The 128× ciphertext expansion is a known property of the Paillier scheme at this key size (256-byte ciphertexts for 2-byte plaintexts). The per-query secure aggregation cost (encrypt + homomorphic add + decrypt) is ~184 ms for five parties, and the homomorphic addition itself is negligible at 0.12 ms. One-time key generation adds ~159 ms and can be amortized across multiple aggregation queries.

Limitations

1. Public proxy data: The 1000 Genomes allele frequencies are publicly available aggregate statistics. This analysis demonstrates HE correctness and overhead, not genuine privacy protection. Real privacy gains require deployment with truly private cohort-level data.
2. 1024-bit key size: This is a fast demonstration; production deployments should use 2048+ bits for long-term security.
3. Single-variant analysis: The demonstration pools counts for one lead variant (chr19:44908967, CA→C). A real genomic study would aggregate across many variants.
4. No network latency: The five "parties" run in-process; a distributed deployment would add network round-trip time.
5. Simulated federated setting: All five cohorts' data resides in a single process; real federated aggregation would require secure multi-party communication channels.

Provenance

• Dataset: 1000 Genomes phase 3, chr19:44905000–44910000 (byte-range tabix slice via pysam)
• Source accession: ALL.chr19.phase3shapeit2mvncallintegratedv5b.20130502.genotypes.vcf.gz
• Access URL: https://ftp.1000genomes.ebi.ac.uk/vol1/ftp/release/20130502/ALL.chr19.phase3_shapeit2_mvncall_integrated_v5b.20130502.genotypes.vcf.gz [tabix 19:44905000-44910000]
• Variants fetched: 163
• Download bytes: 8206
• Lead variant: chr19:44908967:CA:C (spread = 0.6567)
• Analysis seed: 1234
• Analysis script SHA256: 7cfef09d05778800481091c5e2b1e0a7744f2a781b9ff4f9c3747577ea2b7332
• Reference template: hesecureaggregation