# Can PBKDF2 be used to create an XOR cipher key to encrypt random plaintext?

I want to encrypt a truly random plaintext (a key file) based on a user password. I'll use PBKDF2-HMAC-SHA256 to generate an encryption key from the password, but I'm wondering if I even need to bother with AES or some other cipher: can I expect good security if I just use PBKDF2 to generate a key equal in length to the plaintext, and XOR them together?

-
At best you'll get a stream cipher, not a one-time-pad. An OTP needs to be truly random, not pseudorandom. –  CodesInChaos Sep 18 '13 at 7:50
@CodesInChaos: That's true, but I didn't say anything about an OTP =). I think someone else added that tag, I just removed it. –  sh1ftst0rm Sep 18 '13 at 10:32
You put OTP into the title of the question... –  CodesInChaos Sep 18 '13 at 10:52
Ugh, sorry about that. I guess I was using it in a kind of colloquial way, but you're right, it's obviously not a real OTP. –  sh1ftst0rm Sep 18 '13 at 12:02

I would use an encryption method designed for the purpose, such as AES Key Wrap.

That said, PBKDF2 uses a PRF internally, so if you specify an iteration count of 1, your suggestion would effectively amount to using a PRF in CTR mode. Since you put the question that way, then, yes, it would be good enough, in the sense that the weakest link would probably be the password and not the encryption scheme.

Edit: Using the PBKDF derived key as a key stream, rather than as a key for a proper symmetric cipher, would obviously require you to treat the Salt value as a nonce (i.e. it has to be different each time you perform the encryption operation). This is not strictly necessary if you use AES in a secure mode of operation - in such case you would get away with leaving the Salt unchanged, but you would OTOH, depending on which mode of operation you use, might have to set the initial state of the mode of operation to a Nonce value. If you use AES Key Wrap, the initial state is a default constant, but for e.g. CTR mode it would be essential to set the initial counter to a nonce.

-

No it cannot be used to create an OTP as the technical definition of OTP requires that the pad be truely random and the output of PBKDF2 is not true random, only pseudo-random.

Of course you can generate a large pad from a password and xor it with your random plaintext. What you lose though are strong security guarantees. AES has been hammered at by really smart people for a long enough time that we generally accept it as secure. Your protocol, however, has not been analyzed by anyone. I personally wouldn't feel comfortable using it given that fact.

-
Well I'm not inventing a new protocol here, it's really just a question about the security of pbkdf-2: are there any known weaknesses that would lead to security problems in this application? –  sh1ftst0rm Feb 29 '12 at 18:49
@bmearns, but you are inventing a new use of a protocol, which I called a new protocol. As to known weaknesses, there are no known weaknesses to PBKDF2 when used as a password based key derivation function. It is not known if there are any weaknesses when using PBKDF2 as a stream cipher as no one I'm aware of has studied it in that context, which is why I would avoid it. –  mikeazo Feb 29 '12 at 19:06

Don't. Just don't.

You are indeed perceptive enough to note that if the output of PBKDF2 is truly pseudo-random, then XORing it onto data is as secure as the password is. But don't. Really. It's not good hygiene. A KDF is a Key Derivation Function, not a cipher. It's not designed to be used as a cipher, so don't use it as one. Use it to derive keys that you then encrypt with. It's just safer that way.

PBKDF2 is a wrapper for key generation using a string and a PRF (pseudo-random function). You can use any PRF, be it a hash function or a cipher, but hash functions have a nice property of being one-way, and HMACs are a way to strengthen hash functions for purposes such as these.

Nonetheless, if you XOR the PBKDF2 output on your plaintext, you are relying on the security of the hash function for your whole security. If there are itsy-bitsy flaws in the construction that you don't know about, then there are flaws in your crypto. Any bias, non-randomness, distinguisher, and so on is a flaw in your system.

But if you derive a key that can be (e.g.) distinguished from random but nothing more and then throw that into a secure cipher, you have buffered your security by using the staged implementation.

If you need a practical reason, then here's one -- ciphers are faster than hash functions. If you're encrypting data longer than one hash block, then it's faster to use a cipher. Does that make you feel better?

(I'll also add that back in The Crypto Wars, there were plenty of us who noted that you can turn a hash into a cipher pretty much as you described. We don't do that today because of speed and because of crypto hygiene. Use the functions for what they're designed for.)

Jon

-
Well I guess that's really my question, isn't it? Are there any such weaknesses, (biases, etc) in PBKDF-2 as I've described? I see your point (and everyone else's) that neither it, nor hash functions, were designed for this and so haven't been tested for it, and so maybe they have weaknesses, maybe they don't, but noone's really looked into it. Thanks for the input. –  sh1ftst0rm Mar 19 '12 at 18:03
A year after this answer was written, here I come. How would you define crypto hygiene? Why, since PBKDF2 has the same properties of randomness required by a stream cipher, should not be used for one? I understand it wasn't designed for that purpose which may have some practical implications, but in theory, why does that matter? I'm sorry I don't agree with your answer. I find it half-complete and leaning towards a "polemic" that isn't properly explained. Could you please clarify? –  rath Sep 18 '13 at 6:23
@rath: Indeed, if the PBKDF doesn't produce pseudo random output because the internal function used as the "PRF" has a flaw, the crypto would be broken even if the derived key was used for a proper symmetric cipher. –  Henrick Hellström Sep 18 '13 at 7:38