Skip to content
Tenzro
Documentation menu
Keys and identity

Secure messaging

Identity-bound encrypted messages between people, agents and machines, keyed with hybrid X25519 and ML-KEM-768 and signed by the sender's DID.

Secure messaging lets any two Tenzro identities, whether people, agents or machines, exchange messages that only the recipient can read and that provably come from the sender. Each message is encrypted to the recipient's DID and signed by the sender's DID. Key agreement is hybrid, X25519 plus ML-KEM-768, so a message recorded today stays confidential against a future quantum attacker.

What a message guarantees

PropertyHow
ConfidentialityA fresh symmetric key per message, agreed with hybrid X25519 + ML-KEM-768 and used with AES-256-GCM
AuthenticityThe sender signs the envelope with its hardware-rooted key: a composite classical + ML-DSA-65 signature
IntegrityAES-256-GCM authenticates the ciphertext; the signature covers the ciphertext and the headers
Binding to identityThe recipient resolves the sender's DID and checks the signature against its registered keys before decrypting
FreshnessEach message carries a timestamp and a nonce; stale or repeated messages are rejected

How a message is built

  1. Resolve the recipient. The sender resolves the recipient's DID to its DID Document and reads its key-agreement keys: an X25519 public key and an ML-KEM-768 encapsulation key.
  2. Agree a key. The sender makes a fresh ephemeral X25519 key pair and runs X25519 against the recipient's key, and encapsulates to the recipient's ML-KEM-768 key. Both shared secrets feed HKDF-SHA256 together with the transcript of public keys, giving a per-message AES-256-GCM key. Both legs must succeed; there is no fallback to one of them.
  3. Encrypt. The payload is encrypted with AES-256-GCM.
  4. Sign. The sender signs the envelope (sender DID, recipient DID, ephemeral key, encapsulation, ciphertext, timestamp, nonce) with its hardware-rooted key. For a person that is a passkey with user verification; for an agent or machine it is the device's TPM 2.0 or Secure Enclave key. The signature is a composite of a classical leg and an ML-DSA-65 leg.
  5. Send over any transport: A2A, MCP, HTTP or storage.

The recipient reverses the steps: resolve the sender's DID, verify the composite signature, check freshness, run X25519 and ML-KEM-768 decapsulation with its own keys, derive the same AES key and decrypt.

Because the key is derived from both an X25519 exchange and an ML-KEM-768 encapsulation, an attacker has to break both to read a message. Because the derivation is bound to the public keys involved, a captured exchange cannot be replayed against a different recipient.

Agents over A2A

Agent-to-agent messages over A2A use this envelope by default. The receiving agent verifies the sender's DID against the network's identity registry before it decrypts or acts on anything, and it can also check the sender's delegation scope: which operations it may request and what it may spend. See Agents.

Where the keys live

The recipient's key-agreement keys are published in its DID Document; the matching private keys are rooted in the recipient's hardware and derived when a message arrives. The sender's signing key is its hardware-rooted key. No messaging key is kept in a file. See Hardware-rooted keys.