Stronger encryption for your Crypton account (and what it means for you)

We’ve been hardening how your encryption passphrase protects your messages, contacts, and other sensitive data. Most of you won’t need to do anything right away. This post explains what changed, who it affects, and what to do if you use account recovery or the API.

The short version

• Your account password (what you use to sign in) is unchanged.
• Your encryption passphrase (what unlocks your encrypted data) still works the same way you’re used to.
• We’re rolling out a new, stronger way to protect the keys that power that encryption—designed for the long term, including against future “quantum computer” attacks on older designs.
• New accounts (new encryption setup) use the upgraded ML‑KEM wrap by default. Existing accounts are unchanged unless you migrate or re‑create encryption.
• API tokens that carry your encryption key are now bound to the token string itself (see below)—same header and same “copy once” flow; nothing extra to wire in the client.
• If you use a recovery phrase saved to your account, there’s one important heads‑up for a subset of users—see below.

What actually changed?

1. How we “wrap” your encryption key

Behind the scenes, Crypton stores a special key that lets the app encrypt and decrypt your personal data. That key has always been protected with your encryption passphrase and other safeguards.

We now support two modes:

Older accounts that were created before this change stay on classic until you intentionally change how encryption is stored.

Tech note (only because it’s new): ML‑KEM‑768 is part of modern standards for key agreement that remain strong even if large quantum computers someday weaken traditional public‑key math. We ship this through well‑maintained open‑source libraries—no special browser plugin or app install required on your side.

2. API tokens and your encryption key (no client change)

If you use a personal access token that embeds your encryption key (for API access to encrypted data):

• How you use the API is unchanged: same token format, same Authorization: Bearer … header—no extra headers or new fields.
• New tokens: the copy of your encryption key stored with the token is cryptographically tied to that exact token string. A leaked database backup alone is not enough to recover that embedded key; an attacker would also need the plaintext token you were shown once when you created it.
• Older tokens (created before this change): the first time you call the API successfully with the token, we upgrade its stored metadata to the new binding automatically—no need to rotate the token just for that upgrade. Tokens that are never used again keep the old shape until they expire or you delete them.
• Expired tokens are removed on a routine schedule so old hashes and metadata don’t linger past their “valid until” date.

This does not replace choosing a strong token or protecting your device: anyone who has your live token can still use the API as you. The improvement is about offline risk (e.g. a stolen database snapshot without your token strings).

Recovery phrase: one thing to watch

If you’ve saved a recovery phrase to your account (the backup flow after you set up encryption), that phrase is tied to what’s stored in your account—including how your keys are wrapped.

If your account is ever moved to the upgraded encryption wrap, your old recovery phrase may not contain everything needed to recover without re‑saving it once.

What to do: After any prompt or announcement about “post‑quantum” or “upgraded” encryption, if you rely on recovery, open account settings and save your recovery phrase again while you still know your current encryption passphrase. That refreshes the backup so it matches your account’s new shape.

If you skip that step and later try recovery-only reset with an outdated backup, you may see a message asking you to save a new recovery phrase first. That’s expected—it protects you from a recovery path that would otherwise fail halfway.

API users (tokens & recovery)

If you use Crypton’s HTTP API with a personal access token that carries your encryption key:

• There is now a supported POST /api/v1/tokens/create endpoint so you can create that kind of token programmatically, using the same encryption passphrase you use in the app (whether your account uses the classic or upgraded wrap under the hood).
• If you reset your encryption passphrase via recovery (account recovery with your backup phrase or the supported payment‑reference flow, same as the website), you can call POST /api/v1/account/passphrase-recovery-reset with the same information you’d enter on the website.
• After a successful recovery that changes your encryption setup, all existing API tokens for your account are revoked. You must create new API tokens with your new passphrase (or your current one, if only recovery metadata changed)—old tokens will not keep working, by design.

Your normal API requests stay the same (Authorization: Bearer …); only create a fresh token when recovery tells you encryption has rotated or when you intentionally roll keys.

What you don’t need to worry about

• Reading your messages in the app — same flow: sign in, enter your encryption passphrase when asked.
• Phone numbers, billing, and account settings — not tied to this encryption layer.
• Being forced onto something experimental — new setups use the upgraded path by default; existing accounts stay on what they already have until you migrate or reset encryption.

Summary

We’re doing this so Crypton stays trustworthy for years—not to add busywork. If anything here is unclear, open a support ticket and we’ll walk you through it.

— The Crypton team