1
$\begingroup$

Sorry in advance as I am not very skilled in crypto. I am a software developer trying to create secure applications.

I have implemented a diffie-hellman key exchange between client and server. The library I am using only lets me create a minimum size key of 64 bytes (512 bit). During transport messages will be encrypted with an AES-256 cipher. This takes a maximum key of 32 bytes (256 bit).

Is it safe to use the first 32 bytes of the diffie-hellman generated key or does this create a hole in security?

I may be completely incorrect so please forgive me; AES-256 is a standard widely used encryption algorithm today and using a 32 byte key is secure. I didn't just wan't to the approach that "Because it works it must be secure"

$\endgroup$
  • 3
    $\begingroup$ Is there a reason you can't use a KDF? Anyway, you really should be using an existing library. It's not enough if you want a secure application to just use Diffie-Hellman and AES. You need to do a lot more. $\endgroup$ – forest Jul 26 '19 at 9:46
  • 4
    $\begingroup$ Also, it's 2019. Do not use 512-bit Diffie–Hellman! $\endgroup$ – yyyyyyy Jul 26 '19 at 9:47
  • 3
    $\begingroup$ @Harvey It's not enough because you should be using a library that handles all of this for you by itself, like libsodium. For example, are you using AEAD? Are you protecting from reflection attacks? What mode of operation are you using? How are you generating the nonce/IV? How is authentication performed? With a library like libsodium, this is all abstracted away from you so you don't have to worry about things lik eusing sequential vs random nonces for GCM (you are using GCM, aren't you?). Don't implement it on your own! $\endgroup$ – forest Jul 26 '19 at 10:17
  • 2
    $\begingroup$ @Harvey I'll be honest. I think you shouldn't be doing this. Because you're using the shared secret directly, I take it you don't have a MAC key, which means the encryption will be vulnerable to tampering. Please, unless this is just a toy project to learn a bit more about crypto, don't write your own protocol. $\endgroup$ – forest Jul 26 '19 at 10:25
  • 3
    $\begingroup$ @Harvey It's very good to ask the question. My point is that raw crypto libraries are often not very easy to use safely. For example CBC mode is very insecure without an HMAC, and an HMAC requires an extra key. $\endgroup$ – forest Jul 26 '19 at 10:44
5
$\begingroup$

Currently we do not think that 512 bit DH is secure. You can look for more secure parameters (i.e. above 1280 bits at the very least) is secure. Secure key sizes can be found at keylength.com. For DH you can e.g. look at the NIST recommendations for "Discrete Logarithm" (the underlying mathematical problem that is the base of DH-based cryptography).

Using Diffie-Hellman as base for AES-256 is a bit misleading, as it is not likely that your DH provides the same level of security as AES-256. As you can see in the tables DH requires a 15K key size (!!!) to reach the same security level. Claiming a security level of 256 bits would be unfair (but read the next section)


What DH generates is a shared secret. This shared secret has a lot of pseudo-randomness. As such it can be used directly by using the leftmost (or rightmost, but leftmost is more common) bits of the shared secret as a key. More information here (note the author of the question!). This is however not considered good practice, as you preferably do not want to have any bias of bits in the secret (AES) key.

So commonly we use a key based key derivation function (key based KDF or KBKDF) to condense (or extract) the pseudo-randomness of the master secret into one or more keys. That way each bit of the key depends on each and every bit of master secret material and removes any possible bias in the bits of the resulting secret key.

Quite often cryptographic API's offer combined key agreement / key derivation functions where a KDF is already used upon the result. Sometimes that means indicating a hash function, which is then used as (only) primitive within the KDF. The compression functionality within a hash is, as you might imagine, perfect for condensing the pseudo-randomness.

If you do not use a KDF then you might want to use a 256 bit AES key as it will have at least 247 bits of pseudo-randomness, as specified in the answer on my question. A 128 bit key will have less than 128 bits after all.

| improve this answer | |
$\endgroup$
  • 3
    $\begingroup$ This is a direct answer, but I agree with forest: using a ready made, well studied library that offers crypto on a higher level is a better idea than thinking up your own scheme. Even if you do require a very specific scheme, you'd be better off first studying existing ones. $\endgroup$ – Maarten Bodewes Jul 26 '19 at 10:24
  • 1
    $\begingroup$ Ugh, forgot about the bias in AES-128 if that was to be used. See? that's how easy it is to make stupid mistakes when creating your own scheme! $\endgroup$ – Maarten Bodewes Jul 26 '19 at 10:30
  • 1
    $\begingroup$ This is a well written answer. Clearly describing that you can do it. but shouldn't. A resewn why and what is good practice $\endgroup$ – Harvey Jul 26 '19 at 10:50

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.