How Postkey encrypts your data
Postkey encrypts your cards and files on your device before they leave it. This page describes how that works in the current version, which keys exist, what our servers can see and where the limits are.
Status: 12 October 2026
01In short
- Texts, titles, file names, labels and files are encrypted on your device with AES-256-GCM. The keys are made on your device.
- Your password does not leave your device. The server receives only a value derived from it.
- Every file has a key of its own. A link carries its key after the
#sign, which browsers do not send to the server. - We cannot read your cards and files. If you lose both your password and your recovery code, nobody can open them again, not us either.
02The keys
| Key | What it is | How it is protected |
|---|---|---|
| Data key | A random 256-bit AES-GCM key, made on your device when the account is created. It encrypts your texts, titles and labels and the keys of your files. | Stored only wrapped: with your password key, with your recovery code key and, if you add one, with a passkey. |
| Password key | Argon2id from your password (64 MiB of memory, 3 passes, a random 16-byte salt). | Never stored. It is made again on your device when you enter the password. |
| Recovery code | 160 random bits, shown once as 32 characters when you create the account. PBKDF2-SHA256 with 600,000 iterations turns it into a key. | Kept only by you. The server keeps at most a hash of a value derived from it, to check the code before a key change. |
| Passkey key | From the PRF extension of WebAuthn, through HKDF-SHA256. | The PRF output stays on your device; the private key of the passkey stays with your passkey provider. |
| File key | A random 256-bit key for every file, its thumbnail and its screen version. | Wrapped with the data key; for a shared card also with the card key. |
| Card key | A random 256-bit key for a card you share. | Wrapped with the data key and with the key of each link. |
| Link key | A random 256-bit key for every link, in the address after #. | With a link password it is combined with the password (PBKDF2-SHA256, 600,000 iterations, then HKDF). |
03Signing in without sending the password
The sign-in service (Supabase Auth) does not receive your password. It receives HKDF-SHA256(Argon2id(password), "box-auth-v1") and keeps a bcrypt hash of that. Neither the traffic nor the database reveals the password, and every guess against that hash costs a full Argon2id.
Changing the password and every other change of the wrapped keys needs a proof: the current password, the recovery code, or a sign-in with an e-mail code, Google or a passkey in the last 15 minutes. After five wrong proofs in an hour no more tries are accepted for that hour. The new keys and the new sign-in value are saved in one database transaction.
Two-factor sign-in (TOTP) is checked by the database itself on every access to your data, not only by the app. Signing in with Google confirms only who you are; Google receives no key and no content.
04Cards and files
Every text value (card text, title, file name, file type, labels, favourite and hidden flags) is encrypted on its own with AES-256-GCM and a random 96-bit IV. GCM also detects any change of the ciphertext.
Files are stored in the BOXC format: a short header (frame size, number of frames, original size), then the file in frames of 1 MiB, each encrypted with AES-GCM under the file key. The number of the frame and the number of all frames are authenticated with every frame ("index:count"), so frames cannot be reordered, dropped or exchanged unnoticed. Your device decrypts a file frame by frame, which also lets long videos play in parts.
05Sharing links
A link looks like box.sortia.de/s/<code>#<key>. Browsers do not send the part after # to the server. The server keeps the card key and the file keys only wrapped with the link key.
With a link password, the password becomes part of the key: the recipient needs both the address and the password. The server keeps only a check value derived from the password; after 10 wrong passwords the link locks for five minutes at a time.
A link stops working at the time you chose, after the number of openings you allowed, while it is paused, when you end it, or when its card goes to the trash or is deleted. "View only" hides download, copy and print on the recipient's page; it cannot stop a screenshot or a changed browser. Whoever opened a link can keep what they saw.
When Postkey sends a link by e-mail from sortia.de, our server sees the address with its key for that moment. That is why it does so only for links with a password, and the password is never part of that e-mail. A link you copy or share yourself does not pass our server.
06What our servers can see
To run Postkey we keep these data unencrypted: your e-mail address and sign-in data, the type and size of an entry, when it was created and when it expires, whether it is in the Temporary or the Permanent vault, which file belongs to which card, and for links their end, the allowed and counted openings and their times. Connections leave IP addresses in logs for a limited time. The details and periods are in the privacy policy.
We cannot see the texts, titles, file names, labels or the content of files. For entries from older app versions the file type may still be readable until the app converts the entry.
07Where the data are
- Accounts and the encrypted card data: Supabase, data centre in Frankfurt am Main.
- Encrypted files: OVHcloud in Paris (three data centres) and a copy at IONOS in Frankfurt am Main, so that Postkey keeps working when one of them is down.
- Files in the Permanent vault are also kept in a backup at IONOS with Object Lock for 30 days: in that time nobody can delete or change them, not us either.
- The database is backed up every day, encrypted, on our server in Germany and at IONOS (there locked for 27 days), and every copy is deleted after 30 days. Every week a backup is restored from the IONOS copy as a test, and we have checked that files open with the keys from such a backup.
Only encrypted content leaves your device. The services we use are listed in the privacy policy.
08Limits
- Postkey on the web loads its code from our server every time you open it. Someone who took over that server could deliver changed code. Every 15 minutes we compare the files the server delivers with the released version and are alerted on any difference. The Android app carries its code in the app package.
- Metadata: the data listed under "What our servers can see" are visible to us.
- Lost password and recovery code: nobody can open the data again, not us either.
- Your device: malware on it, or an unlocked device in someone else's hands, sees what you see. "Lock after" in the settings and the screen lock of your device help.
- Export: "Download all my data" writes one ZIP file with everything decrypted. Keep it safe.
- Review: currently there is no independent security audit of Postkey.
09Report a vulnerability
If you find a weakness, please write to info@sortia.de with "Postkey security" in the subject, and give us time to fix it before you publish it. Please do not access other people's data and do not test with denial of service. The machine-readable contact is in /.well-known/security.txt.