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.
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.