How call encryption works
What the “Fully encrypted — end-to-end” badge means, what our server sees of a call, and why a device that cannot encrypt every frame is refused instead.
An ordinary internet call is encrypted between your device and the service, which then has the sound. A Private.Ki call is encrypted between the two devices, and the sound never exists anywhere else — not on our servers, not in a log, not in a form anybody here could listen to. This page is what the Fully encrypted — end-to-end badge on the call screen stands for.
Three layers, all of them on the devices
Setting the call up. Every signalling message — the offer, the answer, the network details, ringing, decline, busy, hang-up — is encrypted to the other person's public key and signed with yours before it leaves your device, exactly as a chat message is. Our server relays sealed envelopes. It can tell that an offer went from one address to another at a certain time; it cannot open one.
The key. The caller's device generates a fresh AES-256-GCM key for that one call and puts it inside the encrypted offer. So the key reaches the other person and nobody else, it is never stored, and it is never reused: a second call means a second key.
The media. Every encoded audio frame is encrypted with that key before it is handed to the call engine, and decrypted on the other side after the engine has done with it. Video frames are encrypted the same way, in a format of their own. This is the part that matters: even the transport that carries the call sees only ciphertext.
What our server sees
Cannot see
- Your voice or your picture — not live, not stored, not in any form
- The call's encryption key, or any signalling payload
- Whether a camera was on
Can see
- That a call was set up between two addresses, its call id, and the times it started and ended
- Enough to enforce one call at a time per account and a rate limit on call attempts
While a call is live our server keeps a small record of it so the two sides can find each other and so a second, simultaneous call can be refused. It is deleted when the call ends. The line the conversation shows afterwards — Call · 3:12 — is a normal encrypted chat message written by the caller's device, so even the duration is something the server stores without being able to read.
No media relay, and what that costs
The audio and video travel directly between the two devices. There is no relay of ours in the middle. That is the strongest possible version of "we cannot listen", and it has two honest consequences:
To connect directly, the two devices exchange network addresses. So the person you call learns your device's IP address and you learn theirs — as in any direct call. If that matters for a particular conversation, send messages instead; messages always go through our server and never expose either address to the other party.
The second consequence is that some pairs of networks simply cannot be joined directly, and the call then ends rather than being quietly re-routed. That case has its own page: When a call does not connect.
Why a browser or a device can be refused
Before any microphone is opened, the app asks one question: can every encoded frame of this call be encrypted with the call key? If the answer is no, the call does not happen and you see one of:
- This browser cannot make encrypted calls — with the line Encrypted calls need a browser with WebRTC Insertable Streams (current Chrome, Edge, Safari or Firefox). No unencrypted call is ever made.
- This device cannot make encrypted calls — the same refusal in an app build whose encrypted-frame module did not load.
There is deliberately no fallback. A call that could not be encrypted frame by frame is not offered in a weaker form, is not placed "just this once", and is never started and then downgraded. The same rule applies to video: a side that cannot encrypt video frames has its camera greyed out, and the call continues as an encrypted voice call.
Common questions
Is the encryption different from the one used for messages?
The envelope around the call setup is the same PGP encryption your messages use. The media inside the call uses AES-256-GCM with a key that exists only for that call, because audio and video have to be encrypted frame by frame as they are produced.
Could you be compelled to hand over a call?
There is nothing to hand over. We hold no media, no key and no transcript — only the fact that two addresses set up a call, and for as long as the call lasts. See the transparency report.
Does the badge ever lie?
The badge is drawn from the state of the call, and a call cannot reach a connected state without the frame encryption being attached. If it could not be attached, the call fails instead.
Can I see which browsers support encrypted calls?
The refusal names them: current Chrome, Edge, Safari or Firefox. Desktop and mobile browsers both qualify when they are current.