9
$\begingroup$

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.

$\endgroup$
3
  • 1
    $\begingroup$ 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. $\endgroup$ Jun 29, 2013 at 10:33
  • 1
    $\begingroup$ The advantage to A is that a password can be (significantly more easily) remembered. $\hspace{.7 in}$ $\endgroup$
    – user991
    Jun 29, 2013 at 22:08
  • 5
    $\begingroup$ Do either of you care to put your comments as answers? $\endgroup$
    – mikeazo
    Oct 29, 2013 at 13:59

1 Answer 1

4
$\begingroup$

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.

TL;DR

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.

$\endgroup$
1
  • 1
    $\begingroup$ 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. $\endgroup$
    – otus
    Jul 29, 2014 at 9:45

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.