privymail.eu

A password that never leaves your device

How the OPAQUE method checks your password without our server ever seeing it, what the server stores instead and where the protection ends.

At privymail.eu, your password never reaches us: not when your account is created, not when you sign in and not when you change it. The method behind this is called OPAQUE and is described in RFC 9807. It applies to sign-in in the browser.

The usual way shows the server your password

With most sign-ins on the internet, you type your password and the browser sends it to the server over the encrypted connection. The server computes a check value from it, compares that with the stored one and forgets the password again, if everything is built correctly. For a moment, though, it is there in plain text. A mistake in a log, altered software or an attacker on the running server is enough, and it is in someone else's hands.

With us that would weigh twice as much. Your password does more than open the door: the secret that protects the key to your stored mail, the mailbox key, is also derived from it. A server that sees the password would see more than a login credential.

Your device does the computing. The server helps blind.

OPAQUE reverses the roles. A sign-in takes four steps:

  1. Blind. Your device wraps the password so that the server can compute with it but cannot read it.
  2. Compute blind. The server combines the wrapped input with a secret key that exists only for your account and sends the result back. It does not learn what it has processed.
  3. Stretch. Your device removes the wrapping and continues with Argon2id, a deliberately expensive method that makes trying out passwords costly.
  4. Prove. In a key exchange of three messages, your device proves that it knows the password without stating it. Your device learns whether it is correct after the second message, the server only with the third.

When an account is created, the first three steps run the same way. At the end, your device uploads a record that the server stores and against which it checks every sign-in. It contains neither the password nor an ordinary hash, that is, no value against which a guessed password could be checked with the database alone.

What we hold, and what we never hold

Four things belong to the method. One of them is the service secret: a long-lived key of the server without which no record can be used to check a password.

WhatWhere it is kept
Your passwordonly on your device, while you are typing it
Record for checking the passwordin our database, without the password and without an ordinary hash
Service secretwith us, separate from the database
Unlock secret for the mailbox keyderived on your device; the server sees it only within individual requests, for example when an app password is created or credentials are changed

The separation in the second and third rows carries the protection. Anyone who copies only the database cannot try out passwords against it, because the service secret is missing. Anyone who captures both can guess, but pays a full Argon2id computation for every attempt. How long a password withstands that then depends on how long and how random it is.

What it costs

  • Your device does the work. The expensive computation runs on your side, not ours, and takes longer on a weak device than on a strong one. When an account is created, it runs twice.
  • The server cannot judge your password. Because it does not see it, it cannot enforce a password rule. The program on your device takes that over.
  • A secret that must not be lost. The service secret cannot be replaced without every account repeating the set-up of its password. If it were lost, no sign-in with a password would be possible any more; recovery codes, the codes for emergencies, do not depend on it and keep working.
  • Program code in the browser. The computation needs JavaScript. This website does without it; the sign-in page cannot.
  • A young method. RFC 9807 was published in July 2025 as an informational document of the research group for cryptography, not as an internet standard. Older methods have been in use for longer and have more implementations.

What it does not solve

  • The key to your mail. OPAQUE protects the password, not the mailbox key. In Compatible, the default mode that needs no extra software in the mail app, the server sees this key whenever it needs it, for example every time a mail app signs in. For operations such as a new app password, your device sends along an unlock secret that it derives from the sign-in. RFC 9807 does not describe this hand-over. It is therefore part of what an external party reviews before cryptography goes into operation with us.
  • A server that delivers the wrong code. In the browser, the program that processes your password comes from the same server. A manipulated server could deliver code that captures the password.
  • Mail apps. IMAP and SMTP do not know OPAQUE. That is what app passwords are for.
  • A forgotten password. We do not know it and cannot reset it. Without a recovery code the account cannot be restored; only a mail app that is already set up keeps reading with its app password.

Further reading