Composite Algorithms Catalog (41 Valid Combinations)

Note: This catalog covers composite (hybrid) algorithms that combine classical + PQC components. For single-component algorithms, see Simple Algorithms Catalog (89 algorithms). For a complete overview of all 130 algorithms, see Complete Catalog Overview.

The code catalogue is the authority. CompositeAlgorithmCatalogue in ankasecure-common-algorithms declares the composites, the second naming plane behind the AlgorithmVocabulary façade. A composite operation is metered and audited under its own composite name — X25519+ML-KEM-768, not a COMPOSITE bucket — so an invoice and a signed audit row can tell one composite from another; the composite mode is a property of a composite, not its identity. The catalogue holds the 41 combinations below, and GET /api/v3/key-management/supported-algorithms returns the authoritative list.

Overview

The ANKASecure platform supports 41 composite algorithm combinations that pair classical cryptography with Post-Quantum Cryptography (PQC). These combinations are categorized into two composite modes:

• COMPOSITE_KEM_COMBINE: 27 combinations for hybrid encryption (classical + PQC key encapsulation)
• OKP family: 10 combinations (X25519: 4, X448: 6)
• P-curves family: 14 combinations (P-256: 4, P-384: 6, P-521: 4)
• Brainpool KEM: 3 combinations (brainpoolP256r1, brainpoolP384r1, brainpoolP512r1 with ML-KEM)
• ML-KEM: 15 combinations across all classical curves (NIST FIPS 203 standardized)
  • ETSI scope: exactly 10 of the 15 carry the ETSI attribution — see ETSI TS 103 744 pairing scope below.
• HQC: 12 combinations across all classical curves. All carry ETSI as an in-progress attribution (ETSI standardization of HQC is in progress, no published deliverable). NIST's FIPS 207 is not yet published, so the HQC half earns a pair no NIST (the stand-alone HQC profiles carry NIST only as a declared exception, which a pair does not inherit); the 7 pairs on P-256/P-384/P-521 carry NIST through their SP 800-56A ECDH half (SP 800-227 §4.6.2), and the 5 on X25519/X448 carry ETSI only

• RSA excluded: Not allowed in composite keys

• COMPOSITE_SIGNATURE: 14 combinations for composite digital signatures (one signature from a classical and a PQC algorithm)

• EdDSA family: 4 combinations (Ed25519: 2, Ed448: 2)
• ECDSA P-curves: 7 combinations (P-256: 2, P-384: 3, P-521: 2)
• ECDSA Brainpool: 3 combinations (brainpoolP256r1: 1, brainpoolP384r1: 1, brainpoolP512r1: 1)
• All with ML-DSA (NIST FIPS 204 standardized)

Every combination is a hybrid of one classical and one post-quantum component, and the platform catalogue enforces a security level difference ≤ 2 constraint between them to maintain balanced cryptographic strength. The platform supports NIST-standardized algorithms (ML-KEM per FIPS 203, ML-DSA per FIPS 204) and HQC, whose ETSI and NIST standardization is still in progress, for algorithm diversity.

The Standards column of every pairing table below is the pair's catalogue standards() set. A pair carries a body only when that body recommends both components, with two exceptions the catalogue states. NIST on a KEM pair follows NIST SP 800-227 §4.6.2 literally — the combiner is approved when at least one shared secret comes from an approved KEM or an SP 800-56A key-establishment method — so a pair carries NIST when its post-quantum half is ML-KEM or its classical half is ECDH on P-256, P-384 or P-521 (SP 800-56A r3 Appendix D Table 24); X25519, X448 and the Brainpool curves earn nothing through the classical half. ETSI follows the pairs ETSI enumerates (TS 103 744 §7.7.2 for KEMs, TS 119 312 Table 3.3 for signatures). No pair on X25519, X448, Ed25519 or Ed448 carries ENISA, BSI or ANSSI, because none of those bodies names Curve25519, Curve448 or EdDSA. No pair carries NSA: a hybrid is not a CNSA 2.0 algorithm.

This catalog complements the Simple Algorithms Catalog (89 total algorithms) by documenting specifically which composite pairings are supported and why certain combinations are excluded.

ETSI TS 103 744 Pairing Scope

ETSI TS 103 744 V1.2.1 (2025-03) clause 7.7.2 normatively enumerates the KDF_CURVE_KEM parameter sets an implementation shall use. The constraint it imposes is at the level of the (curve, KEM) pairing, not the curve alone — a curve appearing in the normative curve list of clause 7.5 does not imply every KEM may be paired with it.

The enumerated pairings are:

P-521 and brainpoolP512r1 are absent from the enumeration: the specification's change history records their removal, and the CID enum leaves their slots vacant.

Applied to the platform's 15 ML-KEM composite combinations:

A combination without ETSI is fully supported by the platform; it simply carries no ETSI attribution, because the specification does not enumerate it and the catalogue never asserts more than its source states.

Composite Modes Overview

COMPOSITE_KEM_COMBINE (27 Combinations)

Hybrid Key Encapsulation Mechanism combining classical and PQC encryption for quantum-resistant confidentiality.

Key Characteristics:

• Semantics: AND-decrypt (ciphertext decryptable only if BOTH classical and PQC keys decrypt successfully)
• Format: JWE General JSON Serialization (RFC 7516 §7.2)
• KDF Options: HKDF-SHA256 (default), HKDF-SHA384, HKDF-SHA512, CatKDF, CasKDF — the KDF Specifications state what each token may claim
• Classical KEMs: OKP family (X25519, X448) + P-curves (P-256, P-384, P-521) + Brainpool (brainpoolP256r1, brainpoolP384r1, brainpoolP512r1)
• PQC KEMs: ML-KEM-512/768/1024 (NIST FIPS 203), HQC-128/192/256 (ETSI and NIST standardization in progress)
• Use Cases: Data encryption, secure messaging, key agreement
• RSA Exclusion: RSA algorithms marked allowedInComposite=false in algorithm catalog

Operational Flow (NIST SP 800-227, final, September 2025, §4.6.1):

1. Run the classical component as a real KEM (ECDH-KEM): the encapsulator's ephemeral public key is the ciphertext c_classical, and the ECDH agreement is the shared secret K_classical
2. Run the PQC component through its KEM API (ML-KEM or HQC): (K_pqc, c_pqc)
3. Derive the content-encryption key as the combiner's output, CEK = KeyCombine(K_classical, K_pqc, c_classical, c_pqc, ek_classical, ek_pqc, domain), instantiated by the key's kdf (see KDF Specifications)
4. Encrypt the payload with AES-256-GCM under the CEK; the protected header — which carries anka_kdf — is the additional authenticated data
5. The recipient decapsulates BOTH ciphertexts and recomputes the CEK; a wrong component secret yields a wrong CEK and the AES-GCM tag check fails

Security Guarantee: the CEK cannot be recomputed without both component secrets, so the data stays confidential as long as at least one algorithm remains unbroken. No secret is ever encrypted twice: nothing on the wire but the two KEM ciphertexts.

COMPOSITE_SIGNATURE (14 Combinations)

One composite signature from a classical and a PQC algorithm, for quantum-resistant authenticity.

Key Characteristics:

• Construction: the composite ML-DSA construction of draft-ietf-lamps-pq-composite-sigs-19 §3.2, applied to JOSE as draft-ietf-jose-pq-composite-sigs-04 §4.2 specifies it
• Semantics: all-or-nothing — the signature is valid only if BOTH components verify; there is no verification policy
• Format: a JWS with one signature (RFC 7515 §7.2.1 General JSON on the buffered routes; the flattened form with RFC 7797 b64:false on the detached streaming routes; the attached compact form as the inner JWS of streaming sign-encrypt); its protected header carries the composite alg, the kid, ank_kv and iat, plus exp when validityDays is requested (b64 and crit on the detached form)
• Algorithms: Classical signatures (Ed25519, Ed448, ECDSA P-256/384/521, ECDSA brainpoolP256r1/384r1/512r1) + PQC signatures (ML-DSA-44/65/87)
• Use Cases: Document signing, software distribution, API authentication

Operational Flow (JOSE draft §4.2):

1. Form M, the JWS Signing Input: the protected header and the payload (RFC 7515 §5.1)
2. Form the message representative M' from a fixed Prefix, the pairing's Label and the pre-hash PH(M)
3. Sign M' with ML-DSA, passing the Label as the ML-DSA context → mldsaSig
4. Sign M' with the classical algorithm → tradSig (an ECDSA component is a DER Ecdsa-Sig-Value)
5. Emit one signature value: mldsaSig followed by tradSig
6. The verifier recomputes M' and validates BOTH components

M'        = Prefix || Label || 0x00 || PH(M)        # Prefix = "CompositeAlgorithmSignatures2025"
signature = mldsaSig || tradSig

Each pairing's Label, pre-hash and composite JWS alg are listed in Composite signature algorithms.

Standing of the 14 pairings: 10 are IETF-defined algorithms — 6 carry the alg names of draft-ietf-jose-pq-composite-sigs-04 Table 5, and 4 are draft-ietf-lamps-pq-composite-sigs-19 §6 algorithms whose JOSE name is derived by that table's naming rule and is not registered in JOSE. The other 4 (Ed448+ML-DSA-65, P-384+ML-DSA-44, P-521+ML-DSA-65, brainpoolP512r1+ML-DSA-87) use the same construction with an ANKATech-defined ANKATECH-COMPSIG-* Label; no IETF claim is made for them.

Security Guarantee: a forgery must break both algorithms, so the signature holds as long as at least one algorithm remains unbroken. The construction gives weak non-separability (JOSE draft §6.3), not strong non-separability, and it is not strongly unforgeable (SUF-CMA) when its classical component is ECDSA (LAMPS §9.2.2).

Valid Combinations Matrix

COMPOSITE_KEM_COMBINE (27 Combinations)

Distribution by Family:

• OKP family: 10 combinations (X25519: 4, X448: 6)
• P-curves family: 14 combinations (P-256: 4, P-384: 6, P-521: 4)
• Brainpool family: 3 combinations (brainpoolP256r1: 1, brainpoolP384r1: 1, brainpoolP512r1: 1)
• By PQC type: 15 ML-KEM + 12 HQC

OKP Family Combinations (10 Total)

X25519 (L1) Combinations: 4 valid

X448 (L3) Combinations: 6 valid

P-Curves Family Combinations (14 Total)

P-256 (L1) Combinations: 4 valid

P-384 (L3) Combinations: 6 valid

P-521 (L5) Combinations: 4 valid

Brainpool Family Combinations (3 Total)

brainpoolP256r1 (L1) Combinations: 1 valid

brainpoolP384r1 (L3) Combinations: 1 valid

brainpoolP512r1 (L5) Combinations: 1 valid

Brainpool Characteristics:

• BSI TR-03111 Compliance: German Federal Office for Information Security recommended curves
• European Government: Required for certain EU public sector deployments
• Algorithm Transparency: Verifiable generation process (no NIST P-curve controversy)
• Security: Comparable to NIST P-curves but with transparent parameter selection

Notes:

• OKP Advantage: Smaller key sizes (X25519: 32 bytes, X448: 56 bytes) vs P-curves (P-256: 65 bytes, P-384: 97 bytes, P-521: 158 bytes)
• P-Curves Coverage: Full L1/L3/L5 coverage with all NIST standardized curves
• Brainpool Coverage: BSI TR-03111 compliant curves for European government compliance
• Security Level Distribution: 11 optimal matches (±0), 16 balanced matches (±2)

Excluded Combinations (RSA + Security Level Violations)

RSA Excluded from Composite Keys (marked allowedInComposite=false in algorithm catalog):

Security Level Violations (exceeds ±2 constraint):

Policy Rationale:

• X25519-only: RSA algorithms excluded from composite keys per algorithm catalog policy
• Algorithm diversity maintained: Both lattice-based (ML-KEM) and code-based (HQC) PQC families supported
• Security balance preserved: All valid combinations respect ±2 security level constraint
• RSA availability: RSA remains available for SIMPLE key operations

Algorithm Diversity Benefits (HQC Combinations):

• Mathematical Family Diversification: HQC (code-based) provides different security foundation than ML-KEM (lattice-based)
• Standardization status: ETSI standardization of HQC is in progress (draft expected 2026, finalization targeted 2027), and NIST selected HQC in March 2025 without yet publishing FIPS 207 — the catalogue states both in each HQC pair's advisory
• Defense-in-Depth: Combining different PQC families (lattice + code-based) mitigates algorithm-specific vulnerabilities

See Also: ETSI TS 103 744 Alignment

Notes:

• ✅ RECOMMENDED: Meets security level constraint (±0 to ±2 difference)
• ❌ RSA Excluded: RSA algorithms marked allowedInComposite=false in algorithm catalog
• ⚠️ REJECTED (Level): Violates security level constraint (>±2 difference)
• ETSI on an HQC pair: an in-progress attribution to ETSI's HQC standardization workstream, not a published deliverable
• KDF: Key Derivation Function used to combine classical and PQC encryption results
• Security Levels: L1 = 128-bit, L3 = 192-bit, L5 = 256-bit equivalent strength
• Total Combinations: 27 COMPOSITE_KEM_COMBINE + 14 COMPOSITE_SIGNATURE = 41 total

COMPOSITE_KEM_COMBINE Breakdown (27 total):

• OKP family: X25519 (4) + X448 (6) = 10 combinations
• P-curves: P-256 (4) + P-384 (6) + P-521 (4) = 14 combinations
• Brainpool: brainpoolP256r1 (1) + brainpoolP384r1 (1) + brainpoolP512r1 (1) = 3 combinations
• By PQC: ML-KEM (15) + HQC (12) = 27 combinations

COMPOSITE_SIGNATURE Breakdown (14 total):

• EdDSA family: Ed25519 (2) + Ed448 (2) = 4 combinations
• ECDSA P-curves: P-256 (2) + P-384 (3) + P-521 (2) = 7 combinations
• ECDSA Brainpool: brainpoolP256r1 (1) + brainpoolP384r1 (1) + brainpoolP512r1 (1) = 3 combinations
• All with ML-DSA (NIST FIPS 204)

COMPOSITE_SIGNATURE (14 Combinations)

Distribution by Family:

• EdDSA family: 4 combinations (Ed25519: 2, Ed448: 2)
• ECDSA P-curves: 7 combinations (P-256: 2, P-384: 3, P-521: 2)
• ECDSA Brainpool: 3 combinations (brainpoolP256r1: 1, brainpoolP384r1: 1, brainpoolP512r1: 1)

EdDSA Family Combinations (4 Total)

Ed25519 (L1) Combinations: 2 valid

Ed448 (L5) Combinations: 2 valid 🆕

EdDSA Advantages:

• Compact keys: Ed25519 (32 bytes), Ed448 (57 bytes) vs ECDSA P-521 (158 bytes)
• Performance: ~2x faster than equivalent ECDSA curves
• Deterministic: No nonce generation risk

ECDSA P-Curves Combinations (7 Total)

P-256 (L1) Combinations: 2 valid

P-384 (L3) Combinations: 3 valid

P-521 (L5) Combinations: 2 valid

ECDSA Characteristics:

• Wide support: Most PKI systems, browsers, libraries
• Full L1/L3/L5 coverage: Complete security level range

ECDSA Brainpool Combinations (3 Total)

brainpoolP256r1 (L1) Combinations: 1 valid

brainpoolP384r1 (L3) Combinations: 1 valid

brainpoolP512r1 (L5) Combinations: 1 valid

Brainpool Signature Characteristics:

• BSI TR-03111 Compliance: Required for German government long-term signatures
• European PKI: Widely used in EU eIDAS infrastructure
• Hybrid Signatures: BSI mandates hybrid classical+PQC for long-term validity (except HBS)
• Algorithm Transparency: Verifiable curve generation process

Rejected Combinations (for reference):

Algorithm Usage in Composite Keys

Algorithms Used in Composites (41 Total Combinations)

NIST-Standardized PQC Algorithms

ML-KEM (Lattice-based) - FIPS 203:

• ML-KEM-512: 4 COMPOSITE_KEM_COMBINE combinations (X25519/X448/P-256/P-384)
• ML-KEM-768: 5 COMPOSITE_KEM_COMBINE combinations (X25519/X448/P-256/P-384/P-521)
• ML-KEM-1024: 5 COMPOSITE_KEM_COMBINE combinations (X448/P-384/P-521)

ML-DSA (Lattice-based) - FIPS 204:

• ML-DSA-44: 3 COMPOSITE_SIGNATURE combinations (Ed25519/P-256/P-384)
• ML-DSA-65: 6 COMPOSITE_SIGNATURE combinations (Ed25519/Ed448/P-256/P-384/P-521/brainpoolP256r1)
• ML-DSA-87: 5 COMPOSITE_SIGNATURE combinations (Ed448/P-384/P-521/brainpoolP384r1/brainpoolP512r1)

PQC Algorithms Under Standardization

HQC (Code-based) — ETSI and NIST standardization in progress:

• HQC-128: 4 COMPOSITE_KEM_COMBINE combinations (X25519/X448/P-256/P-384)
• HQC-192: 5 COMPOSITE_KEM_COMBINE combinations (X25519/X448/P-256/P-384/P-521)
• HQC-256: 3 COMPOSITE_KEM_COMBINE combinations (X448/P-384/P-521)

Rationale: Mathematical diversity (lattice + code-based) provides defense-in-depth.

Total: 27 COMPOSITE_KEM_COMBINE + 14 COMPOSITE_SIGNATURE = 41 valid combinations

Algorithms Excluded from Composite Keys

Note: These algorithms are available for SIMPLE key operations but excluded from COMPOSITE keys.

Category 1: RSA Algorithms (Policy Exclusion)

Rationale: RSA marked allowedInComposite=false due to:

• Performance: Slower than ECC (X25519/P-curves)
• Key size: Larger than ECC equivalents
• Platform policy: OKP and P-curves preferred for classical component

Excluded Combinations: 15 total

[See RSA exclusion table in lines 145-161]

Category 2: PQC KEMs Outside the NIST Primary Selections (Research/Diversity Use Only)

Available as SIMPLE keys only:

Rationale: Platform supports NIST-standardized (ML-KEM) and in-standardization (HQC) algorithms for composite operations. Other non-NIST algorithms supported for SIMPLE keys (research/diversity).

Impact: ~16 excluded KEM combinations (4 PQC families × multiple classical curves)

Category 2: Hash-Based Signatures (3 Algorithms)

Rationale:

• SLH-DSA: NIST FIPS 205 standardizes SLH-DSA, but the composite signature construction this platform implements (draft-ietf-lamps-pq-composite-sigs-19, profiled for JWS by draft-ietf-jose-pq-composite-sigs-04) pairs a classical algorithm with ML-DSA only. Neither draft defines a Label or a pre-hash for an SLH-DSA pairing, so there is no composite SLH-DSA signature to produce.
• XMSS/LMS: Stateful algorithms require strict key state management (each signature advances an internal counter). A composite signature would have to keep that state consistent with the classical component on every signing operation, introducing complexity and failure modes.

Technical Details:

• SLH-DSA: a composite signature is one value, the ML-DSA component signature followed by the classical one, over the message representative the construction defines for each pairing. That construction is specified for ML-DSA-44, ML-DSA-65 and ML-DSA-87; an SLH-DSA component has no specified place in it.
• XMSS/LMS State Issue: A composite signature is produced atomically — both component signatures, or none. A stateful component consumes a one-time key even when the other component then fails, which a stateless composite cannot roll back.

Future Consideration:

• SLH-DSA support planned via dedicated composite format (not JWS-based)
• XMSS/LMS remain available for SIMPLE signatures in niche use cases

Impact:

• Total excluded signature combinations: ~15 (5 hash-based × 4 classical signatures, minus level violations)
• Platform uses ML-DSA exclusively for PQC composite signatures

Category 3: Non-FIPS Lattice Signature (1 Algorithm)

Rationale:

• NIST Standardization: ML-DSA (Dilithium) selected for FIPS 204, FALCON not standardized
• Side-Channel Concerns: FALCON implementations are exposed to side-channel attack vectors through floating-point arithmetic. ANSSI still recommends FALCON-1024 as a simple profile (the catalogue attributes ANSSI to it), while no body the catalogue carries recommends FALCON-512
• Regulatory Compliance: FIPS 140-3 modules require NIST-approved algorithms; FALCON excluded from CMVP certification paths

Technical Details:

• FALCON uses floating-point arithmetic for Gaussian sampling (smaller signatures than ML-DSA)
• Side-channel attacks exploit floating-point timing variations to leak secret key bits
• Constant-time implementations challenging due to architecture-specific floating-point behavior

Impact:

• Total excluded FALCON combinations: ~8 (2 FALCON variants × 4 classical signatures)
• Platform uses ML-DSA for PQC signatures, avoiding FALCON side-channel risks

Summary of Excluded Algorithms

Total Excluded:

• PQC KEMs outside the composite set: 7 families (HQC, FRODO, CMCE, BIKE, SABER, NTRU, NTRU-Prime). Note HQC is NIST-selected (Round-4 backup KEM, March 2025) and additionally carries ETSI (in progress) — its presence here reflects composite-set membership, not a lack of NIST standing.
• Hash-based signatures: 3 families (SLH-DSA, XMSS, LMS)
• Non-FIPS lattice signatures: 1 family (FALCON)

Total Excluded Combinations: ~59 (36 KEMs including 15 RSA + 15 hash-based + 8 FALCON)

Platform Strategy:

• Composite Keys: OKP (X25519/X448), P-curves (P-256/P-384/P-521), and Brainpool (brainpoolP256r1/384r1/512r1) for classical components, ML-KEM/HQC for PQC (27 COMPOSITE_KEM_COMBINE + 14 COMPOSITE_SIGNATURE = 41 total)
• SIMPLE Keys: Support RSA and diversification algorithms outside the composite set (RSA, HQC, FRODO, FALCON, SLH-DSA). HQC and SLH-DSA are NIST-selected; “outside the composite set” is not a statement about standardization.
• Compliance: Prioritize FIPS 140-3 certification paths and regulatory requirements
• RSA Policy: RSA excluded from composite keys (allowedInComposite=false), available for SIMPLE keys only
• Algorithm Families: OKP preferred for compactness, P-curves for PKI compatibility

Validation Rules (Security Level Matching)

Security Level Constraint

Rule: Security level difference ≤ 2 steps

Security Levels:

Rationale:

• Prevents "weakest link" scenarios (e.g., L1 classical + L5 PQC = effective L1 security)
• Balances performance (larger keys = slower operations) with security

Validation Examples

✅ Valid Combinations (Δlevel ≤ 2)

⚠️ Warning Combinations (Δlevel = 2, edge case)

Platform allows but logs warning for combinations at maximum ±2 difference:

WARNING: Security level difference at maximum (Δ=2): X25519 (L1) + ML-KEM-768 (L3)
Consider using ML-KEM-512 (L1) for optimal balance.

❌ Rejected Combinations (Δlevel > 2)

Platform Behavior:

• The level constraint is pre-computed in CompositeAlgorithmCatalogue: a pairing outside it is not catalogued
• Key creation admits only catalogued pairings (CompositeAlgorithmCatalogue.isValid, called by KeyGenerationService), which prevents key generation for invalid combinations

Format Specifications

JWE General JSON Serialization (COMPOSITE_KEM_COMBINE)

Standard: RFC 7516 §7.2

Structure:

{
  "protected": "<base64url({enc, kid, typ, ank_kv, anka_kdf})>",
  "recipients": [
    {
      "header": {
        "alg": "X25519"
      },
      "encrypted_key": "<base64url(c_classical: the 32-byte ephemeral X25519 public key)>"
    },
    {
      "header": {
        "alg": "ML-KEM-768"
      },
      "encrypted_key": "<base64url(c_pqc: the ML-KEM-768 ciphertext)>"
    }
  ],
  "iv": "<base64url(initialization-vector)>",
  "ciphertext": "<base64url(encrypted-payload)>",
  "tag": "<base64url(authentication-tag)>"
}

Key Derivation (the combiner of SP 800-227 §4.6.1, instantiated by the key's kdf):

(K_classical, c_classical) = ECDH-KEM.Encaps(ek_classical)   # c_classical = the ephemeral public key
(K_pqc,       c_pqc)       = ML-KEM.Encaps(ek_pqc)           # or HQC, through the KEM API
domain = frame("ankasecure:composite-kem", alg, kdfToken)    # frame = ETSI TS 103 744 cb_f length framing
CEK    = KeyCombine(K_classical, K_pqc, c_classical, c_pqc, ek_classical, ek_pqc, domain)

recipients[0].encrypted_key = c_classical
recipients[1].encrypted_key = c_pqc
protected = base64url({enc, kid, typ, ank_kv, anka_kdf})     # anka_kdf = kdfToken; no alg (RFC 7516 7.2.1)
ciphertext, tag = AES-256-GCM(CEK, iv, plaintext, AAD = protected)

The domain separator names the pairing and the KDF token; it does not carry the kid, which is integrity-bound through the protected header (the AAD) instead. ek_classical and ek_pqc are the component public keys exactly as persisted (the SubjectPublicKeyInfo DER).

The buffered JWE carries exactly these five members and no shared unprotected header. The streaming JWET header adds one root member, anka_composite_mode, which the streaming parser reads to recognise the composite format.

Decryption Requirement:

• The protected anka_kdf must name the KDF the key was created with; an absent, unknown or different token is refused with 422 before any decapsulation
• The recipient decapsulates BOTH recipients[0].encrypted_key AND recipients[1].encrypted_key, recomputes the CEK with KeyCombine and verifies the AES-GCM tag over protected
• A substituted ciphertext of the right length gives a different CEK and fails the tag check (422); a ciphertext of the wrong length or an invalid curve point is refused at the wire (400)

JWS Serialization (COMPOSITE_SIGNATURE)

Standard: RFC 7515 §7.2.1 (General JSON, one signature); RFC 7797 on the detached plane

Structure:

{
  "payload": "<base64url(message)>",
  "signatures": [
    {
      "protected": "<base64url({alg: ML-DSA-65-Ed25519, kid, ank_kv, iat[, exp]})>",
      "signature": "<base64url(mldsaSig followed by tradSig)>"
    }
  ]
}

Signature Generation:

M         = ASCII(BASE64URL(UTF8(protected))) || '.' || BASE64URL(payload)
M'        = Prefix || Label || 0x00 || PH(M)
mldsaSig  = ML-DSA-65.Sign(M', ctx = Label)
tradSig   = Ed25519.Sign(M')
signature = mldsaSig || tradSig

For Ed25519+ML-DSA-65 the value is 3,309 + 64 = 3,373 octets. The protected header is part of M, so alg, kid, ank_kv, iat and exp (when present) are covered by the signature; there is no unprotected member.

Policy: a tenant's allowedKdfs names the tokens its keys may use. A template that names only HKDF-SHA256 denies HKDF-SHA384, HKDF-SHA512, CatKDF and CasKDF keys at create, import, rotation and transition.

Compliance Matrix

ETSI Quantum-Safe Cryptography (QSC) Alignment

The rows above describe the platform's composite design, not a conformance attestation; see ETSI TS 103 744 alignment. The ETSI conformance the platform claims for CatKDF and CasKDF is limited to the 10 TS 103 744 §7.7.2 parameter sets (see KDF Specifications).

Notes:

• ANKASecure supports NIST-standardized (ML-KEM) and in-standardization (HQC) algorithms for composite operations
• HQC provides code-based cryptography diversity alongside lattice-based ML-KEM
• 12 HQC composite combinations (5 classical curves × 3 HQC variants, minus level violations); ETSI standardization of HQC is in progress
• Total 27 valid COMPOSITE_KEM_COMBINE combinations (15 ML-KEM + 12 HQC)
• Classical algorithms: OKP (X25519, X448) + P-curves (P-256, P-384, P-521) + Brainpool (brainpoolP256r1, brainpoolP384r1, brainpoolP512r1) = 8 total
• See ETSI TS 103 744 Alignment for the clause-by-clause description

Cross-References

Related Documentation:

• Algorithm Catalog (89 Total) - Complete simple algorithm inventory (89 SIMPLE algorithms)
• Performance Benchmarks - Composite key generation/operation timings
• Integrity Guarantee - Cryptographic assurances
• NIST CSWP 39 Alignment (partner documentation)^*
• ETSI TS 103 744 Alignment - TS 103 744 clauses the composite KEM keys implement

Last Updated: 2026-09-24

Version: 3.2.0

Maintained By: ANKASecure Platform Team