# Key management and derivation - Allow changing of the passphrase

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.

• 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 – Richie Frame Apr 22 '16 at 23:17
• Maybe I read it wrong and that is not required, the part "does allow revoking passphrases" should probably be "does NOT allow revoking passphrases" – Richie Frame Apr 22 '16 at 23:29
• Yes, sorry. Revocation of passphrases is not possible without re-encryption. – sebi707 Apr 22 '16 at 23:34

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.
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.