Cryptography & architecture

Keylane is a privacy-first, zero-knowledge, end-to-end encrypted transport protocol built to route messages with strong cryptographic guarantees. It explicitly avoids collecting social-graph metadata, sender identities, and online-status footprints.

This document describes the protocol. For an account of what the resulting system does not protect against, read the threat model alongside it.

---

1. Cryptographic identity (no phone numbers)

Unlike messengers that anchor identity to a telecom-issued phone number, Keylane operates entirely on randomly generated cryptographic key pairs.

• Identity keys. A user’s core identity is a hybrid post-quantum identity key combining Ed25519 (classical) with ML-DSA (post-quantum).
• Decoupled routing. Internal network addressing uses time-ordered UUIDs. These identifiers map to a user’s public keys but are entirely decoupled from any real-world identity.
• Device-centric E2EE. Messages are routed and encrypted to specific devices, not users. A user is a collection of cryptographic device endpoints, each holding its own private keys.

The user-facing consequences of this design — creating an identity, linking devices, and what happens when keys are lost — are covered in Keylane ID.

2. Post-quantum proof-of-possession authentication

Keylane discards session cookies and passwords. Authentication to the routing network is proven on every request using a dynamically minted proof-of-possession (PoP) bearer token.

Token format: Base58(header) . Base58(payload) . Base58(signature)

// Payload example
{"iss":"DEVICE_UUID", "exp":1711550000, "jti":"UNIQUE_NONCE"}

• Client-signed requests. Tokens are signed client-side with the device’s hybrid identity key. The server verifies the signature against the public key registered to that device.
• Anti-replay protection. Every token carries a cryptographic nonce (jti), tracked in an ephemeral cache. Tokens enforce a strict 60-second time-to-live, so the cache stays small and the replay window is bounded to those 60 seconds — a captured token is useless once it expires.

3. Post-quantum key exchange (PQXDH)

Before Alice can send a message to Bob, their devices must establish a shared secret. Keylane uses a post-quantum extended Diffie–Hellman handshake.

• Prekey bundles. Devices continuously publish bundles of one-time prekeys to the server. Each bundle contains both classical X25519 curve points and post-quantum ML-KEM public keys.
• Hybrid shared secret. Alice fetches Bob’s prekey bundle, performs classical Diffie–Hellman (X25519), and simultaneously encapsulates a secret against Bob’s ML-KEM key. Both results are fed into a key derivation function to produce a master shared secret.
• Forward secrecy and future-proofing. One-time keys are destroyed after use, so compromise of long-term identity keys does not compromise past messages. The hybrid construction means an adversary must break both the elliptic-curve problem and the lattice problem to decrypt the exchange.

4. Payload encryption

Once the PQXDH shared secret is established, the message payload is encrypted symmetrically using authenticated encryption.

• SecretBox (ChaCha20-Poly1305). Keylane uses the NaCl/Kodium SecretBox construction. Payloads are encrypted with the ChaCha20 stream cipher and authenticated with a Poly1305 MAC, providing confidentiality and integrity together.
• Sealed envelopes. The resulting ciphertext is sent to the server, which holds the encrypted envelope and the destination device ID but lacks the symmetric keys required to open the SecretBox.

5. Group chat fan-out optimization

Standard end-to-end encryption requires encrypting a message individually for every participant device, which is expensive for large groups sending high-resolution media. Keylane reduces this cost with a zero-knowledge shared-payload fan-out.

• Symmetric payload encryption. The sender generates a single random high-entropy AES-256 key and encrypts the heavy payload exactly once with it.
• Key wrapping. That AES key is then encrypted individually for each participant device using the pairwise PQXDH shared secrets.
• Blind distribution. The sender uploads one heavy encrypted payload plus N small encrypted key wrappers. The server fans the payload out alongside each recipient’s wrapper. It never sees the AES key and cannot read the group payload.

6. Zero-knowledge metadata and routing

Metadata is treated as seriously as plaintext. The server architecture is designed to avoid recording sender identities at all.

• No sender graph. The central spooling database does not record who sent a message. The social graph cannot be reconstructed from a database dump.
• Spam prevention via capabilities. To prevent unauthenticated spam without tracking users, Keylane uses hashed capability tokens. The server enforces strict global rate limits on unknown senders; a valid capability token lifts that limit without revealing the sender’s identity to the network.
• Ephemeral storage. Messages are purged the moment a client acknowledges receipt via a cryptographic watermark, or when the strict 14-day maximum TTL expires — whichever happens first.

7. Zero-knowledge file exchange

Routing large media requires a decoupled approach that avoids network congestion while preserving end-to-end guarantees.

• Client-side blob encryption. Before a file leaves the sender’s device it is encrypted with a freshly generated high-entropy symmetric key.
• Opaque capability URLs. The encrypted blob is uploaded to ephemeral storage. The server responds with an unguessable 32-byte identifier and learns nothing about the file’s contents, type, or sender.
• Key exchange via payload. The identifier and the decryption key are embedded inside the end-to-end encrypted message payload sent to the recipient — never alongside the blob.
• Secure retrieval. The recipient decrypts the message, extracts the identifier and key, downloads the opaque blob, and decrypts it locally. The server purges the blob at TTL expiry.

8. Privacy-preserving push notifications

Mobile operating systems sleep background connections, forcing apps to route wake-up signals through Apple Push Notification service or Firebase Cloud Messaging. Passing ciphertext through those networks creates severe metadata leaks.

• Decoupled triggers. Keylane does not send encrypted message payloads through Apple or Google infrastructure.
• Metadata-stripped wake signals. To wake a sleeping device the server sends a generic signal containing no sender information, no message type, and no ciphertext — only a random message ID or a generic localization key.
• Direct ciphertext retrieval. On receiving the signal, the client opens a direct connection to the Keylane relay to download pending ciphertexts. Apple and Google observe only that a wake-up occurred, and stay blind to the communication graph and the payload.

---

Implementation status

This specification describes the protocol as implemented in the public beta. The cryptographic core is published as Kodium under the Apache License 2.0; the full client source is being prepared for release. No independent audit of the implementation has been completed yet — progress is tracked on the roadmap.

Errors and ambiguities in this document are worth reporting. Protocol design flaws are in scope under the vulnerability disclosure policy.