Protocol Specification

Keylane is a privacy-first, zero-knowledge, end-to-end (E2E) encrypted transport protocol built to route messages with mathematical certainty. We explicitly avoid the collection of social graph metadata, sender identities, and online status footprints.

This document outlines the cryptographic primitives and architectural design choices that enforce our zero-knowledge guarantee, ensuring that even under legal compulsion or server compromise, user data remains mathematically inaccessible.

1. Cryptographic Identity (No Phone Numbers)

Unlike legacy secure 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 defined by a Hybrid Post-Quantum Identity Key combining Ed25519 (classical) and ML-DSA / Kyber (post-quantum).
• Decoupled Routing: Internal network addressing utilizes time-ordered UUIDs. These identifiers map to a user's public keys but are entirely decoupled from their real-world identity.
• Device-Centric E2EE: Messages are routed and encrypted to specific Devices, not Users. A User is simply a collection of cryptographic Device endpoints, each with its own localized private keys.

2. Post-Quantum Proof-of-Possession Auth

Keylane discards traditional session cookies and passwords. Authentication to the routing network is proven mathematically on every request using a dynamically minted Proof of Possession (PoP) Bearer Token.

• Client-Signed Requests: Tokens are signed client-side using the device's Hybrid Identity Key. The server verifies the signature against the public key registered to that device.
• Anti-Replay Protection: Every token contains a cryptographic nonce (jti). The server tracks all nonces in a highly-optimized ephemeral cache. Because tokens enforce a strict 60-second Time-To-Live (TTL), the cache is easily pruned, making intercepted token replay attacks mathematically impossible.

3. Post-Quantum Key Exchange (PQXDH)

Before Alice can send a message to Bob, their devices must establish a shared secret. Keylane utilizes a Post-Quantum Extended Diffie-Hellman (PQXDH) handshake.

• PreKey Bundles: Devices continuously publish bundles of "One-Time PreKeys" to the Keylane server. These bundles contain both classical X25519 curve points and post-quantum ML-KEM public keys.
• Hybrid Shared Secret: When Alice initiates a chat, she fetches Bob's PreKey bundle. She performs classical Diffie-Hellman (X25519) and simultaneously encapsulates a secret against Bob's ML-KEM key. Both resulting secrets are fed into a Key Derivation Function (KDF) to produce a master shared secret.
• Forward Secrecy & Future-Proofing: Because one-time keys are destroyed after use, compromise of long-term identity keys does not compromise past messages. The hybrid approach ensures that an adversary must break both the classical elliptic curve and the post-quantum lattice problem to decrypt the communication.

4. Payload Encryption

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

• SecretBox (ChaCha20-Poly1305): Keylane utilizes the high-performance NaCl/Kodium SecretBox construction. Payloads are encrypted using the ChaCha20 stream cipher and authenticated with a Poly1305 MAC, ensuring confidentiality and cryptographic integrity.
• Sealed Envelopes: The resulting ciphertext is sent to the server. The server acts purely as a "dumb pipe." It holds the encrypted envelope and the destination device ID, but it completely lacks the symmetric keys required to open the SecretBox.

5. Group Chat Fan-out Optimization

Standard E2EE requires encrypting a message individually for every participant's device, which consumes massive bandwidth for large groups sending high-resolution media. Keylane solves this using a zero-knowledge "Shared Payload" fan-out.

• Symmetric Payload Encryption: Alice generates a single, random, high-entropy AES-256 key. She encrypts the heavy media or message payload exactly once using this AES key.
• Key Wrapping: Alice then takes this AES key and encrypts it individually for every participant's device using their pairwise PQXDH shared secrets (the SecretBox).
• Blind Server Distribution: Alice uploads one heavy encrypted AES payload and N tiny encrypted key wrappers. The server blindly fans out the heavy payload to all requested devices alongside their specific key wrapper. The server never sees the AES key, and thus cannot read the group payload.

6. Zero-Knowledge Metadata & Routing

We believe metadata is just as dangerous as plaintext. Our server architecture is explicitly stripped of sender identities.

• No Sender Graph: The central spooling database does not record who sent the message. The social graph (who talks to whom) cannot be reconstructed from our database dumps.
• Spam Prevention (Capabilities): To prevent unauthenticated spam without tracking users, Keylane relies on hashed capability tokens. The server enforces strict global rate-limits on unknown senders. Providing a valid capability token bypasses this limit entirely, allowing the message through without revealing the sender's identity to the network.
• Ephemeral Storage: Messages are permanently purged from the server the moment a client acknowledges receipt (via a cryptographic watermark), or when a strict 14-day maximum Time-To-Live (TTL) expires.

7. Zero-Knowledge File Exchange (Attachments)

Securely routing large media files (images, videos, documents) requires a decoupled approach to prevent network congestion while maintaining strict E2EE guarantees.

• Client-Side Blob Encryption: Before a file leaves the sender's device, it is encrypted entirely client-side using a freshly generated, high-entropy symmetric key (e.g., ChaCha20 or AES-256).
• Opaque Capability URLs: The encrypted binary blob is uploaded to the Keylane server's ephemeral storage. The server responds with a mathematically unguessable 32-byte hex identifier (a capability URL) and knows nothing about the file's contents, type, or sender.
• Key Exchange via Payload: The sender takes the 32-byte file identifier and the symmetric decryption key, and embeds them inside the standard E2E encrypted message payload (the SecretBox) sent to the recipient.
• Secure Retrieval: The recipient's device decrypts the E2E message, extracts the file identifier and symmetric key, downloads the opaque blob from the server, and decrypts the media locally. The server automatically purges the encrypted blob from disk upon TTL expiration.

8. Privacy-Preserving Push Notifications

Mobile operating systems aggressively sleep background connections to save battery, forcing apps to route wake-up signals through Apple Push Notification service (APNs) or Google Firebase Cloud Messaging (FCM). Passing ciphertext through these corporate networks creates severe metadata and privacy leaks.

• Decoupled Triggers: Keylane explicitly refuses to send encrypted message payloads through Apple or Google's infrastructure.
• Metadata-Stripped Wake Signals: When the Keylane server needs to wake a sleeping device, it sends a generic, metadata-stripped "Wake Up" signal. This push payload contains no sender information, no message type, and no ciphertext—only a random message ID or a generic "New Message" localization key.
• Direct Ciphertext Retrieval: Upon receiving the wake-up signal from APNs/FCM, the Keylane client application immediately spins up a secure, direct connection to the Keylane routing server to download the pending encrypted ciphertexts. Apple and Google only ever see that a wake-up occurred, remaining completely blind to the communication graph and payload.