Return to Answer

You don't need a salt (it defaults to a zero length salt) if you generated the session keys using Diffie-Hellman. You should however use a different info (octet) string for each key in the expand part of the function.

The idea is that the salt makes sure that the derived keys are different if the input keying material (IKM) repeats. If no salt is used within the key derivation then the session keys would be identical each time the key derivation function is performed. Diffie-Hellman however should never generate identical input keying material (see note).

The info strings should be static for each key, e.g. an ASCII encoding of "enc" for an encryption key would be a good idea.

Here's a link to the RFC for HKDF. Here's a link to Hugo Krawczyk's paper describing HKDF at length.

Note: at least one of the parties in the DH key agreement should generate sufficiently random ephemeral key material. If the random number generator (RNG) is broken then you may get identical input key material. It is not possible to generate a random salt if your RNG is broken though. In other words, you need a good RNG whatever you do.

You don't need a salt (it defaults to a zero length salt) if you generated the session keys using Diffie-Hellman. You should however use a different info (octet) string for each key in the expand part of the function.

The idea is that the salt makes sure that the derived keys are different if the input keying material (IKM) repeats. If no salt is used within the key derivation then the session keys would be identical each time the key derivation function is performed. Diffie-Hellman however should never generate identical input keying material (see note).

The info strings should be static for each key, e.g. an ASCII encoding of "enc" for an encryption key would be a good idea.

Here's a link to the RFC for HKDF. Here's a link to Hugo Krawczyk's paper describing HKDF at length.

Note: at least one of the parties in the DH key agreement should generate sufficiently random ephemeral key material. If the random number generator (RNG) is broken then you may get identical input key material. It is not possible to generate a random salt if your RNG is broken though. In other words, you need a good RNG whatever you do.

You don't need a salt (it defaults to a zero length salt) if you generated the session keys using Diffie-Hellman. You should however use a different info (octet) string for each key in the expand part of the function.

The idea is that the salt makes sure that the derived keys are different if the input keying material (IKM) repeats. If no salt is used within the key derivation then the session keys would be identical each time the key derivation function is performed. Diffie-Hellman however should never generate identical input keying material (see note).

The info strings should be static for each key, e.g. an ASCII encoding of "enc" for an encryption key would be a good idea.

Note: at least one of the parties in the DH key agreement should generate sufficiently random ephemeral key material. If the random number generator (RNG) is broken then you may get identical input key material. It is not possible to generate a random salt if your RNG is broken though. In other words, you need a good RNG whatever you do.

You don't need a salt (it defaults to a zero length salt) if you generated the session keys using Diffie-Hellman. You should however use a different info (octet) string for each key in the expand part of the function.

The idea is that the salt makes sure that the derived keys are different if the input keying material (IKM) repeats. If no salt is used within the key derivation then the session keys would be identical each time the key derivation function is performed. Diffie-Hellman however should never generate identical input keying material (see note).

The info strings should be static for each key, e.g. an ASCII encoding of "enc" for an encryption key would be a good idea.

Here's a link to the RFC for HKDF. Here's a link to Hugo Krawczyk's paper describing HKDF at length.

Note: at least one of the parties in the DH key agreement should generate sufficiently random ephemeral key material. If the random number generator (RNG) is broken then you may get identical input key material. It is not possible to generate a random salt if your RNG is broken though. In other words, you need a good RNG whatever you do.

You don't need a salt (it defaults to a zero length salt) if you generated the session keys using Diffie-Hellman. You should however use a different info (octet) string for each key in the expand part of the function.

The info strings should be static for each key, e.g. an ASCII encoding of "enc" for an encryption key would be a good idea.

You don't need a salt (it defaults to a zero length salt) if you generated the session keys using Diffie-Hellman. You should however use a different info (octet) string for each key in the expand part of the function.

The idea is that the salt makes sure that the derived keys are different if the input keying material (IKM) repeats. If no salt is used within the key derivation then the session keys would be identical each time the key derivation function is performed. Diffie-Hellman however should never generate identical input keying material (see note).

The info strings should be static for each key, e.g. an ASCII encoding of "enc" for an encryption key would be a good idea.

Note: at least one of the parties in the DH key agreement should generate sufficiently random ephemeral key material. If the random number generator (RNG) is broken then you may get identical input key material. It is not possible to generate a random salt if your RNG is broken though. In other words, you need a good RNG whatever you do.