Is it possible for a client to send a blinded password to a server, so that the server does key derivation+stretching on that blinded value, but the key can then be unblinded by the client?
Clarifications
I'm using "blinded" the way it is used in an "oblivious pseudorandom function" (OPRF) like Ristretto255.
Usually I see Argon2id called a key derivation function, but in some contexts there is another key derivation function in play, and Argon2id is referred to as a key stretching function. I'm happy to learn the formal precise differences between "derivation" and "stretching", but what I care about making oblivious to the secret is the parts of Argon2id with deliberately large costs (or anything with comparable security), regardless of what we call that.
Motivation
So we already have "oblivious salting" by using an oblivious pseudorandom function (OPRF). This is used in asymmetric password authentication schemes (where the client never shares the password with the server), to allow the server to provide a salt without giving it freely to any attacker who "asks" by starting an attempted login. See for example the OPAQUE protocol.
But one downside of something like OPAQUE versus traditional password logins, is that since key stretching runs on the client instead of the server, parameters for the KDF/KSF have to be weak enough that the weakest client can still provide acceptably fast user experience when logging in.
For example, Argon2id with one lane, 16 MiB of memory, and three iterations, in the browser, takes ~250ms on a Pixel 5, but ~1400ms on a Samsung Galaxy 5s.
From a security perspective, I'd love to throw even larger parameters into Argon2id, even though OWASP recommendations considers my parameters above the acceptably safe minimum when I last checked.
But from a user experience perspective, I would hate to have a user login from slower hardware or a resource-constrained multitasking system and have to sit there for many seconds during login while their device struggles through a high cost Argon2id execution.
(And the same user might log in from devices with large capability disparities - one user might have a high-end gaming desktop but not want anything above a cheap low-end smartphone - if they're logging into the same website or app from both, then doing key stretching on the client means you still only get the security of the weakest key stretching parameters that give an acceptable performance and security balance.)
So! If we could do an oblivious KDF/KSF, then we can still have users benefit from a server with expensive hardware investment which can run the KDF/KSF with much larger costs than would be reasonably fast on typical clients.
