Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Let’s Talk about PAKE (2018)

blog.cryptographyengineering.com

Post reply on HN
Print view View original

51–60 of 70 posts

Re: Let’s Talk about PAKE (2018)

#51

Post by cvwright »

tptacek wrote: post #48
cvwright wrote: post #29

Earlier quoted context omitted.

Yeah, sorry if my description wasn't clear. > It sounds like what you want is a password-based KDF, to derive keys clientside for the encrypted bundle. The encrypted blob containing E2EE keys is encrypted with a symmetric key that's derived from PBKDF2 on a passphrase. The problem is that standard password-based authentication exposes the login password to the server every time the user logs in. So if the user is laz…

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…

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.

Re: Let’s Talk about PAKE (2018)

#52

Post by amluto »

nly wrote: post #25
jimktrains2 wrote: post #24

Earlier quoted context omitted.

Not _all_ the benefits. PAKE doesn't share the password with thr server. I would argue the reason http auth failed is that there is no means of logging out, part of that is ui, part of that is protocol.

> PAKE doesn't share the password with thr server. The server has a password derivative stored. An SRP verifier for instance is computed from the password hash, so if the server is compromised the hacker can immediate impersonate the server or the password can be brute-forced offline. I believe OPAQUE is the same, just with stronger (slower) password hash functions in the mix.

If the server is compromised, of course the attacker can impersonate the server. With an _augmented_ PAKE (which OPAQUE is), the attacker cannot impersonate the client without a brute forcing step.

Re: Let’s Talk about PAKE (2018)

#53

Post by cvwright »

xyzzy123 wrote: post #42
cvwright wrote: post #29

Earlier quoted context omitted.

Yeah, sorry if my description wasn't clear. > It sounds like what you want is a password-based KDF, to derive keys clientside for the encrypted bundle. The encrypted blob containing E2EE keys is encrypted with a symmetric key that's derived from PBKDF2 on a passphrase. The problem is that standard password-based authentication exposes the login password to the server every time the user logs in. So if the user is laz…

I think you might as well client-side hash it under these circumstances? Like the "proper" answer is rethink your protocol, have 1 password and make everything not suck. Minimum (and achievable) job? Client side hash. Yes it's sh%tty JS crypto in the web case but you have legacy reasons you don't want plaintext even over SSL and you're not going to promise "military grade crypto" to anyone. It's explicable. You can u…

> The server can store a sha256 of the PBKDF2 output of your client hashing process or whatevs?

Before we started working on the PAKE thing, I actually kludged together something similar in my own client:

https://github.com/matrix-org/matrix-doc/pull/3265

Re: Let’s Talk about PAKE (2018)

#54

Post by tptacek »

cvwright wrote: post #51
tptacek wrote: post #48

Earlier quoted context omitted.

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…

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!

Re: Let’s Talk about PAKE (2018)

#55

Post by cvwright »

tptacek wrote: post #49
cvwright wrote: post #26

Earlier quoted context omitted.

So the two main problems with SRP, according to this post, are: 1. It exposes the salt and verifier to the adversary, enabling a brute-force search for the password 2. It relies on the discrete log problem, and is thus vulnerable to quantum computers In practice, I don't buy the argument that either one of these is a deal breaker, as long as you do SRP in a "modern" way, ie you're not tied verbatim to some 1997 versi…

I don't understand what you're trying to say here. It seems like you're saying that SRP is OK as long as you don't use SRP, but rather a modern PAKE, and then call it SRP. You're certainly not correct that the article is saying SRP is flawed because it "relies on the discrete log problem", as ECDLP-based PAKEs are also vulnerable to QC.

> It seems like you're saying that SRP is OK as long as you don't use SRP, but rather a modern PAKE, and then call it SRP.

No, that is not what I'm saying. The SRP paper says "Use a hash function to hash the password". When SRP was new, that might plausibly have been MD5, and if not, then probably something else like SHA-1 that is now unsafe. I'm saying, in 2021 use a hash function that doesn't suck for hashing passwords, like bcrypt or argon.

> You're certainly not correct that the article is saying SRP is flawed because it "relies on the discrete log problem", as ECDLP-based PAKEs are also vulnerable to QC.

Hmm good point. I must have interpreted the whole "Quantum annoyance" thing too strongly then.

Re: Let’s Talk about PAKE (2018)

#56

Post by tptacek »

cvwright wrote: post #55
tptacek wrote: post #49

Earlier quoted context omitted.

I don't understand what you're trying to say here. It seems like you're saying that SRP is OK as long as you don't use SRP, but rather a modern PAKE, and then call it SRP. You're certainly not correct that the article is saying SRP is flawed because it "relies on the discrete log problem", as ECDLP-based PAKEs are also vulnerable to QC.

> It seems like you're saying that SRP is OK as long as you don't use SRP, but rather a modern PAKE, and then call it SRP. No, that is not what I'm saying. The SRP paper says "Use a hash function to hash the password". When SRP was new, that might plausibly have been MD5, and if not, then probably something else like SHA-1 that is now unsafe. I'm saying, in 2021 use a hash function that doesn't suck for hashing passw…

No, that's not what the article is saying. It's saying that in addition to (1) being based on old multiplicative group cryptography, (2) lacking a security proof, and (3) not being built on a construction we already trust (Noise-KN) and instead its own weird protocol, it's also misuse-prone, because an easy state machine misstep that lots of people make gets you a server that allows offline password guesses.

Further, there's simply no reason to use it; there are better, equivalently simple protocols available. Even if you wanted to use simple multiplicative group DH math, the article points out, you could just instantiate BS-SPEKE on it; it even provides the formulae.

Nobody has "broken" SRP6a, just like nobody has really "broken" DES-EDE, or HMAC-MD5. But you clearly shouldn't be using any of them.

Re: Let’s Talk about PAKE (2018)

#57

Post by cvwright »

tptacek wrote: post #54
cvwright wrote: post #51

Earlier quoted context omitted.

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

Re: Let’s Talk about PAKE (2018)

#58

Post by cvwright »

tptacek wrote: post #56
cvwright wrote: post #55

Earlier quoted context omitted.

> It seems like you're saying that SRP is OK as long as you don't use SRP, but rather a modern PAKE, and then call it SRP. No, that is not what I'm saying. The SRP paper says "Use a hash function to hash the password". When SRP was new, that might plausibly have been MD5, and if not, then probably something else like SHA-1 that is now unsafe. I'm saying, in 2021 use a hash function that doesn't suck for hashing passw…

No, that's not what the article is saying. It's saying that in addition to (1) being based on old multiplicative group cryptography, (2) lacking a security proof, and (3) not being built on a construction we already trust (Noise-KN) and instead its own weird protocol, it's also misuse-prone, because an easy state machine misstep that lots of people make gets you a server that allows offline password guesses. Further,…

SRP never got a security proof?!? Wtf man?

I guess standards for publication have, uh, evolved a bit over the past 20 years.

Thanks for the explanation, this was helpful.

Re: Let’s Talk about PAKE (2018)

#59

Post by tptacek »

cvwright wrote: post #57
tptacek wrote: post #54

Earlier quoted context omitted.

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…

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.

Post reply on HN