What our server can and cannot see
The complete, honest list — what is stored only as ciphertext, what the server must handle to deliver your mail and chats, and why there are no connection logs.
"Encrypted" is easy to say. This page says exactly what that means for Private.Ki: what sits in our database only as ciphertext, what the server has to see for a moment to do its job, and what it keeps. It is written from the data model of the current release and is reviewed with every release.
Some things the server never receives (your passphrase, your password). Some things it receives encrypted and stores encrypted (message bodies, subjects). And some things it receives in the clear to do a job, then stores only encrypted or hashed (an incoming external email, a recovery address). The table below tells you which is which.
The short version
Cannot see
- Email bodies, attachments and inline images — stored PGP-encrypted to your key
- Chat texts, voice messages and emoji reactions — stored PGP-encrypted
- Subject lines, recipient lists and Message-IDs of stored messages — encrypted on your device before upload
- Your passphrase, and your private key in usable form
- Your password — OPAQUE means it never leaves your device, not even hashed
- Your recovery address — only an Argon2 hash is kept
- Which emoji you reacted with, group names and group rosters, your signatures, your recipient autocomplete history
- Your IP address — we keep no access or connection logs. The only value derived from it is a keyed hash in a rate-limit counter that expires within an hour
Can see
- Your username, display name, public key, sign-up date and last sign-in
- Which addresses you send to, when, and how large each message is
- Per stored message: owner, email or chat, sent/received/draft, read and starred flags, timestamps, folder, self-destruct deadline, whether it was unsent or destroyed
- Whether two-factor and a recovery address are set; the TOTP secret (encrypted at rest, decryptable by the running server)
- The subject and — unless PGP-encrypted — the body of email leaving for or arriving from outside Private.Ki, at the moment it passes through
The detailed table
| Data | Server can read it? | How it is held |
|---|---|---|
| Email body, attachments, inline images (between Private.Ki users) | No | Message.content: PGP-encrypted on your device to each recipient's key |
| Chat message text, voice messages | No | Same field, same encryption |
| Subject, To/Cc/Bcc, Message-ID, In-Reply-To of a stored message | No | Message.headers: AES-encrypted on your device (your own copy) or PGP-encrypted to the recipient (their copy) |
| Sender name and address on a stored message | No | Message.sender: PGP-encrypted to the owner's key |
| Emoji reactions | Partly | The emoji and the target Message-ID are PGP-encrypted. The server can see that you reacted, when, and which of your own stored (encrypted) messages the reaction attaches to. It cannot link your copy to the other person's |
| Unsend / destroy | Partly | The instruction to the other side is PGP-encrypted. Each side's own copy is marked unsent or destroyed in the clear, with its content emptied. The server sees that a message was withdrawn and when, not what it said |
| Self-destruct timer | Yes | Mode, duration and the deadline of each message are plaintext — the server has to know when to delete. Who changed the timer is encrypted |
| Group name, member list, admin | No | PGP-encrypted and signed, one copy per member. But the server sees the recipient addresses of every message you send, so it can infer who is in a group from delivery |
| Which threads your messages belong to | Within your account | Threads are grouped by keyed hashes that only your key material produces. The server sees grouping inside your account, not across accounts |
| Your private key | No | Stored PGP-armored and locked with your passphrase (or a key derived on your device from your password). The server holds the locked key and, in Password only mode, half of a per-session unlock secret — never the passphrase or password |
| Your password | No | OPAQUE registration record only. The password is never transmitted |
| Your passphrase | No | Never transmitted. We cannot reset it |
| Your public key | Yes | Plaintext — it is public by design |
| Username, display name, sign-up date, last sign-in, account status | Yes | Plaintext account fields |
| Unlock method (password only / passphrase), whether you have set a password | Yes | Derived from account fields |
| Two-factor | Yes | Whether it is on; the TOTP secret, AES-256-GCM encrypted under a server-held key. The running server must decrypt it to check codes |
| Recovery address | Hash only | Argon2 hash. The address itself passes through when we email you a code, and is not stored |
| Email-code sign-in address | Hash only | HMAC of the address for lookup. The address passes through when we email you a code |
| Sessions and devices | Yes | Device name, creation, expiry and last-use time, DPoP key thumbprint, push token (iPhone/Android) |
| Recipient autocomplete history, imported external public keys, signatures | No | AES-encrypted blobs, looked up by a keyed hash of the address |
| Senders and messages you trusted for external images | Hash only | Keyed hash of the sender address or message id — no plaintext address |
| Delivery metadata | Yes | For every send: the recipient addresses, the time, the size in bytes of each encrypted copy. For chat: typing signals name the peer |
| Presence | Yes | Whether you currently have an open connection (used to decide between an in-app notification and a push) |
| Push notifications | Yes | Apple or Google receive your device token and the words "New email" or "New chat message" — nothing else |
| IP address | No | Not logged. Seen while your connection is open, never written down — see below |
Email that crosses the border
Private.Ki is end-to-end encrypted between Private.Ki users. Email to or from the rest of the internet is different, and we would rather say so than let you assume:
- Outgoing to an external address without their public key. The subject, the recipient addresses and the body reach our server in the clear so it can hand them to the mail server. Before sending, the addresses, subject and body are checked against spam blocklists (see Third-party services). Nothing readable is stored — your Sent copy is encrypted to your key — but the mail leaves as ordinary email.
- Outgoing with their public key. The body is PGP-encrypted on your device and the server never sees it. The subject and addresses are still plain, because SMTP requires it.
- Incoming from outside. Ordinary email arrives in plaintext. Our mail server hands it to the application, which immediately encrypts the body, headers and sender to your public key and stores only that. The plaintext is not kept, but it was readable on arrival. If the sender encrypted the mail to your key, it arrives unreadable.
- No mail server logs. The mail transport hands external mail over and keeps no log of who it was from or to, or when.
See Encrypted email with external contacts for how to get someone's key.
1212IP addresses and connection logs
We don't keep logs.
- No access logs. Our web server writes no access log. Nothing records your IP address, your browser, or which pages or endpoints you requested.
- No connection history. There is no record of who connected, from where, or from which device. IP addresses are never stored in the application database and are not tied to your messages.
- Rate-limit counters for sign-up, username lookup, device pairing and invite redemption are the one thing derived from your IP address: a keyed hash (HMAC) of the address, kept in memory and expiring within an hour. It cannot be turned back into the address. See Rate limits.
- Sign-in leaves one timestamp (
last_login) on your account, without an address. We do not keep a per-session IP history.
If your IP address matters to you, use Tor or a VPN; we do not block either.
What support and operators see
Staff use an operator console that shows the plaintext account fields listed above plus counts: how many threads and messages you have, how many bytes they use, how many devices and push tokens are registered. It shows no message content, no subjects, no keys. Staff can disable an account, end its sessions, allow a username change or clear a mandatory-2FA flag; they cannot decrypt anything. See Contact support.
Common questions
Could you hand my messages to the authorities?
Only the ciphertext and the metadata in the "yes" rows above. We cannot produce readable message content, keys or passphrases, because we do not have them. See the transparency report and warrant canary.
Do timestamps reveal who I talk to?
The server sees recipient addresses on every send, so yes — the server knows who you write to. What the database alone cannot do is join the two sides of a conversation: each participant's copy carries independent identifiers and randomly offset timestamps, so a database dump does not reveal conversation pairs or group rosters.
Why do you need the size of each message?
To enforce size limits (10 attachments × 25 MB per message) and to account for storage per account. The size of a PGP message is not the size of the plaintext, but it is close.
Is search done on the server?
No. Search runs on your device over your decrypted subjects and participants; the server never receives a query. See Search.