WebRTC, the technology behind Chatzyo's video and voice calls, comes with strong encryption built in by the standard itself — not something we added on top. This page explains what that encryption actually is, accurately, and then the part that's more specific to how Chatzyo is built: your video never reaches our servers at all, encrypted or otherwise.
WebRTC mandates encryption for every call — this is written into the standard itself, not a feature a platform can choose to skip. Two protocols handle this: DTLS, which negotiates the encryption keys when a call starts, and SRTP, which uses those keys to actually encrypt the video and audio as it's sent. Plain, unencrypted video is explicitly forbidden by the WebRTC specification — there's no setting anywhere that turns this off.
The cipher suite that every WebRTC implementation is required to support uses 128-bit AES encryption, not 256-bit — that's worth correcting here, since it's an easy detail to get wrong and "256-bit" can sound more impressive without actually being the standard. AES-128 in this context is still considered strong, current encryption; the larger key size isn't meaningfully more secure for this kind of traffic, it's just a bigger number.
Sets up the shared encryption key between the two devices before any video or audio is sent, and protects that setup from tampering.
Uses the key DTLS negotiated to actually encrypt the audio and video stream, plus verify it hasn't been tampered with in transit.
WebRTC implementations are required to favor key exchange methods that support Perfect Forward Secrecy, meaning a new, temporary key is generated for each call rather than reusing the same key repeatedly. The practical benefit: even in the unlikely case that a key from one call was somehow exposed, it wouldn't help decrypt any other call, past or future. Each session is cryptographically independent of every other one.
Here's the part worth being precise about, because it's easy to blur "encrypted" and "private" into meaning the same thing, and they don't quite. The DTLS-SRTP encryption above is a property of WebRTC itself — any WebRTC-based platform gets it automatically, including ones that route calls through a central server. What's more specific to Chatzyo is that, whenever a direct connection between the two devices is possible, your video goes straight there — it doesn't pass through a Chatzyo server at all, encrypted or not, because there's no server in that path to pass through. That's a stronger claim than encryption alone, and it's the one we'd rather you remember.
There's an honest exception worth naming: on some networks — behind certain corporate firewalls, for instance — a direct connection isn't possible, and a relay server (called a TURN server) is used to pass the encrypted data along. The relay can't decrypt or read what's passing through it — it only handles routing, not content — but it's accurate to say the data does pass through a server in that specific case, even though that server has no way to access the call itself.
No. They're generated fresh for each call as part of the standard DTLS handshake and exist only on the two devices in that call — there's nothing for a server to store even if it wanted to.
A VPN masks your IP address from the other person, which is a separate, useful privacy layer — but it doesn't change or improve the underlying DTLS-SRTP encryption itself, which is already mandatory and already active regardless of whether you use one.