How X2Chat protects your conversations
This page is written for people who read security pages. It says what we encrypt, what the server can see, and what we have not solved yet. No marketing adjectives.
Identity: no phone number, no email
An account is a key pair generated on your device. The app creates an Ed25519 signing key and an RSA-2048 encryption key; the server stores only the public halves and assigns a 6-character ID (like A7X29B). Sign-in is a challenge signed with your private key. There is no password to phish and no phone number to SIM-swap.
The private keys live in the OS secure storage (Keychain on Apple platforms, Keystore-backed storage on Android). They never leave the device unless you create an encrypted backup with a password you choose.
Messages and files
- Every message and file gets a fresh random AES-256-GCM key.
- That key is wrapped with the RSA-2048 public key of each recipient device (RSA-OAEP) and sent alongside the ciphertext.
- The server stores and relays ciphertext and wrapped keys. It cannot unwrap them: it has no private keys.
- Group chats work the same way: the sender wraps the message key for every member device.
Calls
- Video and fallback audio go over WebRTC. Media frames are encrypted end-to-end with AES-GCM using Insertable Streams (FrameCryptor) before they reach the network. TURN relays and our servers see encrypted frames only.
- One-to-one audio uses our own QUIC transport with Opus and AES-256-GCM. The relay forwards packets it cannot decrypt.
- Call keys are exchanged through the signaling server, but they are themselves encrypted with the participants’ E2E keys.
Verifying you talk to the right person
Public keys can be exchanged in person by scanning a QR code. A key obtained by QR is marked verified and always takes precedence over a key received from the server, so the server cannot silently substitute one. The server also refuses to overwrite a device’s registered key (it returns a conflict), so a key change is never silent.
What the server can see
| The server has | The server does not have |
|---|
| Your ID, display name, avatar, public keys, device identifiers, push tokens | Message text, file contents, call audio or video |
| Who talks to whom, when, message sizes, delivery status | Your private keys, the AES keys of any message |
| Your IP address at registration and sign-in (kept for abuse handling) | Your phone number, email, contacts book (there is no contact upload) |
| Diagnostic logs if you send them from the app | Any way to decrypt what you sent yesterday |
Known limitations (honest list)
- No forward secrecy yet. Message keys are wrapped with a long-lived RSA-2048 device key. If that private key is extracted from your device, previously captured ciphertext for that device could be decrypted. A ratchet (Signal-style) is on the roadmap; today the mitigation is device secure storage plus the ability to re-key a device.
- Metadata is visible to us. Like most messengers, we know who messaged whom and when. We do not build social graphs from it, but we do not hide it either.
- Chats with bots are not end-to-end encrypted. A bot has no device keys; those messages are readable by the server. The app labels bot chats accordingly.
- No independent audit yet. The design described here has not been reviewed by a third party. We will publish results when it is.
- Closed source. The client and server code are not public today. We understand this limits verifiability and are evaluating what to open first (the crypto layer is the candidate).
- Backups are your responsibility. Lose the device without a backup and the old history is gone; there is no server-side recovery, by design.
Infrastructure
Two data centres in different jurisdictions replicate account metadata so the service survives one of them going down. Encrypted content is stored where it was uploaded and fetched over TLS. The transport layer includes a QUIC relay written in Rust and an obfuscated tunnel for networks that interfere with ordinary traffic; that layer never has plaintext.
Questions and reports
Security reports: privacy@x2chat.com. Please include steps to reproduce; we answer within a few days and credit reporters who want credit.
See also the privacy policy.
Как X2Chat защищает вашу переписку
Эта страница для тех, кто читает такие страницы. Здесь то, что мы шифруем, что видит сервер и что ещё не решено. Без рекламных прилагательных.
Личность: без номера телефона и почты
Аккаунт — это пара ключей, созданная на вашем устройстве: Ed25519 для подписи и RSA-2048 для шифрования. Сервер хранит только публичные половины и выдаёт шестизначный ID (например, A7X29B). Вход — это подпись челленджа вашим приватным ключом. Нет пароля, который можно выудить, и номера, который можно перехватить.
Приватные ключи лежат в защищённом хранилище системы (Keychain на Apple, хранилище на базе Keystore на Android) и покидают устройство только если вы сами сделаете зашифрованный бэкап с вашим паролем.
Сообщения и файлы
- Каждое сообщение и файл получает новый случайный ключ AES-256-GCM.
- Этот ключ заворачивается публичным RSA-2048-ключом каждого устройства получателя (RSA-OAEP) и уезжает вместе с шифртекстом.
- Сервер хранит и передаёт шифртекст и завёрнутые ключи. Развернуть их он не может: приватных ключей у него нет.
- Группы устроены так же: отправитель заворачивает ключ сообщения для каждого устройства каждого участника.
Звонки
- Видео и резервный аудио-канал идут через WebRTC. Кадры шифруются сквозным AES-GCM через Insertable Streams (FrameCryptor) до выхода в сеть. TURN-релеи и наши серверы видят только зашифрованные кадры.
- Аудио один-на-один идёт по нашему QUIC-транспорту с Opus и AES-256-GCM. Релей пересылает пакеты, которые не может расшифровать.
- Ключи звонка передаются через сигнальный сервер, но сами зашифрованы E2E-ключами участников.
Проверка, что вы говорите с тем человеком
Публичные ключи можно обменять лично по QR-коду. Ключ из QR помечается проверенным и всегда имеет приоритет над ключом с сервера, поэтому сервер не может тихо подменить его. Сервер также отказывается перезаписывать зарегистрированный ключ устройства (отвечает конфликтом), так что смена ключа никогда не бывает тихой.
Что видит сервер
| У сервера есть | У сервера нет |
|---|
| Ваш ID, имя, аватар, публичные ключи, идентификаторы устройств, пуш-токены | Текста сообщений, содержимого файлов, аудио и видео звонков |
| Кто с кем и когда переписывается, размеры сообщений, статусы доставки | Ваших приватных ключей, AES-ключей сообщений |
| IP-адрес при регистрации и входе (для борьбы со злоупотреблениями) | Номера телефона, почты, адресной книги (её выгрузки нет) |
| Диагностические логи, если вы отправите их из приложения | Способа расшифровать то, что вы отправили вчера |
Известные ограничения (честный список)
- Пока нет forward secrecy. Ключи сообщений заворачиваются долгоживущим RSA-2048-ключом устройства. Если приватный ключ извлекут с устройства, ранее перехваченный шифртекст для этого устройства можно расшифровать. Ратчет в стиле Signal в планах; сегодня защита — хранилище системы и возможность перевыпустить ключ устройства.
- Метаданные видны нам. Как и в большинстве мессенджеров, мы знаем, кто кому и когда писал. Мы не строим по этому социальные графы, но и не прячем это.
- Чаты с ботами не зашифрованы сквозным шифрованием. У бота нет ключей устройства, такие сообщения читаемы сервером. Приложение помечает такие чаты.
- Независимого аудита ещё не было. Описанная схема не проверялась третьей стороной. Опубликуем результаты, когда проверят.
- Закрытый код. Клиент и сервер сегодня не открыты. Понимаем, что это ограничивает проверяемость, и решаем, что открыть первым (кандидат — криптослой).
- Бэкап — ваша ответственность. Потеряли устройство без бэкапа — старая история пропала; серверного восстановления нет, так задумано.
Инфраструктура
Два дата-центра в разных юрисдикциях реплицируют метаданные аккаунтов, чтобы сервис пережил падение одного из них. Зашифрованный контент хранится там, куда был загружен, и отдаётся по TLS. Транспортный слой включает QUIC-релей на Rust и обфусцированный туннель для сетей, которые мешают обычному трафику; у этого слоя никогда нет открытого текста.
Вопросы и сообщения об уязвимостях
Сообщения о безопасности: privacy@x2chat.com. Приложите шаги воспроизведения; отвечаем в течение нескольких дней и указываем авторов, если они этого хотят.
См. также политику конфиденциальности.