How to store keys for a cascading encryption? What is the best way to implement a cascade encryption?

I'm trying to figure out how to cipher a string (or message) using Serpent-Twofish-AES and then store the keys.

I'll provide an explanation, then maybe someone is going to be able to explain how to resolve the issue I'm facing. I've read the TrueCrypt documentation before posting here.

Let say Anna want to send an email to Bob. Anna type a password and give it to Bob face to face.

Message being sent over internet: Hi Bob, this is Anna


I split the message into chunk.

#1: "Hi Bob,"
#2: " this i"
#3: "s Anna"


After that, each chunk is encrypted with AES then Twofish and then with Serpent.

Key #1 encrypt Chunk #1 with AES
Key #2 encrypt Chunk #1 with Twofish
Key #3 encrypt Chunk #1 with Serpent
Key #1 encrypt Chunk #2 with AES
Key #2 encrypt Chunk #2 with Twofish
Key #3 encrypt Chunk #2 with Serpent


And so on...

Then all encrypted chunk is stored somewhere...

The keys are generated based on the password Anna provided.

Where do I store the keys?

I didn't find any useful information about implementing a cascade encryption and I think this question might be good for the internet's knowledge.
The part of this answer that talks about key storage is at the end, the first part is about implementing a cascade.

There are 2 main methods for cascading block ciphers, inside of the mode and outside of the mode. Within the encryption you have your mode of operation, and you have your block cipher cascade. The first cipher in the cascade will be considered the primary cipher.

Inside the mode means replacing the block cipher inside the mode with the cascade. In this method there is the single mode of operation wrapped around the cascade. The non primary ciphers essentially act in ECB mode on the ciphertext of the primary cipher, and the ciphertext of the final cipher is the ciphertext of the mode's inner cipher.

Outside the mode means you encrypt the plaintext with each mode (and each cipher) in sequence. This allows use of multiple modes, which can either have a security or performance advantage (or both, or neither). For example, the output of AES_CFB can then be encrypted with Twofish_CBC.

Depending on the target platform and development language, either method may have an implementation advantage. Certain modes of operation such as CTR or ECB are parallelizable, whereas CBC and CFB are note. CTR also allows encryption of lengths that are not a multiple of the cipher block size without using padding or CTS. The method Truecrypt uses is optimized for filesystem encryption, and using that method may not meet your requirements (which are not specified). AES also allows high speed timing analysis/DPA resistant implementations on modern processors with AES_NI instructions.

Cascading has not officially been given anyone's seal of approval, but it does have an allure that a single cipher may be completely broken and your ciphertext remains secure. For the actual security of using it, see the answers here: Combining multiple symmetric encryption algorithms - implications? I tried not to talk about how to implement in my answer, as it was not part of the question like it is here, but the security implications are quite relevant.

As for the main point of the question, how to store keys, you would do it the same way as any other cryptosystem, you are just storing more key data in this case. Standard methods include a high entropy unguessable password hashed with a KDF to generate key data, or encrypting the keys using an asymmetric algorithm. The strength of the KDF and asymmetric key size should be at least as strong as the expected security of the cascade. (256 to 768 bits with up to 3 AES candidate algorithms). In your example a password known to both parties is used to generate the keys, so there is no storage of keys, it is generated from hashing that password in some method that generates enough bits.

My personal recommendation for balanced speed and security would be to use AES128_CTR first then encrypt with Twofish256_OCB3. This requires 384-bits of key data, which can be generated using a SHA384 or an appropriate key derivation function, but it is better to use a strong random source if possible. Getting the keys to the recipient securely is a whole different problem.