◇ Writing · in progress
Essays we are writing.
Each entry below is in progress. The status tag is the truth, not a teaser. Essays publish when every claim they make can be checked against running code, a published specification, or a primary source. If an abstract contains a claim you would contest, contact us before we ship — correction during drafting is cheaper than retraction.
- § 01◇ drafting
Why key exchange is not a ledger problem
On the category error of adding shared state to private messaging
The instinct to introduce a shared-ledger component into a private messaging surface is recurrent and, we think, mistaken. Shared state buys no confidentiality property the symmetric primitives do not already provide, and it adds an attack surface — and a metadata surface — that the design did not need.
- § 02◇ drafting
Out-of-band key exchange is a feature, not a bug
On choosing friction over a Shor surface
Conventional wisdom in messenger design is that key exchange must be invisible. We disagree, for the same reason a bank vault has a combination dial and not a fingerprint reader: removing the visible step also removes one of the user's defences against the system being changed underneath them.
- § 03◇ outlined
What ML-KEM actually buys you in 2026
A careful read of FIPS 203 in the context of production transition
The lattice-KEM family is doing real work in production migrations and is also being asked to carry more weight than the original threat model called for. We walk through what the standard guarantees, what it does not, and where we adopt it.
- § 04◇ outlined
The cost of forward secrecy in a browser
On building cryptography that survives the page reload
Forward secrecy is a strong property to claim, and a difficult property to actually deliver in a browser execution environment where state is impermanent and storage is adversarial. We share the constraints we ran into building it for Qubble Chat and the compromises we made.
- § 05◇ notes
Notes on building a security page that auditors trust
How to communicate cryptographic posture without overstating
Security pages tend to drift to one of two poles: marketing copy dressed in monospace, or genuine technical documents that are unreadable to anyone who is not already a cryptographer. We are trying for a third path. The result is auditable against the running code; it is not done.
◇ How we write
Three rules. They govern what ships from here.
01 · Falsifiable or unwritten
If a claim cannot be checked against running code, against a specification, or against a primary source, it does not go in the essay. The job of writing is to give the reader something to push against, not something to nod at.
02 · Cite the disagreement
Where the field disagrees about a design choice, we say where the disagreement is and which side we land on. We do not write past it. A reader who is going to disagree should know what they are disagreeing with.
03 · Slow on purpose
Production cryptography tolerates delay better than error. The essays publish when we can cite every claim to running code, a specification, or a primary source, and survive review by a reader who wants to find errors.
The briefing line announces published essays. It sends when there is writing to send, and nothing else — the explicit terms are on the contact page.
◇ The essays are not financial commentary. They are technical writing about cryptographic infrastructure.