Security

Nothing readable leaves the node.

This page states the security posture in the terms the design itself uses — and it states the limits in the same breath. Nothing here asserts a guarantee the design does not make.

Passkeys onlyAES-256-GCM envelopesRollback protectionFail-closed scanningNo call-home

Identity: passkeys only

There are no primary passwords anywhere in the suite — no password hashing, no breach list, no password policy.

People

  • Sign-in with a WebAuthn passkey; registration, login and step-up all require user verification.
  • A user record holds only public keys. Someone who compromises the object store and the master key still gets nothing they can use to sign in as a user.
  • The one optional second factor is TOTP: never required, and only ever a step-up — never a sign-in factor.

Clients and guests

  • Protocol clients never hold passkeys. They get named, scoped, individually revocable app passwords and access tokens, minted only behind a fresh passkey assertion.
  • Sensitive actions — adding or removing a passkey, minting or revoking credentials, naming recovery peers, approving a signup or recovery, every administrative mutation — take a fresh passkey assertion.
  • A guest — a principal identified by an external ATProto identity — owns nothing here and may be granted a strictly limited ceiling of rights.

Encryption at rest

Everything durable is encrypted on the node before it leaves, against an object-store provider assumed curious and possibly tampering.

What is encrypted

  • Blob contents, record contents, and record and blob names.
  • The object store sees ciphertext, opaque names, sizes, and the timing and shape of access — nothing readable.
  • Rollback protection defends against replay, substitution and un-deletion.

The keys

  • Derived from a per-install master key — 32 random bytes, shown once as a 24-word phrase — held on the node and never in the object store.
  • Blobs use an AES-256-GCM envelope with a fresh random content key per write, wrapped with AES-256-KW.
  • Records bind the record key and revision into the envelope, so a provider cannot swap one record for another.
  • Keys rotate without re-encrypting content; the wrapping and naming halves rotate independently.
The user-held-key tier — decided, not built. The design specifies an opt-in tier in which a principal's blobs are wrapped under a key the install's master key cannot reproduce, narrowing what the operator can read. It is not yet built. Until it is, the accurate statement is: all content is encrypted at rest under install keys that the operator holds, and the tier that narrows the operator is designed but not built.

Anti-abuse, built in and run on the install

Protection against spam, viruses and impersonation is opinionated about where it comes from, and about what it will not do.

Built in, not a subscription

SPF, DKIM, DMARC, ARC, virus scanning, spam scoring, brand-impersonation scoring and lookalike-link warnings are implemented in-house and run on the install.

Fails closed

A scanner error refuses the message rather than accepting an unscanned one. An unscanned inbox is not an option.

No scan-time call-home

The suite never telephones a remote feed to score a message; phishing-URL feeds that would call out at scan time are rejected. Phishing links are matched against a self-hosted snapshot instead.

A shared, not personal, spam model

Personal per-user models are rejected in favour of a shared model that admits only tokens several principals observed independently — pooling works without leaking content between data controllers.

No auto-ban, no lockouts

GeoIP scoring, DNSBL packs and auto-ban are deliberately not in the core — the false-positive lockout risk on shared IPs is documented as a reason, not an oversight.

No metrics vendor

There is no metrics or tracing vendor built in. Observability runs on the install's own private network, through its own status endpoint and doctor tooling.

Where the posture stops

An honest posture names its limits. The design is explicit about what it does not defend, and this page will not inflate them.

The master key is on the node. A party that controls both the node and the bucket can read everything in the default tier.
One trust boundary. Every service except the public web origin holds the master key and the bucket credentials — including the internet-facing mail gateway — by documented decision. The internal secret can reach every internal route.
No external audit yet. The encryption envelopes have passed internal review, known-answer vectors, cross-implementation checks, fuzzing and an adversarial test suite. An independent cryptographic audit has not reviewed them; it is the planned revisit trigger.
Bundles are attested, not signed. An atproto account records an attestation of a bundle's hash, which can be withdrawn.
Report a finding: the disclosure process lives in the source repository — docs/public/vulnerability-disclosure.md at tangled.org/@pipobscure.com/ordner.

Posture read. Now the practice.

What the suite does, and how to use it.

Explore the suite Read the manual