# How are recovery keys possible if something is encrypted using a password?

I thought that encryption works as follows - it is about changing the thing we want to secure using an algorithm and using the password to mathematically change the secured content so it is unreadable.

If something is encrypted using a password then doesn’t it mean that the password is the only thing that can be used to mathematically change the encrypted thing so it becomes unecrypted?

I just have no idea how do recovery keys can even work!

• By searching over the passwords? What is your actual case? – kelalaka Dec 2 '20 at 20:27

When we talk of encryption, we talk of encrypting content with a key, not a password. Passwords are a specific kind of key, one that a user can reasonably type on a keyboard. I draw the distinction because, in encryption schemes with recovery keys, the data is indeed encrypted with a key, but that key is not your password.

They could indeed have used your password as a key. Let's say your password is password1 (a horrible password: never use anything like it). They could absolutely encrypt the harddrive using password1 as the key. However, let's say you forgot that password. There's nothing they can do to help, because that's the only key that decrypts the files. Or let's say you want to change the password. Now we have to re-encrypt every single file with a new key.

Systems like this solve both problems with a single solution. Instead of using your password as a key, they pick one for you. They pick some obnoxious binary string, typically 128 or 256 bits long, but for visual imagery, lets assume they pick an ASCII string like FAy."fts~j\bF7,h[WGT@y2W=erXq7P. I told you it would be obnoxious. They encrypt your data with that key.

Now this key is great. You're never going to have to replace it because nobody is going to guess it in a million years. However, you won't be able to memorize it either! So if we don't do something more, your data will be useless!

These systems create another data file somewhere, where they encrypt the key, FAy."fts~j\bF7,h[WGT@y2W=erXq7P. They encrypt it using your password, password1, as a key. Now if you want access to your files, you provide password1, they decrypt this little file, to get access to the ugly key, and then use that ugly key to actually decrypt things.

A recovery file is yet another data file somewhere, which also stores the ugly key, encrypted. It is encrypted with a different key. The form of the key depends on the individual product, but it might be something like 0138b300-7cf9-4eb9-b79d-f84a65e0ad68-313ed151-5ab0-47e6-867d-bf62f77953d6. It's the same game as before. If you have that password, you can use it to decrypt the ugly FAy."fts~j\bF7,h[WGT@y2W=erXq7P key, and decrypt everything else.

The idea behind systems like these is that you end up creating two different passwords which can access the data, but which have very different use cases. This means each password can have different handling mechanisms. While you may need to be able to memorize the first password so that you can type it every day, you may not mind storing a copy of the recovery key somewhere safe, and having to physically haul it out if you forget your first password.

Or, in the case of corporations, often the recovery key is entrusted to an IT team and corporate policies are used to ensure those individuals don't abuse the key, and corporate security ensures that no adversary gets their hands on them. In either case the pattern is the same: two passwords, but the way they are handled may be very different.

Obviously, if you forget both passwords (your real password and the recovery one), you're stuck. Typically this means you store the recovery one somewhere that you can rely on. Safety deposit boxes in banks might be a good place for some (always figure out a threat model, then decide where it is safe to store these passwords).

Another fancy trick that can be done is to use an algorithm to generate the recovery password. This can let you do clever things like break a password into 3 parts, give one to a CEO, one to the head of IT, and one to the chairman of the board. No one of them can use the key on their own, but put the three parts together, and you can generate the key.

• Very nice answer (+1). To add to the last part "No one of them can use the key on their own, but put the three parts together, and you can generate the key.", it is also possible to have a system where only n out of m partial keys are needed to decrypt. – WoJ Dec 3 '20 at 8:43
• BTW, the "breaking a password into parts" from the last paragraph is called secret sharing or secret splitting – cg909 Dec 3 '20 at 14:14
• @cg909 assuming you do it the right way. Be careful of actually just literally splitting the recovery key since instead of needing all of the key parts you might have just changed it so you know can only steal one of three. – DRF Dec 3 '20 at 15:55
• @DRF of course you need an appropriate sharing algorithm like the trivial XOR-algorithm (if n=m`) or Shamir's Secret Sharing. The Wikipedia article on secret sharing that I linked in my comment also explains the problems with simple string splitting – cg909 Dec 3 '20 at 16:57
• It's also possible to have a recovery key generated and stored on a removable medium, which is then stored within a sealed container, and destroy all copies that exist anywhere else. If the seal is one that the administrator could not open and reclose without evidence of tampering, this would allow an administrator the ability to use a recovery key, but not allow the administrator to do so undetectably. – supercat Dec 3 '20 at 17:37

Conceptually, a recovery key is usually like a second password. The data is typically encrypted with a data encryption key and then the data encryption key is then encrypted twice, once with a key derived from recovery key and once with a key derived from the user password. A significant point here is that the data encryption key never changes. If you change your password then that just results in the data encryption key being encrypted with a new key derived from the new password.

The specifics depend on the exact product that you're interested in (e.g. Bitlocker or Apple or whatever).

By the way, the above (again at a high level) is very similar to how data is encrypted using PGP and I've read that it's similar to S/MIME as well (though I've never read that spec so cannot confirm that).

• It's also possible to change the actual data encryption key, simply by adding another layer of encryption underneath. – alex.forencich Dec 3 '20 at 7:44
• @Swashbuckler Can I ask for clarification here please. In the specific case where you say "encrypted twice", do you mean that the encrypted version is stored twice i.e. separately? I'm trying to distinguish this from the "encrypted twice" used for example when data is run sequentially through a sender's private key and a recipient's public key in PKE systems. – Mark Morgan Lloyd Dec 3 '20 at 12:41
• @MarkMorganLloyd The key is stored twice, each time encrypted with a different key. Usually you also change the encryption key but it's costly for one and in many cases you will also have to generate new recovery keys since the system doesn't know the recovery key. (suriprisingly this doesn't have to be the case for Bitlocker given a somewhat unorthodox way of key management. – DRF Dec 3 '20 at 15:53
• @DRF Thanks for that. – Mark Morgan Lloyd Dec 3 '20 at 16:50
• Wow! Thanks! I had no idea that this is how it works! :) – Kaykay2137 Dec 4 '20 at 10:56