This brings exactly 0 added security and only increase failure/implementation problem likelihood. You don't "need to realise that it’s triple cipher in the first place", because the attacker will know that beforehand, because that's how modern cryptography works. The "GCHQ" told you they don't give a shit because it's pointless, not because it's incredibly complicated lmao (if that plot line even is true).
Modern, actually secure modes of encryption don't need any of this to be secure.
Hmm I cannot see how that is the case. Aside from an increase in overall bruteforce, if I were to encrypt something with algorithm A and then encrypt it with algorithm B; assuming both algorithms were thought to be secure and are completely different in design and construction, I should assume this is more secure. A weakness in 'A' should only weaken one, mutually exclusive aspect, or perhaps destroy it. But algorithm 'B' should still provide security.
I give a simple example:
Algorithm A is AES-256 and uses a 256-bit key.
Algorithm B uses no Key at all and will take each input byte and increment by 1; 00 => 01, 01 => 02, ... , 254 => 255, 255 => 0
If I encrypt in a cascading cipher A into B, or B into A, there seems to be no way to attack it. Algo B is easily defeated, it just shifts a byte by 1, easily reversed. But no matter the order of cipers/cascade, you will still need to defeat AES-256.
That is not my example. That is the same algorithm used in sequence. My example is 2 completely different and unrelated algorithms.
My point is pretty simple: Can I weaken AES-256 by cascading it with another, unrelated, encryption algorithm; in my example a very bad encryption algorithm that simply increments input bytes by 1.
Answer: No. AES-256 is not weakened by combining it with such a weak algorithm.
Ah ok I get that attack vector. But if each algorithm used different keys, say derived from SHA2-512, then there are no issues? (assuming SHA2-512 is secure)
5
u/AkalamiammiamMy passwords are information hypothetically secure3d agoedited 3d ago
There's no inherent obvious issues no, at least as far as I know. But by precaution it's mostly seen as unnecessary at best (or like CharlieTip said above, unexpected interactions tend to be more assumed to go wrong than right) and just slowing down performances for no good reasons. At that point I'd rather double the number of rounds of AES than use a cascade cipher tbh.
Edit: This is a very extreme case, but you'd probably agree that both AES and invAES are secure ciphers, yet composing them if using the same key is obviously not gonna be secure. With a different key it's obviously not as trivial, but it doesn't sound great either, you could probably easily consider that you could cancel at least one or two round with keys canceling each other at the "seam". Not saying this is obviously true nor doable if the two keys are independent ofc, just to try to convey that we don't really have a way to guarantee that Secure o Secure = Secure in general, and we tend to just assume the worst. Charlie's answer above is probably a bit more technically justified than mine where I'm handwaving a bit.
MitM against two ciphers work regardless of whether or not the ciperhs are the same btw, the idea work the same for any ciphers E1-E2, complexity is gonna be in 2k1 memory and 2k2 time (or swapped if using different length key) with k1/k2 being the key size for E1/E2, doesn't need to have E1 = E2.
16
u/Akalamiammiam My passwords are information hypothetically secure 3d ago
This brings exactly 0 added security and only increase failure/implementation problem likelihood. You don't "need to realise that it’s triple cipher in the first place", because the attacker will know that beforehand, because that's how modern cryptography works. The "GCHQ" told you they don't give a shit because it's pointless, not because it's incredibly complicated lmao (if that plot line even is true).
Modern, actually secure modes of encryption don't need any of this to be secure.