Comparing Encryption Methods for Genomic Data at Rest

By Dr. Zubair Khalid, DVM, MS, PhD · 2026-11-11

Full-disk encryption protects a device, file-level encryption protects an individual file, and application-level encryption protects the data itself, even while it is being processed. That one sentence is the backbone of comparing encryption methods for genomic data at rest. The rule of thumb that follows from it is simple. Put transparent volume encryption under every system that stores sequence data, wrap anything that leaves your storage boundary in file-level encryption with keys you control, and reserve compute-on-encrypted-data methods for the specific jobs that must run on infrastructure you do not trust.

The stakes justify the discipline. A single 30x whole genome produces roughly 100 GB as BAM and about half that as CRAM, and a working genomics data storage estate accumulates thousands of those files alongside VCFs, expression matrices, and clinical phenotypes. Genomes are the strongest identifiers in biomedicine. They are inherited, shared across relatives, stable for life, and impossible to re-issue after a breach the way a password or a payment card can be. Genomic variants reveal potentially private facts about individuals, which is why controlled access and strong storage protection are treated as baseline requirements in human genomics [1].

This guide is written for the people who run that storage, including bioinformaticians, research IT staff, and data stewards. It explains each encryption option on its own terms, compares the options on the criteria that decide real deployments, walks through four worked scenarios, and closes with the mistakes that most often undermine otherwise sound designs.

Why Genomic Data Needs Encryption at Rest

Encryption at rest means the bytes sitting on a disk, tape, or object store are written as ciphertext. An encryption algorithm such as AES (Advanced Encryption Standard) converts plaintext to ciphertext using a key, and only holders of the correct key can reverse the process. Data in this state is unreadable to anyone who steals a drive, dumps a backup, or scrapes a misconfigured bucket, unless they also obtain the key.

Genomes earn this treatment more than almost any other data type. Genotype data can identify individuals and families, which is why ethical analyses of large sequencing programs argue for careful control over access to genotype, phenotype, and pedigree data [2]. The exposure is not limited to institutional repositories. Individuals now upload genotypes, health records, and family history to open sharing platforms such as Portable Legal Consent, Free the Data, and Genomes Unzipped, and those initiatives ask people to balance the risks and benefits of sharing largely on their own [3]. Both audiences, the archive and the individual, need the same technical floor.

Three terms recur throughout this article. Controlled access means a documented process that reviews requests and grants permissions, common in human genomics archives. De-identification means removing or transforming direct identifiers such as names and dates. Encryption is complementary to both, because it protects bytes while the other two govern who may see them.

Encryption is also one layer inside broader bioinformatics data management, not a substitute for it. Large research programs pair storage protection with role-based access control, de-identification, and disciplined backup processes [4]. Secure computing environments at academic medical centers treat user access, data controls, hardware, software, and audit as a single design problem rather than separate purchases [5].

Start With the Threat Model, Not the Cipher

A threat model is a written list of the adversaries and accidents you are defending against. Comparing encryption methods without one produces arguments about ciphers instead of decisions about risk. For genomics data storage, the recurring adversaries look like this.

Two of these rows deserve emphasis. Insiders with legitimate access are the classic blind spot, because encryption at rest by definition decrypts data for authorized users, so the countermeasures are least privilege, separation of duties, and audit design [5]. And a compromised collaborator turns your sharing choices into your exposure, which is why per-recipient encryption and controlled access agreements belong in the same conversation [6].

Write the adversary list down for your own estate, ranked by likelihood. Every recommendation in the rest of this article only makes sense relative to a named adversary.

Encryption Methods for Genomic Data at Rest: The Main Options

Each option below is described on its own terms with pros and cons, then the full set is compared side by side in the next section.

Full-Disk and Volume-Level Encryption

Full-disk encryption (FDE) encrypts every sector of a block device under a single key, unlocked at boot or at mount time. On Linux the standard is LUKS2, managed with cryptsetup, on Windows BitLocker, and on macOS FileVault. All three use AES in XTS mode, a tweakable mode built for sector-addressed storage, and modern CPUs include AES instruction extensions that keep the throughput penalty small. Current Windows releases default to XTS-AES-128 for operating system drives, while LUKS2 commonly runs aes-xts-plain64 with 256-bit data keys. On a modern cryptsetup install the defaults are sensible and the working commands are short.

sudo cryptsetup luksFormat /dev/nvme1n1
sudo cryptsetup open /dev/nvme1n1 seqdata
sudo mkfs.xfs /dev/mapper/seqdata

ZFS offers native dataset encryption with AES-GCM, which adds per-dataset keys and the ability to replicate encrypted data without exposing plaintext to the destination.

Pros:

• Transparent to every pipeline and application, no per-file work.
• Covers swap space, scratch directories, and temp files, which routinely leak read names and sample identifiers.
• Mature tooling, low overhead with hardware AES.

Cons:

• Protects a powered-off or locked system, not a running system with a logged-in attacker.
• One key per volume, so compromise is all or nothing.
• Protection does not travel with the file, a copied FASTQ leaves it behind.
• No defense against a compromised root account or a malicious administrator.

Self-encrypting drives (SEDs) that implement the Opal standard move this encryption into drive firmware. They are fast and simple to deploy, but security depends on the vendor implementation, which you cannot audit the way you can audit a software stack, so many security teams prefer software volume encryption for genomic workloads.

File-Level and Object-Level Encryption

File-level encryption protects individual files, so the protection follows the data across disks, buckets, networks, and archives. Three tools dominate genomics practice.

GnuPG (GPG) uses hybrid encryption. A random session key encrypts the file with a symmetric cipher, and each recipient's public key wraps that session key, so one command produces a file readable only by the intended recipients.

gpg -e -r [email protected] run_0042.fastq.gz
gpg -d -o run_0042.fastq.gz run_0042.fastq.gz.gpg

age is a smaller, modern file encryption tool built around X25519 keys, with the same hybrid design and far fewer configuration traps.

age-keygen -o key.txt
age -r "$RECIPIENT" -o run_0042.fastq.gz.age run_0042.fastq.gz

crypt4gh is the open format designed specifically for encrypting genomic data files. It uses Curve25519 key pairs, encrypts the payload in fixed 64 KB segments with ChaCha20-Poly1305, and stores the per-file data keys encrypted in a header that can list multiple recipients. One encrypted CRAM can therefore be readable by an entire authorized collaboration, and the command line tool takes your secret key, the recipient public key, and the file to produce a .c4gh artifact.

Pros:

• Protection travels with the file to any storage system, including tape and third-party archives.
• Per-recipient keys make adding or removing readers a header or file re-encryption, not a storage-wide event.
• Fits federated sharing, where each node holds encrypted data and grants access by key, not by location.

Cons:

• Pipelines must either handle ciphertext or decrypt into a staging area, and staging areas recreate the exposure you were avoiding unless they are treated as sensitive.
• Sidecar files need the same treatment, because BAM indexes, VCF tabix indexes, checksum files, and pipeline logs all leak information on their own.
• Without automation, key distribution and rotation become per-file chores that people stop doing.

Server-Side Encryption in Cloud Object Storage

Object stores encrypt objects on write, usually with three key ownership models. Provider-managed keys require no setup and give you no control. Customer-managed keys place the root key in a key management service (KMS) that you operate, and the storage service fetches it for each operation. Customer-supplied keys travel with each request and are never stored by the provider. The underlying pattern is envelope encryption, in which a per-object data key encrypts the bytes and a master key in the KMS wraps the data key.

Pros:

• Always on by default in the major object stores, with zero pipeline changes.
• Customer-managed keys support independent revocation, removing KMS access makes the data unreadable even if object permissions leak.
• Integrates with cloud-native identity policy and audit trails.

Cons:

• Protects bytes on the provider's disks, not against a principal holding valid read credentials.
• Provider-managed keys give you no independent control and no technical way to revoke.
• Bucket policy mistakes and leaked tokens bypass encryption entirely, which is why identity design matters as much as key design.

Database-Level Encryption

Transparent data encryption (TDE) encrypts database data files, redo or write-ahead logs, and backups at the storage layer, transparently to applications. Column-level encryption goes finer and protects specific fields, and in designs such as SQL Server Always Encrypted the database server never holds the plaintext keys, so even a database administrator cannot read protected columns.

The published record shows this tier carrying sensitive participant data at scale. A large population research project built its central data management on an Oracle database in a high availability cluster, protected by a multi-layered role and rights system, with de-identification of identifying fields and a defined backup process, capturing roughly 5 TB of sensitive data over eighteen months without a critical incident or data loss [4].

Pros:

• Backups and logs inherit protection automatically, closing the most common gap in file-system-only designs.
• Policy can be applied per tablespace or per column, matching sensitivity levels.
• Encryption, access control, and query audit live in one system with one operator model.

Cons:

• A database administrator or a compromised application account still sees plaintext through the normal query path.
• Index behavior and query performance can degrade depending on the mode used.
• Features are vendor specific, which complicates migration between database engines.

Application-Level and Field-Level Encryption

Application-level encryption encrypts data inside the application before it ever reaches storage, with granularity down to individual fields or smaller. For genomics, the notable design point is single-variant granularity. The PROMISE system for precision medicine implements selective access with single DNA base-pair resolution cryptography, allowing the patient to grant access to defined parts of their genetic information from a smartphone app. In a pilot with nineteen cardiomyopathy patients, 79 percent rated the safety of their genetic data as very important, and after roughly four months of use more than half reported a changed attitude toward how their genetic data is handled, with higher confidence in data security and greater willingness to share with third parties [7].

Pros:

• Granularity can match consent, down to a variant region or a single base pair.
• Plaintext for protected fields never reaches the storage tier.
• Enables patient-held keys and patient-mediated sharing models.

Cons:

• Patient-held keys create a recovery problem, a lost key means lost access to irreplaceable data.
• Bespoke cryptographic designs need expert review, because home-grown schemes fail in predictable ways.
• Integration cost across pipelines is the highest of any option in this list.

Homomorphic Encryption for Compute on Encrypted Data

Homomorphic encryption (HE) allows computation directly on ciphertext. The encrypted result, decrypted with the owner's key, matches what the same computation would have produced on plaintext. The standard families are BFV, which supports exact integer arithmetic, and CKKS, which supports approximate arithmetic on real numbers. Genotype data encrypted this way stays secure in transit, at rest, and during analysis, and only the data owner can decrypt.

The demonstration that moved HE toward practice in genomics is secure genotype imputation, the step that predicts missing genotypes from nearby tag variants. HE-based imputation models matched three non-secure comparison methods on accuracy for common variants while keeping time and memory requirements comparable or lower, and the implementation is freely available at github.com/K-miran/secure-imputation [8].

Pros:

• The only option here that protects data while it is being processed, closing the gap between encryption at rest and encryption in use.
• Enables outsourcing imputation and similar tasks to services you do not trust with plaintext.

Cons:

• Supports a narrow set of computations, not general pipelines such as alignment or assembly.
• Scheme and parameter selection requires cryptographic expertise.
• Not a storage format for archives, it is a method for specific outsourced computations.

Read Pooling and Other Obfuscation Approaches

Obfuscation is not encryption. It transforms or mixes data so sensitive structure is hard to recover, with no key and no decryption step. For dual-use sequence data, where a raw sample could enable malicious reconstruction of a pathogen, read pooling mixes raw reads from multiple samples of the same organism before the data is stored or shared. Demonstrations show that pooling prevents full reconstruction of any individual sample while most genomic information remains available, and the protection holds both while the data is stored and while it is transferred [9].

Pros:

• Deters reassembly of individual samples in shared archives of sensitive organisms.
• Preserves most downstream utility for surveillance and research.
• No key infrastructure to operate or lose.

Cons:

• No cryptographic guarantee, the security depends on pool composition and on what every contributor contributes.
• Per-sample queries and sample-level quality control become harder or impossible.
• Requires coordination among every party contributing reads to a pool.

Side-by-Side Comparison

The table condenses the options into the columns that decide real deployments. Read the Stops and Does not stop columns against your own threat model, not in the abstract.

No row wins on its own. Mature genomics data storage stacks run volume encryption, cloud or file-level encryption, and database encryption together, and add field-level encryption, homomorphic computation, or read pooling only where a specific threat demands them.

How to Choose: The Criteria That Decide Real Choices

Performance on Real Genomics Workloads

Benchmark with your own files. A useful drill is to copy one 30x CRAM and its index onto an encrypted LUKS2 volume and onto an unencrypted control, run the same alignment or variant calling step on both, and compare wall-clock times. With hardware AES, volume encryption overhead is usually small. File-level encryption adds per-file key operations that are trivial for large CRAMs and noticeable across millions of small objects. Database encryption costs depend on which parts stay plaintext and how indexes are built. Homomorphic encryption is the outlier, general overheads are heavy, and only carefully tuned workloads have approached conventional performance.

Key Management and Recovery

Key management is where genomic data storage projects fail, not the ciphers. The working rules are short.

1. Never store keys on the same volume, bucket, or backup as the data they protect.
2. Use envelope encryption with a KMS, or a hardware security module (HSM) where policy requires keys that never leave hardware.
3. Scope keys per dataset or per collaborator, so revocation is technically possible.
4. Rotate keys on a schedule and on every relevant personnel change.
5. Write and rehearse the recovery procedure before encrypting production data, because a lost key turns a security incident into permanent data loss.
6. Separate duties, the key holder should not also be the only approver of access.

Institutions designing this layer can borrow from published secure computing environments that treat user access, data controls, hardware, software, and audit as explicit, documented design areas [5].

Alignment With Access Control and Audit

Encryption at rest answers what happens if bytes are stolen. It does not answer who may read the data. That question belongs to controlled access decisions, data use agreements, and audit trails. For audit infrastructure, a blockchain-based approach has been demonstrated for genome dataset access, in which the winning iDASH 2018 competition solution logged user activity across multiple sites in MultiChain data streams with efficient storage and query, though the authors note operational drawbacks in running the ledger infrastructure [1]. Federated platforms instead centralize access decisions and push enforcement to the nodes holding the data, the model implemented by DS-PACK [6]. Configure your encryption so these controls keep working, for example by ensuring audit logs are integrity-protected and available to auditors rather than buried inside volumes only one administrator can unlock.

Sharing, Federation, and Portability

Regulatory pressure in Europe has pushed human data sharing from centralized archives toward federated models, in which a central node supports discovery and each node handles its own access requests and data delivery [6]. That shift changes encryption requirements in three ways. Files need formats that travel, which is the case for crypt4gh. Keys need to support revocation when an agreement ends, which argues for per-recipient scoping from day one. And the enforcement point moves onto your node, so at-rest encryption and access control must be configured by the same team rather than split across organizations. Institutions that lack the resources to build controlled access processes from scratch can adopt reusable open-source middleware that semi-automates the path from data submission to access [6].

Operational Simplicity and Staffing

The most secure design that nobody can operate loses to the good design your team can run at 3 a.m. Before choosing, answer three questions. Who unlocks volumes at boot, and what happens when the KMS is unreachable? Who can rotate a key, and how long does rotation take across 50,000 objects? Who gets called when a restore drill fails? Tools that centralize key operations reduce the number of custom scripts, and custom scripts are where key management usually breaks. Document the runbooks alongside the encryption rollout, not after it.

Worked Scenarios

Scenario 1: A Sequencing Lab With an On-Premises Cluster

An academic sequencing core runs a job scheduler, a parallel filesystem, and a tape archive. A sound stack looks like this.

1. LUKS2 on every node scratch disk and on the parallel filesystem backing store, keys held in the institutional KMS, volumes unlocked at boot by the provisioning system.
2. crypt4gh for every dataset that leaves the core, one key pair per recipient institution, with index and checksum files encrypted alongside the CRAMs.
3. Tape encrypted at the volume or application layer, tape keys in the same KMS, and one offline key copy under dual control.
4. A quarterly restore drill from tape, timed, with a written key recovery runbook.

The theft this stack prevents is a decommissioned node or an old tape leaving the building with readable genomes on it. The theft it does not prevent is a compromised login reading decrypted scratch data mid-run, which is a problem for access control and monitoring, not for encryption.

Scenario 2: An Academic Medical Center Research Repository

A medical center aggregates electronic health record extracts, claims data, and genomic pipeline outputs for research. The published Weill Cornell Medicine Data Core is the reference design, with explicit controls on user access, data, hardware, software, and audit, supporting more than 200 users across nearly 60 research and education projects in its first 2.5 years, and with its tooling released on GitHub for other institutions [5]. For the database tier, the pattern proven in large population research applies, a highly available clustered database with transparent protection of data files and backups, a multi-layered role and rights system, de-identification of direct identifiers, and a defined backup process [4]. File-level encryption covers every export to collaborators, and privileged access lands in the same audit trail as everyone else. Budget and staffing are planned as part of the design, because a control nobody can operate is not a control [5].

Scenario 3: A Federated Human Data Sharing Node

Your institution joins a federation in which a central node supports data discovery and each node handles access requests, agreements, and secure delivery itself. A workable configuration combines the following.

1. Customer-managed keys in a KMS for every cloud bucket holding controlled-access genotypes.
2. crypt4gh for file delivery, so an approved access package is encrypted to the recipient's public key and unreadable to intermediaries.
3. Access enforcement distributed to your node, with agreements and stewardship supported by middleware such as DS-PACK, which runs in production at the ELIXIR Luxembourg hosting platform [6].
4. Key revocation or re-encryption as a standard offboarding step, so expired agreements stop being technically readable.

The requirement that distinguishes this scenario from an on-premises lab is portability. Your encrypted artifacts must be usable by partner workflows without exposing plaintext to any intermediary.

Scenario 4: Sensitive Pathogen Sequence Data

A surveillance network shares raw reads for an organism with dual-use potential, where a full individual sample could enable malicious reconstruction. Standard encryption and controlled access still apply, and read pooling adds a protection layer that survives both storage and transfer [9]. A practical split is pooled archives for open sharing, where no single sample can be reassembled, alongside per-sample encrypted delivery under agreement for vetted users. Document pool composition and the pooling method so legitimate users can still interpret what they receive, and treat any request for unpooled data as a controlled access decision rather than a technical toggle.

Common Mistakes and Limitations

1. Encrypting the volume but not the exits. NFS exports, staging buckets, and collaborator drop folders routinely sit outside the encrypted perimeter and hold the same genomes.
2. Storing keys next to data. A KMS key kept in the same bucket as the ciphertext is decoration, not protection.
3. Treating full-disk encryption as access control. FDE stops the thief with a stolen drive, it does nothing against a valid login on a running system.
4. Forgetting sidecar files. An unencrypted BAM index still carries read names and coordinates, so encrypt indexes, checksums, and pipeline logs with the same discipline as the primary files.
5. Ignoring snapshot and backup sprawl. Every snapshot is another copy, and it is unprotected unless your encryption layer covers it, which is why backup targets need their own key plan.
6. Skipping restore drills. Encryption converts theft into a non-event and key loss into a catastrophe, so rehearse recovery before production data depends on it.
7. Rolling your own cryptography. Novel modes, naive block ordering, and hand-built key derivation fail in known ways, so use vetted implementations and have any novel design reviewed by a cryptographer.
8. Assuming encryption settles consent. People sharing their own genomes online are asked to weigh risks they may not fully understand, and no cipher repairs an uninformed sharing decision [3].
9. Treating obfuscation as encryption. Read pooling prevents reassembly of the pooled samples [9], it provides no key-based confidentiality for anything held outside the pool.
10. Deploying homomorphic encryption as a storage default. It is a compute technique for specific tasks such as imputation, not an archive format.

Two limitations deserve plain language. The right design depends on your institution, your agreements, and your adversaries, so route any production plan through your information security office and, for human data, through your privacy or ethics review. And performance figures age quickly, so benchmark on your own hardware and software versions before committing.

Frequently Asked Questions

What are the best encryption methods for genomic data at rest?

There is no single best method. The strongest practical setup layers transparent full-volume encryption under file-level or customer-managed cloud encryption, with keys in a managed KMS, and adds homomorphic or field-level methods only for the specific jobs and sharing models that need them.

Does full-disk encryption protect genomic data in the cloud?

Only at the provider's disk layer. Anyone with valid read permission to your bucket or database sees plaintext, so use customer-managed keys and, for data you must control end to end, client-side file-level encryption.

Can analysis run on encrypted genomic data?

Yes for some tasks. Homomorphic encryption lets an untrusted service compute on ciphertext, and secure genotype imputation is the demonstrated genomics use case, but the technique remains specialized rather than a general storage mode.

Is crypt4gh the right choice for sharing encrypted FASTQ and CRAM files?

Yes when your partners support crypt4gh-based workflows, because the format was designed for genomic files and supports multiple recipients per file. It should sit inside a controlled access process, not replace one.

How should encryption keys for genomic datasets be stored?

In a dedicated key management service or hardware security module, separate from the data, with per-dataset scoping, scheduled rotation, separation of duties, and a recovery procedure you have actually tested.

Is read pooling a substitute for encryption?

No. Pooling is an obfuscation strategy that prevents full reconstruction of individual samples while preserving most genomic information, and it works best alongside standard encryption and controlled access.

Sources

1. Using blockchain to log genome dataset access: efficient storage and query.
2. Ethical and legal implications of whole genome and whole exome sequencing in African populations.
3. Challenges of web-based personal genomic data sharing.
4. Efficient data management in a large-scale epidemiology research project.
5. Design and Implementation of a Secure Computing Environment for Analysis of Sensitive Data at an Academic Medical Center.
6. DS-PACK: Tool assembly for the end-to-end support of controlled access human data sharing.
7. Controlling my genome with my smartphone: first clinical experiences of the PROMISE system.
8. Ultrafast homomorphic encryption models enable secure outsourcing of genotype imputation.
9. Methods for safely sharing dual-use genetic data.