1
$\begingroup$

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?

Improve this question
$\endgroup$
3
  • $\begingroup$ 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,... $\endgroup$
    – CodesInChaos
    Commented May 22, 2012 at 14:38
  • $\begingroup$ With KDF, do you mean to diffuse/confuse something like "3333" to "x9rn329m43x982ynxy4"? $\endgroup$
    – kamziro
    Commented May 22, 2012 at 14:48
  • 1
    $\begingroup$ With KDF I mean something like PBKDF2, scrypt or bcrypt. i.e. a deliberately slow, salted hash function. $\endgroup$
    – CodesInChaos
    Commented May 22, 2012 at 15:30

2 Answers 2

Reset to default
2
$\begingroup$

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.

TrueCrypt volumes work in a similar way. When you create a volume, a master key is created which doesn't change throughout the lifetime of the volume, even if you change the password.

Improve this answer
$\endgroup$
1
  • $\begingroup$ 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. $\endgroup$
    – kamziro
    Commented May 22, 2012 at 14:31
1
$\begingroup$

You never want to re-encrypt to deal with a possible key compromise. If you re-encrypt, you now have two keys that must be kept secure to protect the data. Before you only had one.

Improve this answer
$\endgroup$
2
  • $\begingroup$ That's true, but the old compromised key is as good as gone, and whatever it was encrypting can be assumed to be as clear as plaintext. And with the new key, newly encrypted data won't be readable by someone holding the old key, at least. Or are you suggesting something else? $\endgroup$
    – kamziro
    Commented May 23, 2012 at 6:43
  • $\begingroup$ Newly-encrypted data should be encrypted with a different key. I'm talking about the wisdom of re-encrypting existing data. (If you're assuming it can't be compromised, why bother encrypting it? And if you're assuming it can be, why give two chances to compromise it?) $\endgroup$
    – David Schwartz
    Commented May 23, 2012 at 7:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.