--- title: How the encryption works description: Two ciphers instead of one, hybrid post-quantum key agreement, and a pairing ceremony with no key server, plus what this protects against and what it doesn't. order: 3 --- # How the encryption works Calendite's sharing is built on an open, separately auditable library called the [Layered Encryption Protocol](https://github.com/Calendite/layered-encryption-protocol). It's a separate repository on purpose: cryptography you can't inspect is cryptography you have to take on faith. This page explains what it does in plain terms, including the part people ask about most: whether a future quantum computer changes anything. > Sharing is **Android only for now.** Everything below describes what happens when you pair two > phones and sync. --- ## Two ciphers, not one Your data is encrypted **twice**, in layers: ``` your calendar data └─ ChaCha20-Poly1305 (inner layer) └─ AES-256-GCM (outer layer) └─ sealed blob that gets stored or sent ``` The two layers use **independent keys**, each derived separately so the same key is never used twice. Reading your data means breaking ChaCha20-Poly1305 **and** AES-256. A break of one is not a break of your calendar. Encrypting twice is unusual in messaging apps and completely normal in disk encryption, where VeraCrypt and similar tools have done it for years. The cost is a few microseconds per operation. The benefit is that Calendite doesn't have to bet your calendar on any single cipher staying unbroken. Both layers are checked on the way back in, and a blob that fails either check is rejected outright. There is no path that hands back data which hasn't been verified. --- ## Quantum computers, and why "later" is the threat No quantum computer exists that could break this today. The relevant threat is **harvest now, decrypt later**: someone records encrypted traffic today, stores it, and waits for a machine that can open it in ten or twenty years. For a calendar that is a real threat model, because your appointments are still your appointments in 2046. Calendite agrees keys using **X-Wing**, a hybrid of two systems: | Leg | What it is | What breaks it | |---|---|---| | **X25519** | the classical elliptic-curve method used across the modern internet | a large quantum computer running Shor's algorithm | | **ML-KEM-768** | a lattice-based method designed to resist quantum attack | no known quantum algorithm | They're combined, not chosen between. **An attacker has to break both.** A quantum computer defeats the X25519 leg and still faces ML-KEM-768. Equally, if a flaw is ever found in ML-KEM, the classical leg is still standing. Neither is a single point of failure. Signatures work the same way: every one is **Ed25519 and ML-DSA-65**, and both must verify. The combining step is the part that's easy to get subtly wrong, so Calendite doesn't improvise it: it implements the published X-Wing construction exactly, checked against that specification's own official test vectors. It's worth being straight about X-Wing's status. It is a published, peer-reviewed construction, but it is not yet a finished standard. It's still working its way through the process, and along the way it changed names. The original X-Wing document was retired in September 2026 when the method was taken up by the IETF's cryptography research group, where it now appears under the name **MLKEM768-X25519**. That specification, [Concrete Hybrid PQ/T Key Encapsulation Mechanisms](https://datatracker.ietf.org/doc/draft-irtf-cfrg-concrete-hybrid-kems/04/), states in as many words that the construction is identical to X-Wing, and Calendite is tested directly against the official test vectors published in it. So nothing about Calendite's encryption is out of date or unsupported. The method is the same one, still being standardised, just under a newer name. Calendite stays locked to a fixed version of it, so nothing shifts underneath data that's already encrypted. If the finished standard ever changes the details, that would arrive as a new, clearly versioned encryption suite rather than a silent change to the existing one. ### What about the symmetric layers? Quantum computers do have a general speed-up against symmetric ciphers, but a much weaker one: it effectively halves the key length. Against 256-bit keys that leaves 128 bits of security, which is far beyond any practical attack under current understanding. The two-cipher cascade above is not the weak point. --- ## Nobody to impersonate The strongest cryptography in the world doesn't help if you've unknowingly agreed keys with the wrong person. Most systems solve this with a key server, which becomes something you have to trust and something an attacker can target. Calendite has none. Trust is established **once, in person**: 1. Both phones derive a shared secret directly. 2. Both display **the same six digits**. 3. You compare them out loud, and both tap to confirm. 4. Only then are the calendar keys released. There's no directory to look anyone up in, no key server to compromise, and nothing to impersonate. For someone to interpose themselves between two phones, they'd have to make two different key exchanges produce the same six digits, which is what those digits exist to make impossible. This is why the six-digit check matters, and why tapping through it without comparing gives away the security of the whole thing. --- ## Where keys live On your phone, keys are wrapped by hardware-backed storage (StrongBox on devices that have it). They aren't sitting in a file that a backup or another app can read. Removing someone rotates the calendar key, so everything from that point on is sealed with a key they don't have. --- ## What this protects against, and what it doesn't **It protects against:** - A sync server, including ours, reading anything. It holds sealed blobs and has nothing to open them with; see [what leaves your device](/docs/privacy/what-leaves-your-device.html). - Anyone recording your traffic now to decrypt it later, quantum computer or otherwise. - Someone interposing themselves during pairing, provided you compare the six digits. - A single cipher or key-agreement method turning out to be broken. **It does not protect against:** - **Someone with your unlocked phone.** Device security is the floor everything else stands on. If an attacker is past your lock screen, they're past Calendite too. - **What a partner already has.** Revocation protects the future, not the past: anything they synced before you removed them is on their device, and no key rotation reaches it. - **Traffic shape.** A relay can't read your events, but it can see that some mailbox received some data of some size at some time. That last group isn't a gap in the cryptography; it's the boundary of what cryptography can do. --- ## Next - [Sharing your calendar](/docs/privacy/sharing-your-calendar.html): the pairing flow, and hiding individual events - [What leaves your device](/docs/privacy/what-leaves-your-device.html): the complete list of everything that ever gets sent - [Troubleshooting](/docs/troubleshooting.html): if pairing isn't working