$ plaintxt --security

security

what we built, what it protects against, and where the limits are. no marketing, just facts.

// encryption model

key exchange: ECDH P-256

key derivation: HKDF-SHA-256

message encryption: AES-256-GCM

key generation: browser WebCrypto API (non-extractable private key)

private key storage: IndexedDB, device-local only

forward secrecy: per-message ephemeral key pairs

each message uses a fresh ephemeral sender key pair. even if a private key is eventually compromised, past messages encrypted with prior ephemeral keys remain protected.

// what we protect against

✓
server breach
the server stores only ciphertext. a full database dump reveals no message content.
✓
network interception
messages are encrypted before transmission. TLS provides an outer layer, E2EE is the inner layer.
✓
passive surveillance
no plaintext ever passes through our infrastructure. there is nothing to log.
✓
identity linkage
no email, phone, or real name is required. identities are username + public key only.
✓
message persistence
messages are hard-deleted after burn. no soft deletes, no archive, no backup retention.
✓
identity accumulation
identities expire. expired data is swept and deleted on a fixed cron schedule.

// honest limitations

we document what plaintxt does not protect against. security claims that omit limitations are marketing, not engineering.

!
endpoint compromise
if your device or browser is compromised, an attacker with local access can read plaintext messages on-screen or extract keys from IndexedDB. E2EE does not protect against this.
!
recipient behavior
once the recipient decrypts a message, they can screenshot, copy, or forward it. burn-on-read prevents server-side access — it cannot prevent human action.
!
not Double Ratchet
plaintxt uses per-message ephemeral keys (forward secrecy), not the Signal Double Ratchet protocol. the threat model is different. we don't claim otherwise.
!
browser storage eviction
IndexedDB can be evicted by the browser under storage pressure. Pro/Power users should export identity bundles. free users should treat identities as single-session by default.
!
metadata
we store timestamps and username pairs for conversation routing. we do not store message content, but we do know that two usernames communicated at a given time.

// infrastructure

API: Cloudflare Workers — edge-deployed, no persistent application servers

database: Cloudflare D1 — stores ciphertext, timestamps, public keys only

attachments: Cloudflare R2 — encrypted at rest, deleted on burn

WebSocket: Cloudflare Durable Objects — stateless relay, no message storage

CDN: Cloudflare Pages — static assets only, no server-side rendering of private data

// responsible disclosure

found a vulnerability? contact us at plaintxt.app/contact. we respond to all credible security reports. we do not have a bug bounty program at this stage, but we take every report seriously and will credit researchers who help us improve.