Supported Algorithms — Encryption, Key Exchange & Signatures

ANKASecure release: v3.0.0

Last update: Standards attributions re-derived from the algorithm catalogue; the per-algorithm "Policy Templates" column was removed (29 templates, see §13)

Algorithm Coverage Summary

Market Coverage (29 Policy Templates Available):

• 🌎 Global: NIST (15 families), ISO (all certified), IETF (Internet protocols)
• 🇺🇸 USA Federal: NIST_APPROVED template (all FIPS + PQC finalists)
• 🇺🇸 USA Defense: US_NSA_CNSA template (CNSA 2.0 quantum-resistant suite)
• 🇪🇺 European Union: EU_COMPLIANT template (ENISA levels 3-5)
• 🇩🇪 Germany: BSI_COMPLIANT template (TR-02102-1, includes FRODO)
• 🇫🇷 France: ANSSI_COMPLIANT template (Defense, includes FALCON)
• 🇪🇺 EU Telecom: ETSI_QSC template (5G/6G, includes HQC)
• 🇯🇵 Japan: JAPAN_CRYPTREC template (e-Government Recommended Ciphers)
• 🇨🇳 China: CHINA_GMT_COMPLIANT template (SM2, SM3, SM4 mandatory)
• 🇰🇷 South Korea: KOREA_KCMVP template (SEED, ARIA, AES via KISA/ISO)
• 🇲🇾 Malaysia: MALAYSIA_MYSEAL template (28 algorithms approved)
• 🇷🇺 Russia: GOST_COMPLIANT template (Federal Law 149-FZ mandatory)
• 🇸🇦 Saudi Arabia: SAUDI_NCA_COMPLIANT template (NCA-NCS-1:2020)
• 🏦 Finance Sector: FINANCE_COMPLIANT template (PCI-DSS, SOC2, ISO 27001)
• 🔄 PQC Migration: PQC_TRANSITION template (Hybrid classical+PQC)

Security Posture:

• ✅ 100% symmetric encryption is AEAD (authenticated)
• ✅ 20 post-quantum algorithms (quantum-safe)
• ✅ FIPS 140-3 ready (NIST SP 800-90A DRBG, requires FIPS-certified HSM for operational compliance)
• ✅ RFC 7515/7516/7518 compliant (JWS/JWE/JWA)

Quick Start Guide

For Encryption (Confidentiality)

• Quantum-safe: Use ML-KEM-768, or ML-KEM-1024 ✅ where an NSA/CNSA 2.0 attribution is required
• High performance: Use AES-256-GCM ✅ or ChaCha20-Poly1305
• Japan market: Use Camellia-GCM-256 (CRYPTREC)
• Korea market: Use ARIA-GCM-256 (modern, ISO) or SEED-GCM-128 (legacy)
• China market: Use SM4-GCM-128 or AES-256-GCM (GM/T compliance)
• Russia market: Use HMAC-Streebog for MAC, GOST-R34.10-2012 for signatures (encryption pending MGM implementation)
• Saudi Arabia market: Use AES-256-GCM or Camellia-GCM-256 (NCA NCS)

For Digital Signatures (Non-repudiation)

• Quantum-safe: Use ML-DSA-65, or ML-DSA-87 ✅ where an NSA/CNSA 2.0 attribution is required
• Compact size: Use Falcon-512
• Classical: Use ECDSA P-384 ✅ (NSA, CNSA 2.0 transitional)
• China market: Use SM2
• Russia market: Use GOST-R34.10-2012-256

For Message Authentication (Integrity, Shared Key)

• General use: Use HMAC-SHA384 ✅ (NSA, CNSA 2.0)
• High throughput: Use HMAC-SHA256
• China market: Use HMAC-SM3
• Russia market: Use HMAC-Streebog-512

Reading the Standards column

The Standards column of every table below lists the standards bodies that have endorsed that exact algorithm, taken verbatim from the platform's algorithm catalogue — the same source the API serves at GET /api/v3/key-management/algorithms/catalog. It is an attribution, not a claim of availability: an algorithm is listed under a body only where that body's own published specification covers it. An algorithm carries no attribution it cannot support, so a short list is a deliberate statement, not an omission.

These tables no longer carry a "Policy Templates" column. Whether a given algorithm is usable depends on the policy template your tenant is assigned and on how your operator has configured it, and it is decided by two different authorization paths — a standalone key is evaluated against all six template criteria, while a post-quantum algorithm under a hybrid-mandate template is reachable only as a component of a composite. A static per-algorithm cell cannot state that truthfully for every deployment. Read the template inventory in §13 for what each template is for, and call GET /api/v3/key-management/algorithms/catalog for the authoritative, live list of the algorithms your tenant may actually use.

1 • Encryption and Key Exchange (Confidentiality)

Purpose: Protect data confidentiality using encryption
Key Characteristic: Prevents unauthorized reading of data

1.1 • Post-Quantum Key Encapsulation (Quantum-safe)

1.2 • Classical Asymmetric Encryption

1.3 • Symmetric Authenticated Encryption (AEAD)

Note: All symmetric encryption in ANKASecure is AEAD (provides confidentiality + integrity)

2 • Digital Signatures (Non-repudiation, Asymmetric)

Purpose: Prove WHO signed a document (non-repudiation)

Key Characteristic: Requires private key to sign, anyone can verify with public key

2.1 • Post-Quantum Signatures (Quantum-safe)

2.2 • Classical Asymmetric Signatures

2.3 • Stateful Hash-based Signatures ⚠️

Critical Warning: These algorithms maintain state (signature counter) and are incompatible with stateless REST APIs.

Why not recommended: ANKASecure is a stateless REST API. Stateful signatures require:

• Persistent counter storage across requests
• State backup and recovery mechanisms
• No support for distributed/load-balanced deployments

Alternatives: Use ML-DSA or SLH-DSA (stateless post-quantum signatures)

3 • Message Authentication Codes - MACs (Integrity, Symmetric)

Purpose: Verify message integrity and authenticity with shared secret key

Key Characteristic: Fast authentication, but BOTH parties share the same key (repudiable)

When to use MACs vs Signatures:

• ✅ Use MACs: Internal APIs, JWT between your services, high-throughput
• ❌ Use Signatures: Contracts, third-party verification, non-repudiation needed

3.1 • HMAC (Hash-based Message Authentication Code)

How it works: Combines a hash function with a secret key using nested hashing

Standard: RFC 2104 (HMAC), NIST FIPS 198-1

Variants (different hash functions):

All HMAC variants:

• ✅ Quantum-resistant (Grover bounded)
• ✅ Fast (software optimized)
• ✅ Widely supported

3.2 • CMAC (Cipher-based Message Authentication Code)

How it works: Uses a block cipher (AES) in CBC mode to create MAC

Standard: NIST SP 800-38B, RFC 4493

Variants (different key sizes):

When to use CMAC:

• ✅ Hardware with AES acceleration
• ✅ Existing AES infrastructure
• ⚠️ Otherwise prefer HMAC (more flexible, easier to implement)

3.3 • KMAC (Keccak Message Authentication Code)

How it works: SHA-3 derived function with variable-length output

Standard: NIST SP 800-185

Variants:

When to use KMAC:

• ✅ Require SHA-3 family (FIPS 202)
• ✅ Need customizable output length
• ⚠️ Otherwise prefer HMAC-SHA384 (more widely supported)

4 • Understanding Cryptographic Constructions

What is a Construction?

A construction is a cryptographic recipe that takes a base primitive (hash, cipher) and builds a higher-level operation:

HMAC (Construction):
├─ Input: Hash function + secret key
├─ Process: Nested hashing with key mixing
├─ Output: Message authentication code
└─ Variants: HMAC-SHA256, HMAC-SHA384, HMAC-SM3, etc.
    (Same construction, different hash functions)

CMAC (Construction):
├─ Input: Block cipher + secret key
├─ Process: CBC-MAC with cipher
├─ Output: Message authentication code
└─ Variants: CMAC-AES-128, CMAC-AES-256
    (Same construction, different key sizes)

Algorithm vs Construction vs Variant

Key Insight: ANKASecure has ~15 base algorithms but ~50 variants (configurations).

Why Multiple Variants?

1. Security Strength Matching:

HMAC-SHA256: 128-bit security (good for most uses)
HMAC-SHA384: 192-bit security (CNSA 2.0 requirement)
HMAC-SHA512: 256-bit security (maximum classical)

2. Regional Compliance:

HMAC-SHA256: Global (NIST, ISO)
HMAC-SM3: China (GB/T mandatory)

3. Performance Trade-offs:

HMAC-SHA256: Fastest
HMAC-SHA512: Slightly slower, stronger
CMAC-AES-256: Hardware accelerated if AES-NI available

5 • Algorithm Selection Guide

5.1 • For Encryption Decision Tree

graph TD
    Start(["What security model?"])

    Start --> QSafe{"Need quantum-safe<br/>future-proof?"}
    Start --> Classical{"Classical asymmetric<br/>pre-2030?"}
    Start --> Symmetric{"Symmetric bulk<br/>encryption?"}

    QSafe -->|YES| MLKEM["ML-KEM-768<br/>ML-KEM-1024 ✅ NSA"]

    Classical -->|RSA Legacy| RSAOAEP["RSA-OAEP-512<br/>All key sizes 2048-8192"]
    Classical -->|EC Modern| ECDH["ECDH-ES+A256KW<br/>P-384 ✅ CNSA 2.0"]

    Symmetric --> Market{"Which market?"}
    Market -->|Global Standard| AES["AES-256-GCM ✅<br/>CNSA 2.0"]
    Market -->|High Performance| ChaCha["ChaCha20-Poly1305<br/>Mobile/Web optimized"]
    Market -->|Japan| Camellia["Camellia-GCM-256<br/>CRYPTREC certified"]
    Market -->|Korea| SEED["SEED-GCM-128<br/>KISA compliance"]
    Market -->|China| AESChina["AES-256-GCM<br/>GB/T compatible"]

    style MLKEM fill:#90EE90
    style AES fill:#90EE90
    style ECDH fill:#90EE90
    style ChaCha fill:#87CEEB
    style Camellia fill:#FFD700
    style SEED fill:#FFA500
    style AESChina fill:#FF6B6B
    style RSAOAEP fill:#D3D3D3

5.2 • For Signatures Decision Tree

graph TD
    Start(["Need to authenticate<br/>a message or document?"])

    Start --> NonRepud{"Need non-repudiation?<br/>Prove WHO signed?"}

    NonRepud -->|YES - Asymmetric| AsymType{"Quantum-safe<br/>or Classical?"}
    NonRepud -->|NO - MAC OK| MACType{"Which MAC<br/>construction?"}

    AsymType -->|Quantum-Safe| PQC{"Primary use case?"}
    AsymType -->|Classical| Classic{"Which market?"}

    PQC -->|General/Financial| MLDSA["ML-DSA-65<br/>ML-DSA-87 ✅ NSA"]
    PQC -->|Compact signatures| Falcon["Falcon-512<br/>Smallest size"]
    PQC -->|Hash-based backup| SLHDSA["SLH-DSA-192s/256s<br/>NIST, BSI, ANSSI, ENISA"]

    Classic -->|Global| ECDSA384["ECDSA P-384 ✅<br/>CNSA 2.0 transitional"]
    Classic -->|China GB/T| SM2["SM2<br/>GB/T 32918 required"]
    Classic -->|Legacy PKI| RSAPSS["RSA-PSS<br/>PS256"]

    MACType -->|CNSA 2.0?| CNSAMAC{"NSA compliance?"}
    MACType -->|General| GeneralMAC["HMAC-SHA256<br/>Fast, widely supported"]
    MACType -->|Regional| Regional{"Which region?"}

    CNSAMAC -->|YES| CNSACHOICE{"HMAC or CMAC?"}
    CNSACHOICE -->|HMAC preferred| HMAC384["HMAC-SHA384 ✅<br/>CNSA 2.0"]
    CNSACHOICE -->|AES hardware| CMAC256["CMAC-AES-256<br/>NIST, ISO"]

    Regional -->|China| HMAC_SM3["HMAC-SM3<br/>GB/T compliance"]
    Regional -->|SHA-3 required| KMAC["KMAC256<br/>NIST SP 800-185"]

    style MLDSA fill:#90EE90
    style SLHDSA fill:#90EE90
    style ECDSA384 fill:#90EE90
    style HMAC384 fill:#90EE90
    style CMAC256 fill:#90EE90
    style Falcon fill:#87CEEB
    style SM2 fill:#FF6B6B
    style HMAC_SM3 fill:#FF6B6B
    style GeneralMAC fill:#D3D3D3
    style RSAPSS fill:#D3D3D3
    style KMAC fill:#FFB6C1

5.3 • Key Differences: MACs vs Signatures

6 • Detailed Algorithm Specifications

6.1 • Symmetric AEAD Algorithms

AES-GCM (Advanced Encryption Standard - Galois/Counter Mode):

• Mode: AEAD (Authenticated Encryption with Associated Data)
• IV: 12 bytes (96 bits), automatically generated
• Tag: 16 bytes (128 bits), automatically appended
• Standards: NIST SP 800-38D, ISO/IEC 19772, RFC 5288
• Cipher: Cipher.getInstance("AES/GCM/NoPadding")

ChaCha20-Poly1305:

• Type: Stream cipher with Poly1305 MAC (AEAD)
• Nonce: 12 bytes, automatically generated
• Tag: 16 bytes (Poly1305 MAC)
• Standards: IETF RFC 8439
• Performance: Optimized for software, excellent on ARM/mobile

Camellia-GCM:

• Type: Block cipher (128-bit blocks) with GCM mode
• Origin: Japan (NTT, Mitsubishi)
• Standards: ISO/IEC 18033-3, CRYPTREC, MySEAL AKSA (Camellia was also a NESSIE portfolio selection in 2003 — historical provenance, not a platform standards attribution)
• Purpose: Asian market alternative to AES (Japan, Malaysia)

ARIA-GCM and ARIA-CCM:

• Type: Block cipher (128-bit blocks) with GCM/CCM modes
• Origin: Korea (developed by KISA, standardized 2004)
• Standards: ISO/IEC 18033-3 (2010), IETF RFC 5794, KISA

• Variants:

  • ARIA-GCM-128/192/256: GCM mode for high performance
  • ARIA-CCM-128/192/256: CCM mode for constrained devices

• IV: 12 bytes (96 bits), automatically generated

• Tag: 16 bytes (128 bits), authenticated encryption
• Cipher: Cipher.getInstance("ARIA/GCM/NoPadding") or ARIA/CCM/NoPadding
• Purpose: Korean government and industry compliance (selected as Korean standard 2004)
• Use Cases: Korean market alternative to AES, KCMVP certification requirements
• History: Winner of Korean cipher competition, now ISO standard

SEED-GCM:

• Type: Block cipher (128-bit blocks) with GCM mode
• Origin: Korea (KISA, 1998)
• Standards: KISA, CRYPTREC, ISO/IEC 18033-3, IETF RFC 4269
• Purpose: Korean government compliance (first Korean cipher standard, now legacy)
• Note: ARIA is the modern Korean standard (2004), SEED maintained for compatibility

SM4-GCM and SM4-CCM:

• Type: Block cipher (128-bit blocks) with GCM/CCM modes
• Origin: China (State Cryptography Administration)
• Standards: GM/T 0002-2012 (Chinese national standard), ISO/IEC 18033-3:2010/Amendment 1:2021

• Variants:

  • SM4-GCM-128: GCM mode (Galois/Counter) for high performance
  • SM4-CCM-128: CCM mode (Counter with CBC-MAC) for constrained devices

• IV: 12 bytes (96 bits), automatically generated

• Tag: 16 bytes (128 bits), authenticated encryption
• Cipher: Cipher.getInstance("SM4/GCM/NoPadding") or SM4/CCM/NoPadding
• Purpose: Chinese government GM/T (Guó Mì / 国密) compliance
• Use Cases: Chinese market, cross-border data, GB/T regulatory requirements

6.2 • Asymmetric Encryption Methods

RSA-OAEP-512:

• Method: RSA with OAEP padding using SHA-512 and MGF1
• JWE Algorithm: RSA-OAEP-512
• All key sizes (2048-8192) use SHA-512 (CNSA 2.0 hash function)
• Standards: RFC 8017, RFC 7518

ECDH-ES+A256KW:

• Method: Elliptic Curve Diffie-Hellman Ephemeral-Static + AES-256 Key Wrap
• JWE Algorithm: ECDH-ES+A256KW
• KDF: Concat KDF with SHA-256 (NIST SP 800-56A)
• Key Wrap: AES-256-KW (RFC 3394)
• Ephemeral key included in JWE "epk" header field
• Standards: RFC 7518 Section 4.6, NIST SP 800-56A
• Supported in: Both compact and streaming (detached) JWE modes

ML-KEM (Kyber):

• Method: Lattice-based Key Encapsulation Mechanism
• JWE Algorithm: ML-KEM-512/768/1024
• Standards: NIST FIPS 203
• CNSA 2.0: ML-KEM-1024 carries the NSA attribution for the 2030+ PQC transition

FrodoKEM (Conservative Lattice-based KEM):

• Method: Learning With Errors (LWE) based Key Encapsulation
• JWE Algorithm: FRODO-640/976/1344
• Standards: BSI TR-02102-1 (German Federal Office for Information Security)

• Parameter Variants:

  • FRODO-640: 128-bit security (conservative mapping to Level III)
  • FRODO-976: 192-bit security (BSI recommended, Level III)
  • FRODO-1344: 256-bit security (maximum strength, Level V)

• PRF: AES-based (all variants use -AES suffix internally)

• Use Cases: Long-term archives (>30-50 years), conservative PQC deployments
• Trade-off: Larger keys/ciphertexts than ML-KEM (more conservative security assumption)
• Why FrodoKEM?: Based on well-studied LWE problem (older research than ML-KEM's Module-LWE)

• Technical: Uses FrodoParameterSpec.frodokem{640|976|1344}aes HQC (Hamming Quasi-Cyclic):

• Method: Code-based Key Encapsulation Mechanism

• JWE Algorithm: HQC-128/192/256
• Standards: ETSI Quantum-Safe Cryptography (not NIST-standardized)

• Parameter Variants:

  • HQC-128: 128-bit security (Level I)
  • HQC-192: 192-bit security (Level III)
  • HQC-256: 256-bit security (Level V)

• Use Cases: European markets, VPN endpoints, email encryption

• Trade-off: Fast key generation, moderate ciphertext size
• Why HQC?: Alternative mathematical foundation (code-based vs lattice-based)

Classic McEliece (CMCE - Code-based KEM):

• Method: Goppa code-based Key Encapsulation (oldest PQC approach)
• JWE Algorithm: CMCE-460896/6688128
• Standards: NIST PQC Round 4 Finalist, BSI TR-02102 recommended fallback

• Parameter Variants:

  • CMCE-460896: 192-bit security (Level III)
  • CMCE-6688128: 256-bit security (Level V)

• Technical: Uses CMCEParameterSpec.mceliece{460896|6688128}- Use Cases: Ultra-conservative deployments, defense, 40+ year archives

• Trade-off: Largest keys/ciphertexts (>250 KB public keys) but 40+ years of cryptanalysis
• Why CMCE?: Most conservative PQC choice (oldest mathematical foundation, 1978)
• Regional: Germany (BSI high-assurance), Netherlands (NLNCSA), EU defense

BIKE (Code-based KEM):

• Method: Quasi-Cyclic Moderate Density Parity Check codes
• JWE Algorithm: BIKE-128/192/256
• Standards: NIST PQC Round 4 Alternate, ETSI experiments

• Parameter Variants:

  • BIKE-128: 128-bit security (Level I)
  • BIKE-192: 192-bit security (Level III)
  • BIKE-256: 256-bit security (Level V)

• Technical: Uses BIKEParameterSpec.bike{128|192|256}- Use Cases: VPN, TLS experiments, low-memory systems

• Trade-off: Fast, low CPU usage, moderate ciphertext size
• Why BIKE?: Lightweight code-based alternative with good performance
• Regional: EU (ETSI TLS PQC trials), Canada (CMC research)

SABER (Lattice Module-LWR KEM):

• Method: Module Learning With Rounding (not LWE)
• JWE Algorithm: LIGHTSABER-128/SABER-192/FIRESABER-256
• Standards: NIST PQC Round 3 Finalist, Horizon Europe projects

• Parameter Variants:

  • LIGHTSABER-128: 128-bit security (Level I)
  • SABER-192: 192-bit security (Level III)
  • FIRESABER-256: 256-bit security (Level V)

• Technical: Uses SABERParameterSpec.{light|saber|fire}saberkem{...}r3- Use Cases: IoT, embedded systems, hardware-efficient deployments

• Trade-off: Excellent performance on ARM/embedded, smaller than ML-KEM
• Why SABER?: Optimized for resource-constrained devices
• Regional: EU (Belgium - Université Catholique de Louvain), India (academic research)

NTRU (Lattice-based KEM):

• Method: NTRU lattice polynomials (historical PQC)
• JWE Algorithm: NTRU-701/1373
• Standards: NIST PQC Round 3 Finalist, ISO/IEC 18033-2, IEEE P1363.1

• Parameter Variants:

  • NTRU-701: 192-bit security (Level III - HRSS variant)
  • NTRU-1373: 256-bit security (Level V - HRSS variant)

• Technical: Uses NTRUParameterSpec.ntruhrss{701|1373}- Use Cases: High-speed applications, IoT gateways, low-latency networks

• Trade-off: Fastest PQC KEM, compact ciphertexts
• Why NTRU?: Speed advantage, basis for South Korea's NTRU+ national standard
• Regional: USA (historical), South Korea (NTRU+ base), EU (academic)

NTRU Prime (Lattice-based KEM):

• Method: Prime-degree NTRU with cleaner security proofs
• JWE Algorithm: NTRUPRIME-761/857
• Standards: NIST PQC Round 3 Alternate, IETF draft

• Parameter Variants:

  • NTRUPRIME-761: 192-bit security (Level III)
  • NTRUPRIME-857: 256-bit security (Level V)

• Technical: Uses NTRULPRimeParameterSpec.ntrulpr{761|857}- Use Cases: Conservative NTRU deployments without structured assumptions

• Trade-off: Similar speed to NTRU, simpler parameter generation
• Why NTRU Prime?: NTRU without structured ring assumptions (cleaner proofs)
• Regional: USA/Canada research, EU cryptography labs

6.3 • MAC Constructions Explained

HMAC Construction (RFC 2104):

HMAC(K, m) = H((K ⊕ opad) || H((K ⊕ ipad) || m))

Where:

- K = secret key
- m = message
- H = hash function (SHA-256, SHA-384, SM3, etc.)
- opad, ipad = padding constants

Why different variants:

• HMAC-SHA256: Uses SHA-256 as H (fast, 128-bit security)
• HMAC-SHA384: Uses SHA-384 as H (CNSA 2.0, 192-bit security)
• HMAC-SM3: Uses SM3 as H (China GB/T, 256-bit)

They are the SAME algorithm (HMAC), just with different hash functions.

7 • NSA CNSA 2.0 Approved Algorithms

The U.S. National Security Agency (Sep 2022) requires these specific algorithms for national security systems:

The table below separates two facts that are easy to conflate: whether ANKASecure catalogues an NSA attribution for the algorithm, and whether the shipped US_NSA_CNSA template admits it. They are not the same, and the second is far narrower than the first.

CNSA 2.0 Restrictions:

• ❌ NO 128-bit symmetric algorithms (only AES-256)
• ❌ NO RSA (quantum-vulnerable, removed from CNSA 2.0)
• ❌ NO Elliptic Curve (P-384 deprecated in Sep 2022, removed from CNSA 2.0)
• ❌ NO Level I or Level II PQC (only Level V)

US_NSA_CNSA Template Configuration (the shipped default, verbatim):

{
  "explicitAlgorithms": ["AES-GCM-256", "AES-CCM-256"],
  "allowedFamilies": ["ML-KEM", "ML-DSA", "oct"],
  "allowedLevels": ["L5"],
  "mandatoryStandards": ["NSA"]
}

The allowedFamilies, allowedLevels and mandatoryStandards entries above are inert — they are retained only as a record of the template's intent, and are never evaluated while explicitAlgorithms is non-empty.

Effective Timeline:

• Sep 2022 - 2030: Transition period (EC P-384 allowed in other templates, but not CNSA 2.0)
• 2030+: Pure PQC (ML-KEM, ML-DSA, XMSS/LMS)

8 • Regional Compliance Matrix

Policy Template Coverage by Region:

• 🇺🇸 USA Federal: NIST_APPROVED template (all FIPS + PQC finalists)
• 🇺🇸 USA Defense: US_NSA_CNSA template (CNSA 2.0 - AES-GCM-256 and AES-CCM-256 only; see the explicitAlgorithms note in §7)
• 🇩🇪 Germany: BSI_COMPLIANT template (FRODO, CMCE for high-assurance)
• 🇫🇷 France: ANSSI_COMPLIANT template (FALCON for defense/eID)
• 🇪🇺 EU Telecom: ETSI_QSC template (HQC backup for 5G/6G)
• 🇪🇺 EU General: EU_COMPLIANT template (ENISA levels 3-5)
• 🇯🇵 Japan: JAPAN_CRYPTREC template (Camellia national cipher; ARIA carries no CRYPTREC attribution)
• 🇰🇷 South Korea: KOREA_KCMVP template (SEED, ARIA via KISA tags)
• 🇨🇳 China: CHINA_GMT_COMPLIANT template (SM2/3/4 mandatory by law)
• 🇷🇺 Russia: GOST_COMPLIANT template (Streebog, GOST-EC mandatory by Federal Law)
• 🇸🇦 Saudi Arabia: SAUDI_NCA_COMPLIANT template (NCA-NCS-1:2020 classical only)
• 🇲🇾 Malaysia: MALAYSIA_MYSEAL template (28 approved algorithms)
• 🌐 Internet: IETF_RFC template (TLS, VPN, SSH protocols)
• 🌐 International: GLOBAL_ISO_COMPLIANT template (all ISO-certified algorithms)
• 🏦 Finance: FINANCE_COMPLIANT template (PCI-DSS, SOC2, ISO 27001)

9 • NIST Post-Quantum Security Levels

CNSA 2.0: Only Level III and V approved

10 • Regulatory Standards Reference

PQC Round Classification:

• NIST FIPS (Standardized): ML-KEM (FIPS 203), ML-DSA (FIPS 204), SLH-DSA (FIPS 205)
• Round 4 Finalists: Classic McEliece (carries ISO + BSI; NIST never standardized it)
• Round 4 Alternates: BIKE
• Round 3 Finalists: SABER, NTRU
• Round 3 Alternates: NTRU Prime
• Non-NIST: FrodoKEM (BSI), Classic McEliece (ISO in progress + BSI). HQC is not in this group — NIST selected it in March 2025 as the Round-4 backup KEM, so it carries both NIST and ETSI.

11 • Implementation Notes

Crypto-Agility in ANKASecure

Key Generation (algorithm-agnostic):

POST /api/keys/generate
{
  "alg": "<any-algorithm>",  // ML-KEM-768, HMAC-SM3, SM2, etc.
  "kid": "<unique-id>",
  "key_ops": ["sign", "verify"]  // or ["encrypt", "decrypt"]
}

Usage (algorithm-agnostic):

POST /api/crypto/sign
{
  "kid": "<the-kid-you-generated>",  // System auto-detects algorithm
  "data": "<base64-data>"
}

System Behavior:

1. Reads key metadata from keystore
2. Detects key type (kty: "oct" = symmetric, "EC" = asymmetric, etc.)
3. Routes to appropriate service (SymmetricCryptoService or AsymmetricCryptoService)
4. Selects correct cryptographic primitive based on alg field
5. Performs operation
6. Returns result in standard format (JWE, JWS)

You can switch algorithms without changing client code - just change alg during key generation.

Automatic Security Features

• ✅ IV/Nonce Generation: Automatically generated per operation (no user management)
• ✅ Key Size Validation: System enforces correct key sizes per algorithm
• ✅ Operation Validation: key_ops enforced (can't encrypt with sign-only key)
• ✅ Algorithm Matching: Header alg must match key's actual algorithm
• ✅ FIPS Mode: Enable with -Dcrypto.random.fips-mode=true (NIST SP 800-90A DRBG)

Supported Modes

Both modes use the same cryptographic algorithms - only packaging differs.

12 • Security Considerations

Quantum Resistance (Grover's Algorithm)

Symmetric algorithms are quantum-resistant but with reduced effective security:

CNSA 2.0 Guidance: Use ≥256-bit symmetric keys for post-2030 security.

Key Lifecycle

ANKASecure enforces key usage limits based on operation type:

Key Features:

• ✅ Automatic expiration: Keys marked as EXPIRED when limit reached
• ✅ Soft limits: Warning at 80% of max usage (40K decrypt, 80K sign, 4M encrypt)
• ✅ Time-based expiration: Default 2 years, with 2-month grace period
• ✅ Thread-safe: Atomic counters for concurrent operations
• ✅ NIST compliant: All limits well below NIST SP 800-38D recommendations

Why different limits?:

• Decrypt (most conservative): Higher exposure to chosen-ciphertext attacks
• Sign (moderate): Balances security with CA and signing service needs
• Encrypt/Verify (least restrictive): Minimal security risk, supports high-volume APIs

These limits provide strong security while supporting production workloads and are based on NIST SP 800-38D, SP 800-57, and BSI TR-02102-1 guidelines.

13 • Algorithm Availability Policy Templates

ANKASecure ships 29 pre-configured policy templates that control which algorithms tenants can use. Each template aligns with specific regulatory standards or use cases.

A template is a starting point: your operator assigns one per tenant and may adjust it. The template names below are the shipped defaults — call GET /api/v3/key-management/algorithms/catalog for the algorithms your own tenant may use.

13.1 • Core Templates (Basic Filtering)

13.2 • Regional Compliance Templates

13.3 • Sector-Specific Templates

13.4 • Hybrid-Mandate Templates

These templates change how a post-quantum algorithm may be used, not only which ones are available. Where a template sets requireComposite, a standalone post-quantum key is refused and the algorithm is reachable only as a component of a composite (hash-based signatures — SLH-DSA, XMSS, LMS — are exempt from the mandate and remain creatable standalone).

13.5 • Template Selection Guide

For USA Government:

• Federal agencies → NIST_APPROVED
• DoD/IC/NSS → US_NSA_CNSA

For European Market:

• General EU → EU_COMPLIANT
• Germany → BSI_COMPLIANT
• France → ANSSI_COMPLIANT
• Telecom → ETSI_QSC

For Asian Markets:

• China → CHINA_GMT_COMPLIANT (mandatory by law)
• Japan → JAPAN_CRYPTREC
• South Korea → KOREA_KCMVP (SEED, ARIA national ciphers)
• Malaysia → MALAYSIA_MYSEAL

For Russia/CIS:

• All sectors → GOST_COMPLIANT (mandatory by law)

For Global Operations:

• Multi-national → GLOBAL_ISO_COMPLIANT
• Internet services → IETF_RFC
• Financial services → FINANCE_COMPLIANT
• PQC migration → PQC_TRANSITION

13.6 • How Templates Work

A standalone key request is filtered using 6 criteria (evaluated in priority order):

1. explicitAlgorithms (override): If specified, ONLY these algorithms are allowed
2. allowedFamilies (filter): Algorithm family must match (e.g., "ML-KEM", "oct" for symmetric)
3. allowedCategories (filter): Must be POST_QUANTUM, CLASSICAL or HYBRID
4. allowedLevels (filter): Security level must match (1, 3, or 5)
5. mandatoryStandards (filter): Algorithm must have at least ONE matching standard tag
6. allowedOperations (filter): Operations must be subset of allowed

A composite key request is filtered by name against explicitAlgorithms and allowedOperations, then against the template's allowedCompositeModes, allowedKdfs and minSecurityLevel. This is why a template's algorithm coverage cannot be reduced to one list — the same template can admit an algorithm in composite form while refusing it standalone.

Example (JAPAN_CRYPTREC template):

{
  "allowedFamilies": ["ML-KEM", "ML-DSA", "RSA", "EC", "OKP", "XMSS", "LMS", "oct"],
  "mandatoryStandards": ["CRYPTREC"]
}

This allows:

• ✅ ML-KEM-512/768/1024 (have CRYPTREC tag, family matches)
• ✅ AES-GCM-256 (has CRYPTREC tag, family "oct" matches)
• ✅ Camellia-GCM-256 (has CRYPTREC tag, family "oct" matches)
• ❌ HQC-128 (has ETSI and NIST tags, but NOT CRYPTREC tag)

© 2025 ANKATech Solutions INC. All rights reserved.