I've been using Diffie-Hellman (although, now looking into SRP) for sending data encrypted between two hosts. After the initial handshake, both the end hosts have generated the same shared secret. So, I immediately made the assumption that the shared secret can be used as a "password" in a cipher, since, I can safely assume that only the hosts will know about the secrets, and no one else. But that was purely out of my own assumption, that is without consulting anyone who is actually seasoned in information security.

I was hoping some of you can give me an idea about what to do once the shared secret has been generated. Is it a password for a cipher? Or must I take an additional step?

  • It's better to use it as the input for a KDF. Personally I'd choose HKDF and use it to derive the necessary keys. (At least one key per direction. Possibly one encryption and one MAC key for each direction). Mar 13, 2014 at 22:27
  • @CodesInChaos: thanks. The first part makes sense. I could maybe use PBKDF2 with the shared secret as the "password", while also explicitly requesting a 128-bit key length, and use the derived key for--say--AES. As for the suggestion about HKDF, I'm lost, because I'm a beginner. Any help?
    – Sal Rahman
    Mar 13, 2014 at 22:50

1 Answer 1


It's "secret" enough to be used as the key to a cipher, but it might not be long enough. The concept of key stretching was invented to bridge that gap. Basically you run the small secret through a cryptographic function to create a big secret.

An algorithm specifically designed for this function is PBKDF2 ("password-based key derivation function version 2"). It does very much precisely what you're looking for. You can use this same algorithm with slightly varied inputs to create multiple independent keys.

  • Thanks for the answer. In my question, though, @CodesInChaos commented that he suggests using HKDF and derive the necessary keys. I'm not doubting that what he says is relevant. The more secure, the better. But I'm just not sure what he meant by that. Any thoughts?
    – Sal Rahman
    Mar 13, 2014 at 23:47
  • @skizeey yes, he certainly is a fan. I suggested PBKDF2 because HKDF is very new and implementations are not as easy to find (or not as well-vetted). But it's a good solution. Though honestly you're just turning one secure secret into another, so the security implication isn't huge. A single pass of SHA1 is good enough for 99.99% of cases.
    – tylerl
    Mar 13, 2014 at 23:59
  • If your particular PBKDF2 native cipher has a length equal to or greater than the key(s) you need, you're already good. For instance, PBKDF2-HMAC-SHA-512 already natively provides you with two 256-bit or four 128-bit keys. @CodesInChaos, please clarify, but I believe you have specifically recommended using a HKDF on the KDF output if more bits than the native hash size are required, because that particular case gives the attacker a greater margin of advantage over you, the defender. Mar 14, 2014 at 2:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .