Introducing H33-3-Key:
Triple Post-Quantum Signatures with Lattice-Family Independence

What happens when a quantum computer breaks Dilithium? Or FALCON? The honest answer is: nobody knows which lattice construction will fall first, or if either will fall at all. But "probably fine" isn't a security posture. H33-3-Key is our answer to that uncertainty—three independent signature algorithms nested into a single cryptographic proof, where breaking the signature requires breaking all three.

Today we're launching H33-3-Key as a production API. One endpoint. Three algorithms. Sub-millisecond signing. Here's what it is, how it works, and why it matters.

The Problem: Single-Algorithm Risk

NIST finalized its post-quantum standards in 2024. Dilithium (now ML-DSA) and FALCON are both lattice-based signature schemes, and both are excellent. But they share a philosophical vulnerability: they derive security from the hardness of lattice problems. If a novel mathematical breakthrough compromises one lattice family, it could potentially compromise others.

This isn't theoretical paranoia. The history of cryptography is littered with algorithms that were "provably secure" until they weren't. MD5 was trusted for decades. SHA-1 lasted 15 years past its first theoretical weakness. RSA key sizes that were considered safe in 2000 are laughable today.

For operations where the signature needs to remain valid for years or decades—legal documents, property records, financial instruments, Soulbound NFTs—betting on a single algorithm family is an unnecessary risk.

The Solution: Three Algorithms, Two Lattice Families, One Signature

H33-3-Key combines three signature algorithms into a single nested signature:

• Ed25519 — Classical elliptic-curve signature (128-bit security, deterministic per RFC 8032)
• Dilithium-5 (ML-DSA-87) — Module-LWE lattice signature (NIST Level 5, ~256-bit equivalent)
• FALCON-512 — NTRU lattice signature with GPV hash-and-sign framework (NIST Level 1)

The critical insight is lattice-family independence. Dilithium is built on Module Learning With Errors (MLWE) with Fiat-Shamir aborts. FALCON is built on NTRU lattices with the GPV framework. These are fundamentally different mathematical constructions. A cryptanalytic breakthrough against MLWE does not automatically extend to NTRU, and vice versa.

Ed25519 adds a classical layer—an attacker would need both a quantum computer powerful enough to run Shor's algorithm and a lattice breakthrough to forge a signature.

How the Nesting Works

H33-3-Key doesn't simply concatenate three signatures. It uses a temporal binding chain where each outer layer cryptographically commits to all inner layers. This prevents signature substitution attacks and creates a verifiable dependency order.

Signing (Inner to Outer)

1. Layer 1 — Ed25519: Signs the original message. Produces a 64-byte signature.
2. Layer 2 — Dilithium-5: Signs message || ed25519_signature. The Dilithium signature now cryptographically commits to both the message and the Ed25519 signature. Produces a 4,627-byte signature.
3. Layer 3 — FALCON-512: Signs message || ed25519_signature || dilithium_signature. The FALCON signature commits to the entire chain. Produces a ~690-byte signature.

Verification (All-or-Nothing)

Verification reconstructs the same payloads and checks all three layers. If any single layer fails, the entire signature is rejected. There is no partial validity.

// The verification chain
verify_ed25519(message, ed25519_sig, ed25519_pk)           // Layer 1
verify_dilithium(message || ed25519_sig, dil_sig, dil_pk)  // Layer 2
verify_falcon(message || ed25519_sig || dil_sig, fal_sig, fal_pk)  // Layer 3

// ALL three must pass — any failure = invalid

Why Nesting Matters

The temporal binding chain means you can't swap out one layer's signature without invalidating the outer layers. If an attacker forges a new Ed25519 signature, the Dilithium layer immediately rejects because it signed the original Ed25519 output. If someone tampers with the Dilithium signature, FALCON catches it. The dependencies flow in one direction and cannot be circumvented.

Performance: Sub-Millisecond Signing on Graviton4

Cryptographic security means nothing if it's too slow to use. We benchmarked H33-3-Key on our production infrastructure (AWS c8g.4xlarge, Graviton4 Neoverse V2) with real workloads:

• Key Generation: ~5ms (generates all three keypairs)
• Triple Sign: ~450µs (three nested signatures in under half a millisecond)
• Triple Verify: ~240µs (all three layers verified)
• Full cycle (sign + verify): ~690µs

For context, a typical HTTPS handshake takes 50–200ms. H33-3-Key's entire sign-and-verify cycle completes in under 700 microseconds—roughly 200x faster than the network overhead you're already paying.

Wire Format

The serialized triple signature uses a version-tagged binary format:

+----------+-----------+------------------+-----------+----------------+-----------------+
| Version  | Dil Len   | Dilithium Sig    | Fal Len   | FALCON Sig     | Ed25519 Sig     |
| (1 byte) | (4 LE)    | (4,627 bytes)    | (4 LE)    | (~690 bytes)   | (64 bytes)      |
+----------+-----------+------------------+-----------+----------------+-----------------+
  0x03       Variable    NIST Level 5       Variable    NIST Level 1     128-bit classical

Version byte 0x03 identifies this as a triple signature, distinct from H33's dual-hybrid (0x02) and concatenated (0x01) formats. Total signature size is approximately 5,390 bytes.

Key Sizes

Each algorithm contributes its own public key material:

• Ed25519: 32 bytes (public key)
• Dilithium-5 (ML-DSA-87): 2,592 bytes (public key)
• FALCON-512: 897 bytes (public key)
• Total public key material: 3,521 bytes

Larger than classical algorithms, but manageable. For reference, a typical JWT token is 500–1,000 bytes. The public key set is a one-time transfer per key rotation cycle.

The API

H33-3-Key exposes four core endpoints. No cryptography libraries to install, no parameter tuning, no side-channel audits. One API call does the work.

Generate a Keypair

curl -X POST https://api.h33.ai/api/v1/triple-key/generate \
  -H "X-API-Key: YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"security_level": "critical"}'

Returns a key_id along with all three public keys (base64-encoded). The security level controls automatic key rotation: standard (30 days), high (14 days), or critical (7 days).

Sign a Message

curl -X POST https://api.h33.ai/api/v1/triple-key/sign \
  -H "X-API-Key: YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "key_id": "tk_abc123",
    "message_b64": "SGVsbG8gZnJvbSBIMzM="
  }'

Returns the nested triple signature, version byte, and per-stage latency.

Verify a Signature

curl -X POST https://api.h33.ai/api/v1/triple-key/verify \
  -H "X-API-Key: YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "message_b64": "SGVsbG8gZnJvbSBIMzM=",
    "signature_b64": "AwAA...",
    "ed25519_public_key": "...",
    "dilithium_public_key": "...",
    "falcon_public_key": "..."
  }'

Returns valid: true/false with a list of which layers were verified.

Key Rotation

curl -X POST https://api.h33.ai/api/v1/triple-key/rotate/execute \
  -H "X-API-Key: YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"key_id": "tk_abc123"}'

Generates a new keypair, archives the old one, and returns the new key_id. Previous signatures remain verifiable with archived keys.

Memory Safety

All secret keys use Zeroizing<T> wrappers from the zeroize crate, ensuring automatic secure erasure when keys go out of scope. Ed25519 signing keys are reconstructed on-demand from a zeroized seed rather than held in memory. No copies of secret material persist in stack or heap after use.

Use Cases

Soulbound NFTs and Permanence Proofs

Tokens that are never meant to be transferred need signatures that remain valid indefinitely. A single-algorithm signature is a bet that the algorithm survives. H33-3-Key makes that bet across three independent constructions.

Financial Instruments and Legal Documents

Contracts, deeds, and regulatory filings often need to be verifiable for 30+ years. H33-3-Key provides the strongest available assurance that the signature will still be valid when someone checks it in 2056.

Software Supply Chain

Code-signing a critical infrastructure package with H33-3-Key means an attacker can't forge an update even if they break one post-quantum algorithm. The nested chain catches any tampering.

Cross-Border Regulatory Compliance

Different jurisdictions may mandate different algorithms. H33-3-Key satisfies requirements for classical signatures (Ed25519), NIST PQC (Dilithium-5), and alternative lattice constructions (FALCON) simultaneously.

Try It Now

H33-3-Key is live on our production API. You can run a real triple-key demo—generating keys, signing, and verifying against our Graviton4 infrastructure—from the Verify page or the H33-3-Key product page.

The API is included in all H33 plans, starting with 1,000 free operations per month. Full documentation is available at /docs/api/.