lortnoc_tahc
Encrypted messaging on unencrypted platforms. You type a real message in Telegram. Before it
sends, an overlay swaps it for innocuous cover text — and that cover text is all Telegram ever
stores. Your correspondent, running the same extension with the same derived key, sees it decode
back inline. Everybody else sees small talk.
Then there's the second half: a messenger you can walk away with. Your handle is an ENS name you
own, your messages live in a vault you control, and the membership that pays for it can't be
linked to the handle it bought.
Status: closed alpha. The hosted codec is paused.
Too many people arrived at once for a build still being fixed, so the download is closed and
the hosted service returns a 503 rather than failing in your hands. The code is unaffected —
run your own codec and the whole thing works end to end, with no part of
it touching us. Early access: lortnoctahc.com.
Positioning: this is a privacy / stealth-comms product. The language model that generates
cover text is invisible plumbing — never the pitch.
What's actually live
Everything below is deployed and was exercised with real transactions, not mocked.
| Layer | Where | Address / id |
|---|
| Handles | Ethereum Sepolia | lortnoctahc.eth · registry 0x2D95c86b…62a5 · registrar 0x49bba8ce…f24ae |
| Membership | 0G mainnet (16661) | LortnocMembership 0xe9031484…e3d6 — real money, $1 |
| Storage | Sui testnet + Walrus | package 0xb214da01…4faf |
| Codec | fly.io | lortnoc-codec.fly.dev — paused during the alpha |
| Sealed inference | fly.io + 0G Compute | lortnoc-zerog.fly.dev |
| Relayer + gate | kimi-vps behind a Cloudflare tunnel (deploy/kimi-vps/) | relayer.lortnoctahc.com, gate.lortnoctahc.com |
Four handles have been issued. Three of them are owned by wallets that have never sent a
transaction on any chain — because the relayer paid, not them. More on why that matters below.
The two surfaces
1. The extension — hiding messages inside Telegram
A Chrome MV3 extension that runs a content script on web.telegram.org. No bot, no MTProto, no
stored session credential: you are a human typing in your own Telegram, and the extension only
reads and writes the DOM. That removes the ToS and ban risk entirely.
Outbound. It intercepts the send path, encrypts your text with AES-SIV under a key only you and
your correspondent can derive, posts the ciphertext to the codec, and replaces your compose box
with the cover text that comes back. Plaintext never leaves the page.
Inbound. A MutationObserver watches new message bubbles, sends each to the codec to decode,
and tries to decrypt. The AES-SIV auth tag is the detector — a valid tag means this was one of
ours and it renders decoded inline; an invalid tag means it's ordinary chatter and is left alone.
There's no marker to spot, because there is nothing to mark.
The handshake — how two people get a key without ever sending one
This is the part worth understanding, because it is what makes the whole thing work with no
passphrase, no server, no wallet and no gas.
You click Connect. Your extension generates a fresh X25519 keypair, wraps the public half in
a 41-byte frame, runs it through the same codec a message goes through, and sends the result as an
ordinary Telegram message. Your correspondent's extension recognises it, replies the same way, and
both sides now hold the same conversation key.
A clicks Connect → OFFER frame → cover text → sent as a normal message
B taps Accept → ACK frame → cover text → sent as a normal message
→ both now hold K_conv
Two messages. That is the whole exchange. To Telegram, and to anyone reading over your
shoulder, it is two more lines of small talk.
The key is never transmitted — it is derived. Only public keys cross the chat. Both ends
compute:
K_conv = HKDF( ECDH(my_private, their_public), info = sorted(both public keys) )
ECDH is symmetric, so ECDH(a, B) == ECDH(b, A): the same key on both sides, and nothing secret
ever travelled. Sorting the two public keys into the HKDF info means it does not matter who offered
and who accepted — both arrive at the same value.
The frame. MAGIC("LTNC") · type · x25519_pubkey(32) · crc32 = 41 bytes. It is encoded but
not encrypted — it carries a public key, and there is no shared key yet; that is the
chicken-and-egg the handshake exists to break. The magic prefix and CRC are how a receiver tells a
handshake frame apart from an AES-SIV message and from genuine chatter. Frames skip the 0G
best-of-N pass (fast: true), so they take ~2–3s instead of ~10s — cover polish is wasted on a
sentence nobody reads.
If you both click Connect at once (the "glare" case) it still works: each side establishes from
the other's offer. It costs two extra cover messages, because both also send a now-redundant ACK.
There is exactly one way a chat is keyed. An earlier version also supported a shared passphrase,
and that was removed — not for simplicity, but because two keying paths meant the two ends could
silently pick different ones, and each would then read only its own messages while the peer's
stayed cover text. No key now means no key: a visible state rather than a silent wrong answer. If
several messages decode but fail the authentication tag, the extension says "key mismatch —
reconnect" instead of leaving garble on screen.
What this does and does not protect against
| |
|---|
| Telegram sees | two innocuous sentences |
| A person reading your screen sees | small talk |
| Another extension user watching the chat | can tell a handshake happened and read both public keys — harmless, but not hidden |
| An active man-in-the-middle on the first exchange | is not stopped |
This is the beginning of the README. Read the rest at the original. Read the full README ↗
