3. Transport (WebRTC)
This chapter is part of an initial draft specification. Enkrypted Chat has not been independently audited. Content may change.
3.1 Overview
Enkrypted Chat uses WebRTC for peer connectivity. PeerJS wraps WebRTC for peer discovery and signaling. Application messages travel over encrypted data channels (SCTP over DTLS). Media for calls uses SRTP (DTLS-SRTP).
Application-level E2EE (cascade) is in addition to transport encryption, not a replacement.
3.2 Connection establishment (v1)
This specification documents online broker signaling only:
- Each peer connects to a signaling server with its peer ID.
- Caller initiates connection to callee’s peer ID via the broker.
- Peers exchange SDP and ICE candidates through the broker.
- WebRTC establishes a direct or relayed path.
- Application keys and ciphertext are exchanged over the established data channel.
Out of scope for v1: QR-based or fully offline SDP exchange (implemented in UI components but not specified here per product direction).
3.3 ICE, STUN, and TURN
| Mechanism | Role |
|---|---|
| STUN | Discovers server-reflexive addresses for NAT traversal |
| TURN | Relays traffic when direct P2P fails |
| ICE | Selects best candidate pair |
Deployments MAY configure custom STUN/TURN servers. Default third-party TURN (e.g. metered.ca) is semi-trusted.
Relay-mode: When enabled, traffic may be proxied through TURN continuously. This improves connectivity but increases exposure to traffic analysis on the relay. Users MAY combine relay-mode with a trusted VPN as a hardening measure (user-operated, not provided by the app).
3.4 What the transport layer protects
| Property | WebRTC transport | Notes |
|---|---|---|
| Confidentiality on wire | DTLS (data), SRTP (media) | Browser-dependent |
| Integrity | DTLS/SRTP | |
| Forward secrecy (transport) | DTLS key agreement | Browser implementations vary |
| Hiding peer IPs | Partial | TURN/VPN may help; not guaranteed |
Application plaintext MUST NOT be assumed protected by transport alone if application crypto is disabled (debug builds).
3.5 Signaling security
The signaling server:
- MUST NOT be relied upon to keep conversations confidential (it does not hold MLS/Signal keys).
- SHOULD be operated over HTTPS/WSS.
- SHOULD be self-hosted for high-threat users.
Compromise of signaling enables metadata analysis and MITM on connection setup unless peers verify out-of-band (future TOFU/QR work).
3.6 Tor, VPN, and anonymity
- Tor: WebRTC is generally unsuitable over Tor; treated as a non-goal for this product.
- VPN: Optional user hardening; does not replace E2EE.
- Onion routing: Listed as future investigation in project roadmap, not implemented.
3.7 Performance
No formal benchmarks are published in this draft. Latency depends on P2P path, TURN use, and cascade depth. Fast file transfer (optional) uses a dedicated data channel path documented in Chapter 6.