0
$\begingroup$

Password-authenticated key exchange (PAKE) is a method in which two or more parties, based on their knowledge of a shared password, establish a cryptographic key using an exchange of messages, such that an unauthorized party (one who controls the communication channel but does not possess the password) cannot participate in the method and is constrained as much as possible from brute-force guessing the password.

source

Could someone please explain why the parties want to establish a common session key, why is knowing a common password not enough?

$\endgroup$
8
  • $\begingroup$ You quoted Wikipedia (I added the link), but did you check out the reference in that paragraph? It's to a paper. 1st line of the 2nd paragraph: "However, passwords are low-entropy secrets, and subject to dictionary attacks..." The answer is simply: keys are much harder to crack. $\endgroup$
    – schroeder
    Commented Jul 8 at 15:31
  • $\begingroup$ “Knowing a common password” isn’t a cryptographic algorithm. If two parties want to exchange confidential messages, they have to actually do something with the password. So what did you have in mind as an alternative to establishing a session key? Depending on how exactly the password is used, this will lead to different desirable and undesirable properties of the algorithm. $\endgroup$
    – Ja1024
    Commented Jul 8 at 15:50
  • $\begingroup$ @Ja1024 a key is not an algorithm either. So, why a key over a password when a password is required anyway? $\endgroup$
    – schroeder
    Commented Jul 8 at 16:02
  • $\begingroup$ @schroeder: Establishing a key is an algorithm. If the OP wants to use a password-based key deriviation function to directly calculate a key from the password, then we can talk about which problems come with that and how they’re solved in modern PAK protocols. But discussing “passwords vs. keys” makes no sense – passwords generally cannot be used as encryption keys, so it’s almost always necessary to derive a key from the password. $\endgroup$
    – Ja1024
    Commented Jul 8 at 17:34
  • $\begingroup$ @Ja1024 I think the concept the OP is missing is the functional difference between a password and a key and why a password can't be used in place of a key. If using PBKDF, why not just use the password? What does PBKDF offer more than a brute-force-resistant password or a "stretched" password? If we can address that, I think we'll have a solid answer. $\endgroup$
    – schroeder
    Commented Jul 8 at 20:55

2 Answers 2

0
$\begingroup$

Could someone please explain why the parties want to establish a common session key, why is knowing a common password not enough?

A direct answer here is that since this is about Password-Authenticated Key Exchange protocols (PAKE), this is what these protocols are designed to do... Namely, established a session key that is for example appropriate to use with a secure channel protocol.

Expanding a bit to give further intuition into the goal of PAKE protocols. Consider this context: users who share nothing more than passwords want to establish a secure channel. Here, passwords mean easily guessable information. One way to capture this is that all possible values of user passwords come from a dictionary $D$ that is easily enumerated by practical attackers. If these passwords are high entropy like cryptographic keys, there are other protocols. ¨ On sessions. In the real world, users establish many secure channels. That is, one client may have many concurrent secure channels with one or many other users. Therefore, we will need to consider security guarantees across sessions.

What kind of guarantees are desirable? If we are going to build secure channels by authenticated key exchange with passwords, then we'll want to have some of the same guarantees that we expect from similar protocols. Something to stress here is that secrecy isn't the only goal for session establishment; authentication is just as important. The basic guarantees we would like to have:

  • Session key security: the key should be indistinguishable from random.
  • Mutual and session key authentication: At the end of each session, users should have authenticated each other, have the same view of who is talking to whom, and agree on the same key for this session.
  • Forward secrecy: Past session (finished) keys should remain secret even if the password is revealed at some point.

What can't we expect when working with passwords: The dictionary is small, and the attacker can enumerate it. A naive protocol that just applies a key derivation function to the password and uses it as a session key is vulnerable to an offline dictionary attacker. And for any other protocol, the attacker may simply interact with a party and try to guess their passwords. After so many interactions, the attacker will likely guess the password. This is an online dictionary attack.

So, this is the basic guarantee of PAKEs: the best an attacker can do is an online dictionary attack. In practice, rate limiting can be implemented along this kind of protocol to enhance security.

Some PAKEs consider an even stronger attacker who could steal password hashes from a server and then try to impersonate users. In such a scenario, we would like to guarantee that the best an attacker can do is an offline dictionary attack. Such an attack is always feasible but can be more painful in practice with a slow, memory-hard password hashing function.

Remark: The last paragraph does not endorse naive approaches. Again, simply using a deterministic function of the password as a session key is not a good protocol, even if the function is a slow hash. For one thing, forward security is not guaranteed.

$\endgroup$
1
  • $\begingroup$ Thank you very much! $\endgroup$
    – yolooow
    Commented Jul 12 at 14:52
1
$\begingroup$

For forward secrecy.

Consider the situation when someone records the encrypted messages and then later learns the password. If the messages are encrypted with the password, they can decrypt them as soon as they learn the password. If they were encrypted with a password authenticated key, they cannot.

$\endgroup$
3
  • 1
    $\begingroup$ But won't knowing the password allow you to unlock the key in the future? $\endgroup$
    – schroeder
    Commented Jul 8 at 15:47
  • $\begingroup$ @schroeder, it all depends on how the session key is established. If $k = H(pwd)$, then yes, no forward secrecy is expected. But consider a protocol that additionally uses ephemeral Diffie-Hellman and computes the session key by doing something like $k = H(pwd, g^x, g^y, g^xy,...)$. Then, intuitively, the password alone doesn't help when the $x$ and $y$ have been long deleted. $\endgroup$ Commented Jul 10 at 13:32
  • $\begingroup$ @MarcIlunga that's what I was thinking, but the way it was described, it didn't exclude that simple use case. $\endgroup$
    – schroeder
    Commented Jul 10 at 15:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.