Skip to content

Data-level protection: the pragmatic path to quantum safety

Why hybrid cryptography at the payload layer solves what TLS migration cannot

The quantum computing threat is not a distant concern—it's a present-day risk. Intelligence agencies are already capturing encrypted traffic today, storing it with the expectation of decrypting it once sufficiently powerful quantum computers become available. This is the Harvest Now, Decrypt Later (HNDL) attack, and it means that sensitive data transmitted today over classical cryptography is already compromised for the future.

The data classification problem

Traditional security frameworks classify data into three states:

Data at rest — stored in databases, disks, backups. Typically protected with symmetric encryption (AES-256) or asymmetric encryption for key wrapping.

Data in transit — moving across networks via TLS, VPNs, HTTPS. Relies on an initial handshake using asymmetric cryptography (RSA, ECDH) to negotiate symmetric session keys.

Data in use — actively being processed in memory. Protected by secure enclaves (Intel SGX, ARM TrustZone), homomorphic encryption, or confidential computing.

But there is a fourth, often-overlooked state that is critically vulnerable today:

Data in the future (HNDL) — encrypted data captured today by adversaries who store it indefinitely, waiting for quantum computers to decrypt it later.

Quantum threat impact by data state

The quantum threat does not affect all data states equally:

graph TD
    subgraph "Data States & Quantum Vulnerability"
        A[Data at Rest<br/>Databases, Backups]
        B[Data in Transit<br/>TLS, VPNs, HTTPS]
        C[Data in Use<br/>Memory, Processing]
        D[Data in Future HNDL<br/>Captured Today]
    end

    subgraph "Quantum Attack Impact"
        A --> A1[HIGH RISK<br/>If RSA/ECC key wrapping]
        A --> A2[MEDIUM RISK<br/>If pure AES-256]
        B --> B1[CRITICAL RISK<br/>RSA/ECDH handshake broken]
        C --> C1[LOW-MEDIUM RISK<br/>Attestation signatures vulnerable]
        D --> D1[CRITICAL RISK TODAY<br/>Everything capturable is compromised]
    end

    style B1 fill:#ff4444,stroke:#aa0000,color:#fff
    style D1 fill:#ff4444,stroke:#aa0000,color:#fff
    style A1 fill:#ff9944,stroke:#cc6600,color:#fff
Data State Quantum Risk Why?
Data at rest High if keys are wrapped with RSA/ECC; medium for pure AES Shor's algorithm breaks asymmetric key wrapping; Grover's only weakens AES
Data in transit CRITICAL TLS handshake depends on RSA/ECDH for key exchange—Shor's breaks it completely
Data in use Low to medium Secure enclaves rely on hardware isolation more than asymmetric crypto, though attestation uses vulnerable signatures
HNDL (future) CRITICAL TODAY Everything captured today encrypted with RSA/ECC will be readable when quantum computers arrive

The most dangerous misconception is believing HNDL only affects data in transit. While network traffic is the easiest to capture at scale (via fiber optic taps, ISP monitoring, internet exchange points), HNDL applies to any encrypted data an adversary can obtain:

  • Stolen databases encrypted with RSA-wrapped keys
  • Exfiltrated backups protected with classical PKI
  • Captured TLS sessions (the primary vector)

The common factor: if asymmetric cryptography protects it today, a quantum computer will break it tomorrow.

The channel-level migration trap

The standard industry response is to migrate TLS to post-quantum algorithms. This approach has a fundamental operational flaw:

Every link in the chain must be upgraded simultaneously.

graph LR
    subgraph "Channel-Level PQ TLS Migration"
        direction TB
        WS[Web Server<br/>❌ Not Upgraded] --> LB[Load Balancer<br/>✅ PQ Ready]
        LB --> CDN[CDN<br/>❌ Not Upgraded]
        CDN --> Proxy[Reverse Proxy<br/>✅ PQ Ready]
        Proxy --> Client[Client App<br/>❌ Legacy]

        Result1[🔴 ENTIRE CHAIN BREAKS<br/>Falls back to classical crypto]
    end

    subgraph "Data-Level Protection ANKASecure©"
        direction TB
        App[Application<br/>✅ ANKASecure SDK] -->|Hybrid Encrypted<br/>Payload| TLS1[Any TLS<br/>Classical or PQ]
        TLS1 -->|Already Protected| TLS2[Any Infrastructure<br/>No Changes Needed]
        TLS2 -->|Quantum-Safe Data| Dest[Destination]

        Result2[🟢 PROGRESSIVE MIGRATION<br/>Each app independent]
    end

    style Result1 fill:#ff4444,stroke:#aa0000,color:#fff
    style Result2 fill:#44ff44,stroke:#00aa00,color:#000

A single component without post-quantum support breaks the entire protection:

  • Web servers
  • Load balancers
  • CDNs (Content Delivery Networks)
  • Reverse proxies
  • Client applications
  • Mobile SDKs
  • IoT devices

This is a coordinated, synchronized migration—expensive, slow, and operationally risky. A single misconfigured proxy or legacy client forces a fallback to classical cryptography, and the HNDL vulnerability returns.

More critically: while the infrastructure migrates, data continues to be captured.

Even with the best migration plan, the gap between "we decided to migrate" and "every component is upgraded" can span months or years. During that window, adversaries continue harvesting traffic.

The ANKASecure© alternative: protect the data, not just the channel

ANKASecure© takes a fundamentally different approach: encrypt the data with post-quantum algorithms before it enters the transport channel.

Instead of depending on TLS as the only layer of defense, the application calls the API to encrypt the payload with hybrid cryptographic keys—combining classical and post-quantum algorithms—before the data leaves the application.

How hybrid key exchange works

ANKASecure© implements hybrid key encapsulation following industry standards and best practices recommended by NIST, IETF, and international security agencies.

The platform combines:

  • Classical ECDH (Elliptic Curve Diffie-Hellman) — mature, battle-tested, secure against all known classical attacks today. Uses NIST P-curves (P-256, P-384, P-521) specified in FIPS 186-5.

  • Post-quantum ML-KEM (Kyber) — NIST-standardized lattice-based algorithm (FIPS 203), resistant to Shor's algorithm and quantum attacks. Paired with a classical algorithm as the hybrid cryptographic algorithms NIST CSWP 39 §3.2.4 describes.

The two algorithms work together following the IETF draft-ietf-lamps-pq-composite-kem specification to derive a shared secret. This shared secret is then used to generate symmetric keys for AES-256 encryption of the actual payload.

Defense-in-depth: If ECDH is broken by a quantum computer, ML-KEM maintains protection. If a cryptanalytic weakness is discovered in ML-KEM (a new algorithm), ECDH maintains protection. Both would need to fail simultaneously for the data to be compromised.

Standards alignment: This approach is consistent with NIST SP 800-227, ETSI (European Telecommunications Standards Institute) TS 103 744, and the hybrid approach the GSA (General Services Administration) PQC Buyer's Guide lists as a consideration.

flowchart TD
    subgraph "Hybrid Key Exchange: ECDH + ML-KEM"
        A[Start: Data to Encrypt] --> B[Classical Component<br/>ECDH P-256/P-384/P-521]
        A --> C[Post-Quantum Component<br/>ML-KEM-768/1024]

        B --> D1[Classical Shared Secret<br/>FIPS 186-5 curve]
        C --> D2[PQ Shared Secret<br/>FIPS 203 ML-KEM]

        D1 --> E[Key Combiner<br/>NIST SP 800-227<br/>secrets + ciphertexts]
        D2 --> E

        E --> F[Combined Shared Secret<br/>Defense-in-Depth]

        F --> G[AES-256-GCM Key Derivation<br/>NIST SP 800-38D]

        G --> H[Encrypted Payload<br/>Quantum-Safe]
    end

    subgraph "Security Guarantee"
        I[If ECDH is broken<br/>by quantum computer] -.->|ML-KEM protects| H
        J[If ML-KEM has<br/>cryptanalytic weakness] -.->|ECDH protects| H
        K[Both must fail<br/>simultaneously] -.->|to compromise| H
    end

    style F fill:#44ff44,stroke:#00aa00,color:#000
    style H fill:#4444ff,stroke:#0000aa,color:#fff

Comparison: TLS migration vs. data-level protection

Aspect Channel-level (PQ TLS) Data-level (ANKASecure©)
Migration dependency Requires servers, load balancers, CDNs, proxies, and clients to support PQ TLS simultaneously Only requires integrating ANKASecure© APIs into applications that handle sensitive data
Coordination requirement Synchronized migration: a single component without PQ support breaks the entire chain Progressive migration: each application adopts PQ protection independently
Protection during migration If the TLS channel is compromised during rollout (traffic capture), the attacker obtains plaintext data Even if the channel is compromised, data travels encrypted with hybrid cryptography. The attacker only obtains ciphertext resistant to quantum computation
Protection of previously stored data Does not protect previously stored data (at rest) encrypted with classical cryptography Enables re-encryption of stored data with PQ algorithms through re-encrypt and key rotation operations
Infrastructure changes Network-wide changes to all TLS endpoints No changes needed to network infrastructure
Standards alignment Limited (depends on vendor support for new TLS 1.3+ extensions) FIPS 186-5, FIPS 203, NIST SP 800-227, ETSI QSC; aligned with NIST CSWP 39 and the GSA PQC Buyer's Guide

Key platform capabilities with hybrid cryptography

Hybrid Key Exchange (ECDH + ML-KEM) — combines classical elliptic curve cryptography with post-quantum lattice-based KEM. Derives symmetric keys for AES-256 encryption. Provides defense-in-depth: if either algorithm is compromised, the other maintains protection. Fully neutralizes HNDL while maintaining current security standards. Built on FIPS 186-5 (P-256/P-384/P-521 curves) and NIST FIPS 203 (ML-KEM standardization).

Sign/Verify with ML-DSA (Dilithium) — ensures authenticity and integrity cannot be forged in the future, even with quantum computers. ML-DSA as NIST FIPS 204 specifies it.

Re-encrypt & key rotation — migrates previously stored data (at rest) to post-quantum protection without rewriting applications. Aligns with the crypto-agility practices NIST CSWP 39 describes (§5.1, data at rest when an algorithm is replaced).

Algorithm diversity — supports both lattice-based (ML-KEM) and code-based (HQC) post-quantum algorithms, a mathematical diversity that hedges against future cryptanalytic breakthroughs.

Standards alignment: built for regulatory and federal markets

ANKASecure© is designed from the ground up around the algorithms that regulatory frameworks and government standards specify. What follows maps those algorithms to the standards; it is not a certification or validation claim:

Federal and Defense Markets

FIPS 186-5 curves — Full support for the NIST P-curves (P-256, P-384, P-521) that FIPS 186-5 specifies, the curves federal and Department of Defense buyers ask for. The classical components run in the Bouncy Castle (bcprov-jdk18on) and JDK SUN providers, which are not FIPS-validated cryptographic modules; a deployment can hold its key-encryption keys in a customer's own FIPS-validated HSM.

NSA CNSA 2.0 parameter sets — ML-KEM-1024 and ML-DSA-87, the CNSA 2.0 public-key parameter sets, are offered standalone and in composite keys. This serves Intelligence Community and defense contractor markets.

GSA PQC Buyer's Guide (aligned) — Composite keys with AND-decrypt semantics protect against Harvest Now, Decrypt Later (HNDL) and deliver the hybrid approach the guide lists as a consideration in §6.3. Crypto agility and transparent key rotation align with the futureproofing consideration of §6.5. See GSA PQC Buyer's Guide Alignment*.

NIST CSWP 39 (aligned, §3.2.4) — Implements hybrid cryptographic algorithms for key establishment and the transition from traditional to hybrid. See NIST CSWP 39 Alignment*.

International Standards

IETF draft-ietf-lamps-pq-composite-kem (aligned with the draft) — Follows the Internet Engineering Task Force's composite KEM specification for X.509 and CMS interoperability. Implements ECDH-ES+A256KW as specified in RFC 7518 §4.6.

Market Access Enabled

This algorithm coverage addresses the cryptographic requirements of 8 market segments (each market's own certification and accreditation remain separate obligations):

  • ✅ US Federal Government (FIPS + NIST + GSA)
  • ✅ Department of Defense (FIPS 203/204 + NIST SP 800-227)
  • ✅ National Security Systems (CNSA 2.0 parameter sets)
  • ✅ Intelligence Community (CNSA 2.0 parameter sets)
  • ✅ Healthcare (HIPAA encryption requirements, FIPS algorithms)
  • ✅ Financial Services (NIST algorithms, PCI DSS encryption requirements)
  • ✅ European Telecom (ETSI QSC + eIDAS 2.0)
  • ✅ Global Enterprise (dual-compliance algorithm coverage across regional standards)

No other commercial platform currently offers this breadth of standards coverage with AND-decrypt HNDL protection and the CNSA 2.0 parameter sets in composite keys.

graph TD
    subgraph "ANKASecure© Standards Alignment Matrix"
        direction TB

        subgraph "Federal & Defense"
            FIPS[FIPS 186-5<br/>✅ Curves offered<br/>P-256/P-384/P-521]
            NSA[NSA CNSA 2.0<br/>✅ Parameter sets offered<br/>ML-KEM-1024, ML-DSA-87]
            GSA[GSA PQC Guide<br/>✅ Aligned<br/>Hybrid approach]
            NIST[NIST CSWP 39<br/>✅ Aligned<br/>Hybrid Algorithms]
        end

        subgraph "International"
            IETF[IETF Composite KEM<br/>✅ Draft aligned]
        end

        subgraph "Market Access Unlocked"
            M1[🏛️ US Federal Government]
            M2[🛡️ Department of Defense]
            M3[🔒 National Security Systems]
            M4[🕵️ Intelligence Community]
            M5[🏥 Healthcare HIPAA]
            M6[💰 Financial Services]
            M7[🌍 European Telecom]
            M8[🌐 Global Enterprise]
        end

        FIPS --> M1
        FIPS --> M2
        FIPS --> M5
        FIPS --> M6
        NSA --> M3
        NSA --> M4
        GSA --> M1
        GSA --> M2
        NIST --> M1
        NIST --> M2
        NIST --> M6
        ETSI --> M7
        ETSI --> M8
        IETF --> M8
    end

    style FIPS fill:#4444ff,stroke:#0000aa,color:#fff
    style NSA fill:#4444ff,stroke:#0000aa,color:#fff
    style GSA fill:#4488ff,stroke:#0044aa,color:#fff
    style NIST fill:#4444ff,stroke:#0000aa,color:#fff
    style ETSI fill:#4444ff,stroke:#0000aa,color:#fff
    style IETF fill:#4488ff,stroke:#0044aa,color:#fff

Why hybrid cryptography matters now

Post-quantum algorithms like ML-KEM were only standardized by NIST in 2024. They are mathematically sound but relatively new compared to decades-old classical algorithms like ECDH and RSA.

Hybrid key exchange offers the best of both worlds:

  • Confidence today: ECDH is mature, widely analyzed, trusted, and approved in NIST SP 800-56A
  • Protection tomorrow: ML-KEM is quantum-resistant, NIST-standardized, future-proof
  • No single point of failure: breaking the encryption requires breaking both algorithms
  • Regulatory acceptance: BSI (TR-02102-1) and ANSSI recommend hybrid key establishment during the transition; NIST permits it (SP 800-227) and ETSI specifies combiners (TS 103 744). NSA does not require hybrid for CNSA 2.0

This dual-algorithm approach is not just a technical preference—it is the path several European security agencies recommend while post-quantum algorithms accumulate real-world analysis.

The strategic takeaway

Waiting for the entire infrastructure chain to migrate to post-quantum TLS is a risky bet: while the industry aligns, data continues to be captured and stored by adversaries.

Data-level protection with hybrid cryptography eliminates this dependency. Each organization can safeguard its critical assets today, independently, without waiting for network providers, CDNs, and load balancers to complete their own transitions.

Moreover, ANKASecure©'s standards alignment gives federal, defense and international buyers the algorithms FIPS, NSA, NIST and ETSI specify. It does not replace the certification or accreditation each of those markets requires of a deployment.

ANKASecure© renders traffic capture useless against both classical and quantum attackers, because the data is already encrypted with hybrid cryptography built on standardized algorithms—combining FIPS 186-5 classical curves with NIST-standardized post-quantum algorithms—before it ever touches the network.

TLS becomes a second layer of defense, not the only one.

About ANKASecure©

ANKASecure© is a post-quantum cryptography platform providing REST APIs, a Java SDK, and CLI tools for enterprises to integrate quantum-resistant cryptographic operations into their applications. The platform supports hybrid key exchange (ECDH + ML-KEM), post-quantum digital signatures (ML-DSA), and crypto-agility for seamless algorithm updates as standards evolve.

Standards: FIPS 186-5 curves, IETF composite KEM drafts; aligned with NIST CSWP 39 and the GSA PQC Buyer's Guide; CNSA 2.0 parameter sets ML-KEM-1024 and ML-DSA-87 offered.

Market Access: Federal government, Department of Defense, National Security Systems, Intelligence Community, healthcare, financial services, European telecom, global enterprise.

For more information: [contact details or website]

* restricted content — see higher-tier documentation