Telenoda Overview
Telenoda apps connect to the server using our own protocol, ClouProto 3. It is a binary protocol over a single long-lived connection carrying method calls from the client and events from the server — new messages, read statuses, presence, calls.
The connection is protected by standard TLS 1.3 in a strict configuration, not by custom cryptography. Only the official Telenoda apps use the protocol.
Transport
| Parameter | Value |
|---|---|
| Channel protection | TLS 1.3 only; older versions are not supported |
| Key exchange | hybrid X25519 + ML-KEM-768 only |
| Ciphers | AES-256-GCM, ChaCha20-Poly1305 |
| 0-RTT | disabled |
| Web client | WebSocket over HTTPS |
Server verification
The mobile apps don't rely on certificate authorities: the server's public key is pinned in the app itself. A forged certificate from any certificate authority won't pass verification. A backup key is kept offline, and switching to it doesn't require releasing new apps.
Browsers can't pin keys, so the web client relies on the regular certificate check for web.telenoda.org.
Sign-in and connection binding
The device proves its key with a proof bound to the specific TLS connection (RFC 9266). An intercepted proof can't be replayed on another connection. Before sign-in, only registration methods are available.
Storage and notifications
- On the server, messages are encrypted with AES-256. Every chat has its own key, and keys are stored separately from the data.
- Push notification content is encrypted with the key of the app installation.
- The apps' local database is encrypted with a key from the system's secure storage.
Calls
Call signaling goes through ClouProto, and media goes separately over SRTP. The devices negotiate media keys themselves via DTLS-SRTP. By default, traffic goes through a relay, so participants don't see each other's IP addresses.
Threat model
| Threat | Security |
|---|---|
| Interception and tampering on the network | TLS 1.3 and a pinned server key |
| A certificate from a compromised certificate authority | the apps don't trust certificate authorities |
| Downgrade to an older TLS version or classical key exchange | the client doesn't offer it, the server doesn't accept it |
| “Harvest now, decrypt later” | ML-KEM-768 in the key exchange |
| Replay of an intercepted sign-in | binding the proof to the connection |
| Server key leak | switching to the backup key without updating the apps |
What is not published
The ClouProto method schema is not published. For your own integrations, use the Bot API.