I'm working on a program, which allows encrypting files before storing it on a cloud service. Currently I'm trying to figure out how to derive and store the keys.

First, I wanted to use a simple passphrase from which the file encryption keys are derived using PBKDF2HMAC and a file specific random salt. This helps providing unique nonce/key pairs, which is required for GCM mode.

Now one additional feature would allow changing the passphrase without re-encrypting and re-uploading all files. The new key derivation would look like this: The passphrase is used to generate a decryption key, again using PBKDF2HMAC with salt. This key can be used to unwrap a master key file, which is encrypted and authenticated using AES-KW. This master key is randomly generated and matches the key size used for file encryption. To generate unique keys for every file the master key is then XORed with a file specific random salt, which acts as a one-time-pad. To change the passphrase one would unwrap the master key and wrap it again using a different passphrase. I know that this technique does not allow revoking passphrases. Any previously used passphrase and master key file can still be used to decrypt the data.

While I am quite sure, that this method is secure (given that all random generated keys and salts are truly random) it seems a bit complex. Is there a reason to avoid the obvious extension to the first method? That is: Changable passphrase decrypts random master passphrase (using GCM mode), which again decrypts the files.

  • $\begingroup$ I believe your scheme requires you to change the key data for EVERY file and file chunk, which could be millions or even billions of chunks $\endgroup$ Apr 22, 2016 at 23:17
  • $\begingroup$ Maybe I read it wrong and that is not required, the part "does allow revoking passphrases" should probably be "does NOT allow revoking passphrases" $\endgroup$ Apr 22, 2016 at 23:29
  • $\begingroup$ Yes, sorry. Revocation of passphrases is not possible without re-encryption. $\endgroup$
    – sebi707
    Apr 22, 2016 at 23:34

2 Answers 2


If you want to allow sharing of files between users without sharing their master key and/or pass phrase, you need to allow for something like this extra layer of "indirection" complexity.

However, per-file keys must be crated from HKDF(master_key, file_nonce) or a similar one-way key derivation function. Using simple XOR in this case would expose the master key to anyone with whom a per-file key is shared.

A file share would be simply taking the per-file key and wrapping it using some key known to the "destination" user. The "owning" user doesn't need this information, as they can always re-derive the per-file key using their master key and the per-file nonce.

Note that you will want to use a string such as "per-file key derivation" as the info parameter to HKDF to provide "domain separation". That is, you are using the source key and a nonce as input, and then deriving a key for a specific purpose. You don't want to generate the exact same key and use it for a different purpose later on, you would use for example a different info parameter if you were going to generate something else from the same master_key and file_nonce.


It's strange, but I was just thinking about this some time ago. It seems to me that you could first calculate the old master key (using the old password - you'll need that). Then calculate the new master key using your new scheme and XOR it with the old key. The result you should store with the salt. Now you have a method of calculating the old key: you just perform your new scheme and XOR with the stored value.

The biggest problem is that it would still be possible to find out the old password using the scheme above. As long as an attacker can verify that a password leads to the old key (e.g. by decrypting files) the old password may still be vulnerable. So you should make clear to users that their old password could become compromised. This is of course already the case if the data-at-rest was stolen beforehand.


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.