EC-Council Certified Encryption Specialist study materials
EC-Council Certified Encryption Specialist study resources

Harvest-Now-Decrypt-Later at a Biobank

EC-Council Certified Encryption Specialist · Put your knowledge to work in context.

All case studies

Harvest-Now-Decrypt-Later at a Biobank

Aster Biobank stores 4 PB of genomic and clinical data under a 20-year retention contract. Data at rest is AES-256-GCM. Remote access uses TLS 1.2 with ECDHE-P256 key exchange, RSA-2048 server signatures, and AES-128-GCM. Firmware updates for 3,000 sequencers are signed with RSA-2048 PKCS#1 v1.5. The board asks whether to replace AES-256 with a 512-bit variant and whether to accelerate the TLS migration after reading about 'harvest now, decrypt later.' The infrastructure team says P-256 and RSA-2048 are fine because no quantum computer exists. The compliance team wants a defensible 10-year plan. Budget is limited, so sequencing matters: remote access, archived data, or firmware signatures first. A cryptographer is asked to separate real risk from vendor noise and to set a migration order.

1. Rank the three migration areas and justify the order using threat timing and data lifetime.

Read the worked answer

Rank remote access first, firmware signatures second, data at rest third. Remote access uses ECDHE-P256 and RSA-2048; a recorded TLS session can be attacked later once a cryptographically relevant quantum computer exists. Genomic data has a 20-year sensitivity window, so traffic captured today is inside the harvest-now-decrypt-later threat. Move TLS to hybrid X25519 plus ML-KEM-768 first, and migrate server signatures to ML-DSA or a hybrid certificate.

Firmware signatures are second: forgery requires a quantum computer at the time of attack, not retroactively, but sequencers have 10-15 year service lives and a forged update is catastrophic. Plan a hybrid or dual-signature scheme with an offline root and a crypto-agile bootloader. Data at rest is lowest for quantum reasons because AES-256 already has a large margin; the urgent work there is key management and integrity, not replacing AES. Re-encrypting 4 PB is expensive and should be tied to normal media refresh, not panic.

2. Evaluate the AES-512 proposal and Grover's impact. What about SHA-256 in the signature and TLS stacks?

Read the worked answer

AES-512 is not a standard and is unnecessary. Grover's algorithm gives a quadratic speedup for brute-force key search, so AES-256 retains roughly 128 bits of security in a quantum model, while AES-128 would retain about 64 bits. AES-256 is the right choice; a 512-bit variant would change the key schedule and block size assumptions, add implementation risk, and not fix a real problem. The bigger issue is operational: Grover requires a large, fault-tolerant quantum computer and massive parallel repetition; it does not make AES-256 breakable tomorrow.

For hashes, SHA-256 preimage resistance is about 128 bits under Grover, but collision resistance is lower, around 85 bits, because of the BHT algorithm. For 20-year signatures and certificate chains, use SHA-384 or SHA-512 with ML-DSA or SLH-DSA. Do not rip out SHA-256 from TLS today; prioritize the asymmetric algorithms that Shor's algorithm actually breaks. Keep symmetric policy at AES-256 and SHA-384 for long-lived artifacts.

3. Design the PQC migration: standards, hybrid approach, and certificate/signature choices. Address crypto agility.

Read the worked answer

Use the NIST PQC standards finalized in 2024: FIPS 203 ML-KEM for key establishment, FIPS 204 ML-DSA for signatures, and FIPS 205 SLH-DSA for hash-based signatures. For TLS, deploy hybrid key exchange, X25519 plus ML-KEM-768, so the session remains secure if either component fails; this directly addresses harvest-now-decrypt-later without betting everything on a new lattice assumption. For firmware, use ML-DSA-65 or SLH-DSA with a dual-signature transition: the bootloader accepts a hybrid signature until the fleet is updated, then drops RSA.

For certificates, plan hybrid or PQC certificate chains, but expect larger keys and signatures; test MTU, handshake size, and embedded flash budgets. Build crypto agility: inventory every algorithm and key, abstract the crypto library, support algorithm identifiers, and set a retirement date for RSA-2048 and P-256 signatures. Do not use pure PQC in production on day one; hybrid is the risk-managed path. Rehearse key compromise and rollback.