GIF AMA
GA4GH Implementation Forum: Ask Me Anything

31st March 2026

Featured standard

Meeting Overview

Attendees: Oscar Martinez Llobet, Ramona Rego, Mallory Freeberg, Robert Davies, Reagan Thomas, Frederic Haziza, Chui-Chen Kuo, Olfa Massaoud, Beatrice Amos, Kaitlyn Brethour, Slabela de la Torres Pernas, Jinny Park, Maria Yazkova, Venkat S. Malladi, Dimitry Repchevsky, Bastiaan Franssen, Silvia Llorente, Brian O’Connor, Andres Silva, Hedge Hect

Meeting Recording

Slides

Info

• https://gitlab.bsc.es/inb/ga4gh/liquid-crypt4gh 
• https://f1000research.com/posters/14-541 

Summary

Crypt4GH is a scalable, efficient encryption standard for genomic data. The  AMA session highlighted how it has the ability to integrate with bioinformatics tools through features like random access and minimal performance overhead. Examples of real-world implementations demonstrated its scalability and efficiency, including large-scale use in genomic archives. Attendees also discussed Crypt4GH’s integration with other GA4GH standards like Passports for access control.  Its limitations include partial integrity and header vulnerabilities. The experts shared upcoming improvements in version 2, along with future plans for quantum-resistant encryption. All participants agreed that community-driven use cases, testing, and collaboration are necessary to guide the continued development of Crypt4GH.

Questions and Answers

This is a community-driven resource, and your contributions help make it better! If you spot a mistake, see an opportunity to add a resource, or have more details to share, please jump in and make changes. We welcome and encourage your input!

1. Implementations of Crypt4GH

Q: What Application Programming Interfaces (APIs) or services currently implement Crypt4GH? Is there a list of them?
A: Crypt4GH is implemented in multiple tools and libraries.

• SAM/BCF Tools via HTSlib plugin:
  You can build separate plugin libraries to access files through Crypt4GH. The agent process handles your keys, allowing standard SAM tools to read/write encrypted files transparently.

Some implementations include:

• HTSlib plug-in (C): https://github.com/samtools/htslib-crypt4gh
• EGA (Python): https://github.com/EGA-archive/crypt4gh
• EGA (Rust): https://github.com/EGA-archive/crypt4gh-rust
• Nordic eInfrastructure collaboration (Go): https://github.com/neicnordic/crypt4gh
• Javascript: https://github.com/fathelen/crypt4ghJS
• FUSE layer: https://github.com/EGA-archive/crypt4ghfs
• FUSE with additional metadata: https://github.com/silverdaz/crypt4gh-sqlite

2. Usage in Bioinformatics Workflows

Q: Have these tools been used in bioinformatics workflows? Are there code examples?
A: Current usage is limited; examples exist but are not extensively documented.

• FUSE Filesystem Approach (Practical):
  This method decrypts files on-the-fly, so tools can work with encrypted files without modification. On-disk data remains encrypted, and decryption happens in memory.
• EGA Usage:
  Primarily used for uploading and downloading files, not yet widely applied in processing workflows.
• Community Need:
  The team seeks representative bioinformatics pipelines and benchmark data to validate Crypt4GH performance.

Bottom line: FUSE is more practical than the HTSlib plugin for real workflows; more community examples are needed.

3. File Access & Encryption Mechanics

Q: Is random access supported during on-the-fly decryption?
A: Yes. Crypt4GH uses block-level decryption, which allows:

1. Searching for the correct block
2. Calculating block location
3. Decrypting only that block in memory

Performance impact is minimal (~2% slower than decrypted files). Random access supports indexed workflows.

Q: How much does the data size increase when encrypted?
A: ~28 bytes per 65,536-byte block (~0.04% overhead). The header adds a small extra cost, negligible for practical purposes.

4. Headers and Multiple Recipients

Q: Why include multiple recipients in a single header? Isn’t it better to generate headers on the fly?
A: Crypt4GH supports flexibility:

• Multiple recipients: Single header can encrypt for several users, but adding/removing users requires rewriting the file.
• Detached headers (recommended):

• Keep payload immutable
• Generate small headers (~124–200 bytes) per recipient
• Efficient for real-world file sharing
• Used by EGA in practice

Bottom line: Generating headers on-the-fly is the most practical approach.

5. Passports and Crypt4GH Integration

Q: Could a Passport contain public keys for encryption?
A: Current Passports don’t store keys. Future approaches (Passport 2.0) might:

• Use Passport for authentication/authorization
• Generate detached headers with ephemeral or public keys for encryption
• Session keys can be ephemeral and discarded after use

Q: How could Passports, DRS, and Crypt4GH work together?
A: Proposed integrated workflow:

1. Passport validates identity/access
2. DRS returns encrypted file locations
3. Crypt4GH provides detached headers for decryption

Key points:

• Detached headers act as encrypted permissions
• Ephemeral session keys keep the process secure without storing persistent keys
• Integration discussions ongoing in GIF monthly meetings and GA4GH Connect sessions

6. Quantum Resistance

Q: How urgent is quantum resistance for the community?
A: Medium-term concern (mid-2030s per IBM roadmap).

• "Harvest Now, Decrypt Later" risk: Adversaries could store encrypted files now to decrypt in the future
• Payload safety: Symmetric encryption is already quantum-safe; only headers are vulnerable
• Industry movement: SSH and TLS already adding quantum resistance
• Bottom line: Plan proactively, but no immediate emergency

7. Backwards Compatibility

Q: Would Crypt4GH be backwards compatible?
A: Yes.

• Old readers understand new standards (if new features aren’t used)
• New readers understand old files
• Caveat: Files encrypted with quantum-resistant headers require updated readers

8. Community Needs

Q: What does the Crypt4Gh team need from the GA4GH community?
A:

• Real bioinformatics pipeline use cases
• Performance benchmarks from workflows
• Engagement with encryption challenges
• Feedback on implementation
• Collaboration via GIF monthly meetings

Current usage: EGA stores ~19–20 PB of encrypted data, but wider community examples are desired.

9. Data Size Today

Q: How much data is encrypted with Crypt4GH now?
A: Approximately 19–20 petabytes at EGA