Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

The RFC states the following:

3.2. The 'info' Input to HKDF

While the 'info' value is optional in the definition of HKDF, it is often of great importance in applications. Its main objective is to bind the derived key material to application- and context-specific information. For example, 'info' may contain a protocol number, algorithm identifiers, user identities, etc. In particular, it may prevent the derivation of the same keying material for different contexts (when the same input key material (IKM) is used in such different contexts). It may also accommodate additional inputs to the key expansion part, if so desired (e.g., an application may want to bind the key material to its length L, thus making L part of the 'info' field). There is one technical requirement from 'info': it should be independent of the input key material value IKM.

I'm still a little bit unclear on how to use this input. Does the 'info' input function as somewhat of a salt? If I'm developing a multi-user application, and each user:

  • uses HKDF to expand 16+ psuedo-random byes into a larger key
  • has a unique email address
  • uses the expanded key for a specific algorithm of their choosing

Would it be appropriate to use the user's email address, and the name of the algorithm for which the key will be used? Any analogies for better understanding the usage of this input would be appreciated.

share|improve this question
add comment

1 Answer 1

up vote 3 down vote accepted

No, the info is not a salt. The input key material for a KBKDF (key based key derivation function) should already be pseudo-random, and should therefore contain enough entropy to not need a salt.

If the user already has a unique 16+ pseudo-random bytes key then there is little reason to use the email address as part of the info. The email address could be used to make the derived key specific to the user, but that is already the case (in your example).

The main reason for a KBKDF is to create more keys or longer keys. You would need to use the algorithm name as part of the info when the algorithms would otherwise use the same key material.

The info is the key derivation data. You use identical input key materials to create multiple derived keys. The info makes the distinction between the keys. The KBKDF makes sure that the keys are indistinguishable from pseudo random numbers (and thus independent of each other).

Example uses: create a encryption and mac key from the same input key material (info is ASCII encoding of "ENC" and "MAC" or a counter value 1 or 2).

Another example: encrypt files with the same key without using an IV: input of the info part is the UTF-8 encoding of the file name.

share|improve this answer
    
According to the RFC, the IKM (input key material) listed in section 2.2 ('Step 1: Extract') is the key derivation data. The info parameter is defined as being optional. Also, section 3.1 stresses the importance of using a salt, stating that "the use of salt adds significantly to the strength of HKDF". Despite this - I think your answer makes sense. So I guess the info parameter is required only when using the same IKM for deriving multiple keys, in which case the info should contain data specific to that context. If anyone else has anything to add, I'd be interested to hear it. –  hunter Mar 3 '13 at 18:51
    
The IKM certainly is most important regarding the entropy within the derived key, but the info part should certainly be used to derive the different keys. As always, there's the issue with terms and definitions, I'll check out the HKDF (again, I've implemented the function) to see if I can make changes to make the answer use identical terms & definitions. –  owlstead Mar 3 '13 at 22:47
    
@hunter deriving multiple keys, or when there could be multiple protocols using the same material, and you want to avoid that an attacker can use a broken key (or encrypted messages) from one protocol in another one. –  Paŭlo Ebermann Mar 3 '13 at 22:48
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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