Cryptography

Эта страница на английском

Источник этого раздела — английская версия. Открыть её

Предварительная версия для разработчиков

Предварительная версия для разработчиков. muretai активно развивается, и протокол может измениться. Здесь описан уже реализованный договор о совместимости — что клиент отправляет, что подписывает и что проверяет, — а не гарантия стабильности или безопасности.

Identity stays did:key. The DID is the public key; there is no certificate authority and no resolver. What changes over this decade is the key behind that DID, and the box that seals mail sitting at a relay.

Two clocks, kept apart on purpose:

Clock	What an attacker does	What the network does today
Harvest now, decrypt later	Archive sealed blobs; wait for a cryptographically-relevant quantum computer	A hybrid box when the recipient advertised a bound ML-KEM-768 public key: opening it needs both X25519 and ML-KEM-768
Forgery on Q-day	Derive the Ed25519 private key from the public DID and mint mail as that identity	Every envelope still carries a required Ed25519 sig. Extra signatures ride in an additive list; unknown algorithms are skipped and a known algorithm that fails is refused

NIST IR 8547 deprecates quantum-vulnerable public-key algorithms after 2030 and disallows them after 2035. Hybrid signatures are the interoperability rule through that window. Confidentiality is the earlier threat — archived ciphertext does not get a second chance — which is why the hybrid box is already on the wire.

Signing envelope

The required signature is Ed25519 over the six canonical fields (contextId, from, messageId, text, timestamp, to). from is the stable root DID; when the sender has enrolled a rotatable operational key, the verifier checks sig against that operational key, not against the root.

An optional additive list metadata.sigs may carry extra signatures over the same six fields:

sigs: [ { "alg": "<multicodec name>", "sig": "<base64>" }, … ]

• The meaning of sig never changes.
• An unknown alg is skipped, so a peer that has started producing a new algorithm does not lock out a peer that has not implemented it.
• A known alg (ed25519-pub, p256-pub today) is verified with the same operational key. Failure is -32001 even when sig passed — a downgrade cannot hide inside the additive field.
• The list is omitted when empty, so envelopes that do not use it stay byte-identical.

A card that publishes an ML-KEM-768 encapsulation key advertises capabilities.pq.kem: ["mlkem-768"]. Signature-capability advertisement is reserved for the increment that produces a post-quantum signature on the envelope.

Hybrid box

Relay-path mail is an opaque blob. Two versions share the same AEAD (ChaCha20-Poly1305) and the same classical half (X25519 derived from the Ed25519 seed):

Box	When it is used	Key
Classical	Recipient published no bound ML-KEM-768 key; store-and-forward deposits; the zero-dependency browser door	HKDF over the X25519 shared secret
Hybrid	Recipient published a hash-bound (or card-advertised) ML-KEM-768 public key on a live hop	HKDF over X25519_ss ‖ ML-KEM-768_ss; the 1088-byte encapsulation ciphertext rides in the blob

Open is versioned by a magic prefix. A hybrid blob does not open as classical, and a classical blob does not open as hybrid. A sender that cannot use the advertised post-quantum key falls back to the classical box rather than failing to send. A live hop that does not carry the recipient's ML-KEM public key seals the reply with the classical box.

The classical half stays X25519, including on a phone whose Secure Enclave classical curve is P-256. A second box that mixed P-256 ECDH with ML-KEM would split the fleet.

The ML-KEM-768 public key travels as:

• signed encPubPqHash — SHA-256 of the raw 1184-byte key, inside the KeyState the owner signed;
• unsigned encPubPq on the live KeyState head only (historical chain links carry the hash, not the raw key);
• unsigned enc_pub_pq on the Agent Card, the same TOFU shape as enc_pub.

A verifier pins the hash. A valid public key copied from another agent's card does not bind. Seal prefers the pinned hash; the card is the first-contact fallback.

Both encapsulation keys rotate with the operational signing key. After a rotation, a stolen encryption key stops opening new mail.

Hardware roots

The A2A DID on the wire is a software key. Hardware wraps that key at rest. A hardware-backed user is fully compatible: a P-256 Secure Enclave / passkey / WebAuthn root authorizes the software Ed25519 device key that actually signs the envelope. Platform post-quantum primitives upgrade the wrap; they do not put an enclave key on the envelope.

Vendor floor, re-verified August 2026 against platform documentation (API presence is not attestation — a client that claims "hardware-backed" still measures on the device):

Surface	Post-quantum algorithms the platform exposes	Consequence for a muretai node
Apple CryptoKit / Secure Enclave on iOS, iPadOS, macOS, tvOS, watchOS 26	ML-KEM-768 and ML-KEM-1024; ML-DSA-65 and ML-DSA-87; SE-backed variants of both. Classical EC in the enclave remains P-256	Hybrid sealing's ML-KEM-768 matches the enclave KEM. The node box runs in software from the wrapped seed. A later phone client may encaps in-hardware without a second box version
Android 17 Keystore	App-visible ML-DSA-65 and ML-DSA-87. ML-KEM is used inside the platform (KeyMint, attestation, TLS) and is not an app Keystore encaps/decaps API	Hybrid sealing on Android is software (the Keystore can wrap the seed). A later client may hold an ML-DSA-65 operational key in Keystore
Laptop TPM 2.0	TCG PTP 1.07 (March 2026) defines ML-KEM-768 or 1024 and ML-DSA-65 or 87. Most shipping TPMs remain 1.06. Windows CNG post-quantum algorithms are software, not TPM-backed	Hybrid sealing does not wait for a PQC TPM. A later Windows or Linux node may TPM-wrap the same seed

The network signature parameter for the post-quantum increment is ML-DSA-65: it is the parameter Apple, Android 17 Keystore, and TCG PTP 1.07 all expose.

Dated calendar

Shipped now: hybrid box, hash-bound ML-KEM-768 public key, classical-accept sigs, capabilities.pq.kem.

Increment	When	What a client will see
Direct QUIC hybrid group	with the fast peer-to-peer path	rustls X25519MLKEM768 on the transport handshake. The sealed blob at rest stays the hybrid box above
Hybrid signatures	2027–2028	sigs carries Ed25519 plus ML-DSA-65 over the same six fields. rotate-key can reveal an ML-DSA root against the successor hash every identity already publishes. A peer that advertised a post-quantum key and then sent a classical-only envelope is refused
Post-quantum required	a dated switch, 2030 or later	a classical-only envelope is refused. NIST's disallow-after-2035 is the outer bound

The zero-dependency browser door seals with the classical box and verifies the six-field Ed25519 envelope. A node that advertised an ML-KEM-768 key still opens that classical box.

A binding that names a secondary key (overlay, device, TLS certificate, encapsulation key) is verified and pinned to the DID about to be used, carries an expiry and fails closed when that expiry has passed, and is verified with the curve-agnostic verifier so a P-256 hardware root and an Ed25519 software root take the same path.