zebra report

volume modem chatroom  ·  e2e encrypted  ·  webrtc carrier  ·  unturf

identity

passphrase mode = group; pubkey mode = 1-to-1 ECDH.

room (passphrase mode)

no room key

PBKDF2-SHA256 (600k iter) of passphrase + literal salt "zebra-report-v1" → 256-bit AES-GCM group key.

room (pubkey mode)

your public key (click to copy):

generating…

carrier

tx gain:
0%
rx energy:
—

a 440/441 Hz stereo carrier is generated locally. each frame swings the output gain MARK (0.80) ↔ SPACE (0.20) per bit. the modulated audio is the outbound WebRTC track for every connected peer. mic stays off.

peer connection (WebRTC)

disconnected — start audio first, then pick a role below

role A · start a new connection

step 1: click, then copy the offer to your peer (any out-of-band channel):

step 4: paste your peer's answer here:

role B · join an existing connection

step 2: paste your peer's offer here:

step 3: copy your answer to peer:

each browser modulates its own outbound audio track (no mic). incoming peer audio is decoded in-page via AudioWorklet, no native daemon required. Wireshark sees only encrypted SRTP — chat content lives in audio amplitude transitions inside that stream.

handshake

not yet measured
idle
negotiated baud: —

OFFER and READY frames travel at fixed ZEBRA_BAUD_HANDSHAKE = 50. each peer measures its own scheduling jitter, broadcasts a max baud, room settles on min(all).

chat

peers in room:

none yet

log:

about

The protocol's data path is audio amplitude inside an encrypted WebRTC SRTP stream. The signaling channel (SDP / ICE) is exchanged once at connection setup — it contains no chat content. Every subsequent bit travels as a MARK/SPACE swing in the carrier audio.

threat model · what this protects against · what it doesn't

Protects against: a network-level observer (Wireshark, IDS, DPI) reading chat content. The bits are inside the SRTP audio payload, which is end-to-end encrypted by WebRTC, then additionally encrypted at the app layer (AES-GCM via passphrase or ECDH).

Does not protect against: (1) other same-UID processes that can poll PulseAudio or record the monitor source on either peer's machine — that is the attack surface this whole project documents; (2) an endpoint compromise of either peer's machine; (3) traffic-analysis correlation against the encrypted SRTP flow.

Mitigation for defenders: require a capability for same-UID PulseAudio reads. The current Linux audio IPC trust model grants every same-UID process unrestricted access — the defect whitepaper documents this.