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.
Each encrypted frame is authenticated against its group and its position in the stream, so captured audio cannot be replayed or reordered — all without the server ever decrypting the content.
Group keys are delivered only to authenticated devices, and rotated keys overlap briefly so audio in flight is never lost during a rotation. The relay never holds the means to decrypt the audio it forwards.
All connections use TLS 1.3 with certificate pinning enforced on every client. Transport encryption is a second layer on top of E2EE audio — audio ciphertext rides inside an already-encrypted tunnel.
Dialog PTT binds each account to its device with a private key held in the device's secure hardware — protected by the platform's hardware-backed key store where available, and never exportable from the device.
During authentication the device signs a request with its private key. The server verifies the signature and trusts the key 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 disconnected 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 is registered fresh on first use.
| 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 | Hardware-backed key | Radio ID (spoofable) | Username/password only |
| Replay protection | Yes (authenticated + timestamped) | 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 →