eduKateSG · Why Science?
Keep sensitive genomic files encrypted from storage to analysis—while granting deliberate recipients efficient, auditable access
Choose the closest route, then return to the full index whenever you need the wider evidence chain.
Science learning becomes powerful when students can tell a measured pattern from a model, a statistical decision from a mechanism, and a useful lead from a finished conclusion. Crypt4GH is a GA4GH encrypted file format designed to keep genomic data protected during storage, transfer and analysis while supporting random access. GA4GH lists Crypt4GH v1.0 as current and approved. The format uses envelope encryption so data segments are protected with session keys and recipient-specific header packets can make those keys available to authorised holders of private keys. Encryption is one security control: it does not replace identity, authorisation, consent, endpoint protection, key governance, backups or audit. This guide supports Primary Science, PSLE Science, Secondary Science, O-Level Science and STEM education as a longform evidence-reading route; it is not medical advice, a laboratory protocol, an admission promise or a career guarantee.
Related eduKate reading: PhenoTips and structured genomic health records; GA4GH Phenopackets and computable case representation; GA4GH Beacon v2 and federated genomic discovery; Science Learning Hub; Education Hub; STEM Education; Careers by Subject Capability.
Primary and official sources checked on 12 October 2026: Official GA4GH Genetic Data Encryption product page, approved Crypt4GH v1.0; Official Crypt4GH file-format specification; Official Crypt4GH utility documentation; Crypt4GH file-format paper; 2026 Singapore–Cambridge O-Level Biology syllabus; MOE G2/G3 Lower Secondary Science teaching and learning syllabus; 2026 MOE G2 Computing syllabus. Standards, implementations and recommendations can change, so preserve the version, access date and documentation used.
| Stage | Question | Evidence | Responsible output |
|---|---|---|---|
| Threat-model | Which data, adversary and exposure are in scope? | Sensitivity, storage, transfer and analysis paths | A bounded security objective |
| Encrypt | How are file bytes and session keys protected? | Header packets, data segments and cryptographic algorithms | An encrypted Crypt4GH container |
| Share | Which recipients may decrypt? | Recipient public keys and controlled re-encryption | Explicit key-based access |
| Operate | Can authorised tools access safely and recoverably? | Key custody, logs, backups and integrity checks | A governed encrypted workflow |
Inside this guide
1–12 · Foundations and design
- 1. Start with the threat model
- 2. Understand the approved format
- 3. Use envelope encryption
- 4. Separate header from data
- 5. Understand recipient public keys
- 6. Protect private keys
- 7. Support more than one recipient
- 8. Re-encrypt the header carefully
- 9. Preserve authenticated encryption
- 10. Use random access
- 11. Keep underlying formats meaningful
- 12. Distinguish format and utility
13–24 · Models and estimation
- 13. Generate keys deliberately
- 14. Avoid secret leakage in commands
- 15. Encrypt before risky transfer
- 16. Keep transport security too
- 17. Treat filenames and sizes as metadata
- 18. Do not call encryption anonymisation
- 19. Separate encryption from authorisation
- 20. Plan revocation honestly
- 21. Rotate keys with a migration plan
- 22. Back up keys securely
- 23. Back up encrypted data and manifests
- 24. Audit decrypt and re-encrypt events
25–36 · Diagnostics and interpretation
- 25. Protect analysis endpoints
- 26. Validate interoperability
- 27. Respond to failures safely
- 28. Connect to Primary Science
- 29. Connect to Secondary Science
- 30. Connect to mathematics
- 31. Connect to computing
- 32. Connect to pathways
- 33. Did you know?
- 34. Write a reader-ready security report
- 35. Build a validation ladder
- 36. Finish with a reproducible bundle
Section 1 of 36
1. Start with the threat model
Genomic files can remain sensitive for a lifetime, so security planning must cover storage, transfer, analysis hosts, logs and backups.
Working checkpoint — Crypt4GH: Name the protected assets, likely attackers and acceptable residual risk. Keep the standard, implementation, encrypted-object checksum, recipient fingerprints and approval record together.
For a classroom model, use a paper lockbox analogy and no real keys.
Section 2 of 36
2. Understand the approved format
GA4GH lists Crypt4GH as a current file-format product and v1.0 as the last approved version.
Working checkpoint — envelope encryption: Record specification and implementation versions separately. Read every successful decryption beside key custody, integrity checks and endpoint security.
For future study, connect genomics to cryptography and governance while checking official pathways separately.
Section 3 of 36
3. Use envelope encryption
Crypt4GH encrypts bulk data with session keys and protects those keys for intended recipients in the file header.
Working checkpoint — recipient key: Keep key-management records with the encrypted object manifest. Preserve failures and removed recipients; a current header is not the full access history.
For scientific writing, name the format, tool version and threat model.
Section 4 of 36
4. Separate header from data
The container begins with a header followed by encrypted data segments; changing authorised recipients can focus on header packets rather than rewriting every data byte.
Working checkpoint — header packet: Test header operations on copies before production. Separate encryption from consent, authorisation, anonymisation and scientific validity.
For students, ask where plaintext appears even when storage stays encrypted.
Section 5 of 36
5. Understand recipient public keys
A sender encrypts access information for a recipient’s public key; the corresponding private key is required to unlock it.
Working checkpoint — data segment: Verify public-key fingerprints through a trusted channel. Treat keys, header packets, checksums and audit logs as security-critical data.
For parents, ask who holds keys, who grants access and how loss is recovered.
Section 6 of 36
6. Protect private keys
A private key is a high-value credential: copying it casually can defeat strong file encryption.
Working checkpoint — random access: Use approved storage, access controls and rotation policy. Keep the standard, implementation, encrypted-object checksum, recipient fingerprints and approval record together.
For a classroom model, use a paper lockbox analogy and no real keys.
Section 7 of 36
7. Support more than one recipient
The header can contain packets for multiple recipients, letting one encrypted data body be shared with explicitly authorised key holders.
Working checkpoint — Crypt4GH: Review the recipient list before distribution. Read every successful decryption beside key custody, integrity checks and endpoint security.
For future study, connect genomics to cryptography and governance while checking official pathways separately.
Section 8 of 36
8. Re-encrypt the header carefully
Utilities can add or change recipient access by processing header material, reducing the need to decrypt and re-encrypt the full file.
Working checkpoint — envelope encryption: Require approval and audit every recipient change. Preserve failures and removed recipients; a current header is not the full access history.
For scientific writing, name the format, tool version and threat model.
Section 9 of 36
9. Preserve authenticated encryption
Crypt4GH data segments include integrity protection so unauthorised modification should be detected rather than silently accepted.
Working checkpoint — recipient key: Fail closed on authentication errors. Separate encryption from consent, authorisation, anonymisation and scientific validity.
For students, ask where plaintext appears even when storage stays encrypted.
Section 10 of 36
10. Use random access
The format is designed so authorised tools can access relevant byte ranges without decrypting the entire genomic file first.
Working checkpoint — header packet: Verify indices and requested ranges in the encrypted workflow. Treat keys, header packets, checksums and audit logs as security-critical data.
For parents, ask who holds keys, who grants access and how loss is recovered.
Section 11 of 36
11. Keep underlying formats meaningful
Crypt4GH wraps files such as CRAM or VCF; encryption does not repair a malformed file or supply missing biological metadata.
Working checkpoint — data segment: Validate plaintext format before encryption and after authorised decryption. Keep the standard, implementation, encrypted-object checksum, recipient fingerprints and approval record together.
For a classroom model, use a paper lockbox analogy and no real keys.
Section 12 of 36
12. Distinguish format and utility
The standard defines the container, while Python and other tools implement encryption, decryption and re-encryption.
Working checkpoint — random access: Do not equate one command-line version with the standard version. Read every successful decryption beside key custody, integrity checks and endpoint security.
For future study, connect genomics to cryptography and governance while checking official pathways separately.
Section 13 of 36
13. Generate keys deliberately
The reference utility can generate Curve25519-based key pairs, but secure generation also needs trusted hosts, entropy and custody procedures.
Working checkpoint — Crypt4GH: Document owner, purpose and creation environment. Preserve failures and removed recipients; a current header is not the full access history.
For scientific writing, name the format, tool version and threat model.
Section 14 of 36
14. Avoid secret leakage in commands
Shell histories, environment variables, process listings and logs can expose key paths or passphrases even when files are encrypted.
Working checkpoint — envelope encryption: Use the platform’s approved secret-handling mechanism. Separate encryption from consent, authorisation, anonymisation and scientific validity.
For students, ask where plaintext appears even when storage stays encrypted.
Section 15 of 36
15. Encrypt before risky transfer
Client-side encryption can keep data protected before upload to remote infrastructure.
Working checkpoint — recipient key: Verify the recipient key and resulting file checksum first. Treat keys, header packets, checksums and audit logs as security-critical data.
For parents, ask who holds keys, who grants access and how loss is recovered.
Section 16 of 36
16. Keep transport security too
Encrypted files still reveal traffic metadata and can be replaced or withheld; secure transport and authenticated endpoints remain useful.
Working checkpoint — header packet: Use TLS and verify destination identity. Keep the standard, implementation, encrypted-object checksum, recipient fingerprints and approval record together.
For a classroom model, use a paper lockbox analogy and no real keys.
Section 17 of 36
17. Treat filenames and sizes as metadata
File names, directory paths, object sizes and access timing may remain visible outside the encrypted payload and can reveal sensitive context.
Working checkpoint — data segment: Minimise and govern metadata exposure. Read every successful decryption beside key custody, integrity checks and endpoint security.
For future study, connect genomics to cryptography and governance while checking official pathways separately.
Section 18 of 36
18. Do not call encryption anonymisation
Encrypted personal data become readable to authorised key holders and can remain identifiable after decryption.
Working checkpoint — random access: Apply consent, purpose limitation and minimisation. Preserve failures and removed recipients; a current header is not the full access history.
For scientific writing, name the format, tool version and threat model.
Section 19 of 36
19. Separate encryption from authorisation
Possessing a private key enables cryptographic access, while organisational policy defines whether that possession and use are permitted.
Working checkpoint — Crypt4GH: Reconcile key holders with current access decisions. Separate encryption from consent, authorisation, anonymisation and scientific validity.
For students, ask where plaintext appears even when storage stays encrypted.
Section 20 of 36
20. Plan revocation honestly
Removing a recipient header packet affects future access to that copy, but cannot erase plaintext or keys already copied by that recipient.
Working checkpoint — envelope encryption: Use contractual, technical and monitoring controls together. Treat keys, header packets, checksums and audit logs as security-critical data.
For parents, ask who holds keys, who grants access and how loss is recovered.
Section 21 of 36
21. Rotate keys with a migration plan
Key rotation can require header re-encryption across many objects and careful tracking of old and new recipients.
Working checkpoint — recipient key: Inventory every encrypted object before retiring a key. Keep the standard, implementation, encrypted-object checksum, recipient fingerprints and approval record together.
For a classroom model, use a paper lockbox analogy and no real keys.
Section 22 of 36
22. Back up keys securely
Losing the only usable private key can make correctly encrypted research data permanently inaccessible.
Working checkpoint — header packet: Maintain tested, access-controlled recovery copies. Read every successful decryption beside key custody, integrity checks and endpoint security.
For future study, connect genomics to cryptography and governance while checking official pathways separately.
Section 23 of 36
23. Back up encrypted data and manifests
A backup without keys, checksums or recipient records may be unusable; an exposed backup with keys may be unsafe.
Working checkpoint — data segment: Separate duties and test restoration end to end. Preserve failures and removed recipients; a current header is not the full access history.
For scientific writing, name the format, tool version and threat model.
Section 24 of 36
24. Audit decrypt and re-encrypt events
Cryptographic tools do not automatically supply a complete organisational audit trail.
Working checkpoint — random access: Log who, what, when, purpose and outcome without recording secrets. Separate encryption from consent, authorisation, anonymisation and scientific validity.
For students, ask where plaintext appears even when storage stays encrypted.
Section 25 of 36
25. Protect analysis endpoints
An authorised program eventually handles plaintext or plaintext-equivalent streams in memory, so compromised endpoints can still expose data.
Working checkpoint — Crypt4GH: Patch, isolate and monitor compute environments. Treat keys, header packets, checksums and audit logs as security-critical data.
For parents, ask who holds keys, who grants access and how loss is recovered.
Section 26 of 36
26. Validate interoperability
Different Crypt4GH implementations should exchange files, but option handling and surrounding tools can differ.
Working checkpoint — envelope encryption: Test encrypt, decrypt, range access and re-encryption across intended clients. Keep the standard, implementation, encrypted-object checksum, recipient fingerprints and approval record together.
For a classroom model, use a paper lockbox analogy and no real keys.
Section 27 of 36
27. Respond to failures safely
Wrong keys, damaged headers, truncated segments and authentication failures need distinct recovery paths.
Working checkpoint — recipient key: Preserve the original encrypted file and investigate on a copy. Read every successful decryption beside key custody, integrity checks and endpoint security.
For future study, connect genomics to cryptography and governance while checking official pathways separately.
Section 28 of 36
28. Connect to Primary Science
A locked box with separate recipient keys illustrates that the same protected contents can be opened by selected people.
Working checkpoint — header packet: Explain that real digital keys must never be shared in class. Preserve failures and removed recipients; a current header is not the full access history.
For scientific writing, name the format, tool version and threat model.
Section 29 of 36
29. Connect to Secondary Science
Genomic privacy connects DNA, identity and responsible research to the practical need for security throughout the data lifecycle.
Working checkpoint — data segment: Map where data are encrypted and where plaintext appears. Separate encryption from consent, authorisation, anonymisation and scientific validity.
For students, ask where plaintext appears even when storage stays encrypted.
Section 30 of 36
30. Connect to mathematics
Modern cryptography uses precise mathematical transformations, but security also depends on keys, implementations and human procedures.
Working checkpoint — random access: Distinguish algorithm strength from operational risk. Treat keys, header packets, checksums and audit logs as security-critical data.
For parents, ask who holds keys, who grants access and how loss is recovered.
Section 31 of 36
31. Connect to computing
Binary formats, authenticated encryption, public-key systems, streaming and key management turn Crypt4GH into a full systems lesson.
Working checkpoint — Crypt4GH: Test corrupted segments and unauthorised recipients. Keep the standard, implementation, encrypted-object checksum, recipient fingerprints and approval record together.
For a classroom model, use a paper lockbox analogy and no real keys.
Section 32 of 36
32. Connect to pathways
Genomic encryption links biology, cybersecurity, software and governance and can illuminate STEM pathways.
Working checkpoint — envelope encryption: Check current official course and professional requirements separately. Read every successful decryption beside key custody, integrity checks and endpoint security.
For future study, connect genomics to cryptography and governance while checking official pathways separately.
Section 33 of 36
33. Did you know?
Crypt4GH can change recipient access through header re-encryption without rewriting the entire encrypted data body.
Working checkpoint — recipient key: Remember that prior recipients may retain copies. Preserve failures and removed recipients; a current header is not the full access history.
For scientific writing, name the format, tool version and threat model.
Section 34 of 36
34. Write a reader-ready security report
Name the standard, tool version, object checksum, recipient fingerprints, key custody, access purpose, random-access tests and audit controls.
Working checkpoint — header packet: Never publish private keys or live capabilities. Separate encryption from consent, authorisation, anonymisation and scientific validity.
For students, ask where plaintext appears even when storage stays encrypted.
Section 35 of 36
35. Build a validation ladder
Validate source format, recipient keys and encryption, test authorised and denied decryption, verify integrity and ranges, then audit storage and analysis endpoints.
Working checkpoint — data segment: Treat every failure as evidence, not an inconvenience. Treat keys, header packets, checksums and audit logs as security-critical data.
For parents, ask who holds keys, who grants access and how loss is recovered.
Section 36 of 36
36. Finish with a reproducible bundle
Deliver encrypted files, public-key fingerprints, checksums, tool and command records, access approvals, recovery plan and redacted audit evidence.
Working checkpoint — random access: Keep secret keys in their governed store, not the research bundle. Keep the standard, implementation, encrypted-object checksum, recipient fingerprints and approval record together.
For a classroom model, use a paper lockbox analogy and no real keys.
Contents · Previous section · Continue to the Science Learning Hub