So i am a real beginner . And I use AES(TWOFISH(Serpent))) for my veracrypt file . So I asked myselfe a Question :
When a Cascade is made the Key is split in parts for each algorythm . So if We have AES(Twofish)) with the key : Test-password123 The "Test-pass" Part would be used for AES and the "word123" part gor twofish right ? So if you would use something like rc4(AES)) cascade , The rc4 would weaken the AES cipher right ?
I'm tailoring my question specifically to VeraCrypt where needed.
So if We have AES(Twofish)) with the key : Test-password123 The "Test-pass" Part would be used for AES and the "word123" part gor twofish right ?
No.
VeraCrypt (and any other somewhat decent encryption program for that matter) uses a so-called "password-based key derivation function" (more precisly PKCS#5 PBKDF2), which takes the full password and iterates a moderately fast function (a so-called hash function) very often. This is done so an attacker can't easily verify a guess for your password. Now the result (a sequence of bytes) is taken and split into different sub-keys (2-6 keys in the case of VeraCrypt)1.
So if you would use something like rc4(AES)) cascade , The rc4 would weaken the AES cipher right ?
It depends, but in general no.
AES, Twofish and Serpent are so-called block ciphers, that means they take a block of (16) bytes and transform them into a different block of (16) bytes using the key, such that the transformation is reversible given the key and not if not given the key.
These block ciphers need to be run in a so-called mode of operation (XTS in this case). There is no known attack that performs (significantly 2) better than brute-force key search for this cascade, so you are required to perform at least $2^{256}$ operations which is infeasible.
In your concrete example, it depends on the mode of operation for AES. If this mode is a so-called stream cipher then there's a result that states that the encryption is at least as strong as the stronger algorithm.
1: Actually it runs this chain mulitple times to generate a set of key-bytes each time and then splits.
2: Actually double-encryption is only slightly better than single encryption due to the meat-in-the-middle attack.
It depends.
Well, what “related” means? I am not sure if there is a good definition. If you are using the same key for multiple ciphers or if one key can be derived from another key, they are somehow related. If they are derived in a way that you cannot learn from one key anything about another key (for example using HMAC), then they are unrelated.
Your scheme (splitting password to multiple chunks) tries to generate unrelated keys, which is good. Well, it depends on user's input (user might use repeated patterns in the password), which is not so good. But the worse part is it makes some higher demands on password quality. First, it requires the password to be several times longer for the same degree of security. Second, it depends on password structure, which is very wrong. If password is padded by spaces or some similar pattern, it will make use of weak key with one cipher and strong key with another one. If you are unlucky enough, you will use weak key with AES and strong key with RC4.
Maybe you will want to learn something about key derivation. Note that passwords are not usually used as keys directly. For example, AES requires key to be either 128-bit or 192-bit or 256-bit. A key derivation function (scrypt, bcrypt or PBKDF can be used, hashes or HMAC can be used in some special cases) transforms password to seemingly-random garbage of the desired length.
Bad cipher can leak some info about plaintext or key to someone knowing the ciphertext. If the innermost cipher is, say, totally broken (attacker can derive plaintext and key from cipertext), the inner ciphers will still protect you (unless they are also broken). If the outermost cipher is broken, attacker can still have troubles with breaking inner ciphers.
Bad implementation is quite worse. Let's suppose we have a bad implementation of a cipher that leaks plaintext over some side channel like timing, CPU sound, power characteristics or electromagnetic emissions. (In real world, it is more probable to leak parts of plaintext.) If it is the outermost cipher, you are in the same situation as with bad cipher. If it is the innermost cipher, you are out of luck.
Well, this is a simplification a bit: There are actually various scenarios for attacks (known-plaintext-attack, chosen-plaintext-attack, chosen-ciphertext-attack, …), but the level of exposure should be valid for all of them.
Maybe it is reasonable to use the cipher implementation you trust the most as the innermost cipher and the cipher implementation you trust the least as the outermost cipher.
