# Is the seed/salt input of a Key Derivation Function confidential?

I'm implementing a security protocol and for the key management a scheme is proposed using a key derivation function on the remote device. Thereby the input seed is uploaded in plaintext to the remote device. Now if both entities share the same masterkeys and generate sessionkeys from these masterkeys and the seed/salt, they derive the same sessionkey.

Now the thing I don't understand completely is that the random seed should be generated with a crypto-safe random generator, but can be uploaded in plaintext to the remote device. Is that true? And is that because from a cryptanalysis point of view, using a deterministic random seed would leak information about the masterkeys? As this is part of a thesis I would appreciate any literature on this.

Now the thing I don't understand completely is that the random seed should be generated with a crypto-safe random generator, but can be uploaded in plaintext to the remote device. Is that true?

Yes. The salt is used to make sure that you do not generate the same device key twice. The session key however still depends on the master key, so an attacker cannot generate the device key.

So the device keys will be unique and secure. The random number generator needs to be secure to assure the uniqueness. You'll need to extract a relatively large salt for that (say, 128 bits or 16 bytes for as good as complete uniqueness or 64 bits in case you like playing on the edge) for that as well.

Using a device-specific unique identifier is more common. The advantage of a (large enough) salt is however that you do not need state. You cannot by - accident or otherwise - use a the identifier for two or more devices. Usually the salt is used in addition to other derivation data, if used at all.

And is that because from a cryptanalysis point of view, using a deterministic random seed would leak information about the masterkeys?

No, no matter what, a KDF should never leak information about the master keys. This is why KDF's are generally either build on a block cipher - which of course protects the key - or a one-way hash functions / HMAC.

Notes:

• I would use the word "salt" instead of "seed" here. If used at all when talking about KDF's, the seed is generally the input seed or key, not the salt or any other derivation data.
• The HKDF RFC has a nice section on the use of a salt.
• It is strongly recommended - I would even say required - to authenticate the device keys after derivation as an attacker could otherwise distort the salt value or set it to a constant value; for this generate a MAC authentication tag over data known by both parties and return it to the server, which can then verify the data.
• Often multiple keys are required. Unless those keys rely on additional transmitted data you can use just the one key to authenticate the device; usually that's a MAC key or - even better - a separate key. Creating a set of device keys takes additional key derivation data, generally an ASCII label such as "MAC", "ENC" and "AUTH" or a number 00, 01 and 02.
• Thank you very much! I stumbled upon 'salt' as well but the proposed scheme said seed. Confusing :). The communication with the remote device shall be authenticated and the data the device sends encrypted. So you'd recommend using one sessionkey for generating the MAC and another for the encryption/decryption? – telina Nov 20 '17 at 16:37
• I'd recommend one key for authenticated encryption (GCM, CCM, EAX etc.) and possibly one for initial authentication. It's horrible to implicitly authenticate on the first message exchanged when it comes to developing an application; better do it explicitly as last step in the key exchange/agreement. Using the same key is possible, but beware that you don't muck up your protocol, e.g. by reusing the first init. vector. – Maarten Bodewes Nov 20 '17 at 17:27