2

Background: I'm working with Node's crypto library. I'm using PBKDF2 to convert a variable-length binary "passphrase" into constant-length keys for an AES cipher later on.

The underlying source of this passphrase data, for reasons out of my control, is encoded with base64. Out of habit, I decode the passphrase back to binary before supplying it to PBKDF2. But that got me thinking... Base64 encoding makes the passphrase longer, but with a more limited set of characters. In practical applications, would this make the data better or worse as an input to PBDKF2?

Put another way, if given a choice between:

key = pbkdf2(binaryPassphrase)

...versus...

key = pbkdf2(base64encode(binaryPassphrase))

...is there any difference in the security offered?

1
  • 1
    It makes no difference. The strength is in the entropy of the passphrase, not in its length. The entropy is a measure of the process by which the passphrase was generated, and is not measurable from the passphrase itself after the fact. That said, I would personally decode it from Base64 out of habit and a sense of conceptual purity (e.g., perhaps later the source send you passwords in Base32 or some other encoding). Jan 7, 2014 at 19:22

1 Answer 1

2

Between

key = pbkdf2(binaryPassphrase)

and

key = pbkdf2(base64encode(binaryPassphrase))

there is no difference in amount of security provided. The base64 encoded passphrase is longer input, but it is based on exactly the same amount of entropy and thus offers no additional security.

The pbkdf2 function takes practically same time to execute with either input (unless binaryPassphrase is multiple kilobytes or more). The only significant difference will be that the resulting keys derived will be different.

6
  • Makes sense. I suppose it doesn't matter that base64 adds a predictable pattern to the input (i.e. every high bit is 0)?
    – smitelli
    Jan 7, 2014 at 19:22
  • PBKDF2 is just an iterated hash function, and it's generally considered that one of the effects of a good hash function is to evenly distribute entropy. For instance, if I have a string that contains four zero bytes followed by four random bytes, the first four bytes have zero entropy and the latter four have 32 bits of entropy in total. If I then hash this string (to an 8-byte output), each byte should now have roughly 16 bits of entropy (and the string as a whole will still only have the original 32 bits of entropy). Jan 7, 2014 at 19:25
  • @StephenTouset: PBKDF2 is based on iterated invocation of HMAC. HMAC is considered good randomness extractor ("crypto talk" name for something that is good for retaining entropy available in input). For more information, you can read e.g. Randomness Extraction and Key Derivation Using the CBC, Cascade and HMAC Modes. (Then again, HMAC is indeed based on hash functions.)
    – user4982
    Jan 7, 2014 at 19:31
  • Yes, I am familiar with PBKDF2. As you note, it is built on HMAC which is constructed from an underlying hash function. That hash function is what is responsible for evenly distributing the entropy in the passphrase. This property is not, AFAIK, necessarily a property of other MAC constructions. Jan 7, 2014 at 19:55
  • @StephenTouset: In application of randomness extraction, HMAC is even stronger than usual use of hash. Hugo's paper on HKDF contains much detail. (Most) other MACs are indeed worse (the paper I referenced in fact also tells that), and PBKDF2 does not allow anything except HMAC (unlike e.g. NIST SP 800-108 and SP 800-56C, which approve AES-CMAC as alternative for HMAC).
    – user4982
    Jan 7, 2014 at 20:26

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.