Kelana Logo
Ghost Comm // E2EE Dead-Drop Room (Self-Destructing)

CHAT ROOM

STANDBY
Room Security Code
------
Dead-drop room is idle.
Pair two devices to initialize end-to-end encrypted chat.
DECAY:
Double-Layer E2EE: Messages and Media are encrypted with client-side AES-256-GCM prior to entering WebRTC SCTP DTLS tunnels.
RAM-Only Decaying Footprint: Zero database storage. Messages and blobs self-destruct from the DOM and RAM once timers expire.
Instant Panic Wipe: Triggering Panic immediately tears down WebRTC channels, wipes arrays, and scrubs local session keys.

1. Introduction to Ephemeral Zero-Knowledge Communication

Chat Room is a serverless, peer-to-peer (P2P) ephemeral communication terminal engineered for extreme operational security, confidential intelligence exchange, and zero-footprint digital dead-drops. Unlike conventional messaging platforms that route encrypted traffic through centralized database clusters, push notification relays, and persistent logging servers, Chat Room operates as a sovereign, direct-memory tunnel between two browser instances. By compounding client-side Web Crypto API primitives (AES-GCM 256-bit with PBKDF2 key stretching) over WebRTC DataChannel pipelines (SCTP over DTLS), every transmitted textual fragment and ephemeral media asset resides exclusively in volatile random-access memory (RAM), auto-zeroizing upon expiration or manual panic triggers.

2. Interface Nomenclature & Operational Tokens

Every interactive element and telemetry badge within the terminal fulfills a cryptographic or channel orchestration function:

  • Channel Status Beacon (roomStatusBadge): Dynamic system telemetry indicator reflecting active cryptographic state: STANDBY (Unpaired/Idle), CONNECTING... (STUN/ICE negotiation underway), E2EE ACTIVE (P2P SCTP DataChannel locked with derived AES-GCM session key), TIMED OUT (Connection dropped or unreachable), or ZEROIZED (Session wiped, socket destroyed, keys scrubbed).
  • Topology Selector (tabHostMode & tabJoinMode): Two-state role allocator assigning one browser node as the signaling host (generating the 6-digit session room code) and the opposing node as the dialing peer.
  • Room Security Code (myRoomCode & targetRoomInput): A high-entropy 6-digit numeric identifier serving a dual operational purpose: addressing the peer on public STUN infrastructure and acting as the shared secret seed for client-side PBKDF2 cryptographic key derivation.
  • Optical Pairing Gate (btnHostAction & btnJoinAction): Bidirectional QR transceiver subsystem allowing instant, out-of-band camera scanning of URI-encoded room tokens, bypassing manual entry errors and hardware keyloggers.
  • Unified Chat Viewport (chatViewport): Ephemeral message display arena rendering incoming and outgoing payloads wrapped with real-time CSS decay animations and automated DOM scrubbing triggers.
  • Ephemeral Media Transceiver (btnAttachMedia): Client-side file attachment hook converting local images, audio memos, videos, or documents (≤ 4 MB) into Base64 binary strings, encrypted via AES-GCM prior to transport.
  • Linear Decay Controller (timerPills): Synchronized burn interval selector (10s, 30s, 60s, or OFF). Controls the active countdown bar positioned on each message bubble, permanently redacting and purging payloads from browser DOM and garbage-collection pools upon depletion.
  • Emergency Incinerator (btnPanic): Hardware zeroization trigger that instantly signals the connected peer, aborts active WebRTC sockets, wipes the cryptographic key cache, clears input buffers, and returns the workspace to factory baseline.

3. Technical Operator Tutorial

To establish a secure peer-to-peer dead-drop room and transmit ephemeral payloads, execute the following operational sequence:

  1. Establish Topology: Node A remains on the default Host switch setting. The terminal automatically generates a unique 6-digit security code and initializes a local PeerJS broker listener. Node B toggles the top-right switch to Join.
  2. Pair Nodes Out-of-Band: Node A clicks QR Code to present the optical pairing modal. Node B clicks Scan QR, grants camera permissions, and scans Node A's screen. Alternatively, Node B can manually type the 6-digit code into the Target Room Input field.
  3. Derive Session Cipher Keys: Upon code submission, both browsers independently execute a 100,000-iteration PBKDF2 hash using SHA-256 against the shared 6-digit seed and static application salt, deriving an identical 256-bit AES-GCM symmetric key in local memory.
  4. Confirm Cryptotunnel Lock: The status badge will shift from gray to an active green E2EE ACTIVE indicator. Input text boxes and media buttons unlock automatically.
  5. Calibrate Decay Lifespan: Select your desired burn timer (10s, 30s, 60s, or OFF) in the bottom control bar. When a payload is transmitted, an animated red burn bar will shrink beneath the bubble, replacing content with [REDACTED & WIPED] as soon as the timer reaches zero.
  6. Execute Emergency Zeroization: If physical surveillance is compromised or the session concludes, tap PANIC / BURN ROOM or Disconnect. The application broadcasts an emergency teardown packet, severs the WebRTC transport stream, purges DOM references, and zeroes all cryptographic state variables.

4. Historical Evolution of Cryptographic Dead-Drops & P2P Channels

The concept of the "dead-drop" originates in espionage tradecraft, where operatives exchanged physical intelligence (microfilms, codebooks, cipher sheets) at concealed, unmonitored drop sites without ever meeting face-to-face. During the Cold War, magnetic containers hidden under bridge trestles or hollowed-out bricks allowed clandestine communication while preserving plausible deniability and breaking surveillance chains.

In the digital era, early internet communication mirrored physical centralized mailrooms: IRC networks, email servers, and instant messengers stored communications on central mainframes subject to subpoena, lawful interception, and breach. The late 1990s and early 2000s catalyzed peer-to-peer computing through protocols like Gnutella and BitTorrent, demonstrating that consumer nodes could negotiate direct data transfers without central brokers. The standardization of WebRTC (Web Real-Time Communication) by the World Wide Web Consortium (W3C) and Internet Engineering Task Force (IETF) in May 2011 brought peer-to-peer mesh capability natively into web browsers. Chat Room synthesizes this historic progression: converting traditional espionage dead-drops into client-side, browser-native mathematical tunnels that dissolve completely once conversations end.

5. Legal Frameworks, International Standards & Cryptographic Compliance

Chat Room conforms to established international security directives, cryptographic standards, and privacy regulations:

  • NIST SP 800-38D (Recommendation for Block Cipher Modes of Operation: GCM): The application implements Galois/Counter Mode (GCM) using a 256-bit key schedule, ensuring authenticated encryption with associated data (AEAD) to protect both message confidentiality and cryptographic integrity against ciphertext tampering.
  • NIST SP 800-132 (Recommendation for Password-Based Key Derivation): Session keys are stretched using Password-Based Key Derivation Function 2 (PBKDF2) configured with 100,000 rounds of HMAC-SHA-256 and constant salting, defending against dictionary lookups and precomputed rainbow table attacks.
  • IETF RFC 8827 & RFC 8831 (WebRTC Security & Data Channels): Transport-layer security complies with mandatory IETF WebRTC standards. All peer traffic travels across Stream Control Transmission Protocol (SCTP) encapsulated within Datagram Transport Layer Security (DTLS), ensuring double-layer encryption (payload-level AES-GCM wrapped inside transport-level DTLS).
  • ISO/IEC 18004 (Information Technology — QR Code Barcode Symbology): The integrated optical camera and generation engine adhere strictly to ISO/IEC 18004 specifications, utilizing Reed-Solomon error correction (Level M) to support rapid scanning even under imperfect display lighting or surface glare.
  • EU General Data Protection Regulation (GDPR - Article 17 & Article 25): Demonstrates complete alignment with Privacy by Design and the Right to Erasure (Right to be Forgotten). Because zero data is logged, transmitted to database servers, or serialized to persistent storage, user communication is inherently self-erasing and immune to remote server subpoenas.

6. Key Application Advantages

  • True Serverless Architecture: Zero database backends, message brokers, or centralized storage buckets. Servers only assist in initial STUN signaling; message contents never touch intermediate disks.
  • Double-Layered Defense-in-Depth: Payloads are encrypted client-side with AES-256-GCM before entering the WebRTC transport stream, ensuring that even if DTLS transport were compromised, payload ciphertext remains unreadable.
  • RAM-Only Ephemeral Memory: Message strings, media blobs, and encryption keys exist exclusively in volatile browser execution memory, automatically overwritten and garbage-collected when burn timers expire.
  • Universal Zero-Install Deployment: Operates natively across modern desktop and mobile browsers without requiring native app store downloads, user account creation, phone number verification, or software privileges.

7. Mathematical Formulations & Cryptographic Primitives

Chat Room implements standardized, mathematically validated cryptographic algorithms through the browser's native Web Crypto API:

A. PBKDF2 Key Stretching Formulation

Given the 6-digit user pairing code P and a fixed application salt S, the 256-bit symmetric session key DK is derived over c = 100,000 iterations using pseudorandom function PRF = HMAC-SHA256:

DK = PBKDF2(PRF, P, S, c, dkLen = 256)

U_1 = PRF(P, S || INT_32_BE(1))

U_i = PRF(P, U_{i-1}) [for i = 2, 3, ..., c]

F(P, S, c, 1) = U_1 ⊕ U_2 ⊕ ... ⊕ U_c

This computational cost raises the barrier against brute-force attacks on the 6-digit seed while remaining efficient on client devices.

B. AES-256-GCM Authenticated Encryption

Each message payload M is encrypted using Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) using a freshly sampled 96-bit (12-byte) initialization vector IV ← {0, 1}^96 generated from cryptographically secure pseudo-random numbers (crypto.getRandomValues):

C_i = P_i ⊕ CIPH_K(CTR_i) [for i = 1, 2, ..., m]

Where CTR_i represents the successive counter block. Authentication tag T is derived over the Galois field GF(2^128) using polynomial multiplication with hash key H = CIPH_K(0^128):

T = ( GHASH_H(A, C) ⊕ CIPH_K(J_0) )

The receiver verifies tag T before decrypting ciphertext C, guaranteeing that any in-transit packet alteration results in immediate rejection ([DECRYPTION FAILED]).

C. Linear Temporal Message Decay

The visual and programmatic lifespan of an ephemeral message is governed by linear temporal decay across duration t_decay ∈ {10, 30, 60} seconds. The remaining scale factor S(t) of the burn bar over elapsed time Δt is modeled by:

S(t) = max(0, 1 - (Δt / t_decay))

When Δt ≥ t_decay, the event loop nullifies the inner HTML string, replaces DOM nodes with redaction placeholders, and frees object references to trigger memory zeroization.

8. Frequently Asked Questions (FAQ)

Q: Can STUN or signaling server operators read my chat messages?

A: Absolutely not. Signaling servers only broker initial connection handshakes (ICE candidates and SDP session offers). Once connected, data flows directly peer-to-peer. Furthermore, payloads are encrypted with client-side AES-256-GCM before transmission; signaling servers and intermediate networks only encounter unreadable ciphertext.

Q: Are my messages or files written to the browser's hard drive or cache?

A: No. Chat Room does not write to localStorage, sessionStorage, IndexedDB, or browser service worker caches. All cryptographic keys, plaintexts, and media blobs exist solely in volatile JavaScript runtime memory and are cleared upon timer expiration or tab closure.

Q: What happens if one peer disconnects or closes their tab?

A: WebRTC detects socket closure immediately, triggering an automated cleanup sequence on the remaining peer's screen. The status badge shifts to ZEROIZED, input docks disable, and session state is wiped.

Q: What is the file transfer size limit?

A: Attachments are constrained to 4 MB per payload to ensure reliable, zero-fragmentation transfer across WebRTC DataChannel memory buffers without triggering browser memory warnings.

9. Closing Remarks & Open-Source Security Initiative

Chat Room is maintained as an open-access privacy instrument designed to uphold personal data sovereignty, protect confidential sources, and prove that modern web browsers can host secure, zero-footprint communications without centralized intermediaries. If this peer-to-peer terminal assists your investigative workflows, safeguards your operational data, or reinforces your digital privacy, consider supporting the open-source initiative: share the platform with privacy-conscious peers, star our repository, submit audited pull requests, or support our development team. Communicate freely, protect your privacy, and let mathematics secure your communications!

Host Room QR

Scan with peer camera to join dead-drop:

Scan Host QR

Align Host screen inside target window:

Burn Room & Terminate?

This action terminates the WebRTC pipeline, zeroes local encryption keys, and destroys all messages.

All Tools Directory 118+ Free Apps