# Creating multiple independent keys for cascading - recommended approach?

I would like to use cascading encryption with 3 algorithms in a similar fashion to Truecrypt, so for example:

Encrypted = AES( Twofish( Serpent(Secret, key1), key2), key3)

The aim of this is of course simple: if 1 algorithm is broken, the other(s) still provide security.

But what is the best approach to derive each key independent from each other, from the one passphrase? It was not obvious to me from TrueCrypt source how they did it, my websearches have failed, and understandably from that result it seems there are very few discussions so far on crypto stackexchange in regards to generating multiple independent keys.

I'm asking for suggestions, not making any recommendations, but in Applied Cryptography Bruce Schneier mentions how to derive an independent key that can be used to check if a key is valid, which if I'm understanding correctly is approximated as this:

KeyVerify  = Hash(password . salt)               // stored only for verifying but not used
RealKey    = Hash(KeyVerify . password . salt)   // actually used

Note: KeyVerify is independent from RealKey, but not vice versa

So I'm wondering if that approach might be of use, but I'm not confident how to extend it ... for example, something like this maybe?

RealKey2    = Hash(RealKey1 . password . salt) // for 2nd cipher
RealKey3    = Hash(RealKey2 . password . salt) // for 3rd cipher

Seeing as the KeyVerify/RealKey example shows a one-way line of independence, I'm guessing that the order the keys are used in is also a fundamental part of the solution.

$\newcommand{\concat}{\mathbin\Vert}$Use a key derivation function, such as HKDF, to expand a master password-derived key into subkeys for each cipher.

1. Compute $k = \operatorname{scrypt}(\mathit{password}, \dots)$.
2. Compute $k_\mathrm{AES} = \operatorname{HKDF}_k(\text{‘AES’})$.
3. Compute $k_\mathrm{Serpent} = \operatorname{HKDF}_k(\text{‘Serpent’})$.
4. Compute $k_\mathrm{Twofish} = \operatorname{HKDF}_k(\text{‘Twofish’})$.
5. Throw out Applied Cryptography and get Cryptography Engineering to replace it, but make sure to print out the unauthorized errata and glue them into your copy of it.
6. Step back and write down a clear security model for your application, because higher-level logic in your application will be attacked long before the crypto.
• Is this saying you would use HKDF on some short password "abc" then use the first 128 bits for the AES, the next 128 bits for Serpent, and the next 128 bits for twofish? These keys don't seem to be independent for short passwords, but maybe no scheme is. Dec 4 '17 at 11:07
• More or less, except we go through scrypt first and use HKDF to expand the master secret into a longer one. The only way to make them truly independent is to pick multiple passwords independently in the first place. Dec 4 '17 at 17:04
• or maybe they become independent again in semantic terms once the password is more than 5 characters and has at least 1 numeric character, or something Dec 4 '17 at 17:08
• ...Errr, no, that's not what independence means. Dec 4 '17 at 17:17
• There would be some sized password with your scheme where the second key can't be worked out by a computationally bounded adversary that knows the first key. Dec 4 '17 at 17:20