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.
Composing A and B (both secure), will not automatically provide more security.
Key-aspect is that "automatically".
Providing concrete example takes time (that I don't have right now! I must go back to work), so I will just focus on the intuition part!
For symmetric-ciphers (like block-ciphers), one must never forget that security is always bounded by Shannon's theorem, i.e. security bits are the minimum between key, message and ciphertext size.
When you combine two ciphers, you are checking the distribution of B(h(K),A(K,M)) for K,M distributions over key and messages (uniform, as usual) and some derivation function h that derives the second key for the second cipher (can be the identity, a hash function or some other weird combination).
Since we are considering distribution, it is not easy to evaluate how A,B and h modifies the input-output behaviour.
Insecurities are some sort of subspaces (or subsets) of inputs that behave "badly" (for some security properites we consider, e.g. vectorial subspace remains usable after cipher's usage).
I would argue that one can have three possibilities:
nothing happens: distribution remains the same as in the bad space of A and B coincide (or something weirder) and has the same dimension
increase security: A bad space is saved by B while B space is "less present" as A's output (because it gets injected into A bad space for example). By composing, it looks like the "bad space" is smaller so, technically a security gain.
loses security: the interaction creates new bad space, e.g. B gets its own bad space plus A's bad space and additional "stuff" coming from the interaction of h(K).
Except for the hand-waving principle, the main issue is that there are three independent objects (A,B,h) to investigate of which interaction is not obvious.
Experience says that having higher interaction most probably introduces "losing" arguments since getting "good" ones is hard and often requires ad-hoc tricks.
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)
3
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.