Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In order to setup an authenticated shared secret key between two clients, I am faced with the choice between two possibilities:

  1. Let users set a (low-entropy) shared password and then perform some password-authenticated key exchange that is resilient to low-entropy secrets (as described here, for example).
  2. Generate a high-entropy shared key and use it directly as a shared key.

Are there any advantages to “1.”, especially when users must communicate the password/key through a separate channel in both cases?

Nota Bene: The resulting shared key is used only once per client (Alice $\rightarrow$ Bob and Bob $\rightarrow$ Alice) and subsequently destroyed.

share|improve this question
The problem is how would to generate the shared key without allowing impersonation. If you can do that securely, then go for it. Passwords are just a concession to the feeble human mind. – CodesInChaos Jun 29 '13 at 10:33
The advantage to A is that a password can be (significantly more easily) remembered. $\hspace{.7 in}$ – Ricky Demer Jun 29 '13 at 22:08
Do either of you care to put your comments as answers? – mikeazo Oct 29 '13 at 13:59
up vote 3 down vote accepted

Are there any advantages to “1.”, especially when users must communicate the password/key through a separate channel in both cases?

As the comments (1, 2) already indicated: the first option “1.” will be easier to communicate.

When you talk about a “high-entropy key”, I assume you are generating that high-entropy with a cryptographically secure random number generator. To make such a random piece of data easy to communicate among humans, you would need to convert it to something like Base64… which means “2.” will have a longer message which needs to be communicated between humans. The longer the message, the more room you’re providing for potential human error during that communication.

To keep human communication easy, you could stick to option “1.” and let users set a (low-entropy) shared password. You can always opt-in to a if you want to make it computationally more difficult to crack attack the user-chosen passwords.

Please note that I’m assuming you generate and communicate that shared key without allowing impersonation. If you don’t authenticate communication, no entropy in this universe is going to help.


I would advise to prefer PAK Diffie-Hellman (as described in RFC5683) because it additionally offers authentication, while sharing a high-entropy key without authentication merely provides more entropy… but not a single bit of security which could prevent impersonation () et al.

share|improve this answer
PAK D–H allows forward secrecy and an attacker would need to not only find the password, but then mount a man-in-the-middle attack. So, yes, it's a good idea. – otus Jul 29 '14 at 9:45

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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