Can I use PBKDF2 to generate an AES256 key to encrypt and implicitly authenticate?

I have 2 devices and I want to set up a secure communication channel between them. The only sh开发者_StackOverflowared secret is a (7- to 20- character ASCII) passphrase. If I use PBKDF2 (from RFC 2898) with a common salt, iterations, and passphrase to generate an AES256-CBC key and IV on both sides, I think I can authenticate the user and provide an encrypted channel all in one step. Is that true, or is there some reason why I've only seen people use PBKDF2 to verify passwords?

My reasoning is that both sides need to know the passphrase to generate the same key and IV. So if device B can decrypt data from device A, they both have demonstrated that they have the same passphrase.

PBKDF2 is a fine way to generate a common key from a shared secret (you should not be generating the IV in such a way though - the IV should be random, and sent alongside the ciphertext).

However, CBC is not an authenticating cipher mode. This is because an attacker can take an encrypted message and make predictable modifications to it, without needing to be able to read the message or know the key. Such attacks have broken real world systems in the past.

You can use an authenticating cipher mode, like Galois Counter Mode (GCM) instead of CBC.

An alternative is Encrypt-Then-MAC. Use PBKDF2 with two different salts to generate two different keys - first the data is encrypted using CBC with the first key, and then a HMAC is calculated over the ciphertext using the second key.

You will also need to use single-use-nonces to prevent replay attacks.

In general, you wouldn't be able to authenticate a message using a cipher, because the message could be anything. However, if the message conforms to some specified format, I suppose it's reasonable to assume the ciphertext must have been produced with the shared key—with longer messages in more complex formats giving better assurance. For example, the padding in a block cipher can serve as a weak authentication.

For better security, compute a MAC using the shared secret and send that with the ciphertext.

While PBKDF2 can be used to produce an IV, it can only do so for a single message. In most cases it's better to select a random IV and send it with the ciphertext.

PBKDF2 does not "verify passwords". It generates keys from passwords.

To verify a password, normally you have a thing that gets encrypted with a key. The key is generated from the original password, via PBKDF2. Then the cryptotext is saved.

When you want to check whether the user-entered text matches the password, generate the key from the password candidate using PBKDF2, then try to decrypt the saved cryptotext. If the decryption works, then you have a match.

Normally, though, you would not use the password-based key as a session key.

So, NO, you normally would not protect the secure channel with the password-based key.

caf's answer is good. I'd just like to add that you're trying to implement crypto, and even for trained experts that's generally a bad idea. Using the highest-level library you can is much safe.