Is a random keyfile more secure than a derived key?

Question

I'm devising an encryption layer for some proprietary cloud storage API. Basically this should act as a transparent adapter that encrypts whole binary blobs (files) on upload and decrypts them on download. The reason for this is to store data encrypted on the untrusted server side.

I want to use a symmetric encryption algorithm. The key for this will be generated and kept on the client side. As I'm in no way a security expert my question is whether it would be more secure to generate a binary key of the desired size by use of a pseudo-RNG than relying on a key derivation function? The random key would be somehow secured by a passphrase of course.

A related question is how to go about checking whether the entered passphrase is correct.

Answer 1

If you generate a random key with no password, then its entropy (a measure of how long it takes to find the key through brute force attempts) is the size of the key. For example, if the encryption algorithm is a mode of AES-128 (a common choice), then a random key has 128 bits of entropy, meaning that it takes up to 2¹²⁸ attempts to find it by brute force. (That would take more than a billion years with a billion PCs.) The risk with a random key with no password is that if an attacker obtains the key file, they can use it just as if they were you.

If you use a key that's derived from a password, its entropy will be a lot less. How much depends on how the password is chosen, but you have to rely on having chosen a strong password, which can be a problem if you have many users who can't necessarily be trusted not to pick Passw0rd. Furthermore, the attacker might obtain information about the password by watching you type or other “out-of-band” methods.

If you generate a key file and protect it with a password, you get the best of both worlds, in terms of confidentiality. The attacker would have to obtain both the key file and the password in order to obtain the key. Note that if the attacker obtains the key file, he can try to find out the password, but even then you might have a bit more time to change the key while he attempts to crack the password.

Depending on the application, entering an invalid password may either tell you that the password is incorrect without contacting the server, or may silently compute a wrong key that the server will reject. The latter is better because that means all cracking attempts must reach the server, and the server can limit the rate of cracking attempts. This way, even if the attacker grabs the key file, he'll be limited to the rate of attempts that the server allows, and you'll know that something is going on. If the password can be validated with the key file alone, the attacker can make his cracking attempts offline and can parallelize them over many computers.

Keep in mind that if you make it harder to find the key, that hinders you as well as attackers. If you use a key file, you must back up that key file. If you use a password, you must back up that password. If you use a password-protected key file, you must back both up.

Answer 2

Assuming you don't publish the encrypted keyfile, this would be trying to implement "something you have" (the computer with the keyfile), alongside "something you know" (the passphrase).

But then you have another problem to solve: key distribution. In practice this is a big problem. Particularly for more general systems, and especially for fully generalized paranioa.

If you want to compromise on generality/ease-of-use to gain security, that's cool. Otherwise, it might be best to focus attention elsewhere, e.g. password security, recovery, and server-side login monitoring.

IMO password security is a pain point for most systems, which makes it an important area to focus on. Recovery is a closely related area (and without care, can end up as a weak link that compromises the whole system). Then server-side login monitoring may be able to achieve a similar goal to the keyfile, in a more practical way.

I'm thinking of login monitoring like GMail. "WARNING: You last logged in from China. If this seems suspicious to you, click here for advice". Detecting, mitigating and reporting brute-force attacks. At the browser (or indeed, app) level, I believe some sites maintain a list of used devices, and email the user when they add a new one. Having to add new devices could also be a useful place to put the warning "do you actually trust this device you're using with all the data stored on your account?".