Write the security explainer #98

New issue

Closed

opened 2026-09-23 10:46:10 +01:00 by cruelacid · 1 comment

cruelacid commented

2026-09-23 10:46:10 +01:00

Owner

Why

This is the artefact that earns the right to post in r/netsec, gets submitted to
security newsletters, and gives a writer something to verify rather than repeat.
It is also the strongest form of the product's second pillar: the claim is
checkable, so show the check.

What to do

A technical write-up of the security model, pitched at someone who could
implement it. The content already exists in docs/security-model.md; this turns
it into something a reader arrives at cold.

Ground to cover:

Note content under AES-256-GCM, invisible to the server.
Document ids are HMAC-SHA256(nameKey, path) truncated to 16 bytes — so
paths, folder structure and note titles never reach us.
Attachment content and filenames sealed in a chunked AEAD envelope whose AAD
binds blob id, chunk index, chunk count and algorithm.
Folder display names sealed — there is no such thing as a folder whose name the
server can read.
Passphrase: PBKDF2-SHA256 at 600,000 iterations, never leaving the device; on
the hosted service nothing derived from it is sent at all.
Identity key P-256 ECDH, private half wrapped before upload; folder keys
wrapped per member with ECIES over P-256, fresh ephemeral keypair per wrap.
Per-member key fingerprints comparable off-server — the same mechanism as
Signal safety numbers.
The verification path: the client ships unminified, every release publishes
the SHA-256 of the bundle, and scripts/verify-build.mjs reproduces it from
published source. Verified byte-identical from a clean clone on 18 September
2026.

Constraints

Publish the limits in the same piece, or link the companion page. A
security audience that finds an unstated limit stops reading everything else.
Never "audited" — designed to be audited. Never "zero knowledge" — the term
implies more than we do. Never "we store no metadata" — the membership graph,
account and device records, sizes, timings and IPs are all stored.
Never "open source".
Every claim checkable against the shipped client, because the whole point is
that someone will check.

## Why This is the artefact that earns the right to post in r/netsec, gets submitted to security newsletters, and gives a writer something to verify rather than repeat. It is also the strongest form of the product's second pillar: the claim is checkable, so show the check. ## What to do A technical write-up of the security model, pitched at someone who could implement it. The content already exists in `docs/security-model.md`; this turns it into something a reader arrives at cold. Ground to cover: - Note content under AES-256-GCM, invisible to the server. - **Document ids are `HMAC-SHA256(nameKey, path)` truncated to 16 bytes** — so paths, folder structure and note titles never reach us. - Attachment content and filenames sealed in a chunked AEAD envelope whose AAD binds blob id, chunk index, chunk count and algorithm. - Folder display names sealed — there is no such thing as a folder whose name the server can read. - Passphrase: PBKDF2-SHA256 at 600,000 iterations, never leaving the device; on the hosted service nothing derived from it is sent at all. - Identity key P-256 ECDH, private half wrapped before upload; folder keys wrapped per member with ECIES over P-256, fresh ephemeral keypair per wrap. - Per-member key fingerprints comparable off-server — the same mechanism as Signal safety numbers. - **The verification path**: the client ships unminified, every release publishes the SHA-256 of the bundle, and `scripts/verify-build.mjs` reproduces it from published source. Verified byte-identical from a clean clone on 18 September 2026. ## Constraints - **Publish the limits in the same piece, or link the companion page.** A security audience that finds an unstated limit stops reading everything else. - Never "audited" — *designed to be audited*. Never "zero knowledge" — the term implies more than we do. Never "we store no metadata" — the membership graph, account and device records, sizes, timings and IPs are all stored. - Never "open source". - Every claim checkable against the shipped client, because the whole point is that someone will check.

cruelacid added this to the Backlog - unscheduled milestone

2026-09-23 10:46:10 +01:00

cruelacid added the

marketing

channel:press

gate:pre-ga

labels

2026-09-23 10:46:10 +01:00

cruelacid referenced this issue

2026-09-23 10:46:56 +01:00

Go-to-market programme #110

cruelacid added this to the Marketing project