2
$\begingroup$

I have an application where I need to combine a Diffie-Hellman shared secret, with a user's password and derive a key. I'm investigating the possibility of using HKDF to as follows

  • Initial Keying Material(IKM)= DHE-shared-secret and
  • salt = password-utf-8-bytes

I choose this because the DHE-secret is larger and, has more entropy than the password bytes. Is this correct or should it be the other way around?

$\endgroup$
  • $\begingroup$ I'm confused why you'd use both a DHE shared secret and a password to derive the key. Why isn't the shared secret enough to derive a strong key, without including the password? Isn't the password a secret private to just one party, rendering your derived key also so? In that latter case, why do you need a shared DHE secret? $\endgroup$ – Luis Casillas Jan 11 at 22:02
1
$\begingroup$

I'd say that if you'd use HKDF as it is supposed to, then you should concatenate the two the concatenated result as Input Keying Material (IKM). HKDF has an extract first which will compress the IKM so you can input as much keying material as required.

You should of course make sure that it is impossible to have collisions for concatenated secret and password pairs. This is easily accomplished by making sure that the DH secret is constant sized (which is best practice anyway).

It is always possible to later add an actual salt; a password is not unique across invocations and therefore it is unsuitable to be a salt. You may want to add a salt later to reach a higher security level and leave it empty for now.

You may want to first perform a password hash over the password and include the result in the HKDF calculation. The reason for that is that currently the other party of the key agreement must know the password in advance. It is better to store a password hash in case the other other party gets compromised.

With that in mind you may also be interested in SRP and other augmented PAKE protocols.

$\endgroup$
  • $\begingroup$ I'm starting with "I'd say" because HKDF is build on HMAC, and as such inherits a lot of the sturdiness of HMAC. It is likely - but probably not proven - that if you switch around the input parameters that the result is still secure. It's therefore probably more for reasons of good design practices to use it correctly. $\endgroup$ – Maarten Bodewes Jan 11 at 10:34
  • $\begingroup$ Thanks for your reply. I did look PAKE protocols such as EKE. I will look at SRP as well. $\endgroup$ – wbibile Jan 11 at 13:47
  • $\begingroup$ EKE is balanced; i.e. you need access to the same secret on both sides, so you won't get the benefits of augmented PAKE as explained in the Wikipedia article. $\endgroup$ – Maarten Bodewes Jan 11 at 14:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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