Cryptography

Hybrid Signature Scheme

IDProva employs a hybrid signature scheme combining Ed25519 (classical) with ML-DSA-65 (post-quantum, FIPS 204). An attacker must break both algorithms to forge a signature.

Rationale: NIST standardised ML-DSA (formerly CRYSTALS-Dilithium) in FIPS 204. While ML-DSA is believed quantum-resistant, it has less cryptanalytic history than Ed25519. The hybrid approach provides defense in depth.

Hybrid Signature Generation

Given a message M and key pairs (sk_ed, pk_ed) for Ed25519 and (sk_ml, pk_ml) for ML-DSA-65:

HybridSign(M, sk_ed, sk_ml):
  1. sig_ed  = Ed25519_Sign(sk_ed, M)
  2. sig_ml  = MLDSA65_Sign(sk_ml, M)
  3. sig_hybrid = CBOR_Encode({
       "ed25519": sig_ed,      // 64 bytes
       "mldsa65": sig_ml,      // 3309 bytes
       "version": 1
     })
  4. return sig_hybrid

Hybrid Signature Verification

HybridVerify(M, sig_hybrid, pk_ed, pk_ml):
  1. components = CBOR_Decode(sig_hybrid)
  2. valid_ed = Ed25519_Verify(pk_ed, M, components.ed25519)
  3. valid_ml = MLDSA65_Verify(pk_ml, M, components.mldsa65)
  4. return valid_ed AND valid_ml

Both signatures MUST be valid for the hybrid verification to succeed. A verifier MUST NOT accept a message where only one component is valid.

Classical-Only Mode

For environments where post-quantum cryptography is not yet available:

• The DID Document SHOULD still include an ML-DSA-65 key if available.
• Signatures use standard Ed25519 (64 bytes).
• The verifier MUST note the reduced security level in its trust assessment.
• Implementations operating in classical-only mode MUST NOT claim trust levels above L2.

Signature Sizes

Algorithm	Public Key	Signature	Security Level
Ed25519	32 bytes	64 bytes	~128-bit classical
ML-DSA-65	1,952 bytes	3,309 bytes	NIST Level 3 (quantum)
Hybrid	1,984 bytes	~3,400 bytes (CBOR)	128-bit classical + NIST Level 3 quantum

---

Hashing

BLAKE3 (Primary)

BLAKE3 is the primary hash function:

• Action Receipt hash chains
• Config attestation hashes (default)
• Content-addressed storage

SHA-256 (Interoperability)

SHA-256 is the interoperability hash function:

• Systems that cannot support BLAKE3 MAY use SHA-256.
• When communicating hash values to external systems (e.g., blockchain anchors), SHA-256 SHOULD be used.

Hash Representation

Hashes are represented as algorithm:hex-digest:

blake3:a1b2c3d4e5f67890abcdef1234567890abcdef1234567890abcdef1234567890
sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

---

Key Encoding (Multibase)

All public keys in DID Documents are encoded using Multibase (base58btc) as specified in the W3C Data Integrity specification.

Format: z prefix (base58btc) followed by multicodec-prefixed public key bytes.

Multicodec Prefixes

Algorithm	Multicodec	Prefix Bytes
Ed25519 public key	0xed	0xed 0x01
ML-DSA-65 public key	0x0d65	0x0d 0x65

Encoding Examples

Ed25519:

Raw public key:    [32 bytes]
With multicodec:   0xed 0x01 [32 bytes] = [34 bytes]
Base58btc encoded: z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK

ML-DSA-65:

Raw public key:    [1952 bytes]
With multicodec:   0x0d 0x65 [1952 bytes] = [1954 bytes]
Base58btc encoded: z2Drjgb4TxNYuSiDBqd7pJAn5MfgF1YfNfsaHH3gZXQxqR7kW...

---

Key Management

Key Generation

Implementations MUST generate keys using a cryptographically secure random number generator (CSPRNG):

• Ed25519: Keys MUST be generated per RFC 8032, Section 5.1.5.
• ML-DSA-65: Keys MUST be generated per FIPS 204, Section 6.

Key Storage

Private keys MUST be stored securely. Recommended approaches (in order of preference):

1. Hardware Security Module (HSM) — FIPS 140-2 Level 2+ certified.
2. Trusted Platform Module (TPM) — For device-bound agents.
3. Operating System Keychain — macOS Keychain, Windows DPAPI, Linux Secret Service.
4. Encrypted File — AES-256-GCM encrypted file with key derived from a strong passphrase via Argon2id.

Private keys MUST NOT be:

• Stored in plain text
• Included in DID Documents
• Transmitted over the network
• Logged or included in error messages

Key Rotation

Key rotation is performed via DID Document updates. Implementations SHOULD rotate keys:

• At least every 90 days for Ed25519 keys.
• At least every 180 days for ML-DSA-65 keys.
• Immediately upon suspected compromise.

During rotation, both old and new keys coexist in the DID Document. DATs issued by the old key remain valid until their expiry. New DATs MUST be signed by the new key.

Key Revocation

Individual keys can be revoked by removing them from the DID Document via an update operation. Verifiers MUST re-resolve the DID Document when validating signatures to check for key revocation.

Implementations SHOULD cache DID Documents with a maximum TTL of 5 minutes to balance performance and revocation responsiveness.

---

Algorithm Agility

IDProva is designed for cryptographic agility while maintaining a strong default.

Required Algorithms

All implementations MUST support:

Algorithm	Purpose
Ed25519 (RFC 8032)	Classical signatures
ML-DSA-65 (FIPS 204)	Post-quantum signatures
BLAKE3	Content hashing
SHA-256	Interoperability hashing

Optional Algorithms

Implementations MAY support:

Algorithm	Purpose
Ed448	Higher-security classical signatures
ML-DSA-87	Higher-security post-quantum signatures
BLAKE2b-256	Alternative hash

Algorithm Negotiation

When two agents interact, they MUST use the highest-security overlapping algorithm set. If both support ML-DSA-87, they SHOULD prefer it over ML-DSA-65. Negotiation details are in the Protocol Bindings specification.

Deprecation Process

Algorithms are deprecated through a three-phase process:

1. Advisory — Algorithm flagged as weakening; implementations SHOULD begin migration.
2. Warning — Verifiers SHOULD reject the algorithm; grace period announced.
3. Removal — Algorithm removed from the specification; implementations MUST NOT use it.

---

Post-Quantum Migration Roadmap

Phase	Timeline	Action
Phase 0 (Current)	2026	Hybrid Ed25519 + ML-DSA-65; classical-only fallback permitted
Phase 1	2027	Classical-only mode deprecated (advisory); all new identities MUST include PQC keys
Phase 2	2028	Classical-only mode deprecated (warning); verifiers SHOULD reject classical-only signatures
Phase 3	2029+	Evaluate ML-DSA-87 as default PQC algorithm; assess ML-KEM for key exchange

---

Next Steps

• AID Format & DID Method — DID Document structure and resolution
• DAT Structure & Scopes — How signatures are used in delegation tokens
• Action Receipts — How signatures chain audit records