#opaque protocol

[mentalisttraceur-software]

So if I was to implement asymmetric password logins right now as a learning exercise or proof of concept, I would use Argon2id for key derivation, Ed25519 for signatures, and Ristretto255 for the OPRF.

The thing is, I would really like to get very secure parameters for Argon2id, but even a mere time factor of three with one lane using 256 MiB of RAM costs one to three seconds on recent browser versions on recent hardware with high end specs. That's just for the Argon2id itself.

Of course, if I knew it was making my password resistant to cracking even by state-funded purpose-built ASIC farms, you could make me wait ten seconds to log in and I'd feel pretty good about it. But typical users might start dropping off after half-second delays, and if you can be so responsive that it feels instant, that matters a lot.

Also you could easily create a really nice interface which progressively loads and renders all the UI elements that don't reveal sensitive information while the password verification is happening. If you have an implementation of Argon2id which has hooks or incremental outputs for progress reporting, then you could even accurately and precisely show progress.

So another reason why it's worth carefully looking at OPAQUE is that I'm sure all that stuff it does is actually more performant, much more responsive.

[mentalisttraceur-software]

The most glaring difference to me between OPAQUE and the asymmetric passwords improvement I just described (using an OPRF to avoid ever revealing the salt), is that OPAQUE has an entirely different password setting ("registration") step, extra stuff like a key exchange and per-session information, and a separate private key for the user which is stored encrypted on the server and is decrypted by the key derived from the password at every login.

This is where we reach the edge of my current understanding. I am not confident enough in my cryptographic chops to dare say OPAQUE adds excess stuff here. But I do have the temerity and conceitedness to tentatively think that maybe we don't need all that extra stuff to have secure asymmetric password authentication.

Notably, OPAQUE is trying to achieve more than just authentication - it is a PAKE, emphasis on the KE: key exchange.

But I've often thought that the next natural step once you have asymmetric passwords for login is to use that password-derived key for signing and encryption more generally. Of course then you have to start worrying if it's okay to use keys derived from the same password for signing and for encryption. More importantly, you also quickly realize that you want to minimize what a password-derived key encrypts to just one intermediate encryption key which encrypts everything else - otherwise a password change becomes an O(n) operation where you decrypt and re-encrypt every single thing encrypted by a key derived from that password.

So maybe if we did all that and tightly integrated it into one scheme, we'd end up with something that does everything OPAQUE does.

And of course there's the risk that I'm just missing vulnerabilities which OPAQUE covers and my idea doesn't. It is best to assume I lack the experience and imagination to see the full space of relevant possible ways information can leak from a system and ways an attacker with some visibility or influence could exploit things.

[mentalisttraceur-software]

OPAQUE has security properties above and beyond the advantages I'm looking for from asymmetric password logins over normal password logins, and I'm not yet at the level where I can fully judge the need for all of them.

So if you're implementing asymmetric password logins, I'm not saying "just implement OPAQUE or something like it", I'm saying it is worth it to look at OPAQUE in case it has relevant advantages that I'm missing. That's what I've been doing lately just to get a better grasp on what's available, but maybe the conclusion I will eventually come away with is "OPAQUE is overkill".

But the danger is that I'm not a professional cryptographer. I try to approach this kind of stuff carefully, with the presumption that I'm missing something, because many smart cryptographers have being putting a lot of work into this problem space for longer than I've been alive. There is a real risk that buried in the graveyard of discarded challenge-response login algorithms we can find something very similar to my idea for how to do asymmetric passwords so far.

[mentalisttraceur-software]

A mature, robust, well-designed version of the asymmetric passwords idea probably looks more like the OPAQUE protocol.

OPAQUE seems to share the same goals of password logins between client and server without ever exposing the password, which has been carefully designed and vetted by actual experts in the current state of the art. It has security advantages over what I've described, I'm sure including ones I haven't even thought of yet.

My asymmetric passwords posts should be seen as me trying to build up the idea "from scratch". In the vein of "to really understand something you must independently discover/invent it".

The goal with these "asymmetric password" posts is to

name the overall idea in a more general and accessible way (the general idea is passwords without ever exposing the password; deriving keys for asymmetric cryptography from passwords - however that's implemented),

show that general vision of what's possible in a way that's accessible (by starting with a sketch that might be flawed but requires much less cryptography knowledge), and

flesh out that vision in my own mind (I can see the outline of how I'd implement what I've described so far, but I can't yet see the outline of how I'd implement OPAQUE).

Maybe when I'm more fluent in the technical details of something like OPAQUE, my concise initial description of it will no longer need to mention a server sending a salt to a client.

In the meantime, if you're seriously considering implementing asymmetric password logins or have the time, I recommend taking a look at OPAQUE.