Strong encryption, used correctly, everywhere it matters.

Encryption is only as good as the way it's used. This page lays out the algorithms, key management, and trust model behind every WordsLater message - so you can verify, not just trust.

Encryption at a Glance

AES-256-CBC

Vault Items at Rest

Items you place in the Vault are encrypted at rest with AES-256 in CBC mode, each with a fresh random initialization vector, before being written to storage. AES-256 is the same standard used by banks and governments worldwide.

TLS 1.3

In Transit

Every connection between your browser and WordsLater - and between WordsLater and our delivery providers - is protected with TLS 1.3 using strong, modern cipher suites. HTTP is permanently redirected to HTTPS, and HSTS is preloaded.

Per-item IV

Unique Per-Item IV

Every vault item is encrypted with its own random initialization vector, so two identical items never produce identical ciphertext. The algorithm is recorded with each item for forward compatibility.

Server-held key

Key Management

The AES-256 vault key is held server-side in application configuration and used only to encrypt and decrypt vault items. Access to it and to production systems is limited by strict, audited access controls.

Access controls

Messages & Attachments

Your scheduled messages and their attachments are kept private in an access-controlled database and transmitted over encrypted (TLS) connections. They are never sold, shared with advertisers, or used to train AI.

bcrypt

Password Storage

Passwords are never stored in plain text. We use bcrypt with a per-user salt and a tuned work factor so that even a stolen database remains infeasible to brute-force.

Standards Reference

Layer Algorithm Key Size Notes
Symmetric (vault, at rest)AES-256-CBC256-bitFresh random IV per item.
TransportTLS 1.3ECDHE + AES-GCM / ChaCha20Forward secrecy on every session.
Asymmetric (key exchange)X25519 / RSA-2048+256-bit / 2048-bitUsed in TLS handshakes.
Password hashingbcryptper-user saltTuned work factor; rehashed on login as needed.
Signing & tokensHMAC-SHA-256 / Ed25519256-bitFor session tokens, API tokens, and email links.

Who Holds the Keys?

Encryption is not magic; it's about who holds the keys. Here is who can access what, by design.

Data You Recipient WordsLater staff
Scheduled message body Read & edit anytime before delivery Read at delivery No content access during normal operations
Attachments Read & replace anytime before delivery Download at delivery No content access during normal operations
Vault items Read anytime you're signed in Read only after explicit release No routine access; encrypted at rest under strict controls
Metadata (recipients, dates, file names) Read & edit Visible when message is delivered Access for delivery, billing, abuse prevention
Payment details Last 4 digits only No access No access (handled by PCI-compliant processor)

About your encrypted vault

Vault items are encrypted at rest with AES-256 and kept under strict, audited access controls. They are released only to the people and on the triggers you choose - never handed out on casual request. Because your vault holds your most sensitive information, we strongly recommend enabling two-factor authentication and keeping a copy of anything irreplaceable with your other estate documents.

Key Handling & Crypto-Agility

Fail-closed key handling

If the vault key is ever unavailable, the system fails closed - it refuses to store or open vault items rather than risk mishandling them. The key is never returned to your browser or exposed to recipients.

Crypto-agility

The vault's encryption is versioned - each item records the algorithm it was encrypted with. When the industry moves to a new standard, we can roll forward without re-encrypting existing items.

Want the bigger picture?

See how encryption fits into our broader security and data handling.

Security overview Data retention & custody