I am having trouble following the security design here. If the server ever decrypts this data, it doesn't matter how you store the keys. If it doesn't, the encryption keys never need to leave the client.
I think you need to start by very clearly defining the security model you are trying to design, and then start talking about constructions to throw at it.
I don't know what the shrug means, but you shouldn't use SRP in a 2021 design.
The shrug was that it’s weird to call something dead when it never really took off in the first place.
> you shouldn’t use SRP in a 2021 design
Ok I guess I’ll take your word for it. Which PAKE should we use instead? This is the perfect time to change our plans, since we haven’t really built anything yet.
I'm still not clear on what the PAKE is doing here, or what's being decrypted where. The problem with a PAKE between clients and servers, especially if based on the same password as the root secret for your system, is that it depends on storing a password-derived verifier on the server. That's almost never OK!
I think this gets at the root of the confusion. Talking through this has been helpful, so thanks.
So the main thing is that apparently using a PAKE is not sufficient by itself. Not revealing the password at login time only solves part of the problem.
The second requirement is that the PAKE’s “password related string” that it learns and stores must be something that does not reveal (significant information about) the password itself.
I had assumed that that was a baseline “table stakes” kind of requirement for an authentication protocol in the 2020’s, but apparently that’s not part of the definition here(?)
As to your comment about using the same password to create the verifier and the encryption key, I agree it’s not ideal. But in the real world, what practical alternative do we have?
We have password hashing functions that are pretty good at making password cracking impractical. We should use them and trust them to do their job.
As long as the verifier comes from a hash that makes finding preimages prohibitively expensive (ie, a PHF), then it seems like there’s room to work here.
Or if you have better ideas, I would love to hear them. (Not being snarky here - it would actually be good to get input from someone who works on this stuff.)
I'm still not clear on what problem you're trying to solve, but if you have a messaging system with root secret password that's used to protect message confidentiality, you cannot have information about that password stored on servers. The verifier a PAKE uses to check password validity in an augmented PAKE reveals information about the message-protecting password.
Maybe I'm unclear about the application here! But what I'm reading is a proposal in which the deployment of a PAKE could make the system drastically less secure on the whole.
I think you need to start by very clearly defining the security model you are trying to design, and then start talking about constructions to throw at it.
I don't know what the shrug means, but you shouldn't use SRP in a 2021 design.