telegraph-stego

Posted on Feb 16

Hide a tree in a forest: a messenger that pretends to be a temperature sensor

#steganography #mqtt #iot #security

Imagine you need to send a short message so that nobody — not your ISP, not the network administrator, not a casual observer — even suspects you're communicating with anyone at all.

Not encrypt. Hide the very fact of communication.

Encryption is a safe in the middle of a room. Everyone sees it. Everyone knows something valuable is inside. The only question is whether they can open it. Steganography is when there's no safe. There's a room, a table, a chair, and a temperature sensor on the wall. Quietly transmitting "22.4°C, humidity 61%, pressure 1013 hPa." And inside those numbers — your message.

This is that messenger. One HTML file, zero servers, zero accounts. It's called Telegraph.

The principle: a bug is a feature

In Telegraph, this isn't a joke — it's an architectural principle.

No server? Not a bug — nothing to block, nothing to seize, nothing to hand over by court order.

No message history? Not a bug — nothing to extract retroactively. Close the tab — the data never existed, doesn't exist, and never will.

Both users must be online simultaneously? Not a bug — no message sits anywhere waiting for a recipient. Like a radio: you transmit, and if nobody's on the other end — the signal goes into the void. No notifications, no popups. The chat stays open as long as there's a connection. On disconnect — reconnect at the top of each hour, wait three minutes. Radio discipline.

Only two users per channel? Not a bug — it's the principle of least knowledge. Each "wire" connects exactly two points. Want a network? Build it from wires:

Alpha ←phrase1→ Bravo ←phrase2→ Charlie

Bravo is a relay. Opens two tabs. Reads from one, writes to the other. Compromising one channel doesn't reveal the next. Classic mesh structure where each node knows only its neighbors.

Every "limitation" of the system is a deliberate decision that removes a point of vulnerability.

How to hide a tree in a forest

Steganography (from Greek στεγανός "covered" + γράφω "write") is an ancient discipline. Herodotus wrote about slaves whose heads were shaved, tattooed with a message, then left to grow hair back. In World War II, microdots were used — photographs the size of a printed period, glued into ordinary letters.

Digital steganography is the same thing, but in network traffic. And here the key question arises: what is the "forest" in which we hide the tree?

The answer: the Internet of Things.

According to IoT Analytics, by 2025 there are over 17 billion connected IoT devices worldwide. Temperature, humidity, and pressure sensors. Smart meters. Industrial controllers. Every second, millions of devices send millions of JSON packets via the MQTT protocol through thousands of brokers around the world.

Here's a real packet from a real sensor:

{"d":"sens_a3f7","t":22.41,"h":61.07,"p":1013.25,"v":3.84,"rssi":-67,"seq":142,"ts":1739620800}

And here's a packet from Telegraph:

{"d":"nd_e0b7","t_c":22.53,"hum":60.88,"p":1013.31,"pwr":3.83,"rf":-68,"seq":143,"ts":1739620820,"sid":"f3a1b2","payload":"7b2263...7d"}

See the difference? It's there. The payload field looks like a hex dump of sensor service data, a diagnostic buffer, a firmware dump — anything. Inside it — your message.

Disguise: not just data, but behavior

A "correct" JSON alone isn't enough. If all Telegraph packets look the same — an analyst will build a signature and start filtering.

Telegraph addresses this at several levels:

Unique profile for each pair. From the code phrase (agreed upon by both users in person beforehand), a unique "sensor profile" is generated: field names, topic template, value ranges, prefixes. The Alpha-Bravo pair communicates through a "temperature sensor" with fields t_c, hum, p. The Charlie-Delta pair — through a "power grid sensor" with fields bat_v, rssi, bp. One signature doesn't catch the other.

Realistic value drift. A real sensor doesn't send 22.00°C every time. Temperature fluctuates: 22.41, 22.38, 22.53, 22.47. Telegraph imitates this: base values slowly drift, noise is layered on top. On a graph, it looks like a plausible sensor curve.

Topic rotation (FHSS). Every 5 minutes, Telegraph switches to a new MQTT topic computed from the code phrase and the current time. An unwanted observer who found one topic will discover in 5 minutes that the "sensor" has vanished. And another one has "appeared" — on a different topic, with a different identifier. This technique is an adaptation of FHSS (Frequency Hopping Spread Spectrum), patented in 1942 by Hedy Lamarr and George Antheil to protect torpedoes from radio signal jamming. Only instead of radio frequencies — MQTT topics, and instead of a random sequence — a deterministic chain of SHA-256 hashes.

Constant stream. Between messages, Telegraph sends a heartbeat — an IoT packet with no payload — every 20 seconds. An observer sees a steady stream of telemetry. No "silence → burst → silence" pattern that gives away a chat.

Theoretical background

The idea of covert channels in network protocols is not new. The academic community has been actively researching this topic.

In 2019, Velinov, Mileva, Wendzel, and Mazurczyk published the first systematic study of covert channels in the MQTT protocol — "Covert Channels in the MQTT-based Internet of Things" (IEEE Access, 2019). In 2021, the same group expanded their work into a comprehensive analysis of MQTT 5.0 — "Comprehensive Analysis of MQTT 5.0 Susceptibility to Network Covert Channels" (Computers & Security, Vol. 104, 2021, DOI: 10.1016/j.cose.2021.102207). The authors demonstrated that the MQTT protocol is susceptible to numerous covert data transmission techniques — through header fields, QoS flags, retain bits, and topic structure.

However, all of these works are theoretical analysis with proof-of-concept Python scripts for researchers. Telegraph is possibly one of the first implementations that combines steganography in IoT telemetry with a user interface and works as a tool, not a lab experiment.

Open source and Kerckhoffs's principle

Telegraph's code is fully open. This is a deliberate decision, and here's why.

In 1883, Dutch cryptographer Auguste Kerckhoffs formulated the principle: a system must remain secure even if everything except the key becomes known to the adversary. Claude Shannon rephrased it more simply: "the enemy knows the system."

Telegraph follows this principle. The adversary can read all the code, understand the packet format, know the topic generation algorithm. It won't help, because:

Without knowing the code phrase, it's impossible to compute the topic (SHA-256, 2²⁵⁶ possibilities)
Without knowing the topic, it's impossible to find packets among millions of others on the broker
FHSS rotation every 5 minutes complicates even targeted surveillance
Zero storage makes retrospective analysis pointless

The only secret is the code phrase. Everything else is open.

What Telegraph does NOT do

Honesty matters more than marketing. Here are the limitations you need to know:

This is not Signal or WhatsApp. There's no end-to-end encryption at the application level. Transport is protected by TLS (WSS), but the MQTT broker operator can theoretically see packet contents. They don't know that payload is a message, but if they deliberately analyze your specific traffic knowing the format (and the code is open) — decoding is possible.

Timing correlation. Two "sensors" appear and disappear synchronously. For mass surveillance, this is invisible. For targeted surveillance — it could be a clue.

Endpoint compromise. A keylogger on the computer, a camera behind your back, a compromised browser — steganography is powerless against this.

Wildcard monitoring. Subscribing to # on an MQTT broker with a parser — and all packets are visible. Defense: your own broker.

Telegraph is a tool for ordinary people who need a simple private channel without registration and without traces. Not for state secrets. If your threat model includes an adversary with unlimited resources — you need something else.

Legal status

Encryption regulations. Telegraph does not implement encryption at the application level. TLS is provided at the WebSocket layer (browser + broker) and is a standard channel protection mechanism built into the browser. No licensing required.

Data distribution. Telegraph is not an information distribution service — there is no server component, no control over data transmission. The transmission function is performed by the public MQTT broker.

Data retention. Data storage obligations fall on the telecom operator (the ISP that sees TLS traffic) and on the information distributor (which Telegraph is not). The application stores nothing.

Steganography as such is not subject to legal regulation in most jurisdictions. Masking data format is not prohibited.

Use cases

Who is this for? A few examples:

Journalists and sources. A source doesn't want to install apps and create accounts. One HTML file on a USB drive, one phrase — and the communication channel is ready.

Travelers. In some countries, messengers are blocked. Telegraph uses the standard MQTT protocol; traffic looks like IoT telemetry.

Activists and NGOs. Coordination without digital traces. Close the tab — the conversation never existed.

Privacy enthusiasts. Simply because you can.

IT professionals. As a proof of concept and educational example of steganography, covert channels, and single-page applications.

Can it be misused? Certainly — like any everyday object: a knife can cut bread, or not bread. A postage stamp can be put on a greeting card, or on an envelope with anything inside. We don't control the content of messages, don't store them, have no access to them, and cannot bear responsibility for them — neither practically nor theoretically.

Technical summary

For those interested in the details (others can skip):

Single index.html file (~400KB with embedded mqtt.js)
Zero external service dependencies for UI operation
Protocol: MQTT v3.1.1 over WebSocket Secure
Topic generation: SHA-256(seed + "/" + timeSlot)
Profile generation: SHA-256(seed + "/profile")
FHSS: topic rotation every 5 minutes
Heartbeat: 20 seconds, with peer presence indication
Third participant detection (channel compromise warning)
Feed: last 50 messages, oldest deleted automatically
Connection: auto mode (single broker) or selection by color
Links in text are not clickable (leak protection)
Auto-detection of interface language (RU/EN)
24 built-in tests (Ctrl+T)
Mobile-responsive

DEV Community