Journal of Independent Cultural Commentary

DAWAT FREE MEDIA

Promoting independent discourse, regional literature, and historical research across borders.

Voice Cryptography

Encrypted VoIP Architecture: A Technical Protocol Audit of Wire, Session, and Threema

An architectural audit of secure voice communications: evaluating WebRTC STUN/TURN direct IP leakage, decentralized onion routing, and cryptographic ratchets across high-security calling apps.

Technical diagram of WebRTC VoIP packet flows, STUN TURN server IP relaying, and decentralized onion routing meshes.
Auditing encrypted voice protocols: evaluating WebRTC peer-to-peer IP leaks, comparing Signal vs Proteus ratchets, and assessing Session's decentralized Lokinet routing. (Illustration: Dawat Research Desk)

When investigative journalists conduct voice interviews with confidential whistleblowers, remote sources, or activists in hostile jurisdictions, text messaging is often insufficient. Sensitive conversations require real-time vocal nuance, immediate follow-up questioning, and human connection.

However, voice communications introduce severe operational security risks that do not exist in asynchronous text messaging.

Modern voice-over-IP (VoIP) protocols rely on the WebRTC (Web Real-Time Communication) framework. By default, WebRTC attempts to establish direct, peer-to-peer (P2P) UDP connections between caller and receiver to minimize latency.

In doing so, it exposes the physical IP address of both parties directly to each other’s network stacks. If a state actor poses as a source and calls an investigative reporter, a direct P2P call allows the adversary to pinpoint the journalist’s home or hotel Wi-Fi IP address within seconds.

Beyond Signal, three prominent encrypted platforms claim superior enterprise or privacy architectures: Wire, Session, and Threema.

This technical manual provides an architectural audit of these three encrypted calling platforms, evaluating their cryptographic ratchets, network relay architectures, and metadata logging vulnerabilities.


1. The VoIP Threat Landscape: WebRTC STUN/TURN & Direct IP Leakage

To understand how encrypted calls betray users, one must examine the WebRTC session negotiation handshake:

                            THE WEBRTC CALL NEGOTIATION
                                         β”‚
           β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”΄β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
           β–Ό                                                           β–Ό
    PEER-TO-PEER (P2P) MODE                                RELAYED (TURN PROXY) MODE
  β€’ Caller and receiver connect directly                  β€’ Both parties connect to central TURN server
  β€’ Lowest audio latency (<100ms)                         β€’ Slightly higher latency (~150ms)
  β€’ CRITICAL VULNERABILITY:                               β€’ PRIVACY GUARANTEE:
    Exposes true public IP address to the other party!      Both parties only see the TURN server IP!

The STUN (Session Traversal Utilities for NAT) Trap

When you initiate a VoIP call from behind a home router, your phone queries a STUN server to discover its own public IP address and port mapping. * In a naive implementation, the calling app takes this discovered public IP and shares it directly with the other party via the signaling channel to establish a direct P2P stream. * The Interception Risk: Even if the audio stream is encrypted end-to-end with SRTP, an adversary who convinces you to answer a call now possesses your exact public IP address, enabling physical geolocation and ISP-level subscriber subpoenas.


2. Platform Audit 1: Wire (Proteus Protocol & Enterprise Federation)

Wire was engineered by former Skype engineers to deliver enterprise-grade secure messaging and conferencing.

WIRE TECHNICAL PROFILE:
  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
  β”‚ β€’ Cryptographic Engine: Proteus (Axolotl/Signal fork)  β”‚
  β”‚ β€’ Voice Encryption: DTLS-SRTP                          β”‚
  β”‚ β€’ Identity Anchor: Email or Phone Number               β”‚
  β”‚ β€’ Architecture: Centralized / Federated Enterprise     β”‚
  β”‚ β€’ Server Jurisdiction: Switzerland / EU                β”‚
  β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

Cryptographic Architecture

Wire utilizes the Proteus protocol, an independent implementation of the Double Ratchet Algorithm inspired by Signal. * Audio calls negotiate ephemeral keys via DTLS (Datagram Transport Layer Security) and encrypt audio frames with SRTP (Secure Real-time Transport Protocol) using AES-256. * Provides robust forward secrecy and break-in recovery.

The Metadata Vulnerability

While Wire’s voice streams are end-to-end encrypted, its server architecture maintains persistent metadata logs: * Wire servers historically maintain records of who you communicated with and when, stored in plaintext on server databases to facilitate multi-device synchronization. * Wire is legally subject to Swiss and European data protection laws, but its centralized server model makes it vulnerable to formal judicial mutual legal assistance treaties (MLAT).


3. Platform Audit 2: Threema (NaCl Cryptography & Anonymity by Design)

Threema is an independent Swiss encrypted messenger designed around a strict “metadata minimization” philosophy.

THREEMA TECHNICAL PROFILE:
  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
  β”‚ β€’ Cryptographic Engine: NaCl (Networking & Crypto Lib) β”‚
  β”‚ β€’ Voice Encryption: DTLS-SRTP (Curve25519 + Salsa20)   β”‚
  β”‚ β€’ Identity Anchor: Random 8-character Threema ID       β”‚
  β”‚ β€’ Architecture: Centralized, Privacy-Hardened          β”‚
  β”‚ β€’ Server Jurisdiction: Switzerland (Own Datacenters)   β”‚
  β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

The Anonymity Advantage: Zero Phone Number Requirement

Unlike Signal and Wire, Threema does not require a phone number or email address to register. * Upon installation, the app generates a random 8-character alphanumeric Threema ID tied to an offline public-private keypair generated entirely in local memory. * Users can purchase the app anonymously via Bitcoin or cash vouchers, making it virtually impossible for telecommunications databases to link a Threema ID to a legal physical identity.

Call Relay Policy

Threema enforces strict WebRTC call settings: * Users can toggle “Always Relay Calls” in privacy settings, forcing all voice data through Threema’s Swiss-based TURN proxies and eliminating direct P2P IP leakage. * Ephemeral call signaling packets are deleted from server RAM the instant the call concludes.


4. Platform Audit 3: Session (Decentralized Onion Routing & Lokinet)

Session represents the most radical departure from traditional VoIP architecture, eliminating centralized servers entirely.

SESSION TECHNICAL PROFILE:
  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
  β”‚ β€’ Cryptographic Engine: Session Protocol (Signal fork) β”‚
  β”‚ β€’ Network Routing: Lokinet (Decentralized Onion Mesh)  β”‚
  β”‚ β€’ Identity Anchor: 66-character Ed25519 Public Key     β”‚
  β”‚ β€’ Architecture: Fully Decentralized (Oxen Service Node)β”‚
  β”‚ β€’ Server Jurisdiction: No Central Entity / Jurisdictionβ”‚
  β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

The Decentralized Onion Routing Mesh

Session does not route communications through corporate server clusters. Instead, it operates over a decentralized, incentivized network of thousands of independent Service Nodes operating an onion-routing protocol called Lokinet.

[CALLER] ──► [ONION NODE 1] ──► [ONION NODE 2] ──► [ONION NODE 3] ──► [RECEIVER]
(Encrypts)    (Peels Layer 1)    (Peels Layer 2)    (Peels Layer 3)    (Decrypts)
  1. When an investigator initiates a voice call on Session, the audio packets are wrapped in three concentric layers of encryption.
  2. The packets traverse a multi-hop onion path across three independent global nodes.
  3. No single node knows both the origin and the destination. Node 1 knows who sent it, but not where it is going; Node 3 knows where it is going, but has no knowledge of who initiated it.
  4. Centralized subpoena attacks are physically impossible: there is no central database or company to serve with a warrant.

5. Comparative Evaluation Matrix for Newsrooms

Metric / Dimension Signal Wire Threema Session
Identity Requirement Phone Number Mandatory Phone Number or Email Random 8-char ID (Zero PII) Public Key (Zero PII)
Voice Routing Centralized (Proxy Opt-in) Centralized AWS Servers Centralized Swiss Proxies Decentralized Multi-Hop Onion
IP Leakage Defense “Always Relay Calls” Server-Routed Default “Always Relay Calls” Inherent (Onion Routing)
Server Metadata Sealed Sender (Minimal) Stores Contact History Zero Server Logs Zero Centralized Metadata
Call Quality / Latency Excellent (<80ms) Excellent (<100ms) Excellent (<100ms) Moderate (Higher Latency: 150–250ms)
Code Transparency 100% Open Source 100% Open Source 100% Open Source (Audited) 100% Open Source

6. Operational Recommendations: The Investigative Calling Protocol

  1. For General High-Security Calling: Signal remains the primary choice due to its peer-reviewed Double Ratchet implementation and excellent call quality, provided “Always Relay Calls” is toggled ON.
  2. For High-Risk Anonymous Sources: Threema or Session are technically superior because they decouple digital identity from physical SIM cards and mobile contracts.
  3. The Gold Standard for Hostile Interviews:
  4. Run Session or Threema inside a Whonix or Tails virtual machine.
  5. Verify the source’s cryptographic public key out-of-band via PGP-signed email before initiating the call.
  6. Conduct the call in an acoustically isolated room with mobile phones placed in Faraday enclosures outside the perimeter.

By understanding the network and cryptographic layer of encrypted VoIP, journalists ensure that their voice reporting remains as secure as their written dispatches.

Standard Operating Procedure Step-by-Step Field Protocol

How to Audit Encrypted VoIP Protocols for Direct IP Leakage and Anonymity

Technical evaluation of WebRTC audio streams, decentralized onion meshes, and metadata retention across secure calling platforms.

  1. Evaluate WebRTC STUN/TURN Direct IP Relaying: Verify whether the calling app routes voice packets through proxy servers or creates direct P2P connections.
  2. Audit Identity Anchors and Metadata Footprints: Determine whether accounts require phone numbers, emails, or random cryptographic public keys.
  3. Inspect Decentralized Onion Meshes in Session: Leverage Lokinet multi-hop onion routing to eliminate centralized server subpoena vectors.
  4. Verify Cryptographic Ratchets and Ephemeral Keys: Audit DTLS-SRTP negotiation to guarantee forward secrecy across calling sessions.
Forensic Q&A

Frequently Asked Verification Questions

Key technical principles, error traps, and diagnostic standards for investigative researchers.

How does a standard WebRTC voice call leak your physical IP address to the other party?
WebRTC defaults to peer-to-peer (P2P) mode to minimize latency, directly connecting callers over UDP. This exposes the public IP address of both parties unless a relayed TURN proxy mode is explicitly enforced.
Why is Session considered more anonymous for whistleblower calls than Signal or Wire?
Session requires no phone number or email (identities are random Ed25519 public keys) and routes all packets through a decentralized multi-hop onion network (Lokinet), ensuring no single entity has central metadata records.
Threat Monitoring & Verification Triage Zero Server Uploads β€’ 100% Private RAM

Evaluate Real-Time Threats & Triage Channels

Cross-reference communication intercept risks against regional threat indicators in our real-time Conflict Monitor and decision tree.

Launch Conflict Threat Monitor β†’ Verification Triage Checklist β†’

About the Contributor

The Dawat Forensic Research Desk specializes in open-source investigative intelligence, conflict zone media verification, and digital human rights documentation.

Curated Intelligence

Related Research & Dispatches

View Complete Investigative Archive β†’