Technical overview

CTP

CTP is the Capsule Transport Protocol — a communication system in which a message is not data to be decrypted but a small executable machine that carries its own decryption logic, opens only for the session it was sealed to, renders its content once, erases itself, and leaves nothing behind to store, subpoena, or decrypt later.

Introduction

Every secure communication system in use today shares one structural property: at some point, on some machine, the data must be decrypted. TLS encrypts data in transit and decrypts it at both ends. End-to-end messengers encrypt the message and then hold the plaintext in application memory, in caches, in notification payloads and in backups. Hardware enclaves confine execution but require specific hardware. None of these eliminate the moment of opening — they shorten it.

They also leave something behind. Ciphertext is durable. It sits in transit logs, on relay disks and in the capture files of anyone who was listening, available for offline analysis indefinitely — which is what makes harvest now, decrypt later a coherent strategy rather than a slogan.

CTP takes a different position: the window should not be minimised, it should be structurally unavailable — and there should be nothing left to work on afterwards. A CTP message is an executable binary. It arrives as noise, runs inside a sandbox that has no access to the host, renders its content once, overwrites its own memory and ceases to exist. The receiver holds no decryptor for your message; the message carries its own.

Two properties are load-bearing, and both are measurable rather than aspirational. Non-algorithmic output: the capsule body carries no version byte, no type field and no identity — nothing an observer can key on, and nothing to identify as ciphertext in the first place. The frame that routes it carries a token that means nothing outside the session it belongs to. Temporal finitude: every capsule carries its own expiry and every buffer is overwritten within the same execution tick, so the ciphertext an adversary would need does not survive long enough to be attacked.

This document is in two parts. Part one describes the system in operational terms — what it does and what changes once it is in place. Part two documents the internal mechanisms across seven reference figures: the capsule assembly, the encryption stack, the execution lifecycle, the capsule chain, blind routing, hybrid post-quantum key establishment, and zero-knowledge validation of the wire itself.

PART 1

What CTP does

In operational terms, for readers concerned with what the system changes rather than how it is built.

The problem

Conventional encryption produces ciphertext: structured, algorithmic data that persists. It has a header. It has a length that correlates with what it carries. It sits on a relay, in a backup, or in an intercept archive, and it waits — because the one resource an attacker reliably has is time, and the one thing the maths cannot take away is the copy they already hold.

The second failure is quieter. Even when the content holds, the pattern leaks: who spoke to whom, at what time, how often, and how much. For a large class of adversaries that metadata is the intelligence product, and no amount of payload encryption touches it.

How it works

CTP replaces the unit of transmission. Instead of sending information that must be protected, it sends a small self-contained machine that carries the information inside it, opens for exactly one session, and then destroys itself.

CTP — CAPSULE TRANSPORT PROTOCOL SHEET A WHAT CTP DOES 10 20 30 40 A MESSAGE IS WRITTEN ONE CAPSULE 12 34 THE MESSAGE, ENCRYPTED THE PROGRAM THAT OPENS IT A TAG PROVING IT IS UNALTERED THE RULE FOR WHEN IT DIES A SELF-CONTAINED EXECUTABLE — NOT A FILE 7A 03 C1 9E 44 F0 2B D5 68 1C B7 09 EA 3F ON THE WIRE — PURE NOISE NO HEADER · NO TYPE · NO NAMES RELAY ROUTES BY A ONE-TIME TOKEN STORES NOTHING · LEARNS NOTHING ON THE RECIPIENT'S DEVICE IT RUNS IT SHOWS IT ERASES NOTHING REMAINS 50 60 70 80 EXECUTES INSIDE A SEALED BOX WITH NO ACCESS TO THE DISK, THE NETWORK OR ANY PROCESS. RENDERS ITS CONTENT ONCE. THE ONLY MOMENT ANYTHING EXISTS IN THE CLEAR. OVERWRITES EVERY BUFFER: 0xFF, 0x00, RANDOM, 0x00 — THEN THE CAPSULE IS GONE. NO FILE. NO CACHE. NO BACKUP. NOTHING TO SEIZE, SUBPOENA OR DECRYPT LATER. REF. COMPONENT 10MESSAGE, WRITTEN BY A PERSON 20CAPSULE — EXECUTABLE BINARY 30WIRE FORMAT — UNSTRUCTURED NOISE 40RELAY — BLIND TOKEN ROUTING 50SANDBOXED EXECUTION 60SINGLE RENDER WINDOW 70MULTI-PASS MEMORY WIPE 80TERMINAL STATE — NO RESIDUE WHAT AN OBSERVER SEES THAT A DEVICE TRANSMITTED SOMETHING. NOT WHO IT WAS TALKING TO. NOT WHAT KIND OF THING WAS SENT. NOT WHETHER TWO BLOBS BELONG TOGETHER. FIG. A
FIG. A — A message is packed into a capsule (20) that carries its own decryption logic. It crosses the network as unstructured noise (30) through a relay that routes by a one-time token (40), then executes on the recipient's device (50), renders once (60), and overwrites itself (70).

What that looks like in practice

A capsule is not a file and cannot be saved as one. It is a compiled program that contains four things: the payload, the logic to unlock it, a tag proving nothing in it was altered in transit, and a rule about when it must die. It executes, calls back once with the rendered content, and wipes every buffer it touched. What the user sees is an ordinary message thread. What exists afterwards is nothing.

Everything larger than a few kilobytes — a voice note, a video clip, a long message — is not one large capsule but a chain of small ones. Each link is sealed, authenticated and executable on its own, and the fact that the links belong together is itself encrypted — so a captured chunk announces neither what it is part of nor how much else there is.

CTP — CAPSULE TRANSPORT PROTOCOL SHEET B THE TWO CONDITIONS DECRYPTION NEEDS SOMETHING ALGORITHMIC TO ATTACK, AND TIME IN WHICH TO ATTACK IT ALGORITHMICBINARY NON-ALGORITHMICBINARY INFINITE TIME CIPHERTEXT PERSISTS FINITE TIME CIPHERTEXT SELF-DESTRUCTS CONVENTIONAL ENCRYPTION AES · RSA · TLS · E2E THE ATTACKER HAS TIME — — CTP NOTHING TO TARGET NOTHING TO KEEP THE WINDOW OF VULNERABILITY, DRAWN TO SCALE CONVENTIONAL ENCRYPTION A CAPTURED CIPHERTEXT KEEPS ITS VALUE INDEFINITELY — ON RELAYS, IN BACKUPS, IN SOMEONE ELSE'S CAPTURE FILE. CTP THE PLAINTEXT EXISTS FOR ONE RENDER AND IS THEN OVERWRITTEN. WHAT WAS RECORDED STAYS NOISE, AND STAYS WORTHLESS. REMOVE THE STRUCTURE NO VERSION BYTE, NO TYPE FIELD, NO LENGTH MARKER, NO IDENTITY. AN OBSERVER CANNOT ESTABLISH THAT THE BYTES ARE CIPHERTEXT, LET ALONE WHOSE. REMOVE THE TIME THE CAPSULE EXPIRES AND ERASES ITSELF IN MILLISECONDS. A BETTER COMPUTER, ARRIVING IN TEN YEARS, ARRIVES AT AN ARCHIVE WITH NOTHING IN IT TO SOLVE. REMOVE EITHER CONDITION AND DECRYPTION IS NOT HARD — IT IS UNDEFINED. FIG. B
FIG. B — The two conditions decryption requires: something algorithmic to attack, and time in which to attack it. Conventional encryption concedes both. CTP removes both.

What changes once it is in place

01 — RESIDUE

There is no copy to come back for

No message store, no local database, no history to export. Content exists in memory for the duration of one render and is overwritten immediately afterwards. A device seized a day later yields nothing, because there is nothing on it to yield.

02 — INFRASTRUCTURE

The relay is not trusted, because it is not told anything

The relay sees an opaque blob and a routing token derived per session. It never sees a public key, a name, a message type, or whether two blobs belong to the same conversation. Because the salt that produces those tokens is fresh per session, a relay that logged everything could not join this conversation to the last one.

03 — KEY MATERIAL

Nothing is typed, nothing is shared, nothing is reused

Every key descends from a single established root under its own label — capsule, authentication, envelope, media. No password is chosen by a person and no key serves two purposes, so what a compromise would cost is a bounded and stated quantity rather than an open question.

04 — TIME

Harvest now, decrypt later stops being a strategy

Recording the wire gives an adversary bytes that are statistically indistinguishable from noise and a plaintext that no longer exists anywhere. Key establishment is additionally hybridised with a post-quantum primitive, so the recording does not become valuable when the hardware improves.

What CTP is not

  • Not protection against a compromised endpoint. If the device is owned — keylogger, screen capture, hostile OS — the content is readable during the render window, and no protocol changes that.
  • Not resistant to traffic analysis of the coarsest kind. Content, identity and structure are hidden; the fact that a device is transmitting at a given moment is not.
  • Not a defence against coercion. A user compelled to unlock a session can be compelled to reveal what a capsule rendered.
  • Not available. A relay that refuses to forward stops the conversation; CTP is a confidentiality protocol, not an availability one.
  • Not a peer-reviewed cryptographic primitive. The standard components are standard; the fractal transform layer is proprietary and unreviewed, and Part 2 states plainly what that does and does not buy.

It is a transport protocol with an unusually strict definition of delivery: the content is rendered exactly once, on exactly one device, and then it is gone.

PART 2

Technical reference

Seven figures documenting the mechanisms, with commentary on the property each is designed to hold — and, where it matters, on the property it is not designed to hold.

CTP — CAPSULE TRANSPORT PROTOCOL SHEET 1 OF 7 CAPSULE ASSEMBLY — EXPLODED VIEW ALONG THE UNWRAPPING AXIS FIELD WIDTHS NOT TO SCALE A — ON THE WIRE ENVELOPE IV 12 B · RANDOM 100 AES-256-GCM CIPHERTEXT — THE ENTIRE CAPSULE N BYTES 102 Everything the network carries inside the transport frame of FIG. 5. The body holds no version byte, no type field and no identity. What the frame around it does show — a routing token and a length — is drawn on Sheet 5 rather than hidden here. B — AFTER ENVELOPE DECRYPTION: AN EXECUTABLE BINARY POLYMORPHIC NONCE 32 B 104 RUNTIME HASH 32 B · SHA-256 106 LEN 4 B WASM CAPSULE RUNTIME N BYTES 108 CAPSULE DATA M BYTES 110 Not ciphertext but a program. The runtime hash is verified in constant time; a capsule naming any other program is refused. The first capsule to a peer carries the program — 162,162 bytes natively. After that the hash alone names it, at a cost of 68 bytes. C — INSIDE THE EXECUTABLE: CAPSULE DATA VER 1 B TYPE 1 B SEQ 8 B TIMESTAMP 8 B TTL 4 B PAYLOAD LEN 4 B 112 DX/C ENCRYPTED PAYLOAD N BYTES 114 HMAC-SHA-256 32 B 116 The 26-byte header never appears on the wire. It lives only in decrypted memory, authenticated with the payload and zeroed with it. D — INSIDE THE PAYLOAD: THE DX/C ENVELOPE SALT 32 B 118 IV 12 B LEN 2 B ECDH PUBLIC KEY 97 B · PKCS8 LEN 2 B EPHEMERAL PRIVATE KEY ~185 B · PKCS8 ECC IV 12 B ECC CIPHERTEXT N BYTES Keys are carried in binary PKCS8 rather than JWK — JSON would put structured text inside the ciphertext and cost entropy. Fixed overhead ≈ 342 bytes per capsule. E — INSIDE THE DX/C CIPHERTEXT: THE STREAM HEADER STREAM ID 16 B · RANDOM 120 CHUNK INDEX 4 B TOTAL CHUNKS 4 B TYPE 1 B CHUNK DATA ≤ 4071 B 122 The 25-byte stream header sits inside the encryption rather than in the capsule header. So the relay cannot tell a chunk from a whole message, or two chunks of one message from two unrelated capsules. FIG. 1
FIG. 1 — Capsule assembly: exploded view along the unwrapping axis, from the wire format (100–102) through the executable binary (104–110), the capsule data (112–116), the DX/C envelope (118) and the stream header (120–122).

What this figure establishes

  • The unwrapping order is the drawing order. Each strip is one field of the strip above it, opened. Nothing in strip B can be reached without the envelope key; nothing in C without the authentication tag holding; nothing in D without the capsule key. The picture is the access-control argument.
  • What the receiver gets is a program, not a message. After the envelope comes off there is no ciphertext to hand a decryptor — there is a compiled module 108 and the data it consumes 110. The receiver holds no decryptor for your message; the message carries its own.
  • The runtime hash is checked twice. 106 must match a digest of the carried bytes, and must be the runtime this build trusts. A capsule naming any other program is refused outright rather than sandboxed and hoped for. The program is a constant, published by hash — not obfuscated, not polymorphic, and it should not be sold as either.
  • The 26-byte header never travels in the clear. 112 exists only inside the envelope and only in memory. It is authenticated together with the payload it describes, so a header cannot be edited to point at a different payload.
CTP — CAPSULE TRANSPORT PROTOCOL SHEET 2 OF 7 THE ENCRYPTION STACK — WHAT EACH LAYER CARRIES, AND WHAT IT DOES NOT KEY BARRIER INTEGRITY STRUCTURAL — NOT A KEY BARRIER LAYER 5 — ENVELOPE 210 LAYER 4 — HMAC-SHA-256 208 LAYER 3 — ECC PACKING 206 LAYER 2 — AES-256-GCM 204 LAYER 1 — FRACTAL DIFFUSION 202 PLAINTEXT 200 TWO LAYERS CARRY CONFIDENTIALITY. THE OTHERS CARRY DIFFUSION, SHAPE AND INTEGRITY — WHICH IS WHAT THEY ARE THERE FOR. THE DESIGN DOES NOT ASK THEM TO BE MORE. LAYER 1 — FRACTAL DIFFUSION 202 DOES · XORS THE PAYLOAD WITH A MANDELBROT ESCAPE-TIME MASK SO THAT NO PLAINTEXT STRUCTURE REACHES THE CIPHER. DOES NOT · TAKE A KEY. THE MASK IS A FUNCTION OF BYTE POSITION ALONE, IDENTICAL FOR EVERY MESSAGE — DIFFUSION, NOT SECRECY. LAYER 2 — AES-256-GCM 204 DOES · CARRY CONFIDENTIALITY. KEY DERIVED BY PBKDF2-SHA-256 AT 600,000 ITERATIONS FROM THE SESSION ROOT; 32-BYTE SALT, 12-BYTE IV. DOES NOT · DEPEND ON ANY LAYER INSIDE IT. IF LAYER 1 WERE REMOVED ENTIRELY, THIS LAYER WOULD BE UNCHANGED. LAYER 3 — ECC PACKING 206 DOES · RE-ENCRYPT UNDER A KEY FROM AN EPHEMERAL P-384 AGREEMENT AND A FRESH IV, SO THE BYTE SHAPE DIFFERS PER CAPSULE. DOES NOT · PROVIDE FORWARD SECRECY: THE EPHEMERAL PRIVATE KEY IS PACKED ALONGSIDE IT SO EITHER SIDE CAN OPEN THE SAME BYTES. LAYER 4 — HMAC-SHA-256 208 DOES · AUTHENTICATE THE 26-BYTE HEADER TOGETHER WITH THE PAYLOAD, VERIFIED IN CONSTANT TIME BEFORE ANY FIELD IS PARSED. DOES NOT · COVER THE NONCE, THE CARRIED RUNTIME, OR THE ENVELOPE — THOSE ARE CHECKED BY THEIR OWN MECHANISMS. LAYER 5 — ENVELOPE 210 DOES · SEAL THE ENTIRE EXECUTABLE UNDER AES-256-GCM WITH A KEY DERIVED FROM THE ROOT. THIS IS THE LAYER THAT MAKES THE BODY NOISE. DOES NOT · HIDE THE FRAME AROUND IT. THE ROUTING TOKEN AND THE LENGTH ARE VISIBLE TO THE RELAY BY DESIGN — SEE FIG. 5. WHERE THE KEYS COME FROM NO KEY IN THIS STACK IS TYPED BY A PERSON OR SHARED BETWEEN PURPOSES. EACH IS AN HKDF-EXPAND OF THE ONE HYBRID ROOT ESTABLISHED IN FIG. 6, UNDER ITS OWN INFO STRING — CAPSULE PASSWORD, HMAC, ENVELOPE, MEDIA. ONE MEASURED COST PBKDF2 AT 600,000 ITERATIONS IS ROUGHLY 99% OF THE TIME A TEXT CAPSULE TAKES TO OPEN — ABOUT 363 MS ON A 2019 INTEL MAC. IT IS STRETCHING A ROOT THAT IS ALREADY 256 UNIFORM BITS. FIG. 2
FIG. 2 — The encryption stack: five layers around the plaintext (200), drawn to distinguish the two that carry confidentiality (204, 210) from those that carry diffusion (202, 206) and integrity (208).

Two layers do the work, and the drawing says so

A stack diagram that draws five identical boxes invites a reader to count five independent barriers. That would misdescribe this design, so the sheet distinguishes them by line weight instead.

  • Confidentiality rests on AES-256-GCM, twice. 204 encrypts the payload and 210 seals the finished executable, both under keys expanded from the one root established in FIG. 6. Every other layer sits between those two or inside them.
  • The fractal layer is diffusion, not secrecy. 202 XORs the payload with a Mandelbrot escape-time mask so that no plaintext structure reaches the cipher. The mask is a function of byte position — it takes no key and is the same for every message. It is a whitening step, and describing it as an encryption layer overstates it.
  • The ECC layer is packing, not asymmetry. 206 re-encrypts under a key from an ephemeral P-384 agreement, then packs the ephemeral private key alongside so that either implementation can open the same bytes. That is a deliberate interoperability decision, and it means the layer contributes shape rather than forward secrecy. Forward secrecy in CTP comes from the key schedule in FIG. 6, not from here.
  • One real cost is drawn rather than hidden. PBKDF2 at 600,000 iterations is roughly 99% of the time a text capsule takes to open. It is stretching a root that already carries 256 uniform bits — a cost inherited from DX/C's password origins rather than one this key schedule needs.
CTP — CAPSULE TRANSPORT PROTOCOL SHEET 3 OF 7 EXECUTION LIFECYCLE — WHERE THE PLAINTEXT IS, AND FOR HOW LONG WIRE ENVELOPE DECRYPT (300) UNPACK · RUNTIME HASH (302) HMAC · TTL (304) SANDBOXED EXECUTION (306) RENDER (308) ZERO (310) UI COPY (312) DISK t0 CAPSULE ARRIVES t1 ENVELOPE OPEN t2 RUNTIME VERIFIED t3 CAPSULE AUTHENTICATED t4 PLAINTEXT EXISTS t5 BUFFERS ZEROED t6 TTL PURGE t NOISE IN ENVELOPE OFF CONSTANT-TIME HASH HMAC, THEN TTL DX/C V3 DECRYPT RENDERED ONCE 4 PASSES STRING OR TYPED ARRAY HELD BY THE UI NO WRITE AT ANY POINT — NO FILE, NO CACHE, NO DATABASE, NO BUFFER RETAINED THE ONLY WINDOW ON ANY FAILURE SILENT DROP. NO ERROR TO THE SENDER, NO RENDER, BUFFERS ZEROED ANYWAY — FAILURE COSTS THE OBSERVER NOTHING TO LEARN FROM. THE SANDBOX (306) EMPTY LINKER — ANY HOST IMPORT FAILS INSTANTIATION. 16 MB MEMORY CEILING · 5 SECOND EPOCH DEADLINE. A FRESH STORE PER CAPSULE — LINEAR MEMORY STARTS ZEROED. THE ZEROING PASS (310) 0xFF → 0x00 → RANDOM → 0x00 APPLIED TO THE PLAINTEXT, THE PAYLOAD, EVERY INTERMEDIATE, AND LINEAR MEMORY. FIG. 3
FIG. 3 — Execution lifecycle: the plaintext exists only between t4 and t5, inside the sandbox (306), and every other lane is drawn to show what is not happening — in particular, that nothing is written to disk at any t.

Two properties only a timing diagram can show

  • The window has two hard edges. The heavy rules at t4 and t5 bound the only interval in which the content exists in the clear. Everything to the left is opening; everything to the right is erasure. A system that decrypted into a buffer and freed it later would have the same left edge and no right one — the drawing makes the difference checkable rather than asserted.
  • Authentication precedes parsing. 304 completes before 306 begins: the HMAC is verified in constant time over bytes that are still opaque, and only then is a field read. This ordering is what keeps a malformed capsule from reaching a parser at all, and it is why the lanes are drawn in this order rather than the conventional one.
  • Failure is quiet by construction. A capsule that fails the runtime check or the authentication check is dropped without a response, and its buffers are zeroed regardless. There is no error a probing sender can distinguish from silence, so a failed attempt teaches an observer nothing.
  • The sandbox is drawn by what it lacks. The module declares no host imports at all — it has no clock, no socket, no filesystem, and no source of randomness. The current time arrives as a function argument, which is why TTL enforcement can happen inside a component that cannot ask what time it is.
CTP — CAPSULE TRANSPORT PROTOCOL SHEET 4 OF 7 UNIFORM FRAMING — EVERY TRANSMISSION IS MANY CAPSULES OF ONE SHAPE A — ONE TRANSMISSION (HERE: A FIFTEEN-SECOND VOICE NOTE) 4071 B 4071 B 4071 B 4071 B 4071 B 4071 B 4071 B 400 402 4071 B OF PAYLOAD PLUS THE 25-BYTE STREAM HEADER = 4096 B OF PLAINTEXT PER CAPSULE. A SHORT MESSAGE IS CHUNKED TOO, WITH TOTAL CHUNKS = 1. B — EACH CHUNK IS PACKED, KEYED AND SEALED ON ITS OWN CAPSULE 0 NONCE 32 B STREAM HDR 25 B DX/C PAYLOAD HMAC 32 B ENVELOPE CAPSULE 1 NONCE 32 B STREAM HDR 25 B DX/C PAYLOAD HMAC 32 B ENVELOPE CAPSULE 2 NONCE 32 B STREAM HDR 25 B DX/C PAYLOAD HMAC 32 B ENVELOPE CAPSULE 3 NONCE 32 B STREAM HDR 25 B DX/C PAYLOAD HMAC 32 B ENVELOPE CAPSULE 4 NONCE 32 B STREAM HDR 25 B DX/C PAYLOAD HMAC 32 B ENVELOPE CAPSULE 5 NONCE 32 B STREAM HDR 25 B DX/C PAYLOAD HMAC 32 B ENVELOPE CAPSULE 6 NONCE 32 B STREAM HDR 25 B DX/C PAYLOAD HMAC 32 B ENVELOPE 404 406 408 A FRESH 32-BYTE NONCE AND ITS OWN AUTHENTICATION TAG PER CAPSULE. THE NATIVE CLIENT PADS EVERY TEXT FRAME TO ONE FIXED LENGTH, SO SIZE CARRIES NOTHING EITHER. C — WHAT THE RELAY AND ANY OBSERVER SEE TOKEN 9F2C… TOKEN 9F2C… TOKEN 9F2C… TOKEN 9F2C… TOKEN 9F2C… TOKEN 9F2C… TOKEN 9F2C… EQUAL-LENGTH, STRUCTURELESS BODIES ADDRESSED TO A TOKEN. NOTHING INSIDE THEM MARKS THEM AS RELATED, AS ONE MESSAGE, OR AS ANY KIND OF CONTENT. D — REASSEMBLY, INSIDE THE RECEIVER’S SANDBOX ONLY STREAM BUFFER (410) KEYED BY THE 16-BYTE STREAM ID CARRIED INSIDE THE ENCRYPTION. COMPLETES ONLY WHEN EVERY CHUNK HAS ARRIVED AND VALIDATED. NEVER WRITTEN OUT. THE ASSEMBLED PAYLOAD IS ZEROED WITH THE REST. EXPIRY (412) AN INCOMPLETE STREAM IS PURGED ON A SHORT TIMER. A WITHHELD CHUNK THEREFORE DENIES THE MESSAGE — IT DOES NOT LEAVE A PARTIAL ONE LYING IN MEMORY. FIG. 4
FIG. 4 — Uniform framing: a payload (400) divided at fixed boundaries (402) into independently keyed and sealed capsules (404–408), reassembled only inside the receiver's sandbox (410) and purged if incomplete (412).

One shape for everything

The chain is not a performance optimisation. It exists so that the shape of a transmission carries no information about its content.

  • Size stops being a signal. A voice note, a long message and a short one all leave as a sequence of equal units. Row C is what the relay actually holds: a queue of identical-looking bodies, none of which announces what it is part of.
  • The stream header is inside the encryption. 408 is deliberately not in the capsule header. If it were, the relay could group chunks by stream and count them, which would reconstruct message boundaries — the one piece of structure the chain exists to remove.
  • Independence is per link. Each capsule carries its own nonce, its own authentication tag and its own envelope. Breaking one yields one chunk and no advantage on the next.
  • Incomplete means gone, not partial. A stream that never completes is purged rather than surfaced. Withholding a chunk can deny a message; it cannot leave half of one in memory or on screen.
CTP — CAPSULE TRANSPORT PROTOCOL SHEET 5 OF 7 BLIND ROUTING — THE RELAY IS NOT TRUSTED BECAUSE IT IS NOT TOLD A — HOW AN ADDRESS IS MANUFACTURED IDENTITY KEYS X25519 IK PUBLIC (32 B) ‖ ML-KEM-768 ek (1184 B) SHA-256 ONE-WAY IDENTITY HASH 32 B · STABLE NEVER TRANSMITTED 500 HKDF-SHA-256 SALT = SESSION SALT (32 B) INFO = "ctp-routing-v2" 502 ROUTING TOKEN 32 B · THE ONLY ADDRESS ON THE WIRE 504 HKDF IS ONE-WAY: A TOKEN CANNOT BE RUN BACKWARDS TO AN IDENTITY. THE SALT IS AGREED BETWEEN PEERS OVER THE ENCRYPTED CHANNEL — THE RELAY NEVER LEARNS IT. B — WHAT EACH PARTY HOLDS PEER A IDENTITY KEYS, HELD LOCALLY REGISTERS ITS OWN TOKEN: 9F2C… DERIVES B’S TOKEN: 4E81… NEVER SENDS EITHER IDENTITY RELAY (506) A MAP FROM TOKEN TO OPEN SOCKET. LOOK UP, FORWARD THE BYTES, FORGET. NO INSPECTION · NO LOGGING · NO STORE. HOLDS NOTHING THAT SURVIVES THE SESSION. PEER B THE SAME DERIVATION, MIRRORED REGISTERS ITS OWN TOKEN: 4E81… DERIVES A’S TOKEN: 9F2C… BOTH SIDES COMPUTE, NEITHER PUBLISHES C — THE ONLY FRAME THE RELAY PARSES FRAME TYPE 1 B TOKEN LEN 1 B RECIPIENT TOKEN N BYTES CAPSULE LEN 4 B CAPSULE M BYTES — OPAQUE BINARY FRAMES ONLY — NO JSON IS EVER TRANSMITTED. THE RELAY READS THE FIRST SIX BYTES AND THE TOKEN, AND HAS NO REASON, AND NO ABILITY, TO READ FURTHER. 508 WHAT A COMPROMISED RELAY STILL CANNOT DO (510) RECOVER AN IDENTITY FROM A TOKEN — HKDF DOES NOT INVERT. LINK THIS SESSION TO THE LAST — A NEW SALT MEANS NEW TOKENS. TELL A VOICE NOTE FROM A TEXT, OR A CHUNK FROM A MESSAGE. PROVE TO A THIRD PARTY WHO SPOKE TO WHOM. WHAT IT CAN STILL DO (512) REFUSE TO FORWARD. CTP IS A CONFIDENTIALITY PROTOCOL, NOT AN AVAILABILITY ONE. OBSERVE THAT A SOCKET IS ACTIVE AND WHEN. COUNT BYTES. EQUAL-SIZED CHUNKS BLUNT THIS; NOTHING ERASES IT. FIG. 5
FIG. 5 — Blind routing: identity keys reduced to a stable hash (500), combined with a per-session salt (502) to produce the only address that appears on the wire (504); the relay (506) holds a token-to-socket map and parses one frame (508).

What the relay is not told

  • Addresses are manufactured, not published. Both peers compute the same token from material neither transmits. The relay receives an address that is a one-way function of an identity it never sees, salted by a value it is never given.
  • The salt is what breaks linkability. 502 changes per session, so the same pair of people are a different pair of addresses tomorrow. A relay that logged everything could not join today's traffic to last week's.
  • The frame is drawn honestly. 508 is in the clear: a frame type, a token and a length. Encrypting it would only move the problem, since something has to route. What the design claims is that the body is opaque and the address is meaningless — not that the network sees nothing at all.
  • The limits are structural, and stated. A relay can refuse to forward, can see that a socket is active, and can count bytes. Equal-sized capsules blunt the last of those; nothing in the protocol erases the first two, and a page that claimed otherwise would be describing a different system.
CTP — CAPSULE TRANSPORT PROTOCOL SHEET 6 OF 7 HYBRID KEY ESTABLISHMENT — TWO HARD PROBLEMS, EITHER ONE SUFFICIENT A — TWO MESSAGES, AND WHAT EACH CARRIES INITIATOR RESPONDER HELLO (600) LAYOUT 1 B MSG 1 B SUITE 1 B X25519 PUBLIC KEY 32 B ML-KEM-768 ENCAPSULATION KEY 1184 B ZERO PADDING TO ONE CHUNK 1219 BYTES BEFORE PADDING — ONE CHUNK, THE SAME LENGTH AS ANY DATA CAPSULE RESPONSE (602) LAYOUT 1 B MSG 1 B SUITE 1 B X25519 PUBLIC KEY 32 B ML-KEM-768 CIPHERTEXT 1088 B ZERO PADDING TO ONE CHUNK 1123 BYTES BEFORE PADDING — INDISTINGUISHABLE IN LENGTH FROM ORDINARY TRAFFIC ONLY THE INITIATOR EVER HOLDS A DECAPSULATION KEY. THE RESPONDER VALIDATES THE ENCAPSULATION KEY PER FIPS 203 §7.2 AND ENCAPSULATES TO IT. EACH HANDSHAKE CAPSULE ALSO CARRIES A ONE-SHOT BOOTSTRAP KEY, ELLIGATOR2-ENCODED SO THAT IT IS UNIFORM ON THE WIRE RATHER THAN RECOGNISABLE AS A CURVE POINT. (616) B — THE COMBINER ss_ec X25519 · 32 B ss_pq ML-KEM-768 · 32 B IKM = ss_ec ‖ ss_pq 64 B FIXED · NO XOR, NO NESTING HKDF-SHA-256 (604) SALT = T · INFO = "ctp-hybrid-v1" DUAL-PRF COMBINER, RFC 9954 / SP 800-56C ROOT KEY 32 B T (606) = SHA-256( "CTP-HYBRID-B7" ‖ HELLO ‖ RESPONSE ) — THE COMPLETE TRANSCRIPT, LAYOUT AND SUITE BYTES INCLUDED, BOUND IN AS THE KDF SALT. ALTER ANY BYTE OF EITHER MESSAGE AND THE TWO SIDES DERIVE DIFFERENT ROOTS. EITHER PRIMITIVE SUFFICES (608) IF ML-KEM-768 FALLS, X25519 STILL CARRIES THE ROOT. IF X25519 FALLS TO SHOR, ML-KEM STILL CARRIES IT. THE DESIGN FAILS NO WORSE THAN TODAY IN EITHER DIRECTION, AND BETTER IN THE ONE THAT IS SCHEDULED. DOWNGRADE FAILS CLOSED (610) THE SUITE BYTE TRAVELS ONLY UNDER ENCRYPTION AND IS BOUND INTO THE SALT. STRIP THE POST-QUANTUM HALF AND THE ROOTS DIVERGE: THE FIRST DATA CAPSULE FAILS ITS HMAC AND IS DROPPED. THERE IS NO FALLBACK PATH. THE RATCHET — SPECIFIED (612) THE PROTOCOL RE-ESTABLISHES THE ROOT EVERY 100 CAPSULES: root' = HKDF( root ‖ ss_ec' ‖ ss_pq' ) — CHAINING THE OLD ROOT SO NOBODY CAN SPLICE INTO A RUNNING CONVERSATION. THE COUNTER IS IN PLACE; THE EXCHANGE IS NOT YET DRIVEN. C — EVERY OTHER KEY DESCENDS FROM THAT ONE ROOT (614) ROOT KEY CAPSULE PASSWORD "ctp-capsule-password-v2" HMAC KEY CAPSULE AUTHENTICATION ENVELOPE KEY "ctp-envelope-v1" ROUTING SALT SESSION SCOPED HKDF-EXPAND WITH A DISTINCT INFO STRING PER PURPOSE. NO KEY IS TYPED BY A HUMAN, SHARED BETWEEN PURPOSES, OR REUSED ACROSS A REKEY. FIG. 6
FIG. 6 — Hybrid key establishment: a two-message exchange (600–602) whose two shared secrets are combined under a transcript-bound KDF (604–606), with the consequences that follow (608–612) and the key schedule it feeds (614).

Why hybrid, and why it fails closed

Recording encrypted traffic today in order to decrypt it later is not a hypothetical; it is a strategy with a name and a budget. A key exchange that rests on the discrete logarithm alone is scheduled to fall, and the recording is what makes that schedule matter.

  • Two problems, either sufficient. 604 feeds both shared secrets into one KDF as fixed-length input — the dual-PRF construction from RFC 9954 and NIST SP 800-56C rev. 2, not an invention of ours. If the lattice problem falls, the elliptic curve still carries the root; if the curve falls to Shor, the lattice carries it.
  • The transcript is the anti-downgrade mechanism. 606 hashes both complete handshake messages — including the byte that names the ciphersuite — into the KDF salt. An attacker who strips the post-quantum half does not negotiate a weaker session; the two sides simply derive different roots and the first data capsule fails its authentication. Downgrade does not fail into classical. It fails closed.
  • Length is not a giveaway. Handshake payloads are padded to a full chunk, and the one-shot bootstrap key each carries is Elligator2-encoded so that it is uniform on the wire rather than recognisable as a curve point. Both are there for the same reason: a session that announces its own beginning has already told an observer the one thing they most want.
  • Everything downstream is derived, and nothing is typed. 614 is the whole key inventory: capsule key, authentication key, envelope key, media key, each an HKDF expansion of the root under its own label. No human chooses a password, and no key serves two purposes.
CTP — CAPSULE TRANSPORT PROTOCOL SHEET 7 OF 7 INSPECTRUM — GRADING THE CIPHERTEXT WITHOUT OPENING IT SHANNON ENTROPY (700) H(X) = −Σ p(x) · log₂ p(x) OVER THE 256 BYTE VALUES. RANDOM DATA APPROACHES 8.00 BITS PER BYTE. STRUCTURE — TEXT, HEADERS, PADDING, AN IMAGE — FALLS AWAY FROM IT. CHI-SQUARED UNIFORMITY (702) χ² = Σ (observed − expected)² / expected, expected = N / 256. MEASURES WHETHER THE BYTE VALUES ARE EVENLY SPREAD. A PERFECTLY FLAT DISTRIBUTION GIVES ZERO. PATTERN SCAN (704) RUNS: EIGHT OR MORE IDENTICAL BYTES IN SEQUENCE — PADDING, ZEROED MEMORY, OR AN INCOMPLETE ENCRYPTION. PERIODS: A TWO-BYTE SEQUENCE REPEATING ACROSS THE BUFFER. THE GRADE IT REPORTS (706) PERFECT ENTROPY > 7.9 AND χ² < 300 GOOD ENTROPY > 7.5 AND χ² < 400 WARNING ENTROPY > 7.0 FAIL ANY PATTERN DETECTED — OR BELOW THE ABOVE WHERE A CTP CAPSULE LANDS ON THAT SCALE (708) 6.0 6.5 7.0 7.5 7.9 8.0 BITS / BYTE FAIL WARNING GOOD PERFECT ≈ 7.999 REPORTED FOR LIVE SESSIONS ON THE NATIVE CLIENT AN ENGLISH SENTENCE SITS NEAR 4.2. A JPEG SITS NEAR 7.5. THE DISTANCE FROM 7.5 TO 7.9 IS THE INTERESTING PART OF THE SCALE. ZERO-KNOWLEDGE (710) NOTHING IS DECRYPTED TO PRODUCE THE GRADE. THE THREE MEASUREMENTS RUN ON THE CIPHERTEXT BYTES THEMSELVES, SO A RELAY OR AN AUDITOR COULD RUN THEM TOO. INSTRUMENTATION, NOT AN ADMISSION GATE (712) THE GRADE IS COMPUTED FOR EVERY CAPSULE, OUTBOUND AND INBOUND, AND SURFACED IN THE INTERFACE. DELIVERY IS NOT CURRENTLY BLOCKED ON IT — IT REPORTS, IT DOES NOT REFUSE. FIG. 7
FIG. 7 — Inspectrum: three measurements taken on the ciphertext itself (700–704) producing a reported grade (706–708), with the two properties that bound what the grade means (710–712).

Measuring the wire, and being clear about the measurement

  • It answers one question. Not "is this secure" but "does this look like noise" — entropy, uniformity and repetition, computed over the bytes about to be sent or just received. Weak ciphertext has a statistical signature, and a bug that produced it would show here before it showed anywhere else.
  • Nothing is decrypted to produce the grade. That is what makes it usable in the open: a relay operator or an auditor could run the same three measurements on the same bytes and get the same answer, without any key and without learning anything about the content.
  • It reports; it does not refuse. 712 is the honest statement of what is wired today. The grade is computed for every capsule in both directions and surfaced in the interface, and delivery is not currently blocked on it. It is an instrument, and calling it an admission gate would describe a decision the code does not make.
  • The interesting part of the scale is narrow. Structured data does not sit at 3 or 4 bits per byte; compressed and encrypted data both sit close to 8. The distance between a JPEG and a correct cipher output is a few hundredths of a bit, which is why the thresholds are where they are.
STATE

What is built, and what is specified

CTP exists as two implementations of one protocol. They are not interchangeable, and a claim true of one is not automatically true of the other.

Capsule One is the native client: a Rust workspace of nine crates plus a tenth artefact that is never linked into the application and only ever transmitted inside its messages. It is the implementation the figures describe. The web client is the original reference implementation and the origin of the capsule format, which the two share byte for byte; it runs on fixed demonstration keys and should be read as a demonstration of the format, not as a deployment.

MechanismCapsule One — nativeWeb reference client
Capsule binary formatShippedShipped — byte-identical, and normative for the format
Carried runtime, executedShipped — 162,162 bytes, no host imports, run under WasmtimeCarried and hash-checked; execution runs the JavaScript reference path
Envelope and capsule authenticationShippedShipped
Multi-pass memory zeroingShipped — four writes, volatileShipped in the host; single pass in the carried runtime
Hybrid X25519 + ML-KEM-768Shipped and cross-verified against the TypeScript implementationImplemented in the core library; not yet wired into the client
Blind routingShipped — v2 tokens, random per-launch salt, no identity on diskFixed demonstration salt — tokens do not vary, by design of the demo
Capsule chain, 4 KB unitsDefined; the native client sends fixed-length frames insteadIn use for text, audio and video
Rekey ratchet every 100 capsulesSpecified, counted, not yet drivenNot present
Inspectrum gradingShipped as instrumentation, both directionsShipped as instrumentation, both directions
Audio and videoShipped — one authenticated-encryption layer from the root, a deliberate trade for real-time budgetsShipped through the full DX/C path
DistributionSigned with a Developer ID and hardened; packaging and notarisation outstandingDevelopment server only

Verification is by test and by cross-implementation agreement rather than by external audit: over 350 tests run by default in the native workspace, twelve fuzz targets, and a set of vectors on which the Rust and TypeScript implementations must produce byte-identical encapsulation keys, ciphertexts, shared secrets, transcript hashes and roots. No part of this has been through third-party cryptographic review, and the fractal transform in particular has never been published for it.

Reference numeral index

Ref.ComponentSheet
10Message, written by a personA
20Capsule — executable binaryA
30Wire format — unstructured bodyA
40Relay — blind token routingA
50Sandboxed executionA
60Single render windowA
70Multi-pass memory wipeA
80Terminal state — no residueA
100Envelope IV, 12 B1
102Envelope ciphertext — the entire capsule1
104Polymorphic nonce, 32 B1
106Runtime hash, SHA-2561
108Carried WASM capsule runtime1, 3
110Capsule data — instruction data for the runtime1
112Capsule header, 26 B1
114DX/C encrypted payload1, 2
116HMAC-SHA-256, 32 B1, 2
118DX/C field layout — salt, IV, ephemeral keys1
120Stream header, 25 B1, 4
122Chunk data, ≤ 4071 B1, 4
200Plaintext2
202Layer 1 — fractal diffusion (keyless)2
204Layer 2 — AES-256-GCM (key barrier)2
206Layer 3 — ECC packing (structural)2
208Layer 4 — HMAC-SHA-256 (integrity)2
210Layer 5 — envelope AES-256-GCM (key barrier)2
300Envelope decryption stage3
302Unpack and runtime-hash validation3
304Authentication and TTL enforcement3
306Sandboxed execution boundary3
308Render callback — the single window3
310Zeroing pass3
312Interface copy, purged on TTL3
400Transmission payload4
402Chunk boundary4
404Per-chunk capsule4
406Independent key material per capsule4
408Stream header, carried inside the encryption4
410Reassembly buffer, sandbox memory only4
412Stream expiry4
500Identity hash — X25519 key with static ML-KEM key5
502Per-session salt and HKDF derivation5
504Routing token — the only address on the wire5
506Relay — token-to-socket map5
508Transport frame5
510Properties a compromised relay cannot obtain5
512Properties it retains5
600HELLO — X25519 key with ML-KEM encapsulation key6
602RESPONSE — X25519 key with ML-KEM ciphertext6
604Dual-PRF HKDF combiner6
606Transcript hash, bound in as KDF salt6
608Either-primitive-suffices property6
610Downgrade resistance6
612Rekey ratchet6
614Key schedule from the root6
616Elligator2 bootstrap encoding6
700Shannon entropy measurement7
702Chi-squared uniformity measurement7
704Run and period detection7
706Reported grade7
708Entropy scale7
710Zero-knowledge property7
712Instrumentation, not an admission gate7