feat:added pq-bridge

[vinaysingh8866]

Add PQ-Bridge 1.0 Protocol

Summary

This PR introduces the PQ-Bridge 1.0 protocol, which adds post-quantum (PQ) key exchange, hybrid encryption, and PQ signatures on top of any DIDComm v2 connection. It is a bridge — a stable, interoperable wire format for adding NIST FIPS 203 (ML-KEM) and FIPS 204 (ML-DSA) protection to DIDComm traffic until the DIDComm core specification adopts these primitives natively. The protocol runs after a DIDComm connection reaches completed, negotiates a PQ suite via Discover Features, exchanges encapsulation keys, derives a session-bound shared secret, and optionally upgrades subsequent message bodies and attachments to hybrid encryption (classical + PQ) so that breaking the channel requires breaking both primitives.

Motivation

DIDComm v2 today uses classical X25519/Ed25519 for authcrypt and signing. A sufficiently capable quantum adversary could break these primitives with Shor's algorithm, and the harvest-now-decrypt-later threat is already real: an attacker recording today's DIDComm traffic can decrypt it years later when quantum hardware matures.

Three options exist to address this:

1. Wait for DIDComm core to add PQ — slow standards process.
2. Roll PQ ad-hoc per implementation — fragments interop.
3. Standardize a bridge protocol that wraps PQ implementations behind a stable wire format.

This protocol is option 3. It does not modify DIDComm authcrypt or replace existing JOSE primitives; instead, it adds a second cryptographic layer sitting inside DIDComm message bodies. When DIDComm core eventually adopts ML-KEM and ML-DSA in JWE/JWS, this protocol can be deprecated cleanly.

Key Features

Suite Negotiation

• Explicit propose-upgrade / accept-upgrade / decline-upgrade flow
• Discover Features 2.0 advertisement before negotiation
• Registered suite identifiers — implementations MUST reject unknown suites

Suite Registry

Suite ID	KEM	Signature	Notes
pq-suite-p1	ML-KEM-768	none	Encryption only, minimum viable PQ
pq-suite-p2	ML-KEM-768	ML-DSA-65	Adds PQ signing
pq-suite-p3	ML-KEM-1024	ML-DSA-87	NIST level 5
pq-suite-h1	X25519 + ML-KEM-768	Ed25519 + ML-DSA-65	Hybrid (recommended default)
pq-suite-h2	X25519 + ML-KEM-1024	Ed25519 + ML-DSA-87	Hybrid, NIST level 5
pq-suite-x1	X-Wing	none	Reserved for X-Wing hybrid KEM (IETF draft)

Modes

Mode	Body encryption	Body signature
pq-only	PQ KEM + AEAD only	classical
hybrid-encrypt	DIDComm authcrypt + PQ envelope	classical
hybrid-sign	classical authcrypt	classical + PQ signature
hybrid-full	both layers	both layers

hybrid-encrypt is the recommended default: body decryption requires breaking both classical and PQ primitives.

Transcript Binding

• transcript_hash over canonical proposed-suites/modes/nonces mixed into HKDF
• kem-confirm MAC catches MITM/transcript divergence before app data flows
• Prevents downgrade attacks even if a key is later compromised

Replay Protection

• Per-propose-upgrade 32-byte nonce
• Combined with transcript_hash + kid in seen-set
• ±300-second timestamp window

Key Rotation

• rotate-key with generation counter
• Configurable overlap window so in-flight messages still decrypt
• Triggers: TTL, message count, manual, suspected compromise

Concurrent Initiation Tie-Break

• Lexicographic-DID ordering resolves dual-init races
• Avoids ambiguous dual-keypair states

Mismatched byte lengths MUST be rejected before any cryptographic processing.

Security Highlights

• Hybrid by default — pure PQ loses well-studied classical security guarantees
• Transcript binding prevents downgrade attacks
• Replay protection via nonce + transcript + timestamp window combination
• Forward secrecy via secure erasure of old generation keys after overlap
• Algorithm agility — registered suite identifiers allow seamless additions
• Constant-time crypto — implementations SHOULD use audited PQ libraries
• HKDF context strings normative for cross-implementation interop

Recommended Rollout

1. Phase 1 (additive) — implement protocol with normative type URIs; advertise in Discover Features
2. Phase 2 (default hybrid) — default to hybrid-encrypt with pq-suite-h1
3. Phase 3 (signatures live) — add pq-signature and signed pq-envelope
4. Phase 4 (rotation live) — add TTL/message-count rotation triggers
5. Phase 5 (legacy off) — once all peers advertise pq-bridge/1.0, refuse non-standard predecessors

Use Cases

• Harvest-now-decrypt-later defense — long-lived data resists future quantum decryption
• High-value credential issuance — ML-DSA signatures alongside classical
• PQ-protected vault retrievals — $ref pointers wrapped in pq-envelope
• Long-TTL Swarm pledges — cold archives under hybrid encryption
• Compliance/audit signatures — non-repudiation against PQ adversaries
• Pairwise DIDComm channels — drop-in PQ upgrade for any existing connection