Dialog PTT encrypts voice on the device before it leaves. The server relays ciphertext it cannot decrypt. No RF interception risk. No cleartext audio in transit.
Each talkgroup has its own AES-256-GCM encryption key. Keys are generated by the server and delivered to devices after successful authentication — the server never sends keys to unauthenticated clients.
When a device joins a group, it receives the current key for that group only — not keys for groups it doesn't belong to. Group membership is enforced server-side.
Keys are rotated automatically. If a device leaves a group, the next rotation ensures it cannot decrypt future audio for that group — even if it retains the old key.
The Dialog PTT server's role is pure relay. Audio frames arrive as ciphertext and are forwarded to group members as ciphertext. The server has no decryption capability for audio data.
This means:
AES-256 in Galois/Counter Mode. GCM provides both confidentiality and authentication — a tampered ciphertext is detected and dropped before playback. No separate MAC required.
Each audio frame uses a fresh 12-byte cryptographically random nonce. Nonce reuse is the primary failure mode for GCM — Dialog PTT eliminates this by generating a new nonce for every single Opus frame transmitted.
AAD = group_id (4 bytes) + sequence_number (4 bytes). This binds the ciphertext to its group and position in the stream — providing replay attack protection without decrypting the audio content.
E2EE audio frame payload: [group_id:4][seq:4][nonce:12][ciphertext+GCM_tag:N+16]. The 16-byte GCM authentication tag is appended after the ciphertext. Total overhead per frame: 36 bytes.
GROUP_KEY frames (message type 0xE1) carry: [group_id:4][key_id:2][key:32]. Delivered to authenticated devices only. Previous and current key held simultaneously during rotation for in-flight frame tolerance.
QUIC connections use TLS 1.3 with certificate pinning on all clients. WebSocket fallback uses TLS 1.2/1.3. Transport encryption is in addition to E2EE audio — audio ciphertext rides inside an encrypted tunnel.
Dialog PTT implements device binding using EC P-256 keypairs stored in the Android Keystore (hardware-backed secure element where available) and iOS Secure Enclave.
During authentication (AUTH v3), the device signs a timestamp with its private key. The server verifies the signature and performs TOFU (Trust On First Use):
A device account can only have one active session at a time. When a new connection authenticates successfully, any existing session for the same account is kicked with a KICK_NOTIFY frame before the new session is established.
This prevents credential sharing — if credentials are leaked and used on a second device, the original device is disconnected. The dispatcher can see session changes in the audit log.
Device binding can be reset by an administrator via the web portal. Resetting hardware lock clears the stored public key — the next connection from any device with the credentials will be accepted as a new TOFU registration.
| Feature | Dialog PTT | DMR Radio | Typical VoIP PTT |
|---|---|---|---|
| Audio encryption | AES-256-GCM E2EE | Proprietary (optional, addon cost) | None / transport only |
| RF interception risk | None (IP-based) | Yes (SDR scannable) | None (IP-based) |
| Server can decrypt | No | N/A | Usually yes |
| Key management | Automatic, per-group | Manual / OTA programming | None |
| Transport security | TLS 1.3 + cert pinning | N/A | TLS (varies) |
| Device binding | ECDSA hardware key | Radio ID (spoofable) | Username/password only |
| Replay protection | Yes (AAD + timestamp) | No | Varies |
Request a demo and we'll walk you through the full security architecture — including live verification of E2EE with Wireshark capture if needed.
Request a Demo Self-Hosted →