How passwords are fed to key derivation functions?

Question

Suppose I want to encrypt data, send it over the network, and decrypt it on the receiver side.

I know the elegant way to do this is by using a symmetric key to encrypt the data and an asymmetric key to send the symmetric key to the receiver so he can decrypt the data.

But I just read about another way which is to use a password based key derivation function to calculate a key on both sides. This way, no key exchanged. But this requires both sides to use the same password in the calculation of the key, so I suppose I have to send the password to the receiver at some point so he can calculate the same key and use it to decrypt.

If what I understood is correct, then I don't see the goal of using a PBKDF since I have to send something at some point. If not, then what I'm I missing?

Answer 1

KDFs are better used for offline protocols. What is often used for your second case are Key-agreement protocols. As far I know, there's no secure way of using KDFs in such interactive context where both parties need to know the key a priori. Key-agreement protocols make it feasible to compute a shared-secret (the encryption/decryption key) on demand - both parties can seed such shared-secret into a cryptographic secure PRNG for forward-security.

Answer 2

You are correct: generally it is required to synchronize or otherwise synchronize information if you want to use a password based key derivation function (PBKDF) for sending messages.

That doesn't mean that using a password on the client side a derived key on the server side doesn't have advantages:

• the password isn't stored on the server side, so an attacker may not be able learn the password if the backing database is stolen;
• the password nor key needs to be stored client side (and a key is not so easy to remember) so stealing the device on the client side will likely not lead to any breach of the protocol.

That said, a PBKDF is commonly not used for sending messages in an online protocol. Instead a password based key agreement or PAKE could be used to authenticate the client and establish symmetric keys. However, a PAKE also requires a setup phase. In Augmented PAKE the server doesn't learn the password, only a derived value used for verification.

In the end, there is nothing asymmetric about password based encryption; the password is a secret; that secret or a derived value needs to be shared with the authenticating party.

---

Note that often the client application is often also from the same organization as the server. This means that the client will have to rely on the organization's security at some point - whichever cryptographic protocol is used. It's only possible to mitigate that problem as much as possible.

Answer 3

PBKDF is intended to derive a key (specific length, hard to guess) from a password. That's it.

Indeed, when exchanging messages encrypted only with a symetric cipher, at the end all involved parties need to have the same key. The key needs to be shared somehow at some point.

If what I understood is correct, then I don't see the goal of using a PBKDF since I have to send something at some point

It makes sense when using passwords entered by humans - using only printable characters, different length, easy to remember,. ..

Answer 4

Trying to use a PBKDF for transferring data over a network is not appropriate. The place to use a PBKDF is when you're protecting data at rest, e.g. some sort of archive file like a zip file or a backup. In works well in those contexts.

Answer 5

Sending symmetric key is equivalent to sending password (used for PBKDF) - they are both secret information that require secret channel. Sending session symmetric key encrypted with asymmetric cryptosystem doesn't require secret channel - you use public key of recipient (for instance taking it from certificate signed by root certificate that you trust, say preinstalled in OS).