Package co.ankatech.ankasecure.sdk.examples

Class ExampleScenario18

java.lang.Object
co.ankatech.ankasecure.sdk.examples.ExampleScenario18
public final class ExampleScenario18 extends Object
Scenario 18 — Use Composite Hybrid Keys for Quantum-Resistant Security (data-plane).

Demonstrates the data-plane workflow for using composite cryptographic keys that combine classical and post-quantum algorithms. Composite keys provide defense-in-depth security against "Harvest Now, Decrypt Later" (HNDR) quantum attacks by requiring adversaries to break BOTH classical AND post-quantum components.

The SDK is data-plane-only: it does not create composite keys. This scenario operates on the two composite keys pre-provisioned in the demo playground:

  • P-256+ML-KEM-768 (kty COMPOSITE, compositeMode COMPOSITE_KEM_COMBINE) — used for encrypt/decrypt
  • brainpoolP384r1+ML-DSA-87 (kty COMPOSITE, compositeMode COMPOSITE_SIGNATURE) — used for sign/verify

Real-World Scenarios:

  • Government agencies: NSM-10 compliance for HNDR protection of classified data
  • Financial institutions: Long-term protection of transaction records (10+ years)
  • Healthcare systems: quantum-resistant encryption suitable for protecting PHI under a HIPAA program
  • Critical infrastructure: Defense-in-depth for SCADA systems and utilities
  • Cloud providers: Quantum-safe encryption tiers for enterprise customers

Composite Modes Demonstrated:

  • COMPOSITE_KEM_COMBINE: Hybrid Key Encapsulation Mechanism for encryption. Combines P-256 (classical) + ML-KEM-768 (PQC) outputs. Both secrets required for decryption (AND-decrypt model).
  • COMPOSITE_SIGNATURE: one composite signature for document signing. The ML-DSA-87 (PQC) and brainpoolP384r1 (classical) components each sign the composite message representative M', and the JWS carries a single value, the ML-DSA signature followed by the ECDSA one, under one composite alg. The scenario reads that alg from the protected header of the signature file the server wrote; for this pairing it is ML-DSA-87-ESB384, a name derived by the JOSE draft's naming rule but not listed in its Table 5. The signature is valid only if both components verify.

Steps:

  1. Resolve the pre-provisioned COMPOSITE_KEM_COMBINE key (P-256+ML-KEM-768)
  2. Encrypt sensitive data using the composite KEM (transparent API usage)
  3. Decrypt data demonstrating AND-requirement (both components needed)
  4. Resolve the pre-provisioned COMPOSITE_SIGNATURE key (brainpoolP384r1+ML-DSA-87)
  5. Sign and verify a document with one composite signature (valid only if both components verify)

Security Benefits:

  • HNDR Protection: Data remains secure even if quantum computers break classical algorithms
  • Defense in Depth: Both components must be broken to compromise data
  • Crypto-Agility: Component rotation supported without changing ciphertext format
  • Compliance: NIST CSWP 39, GSA PQC Buyer's Guide, NSM-10 aligned

API Endpoints:

  • POST /api/v3/crypto/stream/encrypt (composite KEM emits a multi-recipient General JSON JWE)
  • POST /api/v3/crypto/stream/decrypt (enforces the composite AND-decrypt)
  • POST /api/v3/crypto/stream/sign (transparent - works with composite KID; emits a detached flattened JWS JSON with "b64": false, RFC 7797)
  • POST /api/v3/crypto/stream/verify (verifies the composite signature: both components must verify)

Prerequisite: a cli.properties for the playground actor of the demo environment, carrying the ankasecure.demo.kids catalogue (supplied with the playground credentials). Key lifecycle (generate/rotate/export) lives in the Key Management SDK, not in this SDK.

See Also:

  • Method Details

    • main

      public static void main(String[] args)