The construction of the cipher doesn't solve the biggest problem with using these stream ciphers, re-use of the IV. Depending on your architecture it is very ha

The construction of the cipher doesn't solve the biggest problem with using these stream ciphers, re-use of the IV. Depending on your architecture it is very hard to guarantee that you'll never re-use an {IV, Key} pair. Encrypting results in P xor S xor T xor A (where P is plaintext, S is Salsa, T is Twofish, A is AES (or rather, the key streams produced by each cipher)). If two different plaintexts were encrypted with the same IV and key pair then I can xor these two cipher texts together: (P1 xor S xor T xor A) xor (P2 xor S xor T xor A) -> P1 xor P2 And I've now removed all of the crypto. AES-SIV aims to solve this problem, but is slower than something like AES-GCM because it needs to process the plaintext twice. Obviously, it is much faster than the scheme proposed here and removes the biggest implementation flaw in nonce-based stream ciphers. Another pitfall here is that encryption == decryption (modulo the HMAC step) which means that if I have an encryption oracle that I can feed {IV, Key} that automatically becomes a decryption oracle. (The YubiHSM I believe was vulnerable to an attack like this, so they do happen in the real world)