- Are the keys related? If they are, it is hard to reason about it in general. If they are not, you can continue.
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.
- Do you consider only ciphers, or their implementations?
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.