01 — Foundation
Core_Security::Pillars
Four non-negotiable principles underpin every interaction in ShareLink. These are not marketing claims — each is a verifiable cryptographic or architectural guarantee.
AES-256-GCM Encryption
All messages and files are encrypted using 256-bit Advanced Encryption Standard in Galois/Counter Mode. AES-256 is a symmetric-key block cipher that operates on 128-bit blocks of data with a 256-bit key, producing ciphertext indistinguishable from random noise. GCM mode adds authenticated encryption, meaning each ciphertext includes a 128-bit authentication tag that detects any tampering — ensuring both confidentiality and data integrity simultaneously at the L4 transport layer.
Zero-Knowledge Storage
ShareLink operates without any persistent database. Your messages, file metadata, and session identifiers exist solely in the volatile RAM of your local browser process. When a WebRTC handshake terminates — either by disconnection or manual closure — all associated memory buffers are deallocated and overwritten. There is no write-ahead log, no disk persistence, and no cloud backup. If you close the tab, the session is cryptographically dead.
Signaling Ephemerality
Our signaling server functions as a one-time matchmaker, never a data relay. It exchanges only Session Description Protocol (SDP) offers and ICE candidates — structured JSON objects that describe network topology, not content. The instant both peers confirm a direct ICE connection path, the signaling server is algorithmically evicted from the data flow. All subsequent communication is peer-to-peer. The server cannot log, inspect, or forward your traffic.
End-to-End P2P Architecture
Unlike centralized architectures where your data is relayed through corporate infrastructure, ShareLink establishes a direct encrypted bitstream between two browser endpoints using WebRTC's RTCDataChannel API. Each channel is bound to a unique DTLS certificate negotiated at session initiation. Data traverses the shortest possible network path — typically a direct UDP stream — and is never buffered, stored, or observable by any intermediate node.
02 — Architecture
Protocol::Stack
Every data channel message in ShareLink descends through the following layered protocol stack before leaving your device. Each layer adds a specific capability — delivery guarantees, encryption, or routing.
03 — Deep Dive
WebRTC::Explained
Web Real-Time Communication is not a single protocol — it is a collection of IETF and W3C standards that work in sequence to establish a secure, encrypted, peer-to-peer data channel inside a browser. Each step below is mandatory and non-bypassable.
SDP: Session Description Protocol
SDP is the foundational handshake language of WebRTC. Before two peers can communicate, they must mutually describe their capabilities in a structured plaintext format. An SDP document contains: the media types supported (audio, video, data), the codec preferences in priority order, the network ports available, the encryption fingerprint (a hash of the DTLS certificate), and the ICE credentials (username fragment + password).
The process begins when Peer A creates an "SDP Offer" — a declaration of what it wants to do and what it supports. This offer is transmitted through the signaling server to Peer B. Peer B examines the offer, selects compatible parameters from its own capabilities, and returns an "SDP Answer" — a confirmation and counter-declaration. This two-step exchange is called the "Offer/Answer" model and is derived from the JSEP (JavaScript Session Establishment Protocol) specification.
Once both SDPs are exchanged and applied via setLocalDescription() and setRemoteDescription(), the peers have a shared understanding of the session parameters. No actual media or data flows yet — SDP purely negotiates the terms of the connection.
ICE: Interactive Connectivity Establishment
ICE is the algorithm that discovers how two peers on the modern internet — separated by NATs, firewalls, and carrier-grade routing — can actually reach each other. The internet's wide deployment of Network Address Translation (NAT) means most devices do not have a publicly routable IP address. ICE solves this through a three-tier candidate discovery process.
First, the browser gathers "Host Candidates" — the device's own local IP addresses and ports. These work when both peers are on the same LAN. Second, if a STUN (Session Traversal Utilities for NAT) server is reachable, the browser queries it to discover its "Server-Reflexive Candidate" — the public IP:port that the NAT assigns to outbound connections. This works for most home and office networks with simple NAT configurations.
Third, when symmetric NATs or strict firewalls block the above, a TURN (Traversal Using Relays around NAT) server is used. TURN acts as a media relay — the only case where a server touches your data path. Even then, since the data is DTLS-encrypted before reaching TURN, the relay server cannot decrypt or read any content.
ICE then performs "connectivity checks" — sending STUN binding requests across all candidate pairs — to find the optimal direct path. The winning candidate pair becomes the active transport.
DTLS: Datagram Transport Layer Security
DTLS is the UDP-compatible variant of TLS, adapted for the unreliable, out-of-order packet delivery characteristics of datagram protocols. WebRTC mandates DTLS 1.2 or higher for all data channels — there is no non-encrypted mode.
During the DTLS handshake (which runs after ICE connectivity is established), each peer generates a self-signed X.509 certificate. The fingerprint of this certificate — a SHA-256 hash — was previously embedded in the SDP exchange. Both peers cross-verify these fingerprints during the DTLS handshake, creating a cryptographic binding between the identity established in SDP and the key material being negotiated.
The DTLS handshake uses the standard TLS 1.2 cipher suite negotiation to establish a shared Master Secret. From this, both sides derive symmetric encryption keys using a key derivation function (PRF). The resulting session keys are used for all subsequent AES-256-GCM encryption of channel data.
A critical security property: the DTLS handshake cannot be forged by a man-in-the-middle without controlling the signaling server AND compromising the fingerprint exchange. Since our signaling server only transmits SDP — not the private keys — interception at the signaling layer cannot enable decryption of channel traffic.
SRTP: Secure Real-time Transport Protocol
While RTCDataChannel uses DTLS directly for data, media streams (audio and video) are transported via SRTP — Secure Real-time Transport Protocol, standardized in RFC 3711. SRTP is a profile of RTP (Real-time Transport Protocol) that adds symmetric encryption and message authentication.
The encryption keys for SRTP are derived from the DTLS handshake using a mechanism called DTLS-SRTP (RFC 5764). The DTLS connection negotiates a shared keying material, which is then fed through a key derivation function to produce separate encryption and authentication keys for each SRTP stream direction (send/receive).
SRTP uses AES in Counter Mode (AES-CTR) for encryption and HMAC-SHA1 for authentication tags on each RTP packet. Each packet includes a Packet Index to prevent replay attacks — an attacker who captures and retransmits a valid encrypted packet will be rejected by the receiver's replay detection window.
ShareLink's data channels do not use SRTP directly (that is reserved for media streams), but understanding SRTP illustrates the layered encryption philosophy of WebRTC: every possible data path is independently secured, with different cryptographic primitives tuned to each transport's latency and reliability requirements.
RTCDataChannel: The Encrypted Data Pipe
RTCDataChannel is the WebRTC API that ShareLink uses to transmit messages and files. Underneath the browser API, data channels are implemented on top of SCTP (Stream Control Transmission Protocol) — a transport layer protocol that provides features of both TCP (reliable, ordered delivery) and UDP (unreliable, low-latency delivery), configurable per channel.
SCTP itself is tunneled inside the DTLS connection, so the encryption stack is: RTCDataChannel → SCTP → DTLS → UDP → IP Network. This means data channel messages are encrypted by DTLS before they hit the network.
Each RTCDataChannel is created with configuration options: "ordered" (whether messages arrive in sequence), "maxRetransmits" (how many times to retry lost packets), and "protocol" (an application-level string identifier). ShareLink creates ordered, reliable data channels for text messages and a separate unordered channel optimized for streaming file chunks with lower latency.
The channel emits events: onopen (DTLS handshake complete and channel ready), onmessage (data received from peer), onclose (peer closed or disconnected), and onerror (SCTP-level error). All message payloads — strings or ArrayBuffers — pass through the DTLS encryption layer transparently, requiring no application-level encryption code.
NAT Traversal & Hole Punching
NAT hole punching is the mechanism ICE uses to establish direct peer-to-peer connectivity through Network Address Translation devices. Understanding it reveals why ShareLink can connect two browser clients on different continents without a media relay server in most cases.
When both peers are behind NATs, neither has a stable public address. The hole-punching technique exploits a behavior of stateful NATs: when a device sends a UDP packet from internal address A:portA to external address B:portB, the NAT creates a mapping entry and will forward future packets from B:portB destined to the NAT's external IP to A:portA.
ICE coordinates simultaneous outbound UDP packets from both peers toward each other's Server-Reflexive candidates. If the timing is coordinated (via the signaling server), each outbound packet "punches a hole" in the sender's NAT — creating a mapping that allows the other peer's incoming packets to pass through. When both packets arrive and the NAT mappings are in place, a bidirectional direct channel is established.
This technique, called "simultaneous open," succeeds with most full-cone, restricted-cone, and port-restricted NAT types. Only symmetric NATs — which create different external mappings for each destination — require falling back to TURN relay. Modern ISPs predominantly use port-restricted NATs, making TURN relay necessary in roughly 15-20% of real-world WebRTC connections, according to industry telemetry.
04 — Lifecycle
Connection::Lifecycle
From the moment you generate a ShareLink token to the moment your session closes, the following sequence of cryptographic events occurs in strict order.
Phase 1
Token Generation & Signaling Room
When you open ShareLink, a cryptographically random room identifier is generated using the browser's window.crypto.getRandomValues() API — a CSPRNG (Cryptographically Secure Pseudo-Random Number Generator) seeded by the OS entropy pool. This 128-bit token is never transmitted to our backend in plaintext; it is used only as a WebSocket room identifier to route SDP and ICE messages between the two peers who share the link.
Phase 2
SDP Offer Creation
Peer A calls RTCPeerConnection.createOffer(), which triggers the browser to compile an SDP document listing its DTLS fingerprint, supported codecs, and ICE credentials. This SDP is set as the local description (setLocalDescription), which simultaneously begins ICE candidate gathering. The SDP offer is transmitted through the WebSocket signaling channel to Peer B.
Phase 3
ICE Candidate Exchange
As the browser discovers network candidates (host, server-reflexive, relay), each candidate is emitted via the onicecandidate event and transmitted through the signaling server to the remote peer. Both sides accumulate candidates and perform connectivity checks — STUN binding requests — against each candidate pair. The first successful check that yields a response promotes that pair to the 'selected candidate pair,' which becomes the active ICE transport.
Phase 4
DTLS Handshake
Over the established ICE transport (a direct UDP path or TURN relay), both peers initiate a DTLS 1.2 handshake. One peer acts as DTLS client, the other as server — determined by the 'a=setup' attribute in the SDP. They exchange certificates, verify fingerprints against the SDP-embedded hashes, perform an ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) key exchange, and derive symmetric session keys. Perfect Forward Secrecy is guaranteed because ECDHE generates a fresh keypair for every session.
Phase 5
Data Channel Open
With DTLS established, the RTCDataChannel handshake occurs over SCTP. The channel transitions to the 'open' state, triggering the onopen event in the application. At this point, ShareLink displays 'Secure Tunnel Active.' All subsequent messages are wrapped by SCTP, encrypted by DTLS-AES-256-GCM, and sent as UDP datagrams directly to the remote peer.
Phase 6
Session Termination & Key Destruction
When either peer closes the connection — by navigating away, closing the tab, or clicking Disconnect — the RTCPeerConnection.close() method is called. This tears down the DTLS session, sending a DTLS close_notify alert. The browser's internal keystore discards all session keys, master secrets, and DTLS certificates generated for this session. Since keys are never persisted to disk and all state lives in volatile RAM, there is no possibility of key recovery after session close.
05 — Threat Model
Attack::Vectors_Mitigated
A security system is only meaningful when analyzed against concrete threats. Here is ShareLink's explicit threat model and the cryptographic countermeasures in place.
Man-in-the-Middle (MitM) on Signaling
CriticalEven if an attacker intercepts SDP messages on the signaling server, they cannot forge the DTLS fingerprint without controlling the private key of the target peer. Fingerprint verification during the DTLS handshake cryptographically binds the identity to the key material. A MitM would require compromising both signaling AND one peer's private key simultaneously.
Passive Network Eavesdropping
NullifiedAll UDP datagrams on the wire are encrypted with AES-256-GCM derived from an ECDHE master secret. Even with complete capture of all network traffic, an observer gains only ciphertext. AES-256 with GCM provides IND-CCA2 security — the strongest semantic security model, provably resistant to chosen-ciphertext attacks.
Server-Side Data Breach
IrrelevantShareLink stores zero message content, zero file data, and zero session keys on any server. Our infrastructure holds only ephemeral WebSocket connection state for the duration of the SDP exchange — typically under 10 seconds. A complete breach of our backend exposes no user data because no user data has ever been written to disk.
Replay Attacks
BlockedDTLS incorporates sequence numbers and epoch counters in every record. A replay detector maintains a sliding window of accepted sequence numbers. Any retransmitted datagram with a previously-seen sequence number is silently discarded. Combined with session-unique keys, captured and replayed packets from any prior session are immediately rejected.
Key Compromise / Session Recovery
ImpossibleECDHE (using Curve25519 or P-256) generates ephemeral key pairs that are discarded after the handshake. The derived session keys exist only in volatile RAM. Even if a long-term private key were somehow obtained, past session keys cannot be reconstructed — this property is called Perfect Forward Secrecy (PFS) and is mandatory in ShareLink's DTLS configuration.
Identity Spoofing / Impersonation
MitigatedShareLink uses room tokens as peer identity channels. Only a peer who possesses the shared room URL can connect to that specific P2P session. Since room tokens are 128-bit CSPRNGs, brute-force enumeration is computationally infeasible (2¹²⁸ possible values). For high-security use cases, ShareLink displays the remote peer's DTLS certificate fingerprint for out-of-band verification.
06 — Reference
Glossary::Terms
Advanced Encryption Standard with 256-bit key in Galois/Counter Mode. Provides authenticated encryption — confidentiality + integrity in a single operation.
Cryptographically Secure Pseudo-Random Number Generator. Produces unpredictable output derived from OS entropy, used for key and token generation.
Datagram Transport Layer Security. TLS adapted for unreliable UDP transport. Provides handshake, key exchange, and record-layer encryption for WebRTC channels.
Elliptic Curve Diffie-Hellman Ephemeral. A key-agreement protocol that generates fresh session keys per handshake, enabling Perfect Forward Secrecy.
Interactive Connectivity Establishment. Algorithm for discovering the optimal direct network path between two peers, handling NAT traversal via STUN and TURN.
Network Address Translation. A technique that maps multiple private IP addresses to a single public IP, complicating direct peer-to-peer connectivity.
A property where compromise of long-term keys does not expose past session keys. Achieved by using ephemeral (one-time) key pairs discarded after each handshake.
Stream Control Transmission Protocol. A transport protocol combining TCP-like reliability with multi-streaming. Used as the carrier for RTCDataChannel messages.
Session Description Protocol. A text format describing multimedia session parameters: codecs, network addresses, DTLS fingerprints, and ICE credentials.
Secure Real-time Transport Protocol. Encrypts RTP media streams using AES-CTR with HMAC-SHA1 authentication. Keys are derived from the DTLS handshake.
Session Traversal Utilities for NAT. A lightweight protocol that reveals a device's public IP and port as seen by an external server, assisting ICE.
Traversal Using Relays around NAT. A relay protocol for cases where direct ICE paths fail. TURN relays encrypted DTLS traffic, cannot decrypt content.
Web Real-Time Communication. A W3C/IETF standard enabling browser-to-browser audio, video, and data channels with mandatory end-to-end encryption.
Security architecture assuming no implicit trust for any node — including internal servers. All data is authenticated and encrypted regardless of network position.
Total Node Privacy
ShareLink is built on the principle of Zero Trust Architecture. We do not know who you are, we do not know what you share, and we cannot track your session history.
The application logic is 100% client-side. DTLS keys are generated in the browser sandbox and never transmitted to any server. The cryptographic guarantees described in this document are enforced by the W3C WebRTC specification — not by our promises.
RE-ENTER_BRIDGE