# Encrypting documents through a proxy key

Suppose I'm developing an app to secure a lot of documents. These documents were encrypted (say, using AES) with a key X.

This key X is basically the password that the user enters before wanting to view any particular document, because that doc need to be decrypted using X.

If the user wishes to change the key X to something else (maybe his password got compromised), then he'll have to decrypt all the documents, and then re-encrypt all of them using the new value of X.

What if, instead, I have a key Y, which is used to decrypt/encrypt the documents. However, Y itself is a key that is stored on the system, encrypted using X, which is what the user enters.

I'm thinking that the advantage of this would be when the user wants to change his password, he only needs to decrypt and re-encrypt Y, without having to decrypt/re-encrypt all the documents.

Are there any possible weaknesses that I'm missing with this method, or is it sound?

-
I hope you did design your system carefully, choosing an appropriate mode(probably using authenticated encryption of some form), deriving the key from the password using a fitting KDF, using salt and IVs correctly,... –  CodesInChaos May 22 '12 at 14:38
With KDF, do you mean to diffuse/confuse something like "3333" to "x9rn329m43x982ynxy4"? –  kamziro May 22 '12 at 14:48
With KDF I mean something like PBKDF2, scrypt or bcrypt. i.e. a deliberately slow, salted hash function. –  CodesInChaos May 22 '12 at 15:30
Ah fair enough, will do that, thanks. –  kamziro May 22 '12 at 16:13

There is the obvious weakness that if Y ever gets compromized, changing the password will not help. The attacker will be able to decrypt all past and future documents. One way this might happen is if the password gets compromized, and the attacker gains access to the encrypted value of Y.
Ah, good to know that truecrypt uses that. I guess if Y gets compromised then I'll have to make functionality that handles changing of Y as well then. –  kamziro May 22 '12 at 14:31