Nested Hybrid Signatures:
Why One Algorithm Isn't Enough

The Problem: Single-Algorithm Risk

NIST standardized three post-quantum signature families in 2024: ML-DSA (Dilithium), SLH-DSA (SPHINCS+), and FN-DSA (FALCON). All three are widely respected. But virtually every implementation today picks one and deploys it alone. That's a category error — it's single-algorithm risk, and it's structurally identical to the mistakes made with RSA in the 1990s.

The lattice-based schemes (Dilithium, FALCON, NTRU variants) each rest on different but mathematically related hardness assumptions. Dilithium relies on Module Learning With Errors (MLWE) and Module Short Integer Solution (MSIS). FALCON relies on the NTRU problem and hardness of finding short vectors in NTRU lattices. These are different mathematical families — MLWE and NTRU do not share the same hardness roots — but they are both lattice problems, and advances in lattice cryptanalysis tend to propagate.

There are three independent failure vectors:

• Mathematical break — a new algorithm significantly reduces the cost of solving MLWE or the NTRU Short Vector Problem.
• Implementation vulnerability — timing side-channels or fault injection exposing secret key material. Highly algorithm-specific.
• Algorithmic backdoor — a deliberately weakened parameter set or hidden trapdoor introduced during standardization. Historical precedent exists (Dual EC DRBG).

Classical Ed25519 (Edwards-curve Digital Signature Algorithm, EdDSA, over Edwards25519 — RFC 8032) relies on the Elliptic Curve Discrete Logarithm Problem (ECDLP) — entirely separate mathematics from any lattice assumption. A quantum computer running Shor's algorithm does break ECDLP, which is why it cannot stand alone post-2030. But today, if a lattice family cracks, Ed25519 remains intact. The independence is the point.

The Solution: Lattice-Family Independence

H33's Nested Hybrid Signature uses three algorithms from three independent mathematical families:

This is not three algorithms in parallel (a concatenated scheme). It is three algorithms in series, where each outer layer signs a message that includes all inner layers. The result is a sequential commitment chain: each outer signature commits to the existence of all inner signatures, creating a dependency ordering that no single-algorithm break can unwind.

Critically, Dilithium and FALCON come from different lattice families. Dilithium's security reduces to MLWE (a ring/module extension of LWE). FALCON's security reduces to the hardness of finding short vectors in NTRU lattices, a distinct problem with a different attack surface. An advance that breaks Dilithium does not automatically transfer to FALCON, and vice versa. This is the meaning of lattice-family independence.

How Nesting Works: The Sequential Commitment Chain

The nesting order matters and is deliberate. Each outer signature commits to all inner material. When Dilithium signs, it signs a message that includes the Ed25519 signature. When FALCON signs, it signs a message that includes both the Ed25519 and Dilithium signatures. The resulting structure is:

Verification Pseudocode

Verification reverses the nesting: outer layer first. Any single failure aborts the chain.

// Inputs
payload       : Bytes          // original identity payload
σ₁           : Ed25519Sig    // 64 bytes — inner classical sig
σ₂           : DilithiumSig  // 4,627 bytes — middle PQ sig
σ₃           : FalconSig    // 666 bytes — outer PQ sig
pk_ed        : Ed25519PK    // 32 bytes
pk_dil       : DilithiumPK  // 2,592 bytes
pk_falcon    : FalconPK     // 897 bytes

fn verify_nested_hybrid(...) → Result<(), VerifyError> {
    // Step 1: Verify outermost layer first
    composite₂ = payload ‖ σ₁ ‖ σ₂
    if !falcon_verify(composite₂, σ₃, pk_falcon) {
        return Err(FalconVerifyFailed)
    }

    // Step 2: Verify middle layer
    composite₁ = payload ‖ σ₁
    if !dilithium_verify(composite₁, σ₂, pk_dil) {
        return Err(DilithiumVerifyFailed)
    }

    // Step 3: Verify innermost classical anchor
    if !ed25519_verify(payload, σ₁, pk_ed) {
        return Err(Ed25519VerifyFailed)
    }

    // All three layers verified — commitment chain intact
    Ok(())
}

Graceful Cryptographic Degradation

If a vulnerability is discovered in any single algorithm, the system can degrade gracefully without token re-issuance. The degradation handler monitors cryptographic vulnerability feeds and transitions verification logic automatically:

• FALCON compromised — Fall back to Dilithium + Ed25519 dual-layer verification. Initiate re-signing with an alternative NTRU or hash-based scheme (SPHINCS+).
• Dilithium compromised — Fall back to FALCON + Ed25519. Initiate re-signing with an alternative MLWE implementation.
• Ed25519 broken by quantum computer — Fall back to FALCON + Dilithium dual post-quantum verification. Initiate re-signing with XMSS or SPHINCS+ for the classical slot.

In all cases, the biometric commitment embedded in the token remains bound to a specific biological identity. Re-issuance is not required — only the affected signature layer is replaced.

Performance: Graviton4 Benchmarks

All measurements on c8g.metal-48xl (96 cores, AWS Graviton4, Neoverse V2, ARM NEON), Criterion.rs v0.5, 100+ samples, February 2026. Timings are per-operation, single-thread, with warm caches.

The ~690µs full cycle fits comfortably within the H33 auth pipeline. SBT minting is a one-time operation per identity — latency here is negligible in practice. For recurring authentication, the standard Dilithium-3 tier at ~106µs remains the default.

Wire Format: Version 0x03

The nested hybrid signature is serialized as a single contiguous blob with a versioned header. Parsers check the version byte first and dispatch to the appropriate verification path. All lengths are fixed at the NIST parameter set — no variable-length fields.

The API

The nested hybrid signature is available under /hybrid/* endpoints. All three algorithm layers are handled server-side — you provide the payload, we return the composite signature blob.

Generate a Nested Hybrid Key Pair

curl -X POST https://api.h33.ai/v1/hybrid/keygen \
  -H "Authorization: Bearer $H33_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "algorithms": ["ed25519", "dilithium5", "falcon512"],
    "label": "sbt-mint-key-v1"
  }'

// Response — public keys for on-chain storage, secret keys returned once
{
  "key_id": "key_4xQf...",
  "pk_ed25519": "base64...",         // 32 B
  "pk_dilithium5": "base64...",      // 2,592 B
  "pk_falcon512": "base64...",       // 897 B
  "algorithm_version": "0x03"
}

Sign a Payload

curl -X POST https://api.h33.ai/v1/hybrid/sign \
  -H "Authorization: Bearer $H33_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "key_id": "key_4xQf...",
    "payload": "base64_encoded_payload",
    "mode": "triple"
  }'

// Response — composite nested signature blob
{
  "signature": "base64...",      // ~5,390 B blob (version 0x03)
  "sig_ed25519": "base64...",   // σ₁ — 64 B, for audit
  "sig_dilithium5": "base64...", // σ₂ — 4,627 B
  "sig_falcon512": "base64...",  // σ₃ — 666 B
  "latency_us": 447,           // measured sign latency
  "algorithm_version": "0x03"
}

Verify a Nested Hybrid Signature

curl -X POST https://api.h33.ai/v1/hybrid/verify \
  -H "Authorization: Bearer $H33_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "payload": "base64_encoded_payload",
    "signature": "base64_composite_blob",
    "pk_ed25519": "base64...",
    "pk_dilithium5": "base64...",
    "pk_falcon512": "base64..."
  }'

// Response
{
  "verified": true,
  "layers": {
    "falcon512": true,    // outer — verified first
    "dilithium5": true,   // middle
    "ed25519": true       // inner classical anchor
  },
  "algorithm_version": "0x03",
  "latency_us": 238,
  "commitment_chain_intact": true
}

Rotate a Key Layer

curl -X POST https://api.h33.ai/v1/hybrid/rotate \
  -H "Authorization: Bearer $H33_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "key_id": "key_4xQf...",
    "rotate_layer": "falcon512",
    "reason": "scheduled_rotation"
  }'

// Rotates only the FALCON-512 layer; Ed25519 and Dilithium keys unchanged.
// Returns new pk_falcon512 and re-signs all active tokens with updated outer layer.
{
  "new_key_id": "key_7rNm...",
  "rotated_layer": "falcon512",
  "pk_falcon512": "base64...",
  "tokens_re_signed": 4821,
  "identity_binding_preserved": true
}

Memory Safety: Zeroize-on-Drop

All three secret keys follow a strict zeroize-on-drop protocol. The Rust implementation uses the zeroize crate (Zeroize + ZeroizeOnDrop traits) to guarantee cryptographic erasure from heap and stack memory when key handles go out of scope. This is not optional hygiene — it is enforced at the type level.

use zeroize::{Zeroize, ZeroizeOnDrop};

/// Triple nested hybrid signing key.
/// All three secret keys are zeroed from memory on drop.
#[derive(ZeroizeOnDrop)]
pub struct NestedHybridSigningKey {
    /// Ed25519 secret key — 32 bytes, zeroized on drop
    ed25519_sk: Ed25519SigningKey,

    /// Dilithium-5 secret key — 4,032 bytes, zeroized on drop
    dilithium5_sk: Dilithium5SigningKey,

    /// FALCON-512 secret key — 1,281 bytes, zeroized on drop
    falcon512_sk: Falcon512SigningKey,
}

impl NestedHybridSigningKey {
    pub fn sign(&self, payload: &[u8]) → NestedHybridSig {
        // Layer 1: classical inner
        let σ₁ = self.ed25519_sk.sign(payload);

        // Layer 2: commit to payload + σ₁
        let composite1 = [payload, σ₁.as_bytes()].concat();
        let σ₂ = self.dilithium5_sk.sign(&composite1);

        // Layer 3: commit to payload + σ₁ + σ₂
        let composite2 = [payload, σ₁.as_bytes(), σ₂.as_bytes()].concat();
        let σ₃ = self.falcon512_sk.sign(&composite2);

        NestedHybridSig { σ₁, σ₂, σ₃ }
        // composite1, composite2 — dropped and zeroed here
    }
}
// When NestedHybridSigningKey is dropped:
// ed25519_sk, dilithium5_sk, falcon512_sk → zeroed by ZeroizeOnDrop
// No secret key material persists in memory after the handle is released

Intermediate composite buffers (composite1, composite2) are also handled as stack-allocated slices that are erased immediately after signing. The public verification key trio is not sensitive and does not require zeroization.

Use Cases

When to Use Each Tier