38

Many password-based encryption utilities (e.g.: KeePass, TrueCrypt) do something along the lines of...

  1. Encrypt data with super-strong random-generated key, "data key".
  2. Encrypt data key with another key, "user key", based on user-provided password.
  3. When access is needed, user provides password. Password is used to recreate user key, which decrypts data key, which decrypts the data.

Presumably the logic behind that is this:

  • User-provided passwords suck, so we need a better key to protect the data.
  • Users still need access to the data, so we need a way for them to do it with a password.

However, the bottom line of all this is that the protection of the data still boils down to the strength and protection of the user-provided password. So, what's the real point of the extra overhead in having a separate key involved?

Improve this question

7 Answers 7

Reset to default
48

The main advantage of using an intermediate key is that is allows changing your password without reprocessing all the data.

E.g. you have a big file (gigabytes...) encrypted with random key K (a 128-bit value), and K is itself encrypted with P (the key derived from the password). If you change your password, you get a new password-derived key P'. To adjust things, you must then decrypt K with P and reencrypt it with P'. This does not require reencrypting or even accessing the big file.

Apart from that advantage, using an intermediate key decouples the operation, which is more flexible. For instance, the process used to turn the password into a symmetric key might not be up to the task of producing a key of the length you want for bulk encryption (for instance, bcrypt will produce a 192-bit key, not a 256-bit key).

Another advantage of the intermediate key is that it allows revealing files. For instance, you have your big file, and you want to show it to Bob. But you do not want to give your password to Bob; you want Bob to be able to see that single file, not all other files which are encrypted with the same password. With the intermediate key, this is easy: you just show K to Bob. As long as each file has its own random K, this works.

Note that the model extends to asymmetric encryption: a file sent to n recipients will be encrypted once with a random key K, and K will be encrypted with the public keys of each recipient. This is how things work in OpenPGP. The corresponding advantages map to the password-based situation as well.

Improve this answer
11
  • 6
    It's not really a trade-off, as the security doesn't go down, but the usability does go up.
    – Jan Fabry
    May 11, 2015 at 15:32
  • 1
    "morally encrypted" with the same file? (guessing a typo)
    – Superbest
    May 11, 2015 at 17:06
  • 1
    @ThomasPornin I still dont see how the word morally fits in that sentence. Btw, good answer
    – rpax
    May 11, 2015 at 22:48
  • 3
    One caveat to keep in mind: A user might encrypt some data with a key and store the encryption of the key under a weak password. If the user later change the password to something stronger such that the key will be re-encrypted, an adversary might still be able to get a copy of the old encryption. This means if additional data is later encrypted using the same key, it will be no more secure than if it had been encrypted under the weak password. This is not quite what users would expect.
    – kasperd
    May 12, 2015 at 6:52
  • 1
    @SiyuanRen: Requiring the user to decrypt and encrypt again in two different steps is not the same as if this feature would be provided by the software in one single step. Indeed, in case of encrypted files, this would mean that the file has most probably been written in clear form at some times on the disk (even wiping may have some flaws).
    – WhiteWinterWolf
    May 12, 2015 at 9:09
10

It allows the user to change the password without having to encrypt again all the data.

If you used directly the password to encrypt the data, then a password change would potentially take a very long time because the whole data will need to be deciphered using the old password and ciphered again using the new one. And what about if this process is interrupted in the middle, when half of the data is encrypted with the new password while the other one still with the old one?

Thank to the system you describe, when the users wants to change his password, all that is needed is to encrypt the data key with the new password. Just quick, simple and reliable.

Improve this answer
1

Presumably this is convenience. If I want to change my password, this will derive a separate key - then I only need to re-encrypt the key with my password derived key encrypting key.

However, if you didn't have a separate key, you'd need to decrypt and re-encrypt the entire database. Given this is passwords that's not likely to be huge, but for other implementations (file systems) the multiple key design makes sense.

Improve this answer
-1
  1. High entropy. If your data key is random it's very likely not the weakest link.
  2. Key separation (not sure if it's called this...): An attacker has to decide either to attack the header with the "weak" key or to attack the data with the strong key for which may have gigabytes of sample data. Thus cryptanalytic attacks are defended against.
  3. Convenience. A user can simply switch his password without the need to re-encrypt gigabytes of data. (which may take hours)
Improve this answer
-1

What actually happens is that a user provided password is turned into a set length hash in a one-way mathematical operation called SHA-256.

"SHA-256 is used as password hash. SHA-256 is a 256-bit cryptographically secure one-way hash function. Your master password is hashed using this algorithm and its output is used as key for the encryption algorithms."

Basically you input a password and it generates a unique SHA-256 hash with length of 256 bits. The security of the password comes from its randomness. The security of using the hash comes from its length and the one-way nature of its generation.

The logic of this actually still requires a strong user-provided password, but yes, the other point is that you want users to be able to remember a password not a 256-bit random hash.

Read more here.

Improve this answer
4
  • 1
    This still doesn't clarify the issue of the question: Why not just use that hash to encrypt all the data, instead of making another key entirely?
    – Iszi
    May 11, 2015 at 15:14
  • Do you plan on memorizing the 256-bit random hash?
    – Fernando
    May 11, 2015 at 20:53
  • No, but the hash can easily be reproduced whenever the user provides the password. That's how the "user key" is re-generated to decrypt the "data key" in the first place.
    – Iszi
    May 13, 2015 at 14:34
  • Got it, I think I misunderstood the question when I read it initially.
    – Fernando
    May 13, 2015 at 22:33
-1

I think there is a bit of confusion here between two different applications Full Disk Encryption (i.e. Truecrypt) and password generation and storage schemes (i.e. KeePass). These two situations have very different goals and security models.

The first application Full Disk Encryption uses a layered key approach to allow easy key change, minimization of data encrypted under low entropy keys and (in some cases at least) multiple methods of data recovery.

If you have a random high entropy key used for data encryption you are giving many P/C pairs to the attacker but the key is also strong. The lower entropy key is then used only for a few P/C pairs (maybe 2-10 blocks or so). This isn't probably a huge issue these days since we believe that finding even one bit of a key or its parity is as hard as finding all of them but it still feels better to give the attacker a smaller attack surface for the worse key.

At the same time for many FDE uses you might want to have multiple people with different passwords/keys be able to access the data or have a different access method for an administrator then a user. Since the underlying encryption must be the same you use some other key to encrypt it with.

For the second application the attack model is a lot different. Whereas for Truecrypt like applications you are assuming someone has access to all the data and headers at the same time (they stole your hard disk), in the case of KeePass you usually assume that the place where the encrypted keys (your KeePass container) are stored is different then the places where the keys are used (the websites/servers/credit cards/what not). This means you generally assume that it is significantly harder or costlier for the attacker to attack the the encrypted keys (your KeePass container) then to launch an attack against the place where the keys are used.

Think of it this way: if your password to your KeePass container is "Princess" and all the keys in it are random generated before the attacker can start writing emails as you he first has to obtain the KeePass container from our hard disk and figure out that "Princess" is your password, since attacking the randomly generated key you use to log in to the email account is unfeasible.

if on the other hand the password to your email account is "Princess" all the attacker has to do is try the first 10 or so most popular passwords and he can hack into your email account.

As an extra bonus if for whatever reason all the passwords in you email providers database are compromised all your systems will be safe since the passwords you used there are random and unrelated to your email password (KeePass generated them). Whereas if you use "Hard2h4ck" for you email password and "h.ard2H4ck" as the admin password for the server you manage the email leak gives an attacker a good starting point to attack your server.

Improve this answer
7
  • The attacker wouldn't be attacking the "randomly generated key you use to log in to the your email account". They'd be attacking (if not your password) the randomly-generated key that encrypts/decrypts all of the randomly-generated passwords you have stored in KeePass - the two models (KeePass/TrueCrypt) are precisely the same in this regard. Once an attacker cracks your KeePass password, or the database encryption key, they have all your stored passwords at once.
    – Iszi
    May 13, 2015 at 14:38
  • @Iszi They are most emphatically not the same in this regard. In one case (TrueCrypt) the key that protects the data (your hard disk) is stored in the same place as that data (i.e. on your hard disk). In the other case (KeePass) the key (i.e. randomly generated password in your local storage) that protects the data is stored in a completely different place then the data (which is in you email/dropbox/system account on a different machine).
    – DRF
    May 14, 2015 at 5:43
  • @iszi The two approaches attempt to protect form significantly different threat models. In the case of KeePass I'm protecting against use of a large number of easily guessed credentials (passwords for the 10's or hundreds of different systems) and credential reuse (since few people will actually have different passwords for different systems). In the other case (truecrypt) I'm attempting to protect a lot of local data from being compromised assuming an attacker has gained physical access to the device in question, which I attempt to mitigate against in other ways aswell.
    – DRF
    May 14, 2015 at 5:48
  • @iszi Obviously if the attacker gains access to your KeePass container then he will attack the password/passphrase used to decrypt the master key used to encrypt the keys. But he must already clear the quite significant hurdle of gaining the container in the first place. (Significant compared to trying to perform a guess and check attack against freely accessible services or abusing a data breach to attempt a credential reuse attack).
    – DRF
    May 14, 2015 at 5:51
  • I'm still not clear on how you think KeePass & TrueCrypt are so different in terms of function. Both operate essentially the same. | 1. Random key is generated and used to encrypt the data - files for TrueCrypt, password database for KeePass. 2. User provides password. 3. Password is fed to a Key Derivation Function (KDF) to generate a Key Encryption Key (KEK). 4. The KEK is used to encrypt the key that protects data. 5. KEK is destroyed, encrypted data key is stored alongside data. ...
    – Iszi
    May 14, 2015 at 13:40
-1

The answer lies in how we encrypt. If we just used a password, or a 128-256 bit key to encrypt large data sets, the data would be vulnerable to attack because it is larger that the key encrypting it. An attacker could easily analyze the encrypted data for patterns and derive the plaintext. To be secure, data needs to be encrypted with a RANDOM key at least as large as the data itself (big K).

Because big K itself is statistically random, there are no patterns to analyze. Therefore we can safely use a much smaller key (128-256 bit small k) to encrypt big K and prevent it from inadvertent exposure. Since big K is already statistically random, encrypting it with a much smaller key exposes it to very little risk from cryptanalysis, which depends on exploiting patterns in meaningful data. By definition, random data contains no patterns.

Thus the smaller key safely conceals the bigger key, and opens up conveniences as others explained above, like user password management.

A password decrypts small k, small k decrypts big K, and big K decrypts the data.

Improve this answer
1
  • First key size is irrelevant. In general both the key-encryption-key and the data-encryption-key will be 128 to 256 bits in length. Second, given the first point, the assertion that "a random key with the same length as the data will be used" is simply incorrect.
    – Xander
    Jan 10, 2016 at 19:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .