5

Ordinarily I'd use PBKDF2 to generate a key which i'd use with AES. But seeing as the hash is going to be as long as the data I need to encrypt is there any disadvantage to just XOR'ing it?

My reasoning is if you can derive the hash you would have the AES key anyway.

*Just to add the reason I would use PBKDF2 is it has to use a user provided password. The data being encrypted can be considered random. I am also salting.

  • 1
    Why don't you want to use AES? Performance? – Neil Smithline May 14 '15 at 20:10
  • What would it gain me (hence the question)? I have no issue using it. But if I don't gain anything from it then not using it simplifies my code, would expand the binary & gets rid of a dependency. – Hector May 14 '15 at 20:14
  • 2
    "What would it gain me" - It gains you from trying to design and implement your own crypto. – Neil Smithline May 14 '15 at 20:19
  • 1
    Dave is that you? – Lucas Kauffman May 14 '15 at 20:27
9

By using PBKDF2 that way, what you are really doing is turning PBKDF2 into a stream cipher. The three main problems with this idea are:

  1. Use of PBKDF2 as a stream cipher has not been thoroughly investigated. It may be fine. Or not. Security properties of PBKDF2 have been analyzed for mostly short outputs only, and then, only as a KDF.

  2. If you reuse the same password and salt, then you get the same output. In a stream cipher XOR-with-the-data mode, this is very bad if you encrypt two elements. In that sense, you have now merged the PBKDF2 salt with what was the IV for AES, thus conflating the requirements. You'd better make sure that your overall protocol deals properly with that. (In that sense, this is similar to using PBKDF2 to generate a key for RC4 encryption, because RC4 has no IV.)

  3. PBKDF2 is made slow with iterations. It so happens that its processing speed is also proportional to the requested output length. If you use PBKDF2/SHA-1 and ask, for, say, 24 bytes, and use 10000 iterations, then you will actually pay for 20000 iterations. This can quick become intolerable for longer messages to encrypt. Take note that the attacker who runs a dictionary attack does not need to compute the whole stream; thus, you incur the risk of needlessly slowing the defender while letting the attacker run at full speed.

  • concerning point 1: Shouldn't it be as secure as if HMAC/HKDF was used directly for this purpose? – SEJPM May 14 '15 at 20:23
  • 2
    I think that there no "longer messages". Question is about encrypting a 32-byte value only. – Neil Smithline May 14 '15 at 21:21
1

Yes. Because of known-plaintext-attacks, a adversiary that can find out the plaintext, could use that to find out the hash to decrypt ciphertexts that the adversiary does not have the plaintext to.

AES is specifically built to prevent a attacker from finding out the key, even if he knows both the plaintext and ciphertext.

If you want to gain performance and still use XOR, it would be suitable to add random charachters to the password, and then include these chars with the message.

Eg, to encrypt M, you generate a random nonce N. Then you use: PBKDF2( Password + N) xor M = C

Send NC to recipient

NC is decrypted by picking out the nonce, and then the recipient supplies the pre-shared password, so

PBKDF2( Password + N) xor C = M.

To find out the key for a message encrypted with XOR + PBKDF2(Password + A ), and have a plaintext and ciphertext belongning to PBKDF2( Password + N ), he would still have to crack the PBKDF2 by using plain bruteforce.

  • I'm salting my hashes with a unique salt. So if you knew the plain-text then you could identify the hash that was used to encode it. But that hash would be unique to that password & salt combination. Surely its safe as long as the salt isn't reused? – Hector May 14 '15 at 20:10
  • doesn't your attack qualify for any stream cipher? And your sentence ("an advisary that can find out the plaintext could use that to find out the hash to decrypt the ciphertext [for which he was given the plaintext?, thats not a known-plaintext attack]") doesn't make sense to me – SEJPM May 14 '15 at 20:10
  • I believe what he is indicating is that if an attacker knows I XOR & they have a plaintext then they can retrieve the hash that I used. Meaning they can calculate the plaintexts for any other ciphertexts that were created with the same hash. I believe the salt saves me though. – Hector May 14 '15 at 20:12
  • In some cases, the plaintext can be found by other means. Imagine a encrypted HTTP request, you know it begins with "GET /" right? If you would use it with XOR, you could easily find out the 5 first charachters of the key. Maybe it was a request for the root path. Voilá 15 chars of key. But using it along with a salt makes it secure to use XOR. About stream chipers, they are secure since those are used with a IV, that prevents known-plaintext attacks. – sebastian nielsen May 14 '15 at 20:13
  • Just to add to this the data I am encrypting was originally generated with a secure RNG (its an Ed25519 key). So there is no predictable means to get a plain text. Further to this the use case means nobody should ever be trusted with the key that can't be trusted with the password. – Hector May 14 '15 at 20:16
-1

There's no reason why this construction should be insecure except for standard chosen-plain and ciphertext attacks. To prevent those you still need an authentication mechanism. (like AES-GCM or Poly-1305).

As practical construction I'd suggest you using an offset. Hence you would use the first few bits from the PBKDF to derive a key for authentication and the rest as pad.
You'd then use for example HMAC-SHA256 to authenticate the ciphertext and append the tag.
This only works in case you know the data size before performing the password derivation. This is the reason why it isn't widely used.

Why is this secure?

I'm skipping the authentication part here as this is standard for stream ciphers.
Basically PBKDF is a repeated call to HMAC, which is a PRF, so if your salt is random (it's your IV here) the output is pseudorandom and should be as secure as HMAC.

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.