#opaque protocol

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.

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.

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".

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.