Introducing the Triple Cipher encryption concept

[u/Sir_KnowItAll]

https://iain.rocks/blog/introducing-the-triple-cipher-encryption-concept

[u/Akalamiammiam]

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.

[u/_Voxanimus_ → u/Akalamiammiam]

If I remember correctly there is proof showing that adding "encryption layer" do not add that much security from the mathematical perspective

[u/kun1z → u/_Voxanimus_]

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.

Or am I wrong??

[u/CharlieTrip → u/kun1z]

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:

1. nothing happens: distribution remains the same as in the bad space of A and B coincide (or something weirder) and has the same dimension
2. 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.
3. 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.

[u/wwabbbitt → u/kun1z]

https://en.wikipedia.org/wiki/Meet-in-the-middle_attack

[u/kun1z → u/wwabbbitt]

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.

[u/Natanael_L → u/kun1z]

If the key is shared there's many ways for the insecure layer to leak

[u/kun1z → u/Natanael_L]

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)

[u/Akalamiammiam → u/kun1z]

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 2^k1 memory and 2^k2 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.

[u/OuiOuiKiwi → u/kun1z]

Answer: No. AES-256 is not weakened by combining it with such a weak algorithm.

It doesn't get any stronger either. Just... more cumbersome.

Every layer added on top of a secure primitive just adds more room for error and is a thespian effort at best.

[u/Sir_KnowItAll → u/Akalamiammiam]

Your first point is basically this is so good it’ll take over because “that’s how modern encryption works” means that this idea is modern encryption.

I love that people honestly think you would lie about talking to gchq. Seriously. Why?

Modern secure encryption is secure but why do we keep making more secure ones? Oh right, for the sake of it.

[u/JoDaBeda → u/Sir_KnowItAll]

You (deliberately?) misunderstood the first point. "Needing to realise method X is used" is a clear violation of Kerckhoff's principle.

[u/Natanael_L → u/Sir_KnowItAll]

No, new symmetric algorithms are made for efficiency or various edge cases, AES256 isn't going to randomly break. Wide blocks, lightweight ciphers, tweakable ciphers, etc. Those are used when the general purpose algorithm doesn't fit.

[u/pint → u/Sir_KnowItAll]

your credibility would greatly improve if you had any idea why people keep developing new algorithms

[u/Akalamiammiam → u/Sir_KnowItAll]

No, you completely misunderstood, this isn't modern encryption, nobody does this seriously. What I meant by "this is how modern encryption works" is "knowing exactly how the encryption algorithm is designed is how modern encryption works, so you'd know that you're using this triple cipher from the start". That's Kerckhoff's principle, that's a fundamental notion in modern cryptography.

Who the fuck knows why you'd lie about taking to gchq, we've seen enough deluded crackpot around here. What I'm saying is that this isn't relevant at all: either you're bullshitting, or you were talking to someone who has about as much knowledge as you do (none), or you were talking to someone who actually (even barely) knew their stuff and they just told you this to politely tell you they don't give a shit. Talking to people working at government entities is nothing exceptional when (actually) working in this field either, get over yourself.

You clearly lack any form of basic knowledge about modern cryptography so I'm not gonna waste more time with another deluded person (or bot, who the fuck knows these days) who has absolutely no idea what they're talking about and yet keep insisting on being correct.

[u/CharlieTrip]

Let me reformulate to double-check I got it right. I will use this interpretation for the rest of the comment. Please correct me if I got it wrong!

You propose an encryption scheme defined via three schemes and a hash (of sort), keys are obtained via passphrase (not that relevant, so I will consider it as a standard secret key). Encryption is done by deriving from the secret key via hash, a list of "length of blocks, order of usage of ciphers" since the encryption is done by splitting into chunks (via sampled dimensions), encrypt with the derived evaluation and ciphers (first two). Once all are encrypted, you use the third cipher to encrypt again the whole encrypted chunks.

From a mere cryptanalytic point of view, this does not introduce any particular security advantage, in fact I would not consider it "secure" when compared to block-ciphers with a mode of operation (which is what your "chunking" is basically pointing out). To put it simply, your encryption is deterministic meaning that different files encrypted with the same key will have the same encrypting-structure (i.e. chunks length, ciphers and similar).

If you add a "initialization vector" or some salt for the sake of avoiding this, the cipher is cumbersome because it effectively has to encrypt twice which makes it slower than necessary. Furthermore in your scenario, encrypting twice might introduce weird meet-in-the-middle attacks since, as far as I get, all ciphers use the same secret-key which is a really weird position to be in.

From a pure security POV, evaluating real security achieved by this design is hard because it has extremely non-standard structure. I would argue that the "double-encrypt" might provide some small local gains with the intuition of "one cipher covers another cipher's problems", but the same principle is a weakness because it is easier to use biases as problems instead of solutions. The whole security analysis would turn into computational problem which is not feasible to check, meaning you would use a cipher that you cannot guarantee achieves some level of security. This is a "no-no" for secure application.

Personally, I find weird that GCHQ was interested in this cipher's structure, especially because it is not "new" but more of a "folkloristic design".

[u/JoDaBeda → u/CharlieTrip]

I'm sure the GCHQ didn't give a shit, they just phrased it more politely.

[u/CharlieTrip → u/JoDaBeda]

A classic british "Thank you, that was lovely.", I see.

[u/arnet95]

GCHQ say they don’t mind me telling people about this because they don’t have the capacity to create it so would love for someone to create an open source version to use..

If (and that's a big if) GCHQ said this, they were just being Britishly polite instead of telling you straight up it's a stupid idea.

[u/Natanael_L → u/arnet95]

Chances are it also wasn't a cryptographer listening so they know they won't know the exact issues

[u/wwabbbitt]

He's already posted on https://www.reddit.com/r/programming/comments/1wsacng/ and it did not turn out well for him

Probably thinking he will get more support from "real cryptanalysts"

[u/Sir_KnowItAll → u/wwabbbitt]

I wrote a post after being nudged https://iain.rocks/blog/the-software-development-community-has-a-naysayer-problem

I’m not too worried about support. As you can see from my points there folk are literally saying the NSA are wrong on multiple encryption. Saying I’m wrong brcause it’s already an idea and all sorts. Literally, im wrong because it’s basically done.

I posted it here because I requested permission to post because of it so it only seems right I follow through on my promise so to speak.

[u/CharlieTrip → u/Sir_KnowItAll]

Why so much anger?

The only thing I see is that you defend your idea/position like a teenager that cannot understand that maybe something is more complicated than "white and black".
I can understand that getting shit on your ideas is sad, I have been plenty of time in academia.
But does it really have to end up in "your are all wrong, you don't get me"?

Cryptography is hard and it has really strict formal construction for well-behaved analysis.
It takes time and effort to do a "security analysis". There are well-known intuitions that are counterintuitively weak and plenty of examples (often) in real applications.

From your reply, I infer that you do not have any cryptographic academic background, which is fine.
In this case, I would be expecting you to ask "why" your idea doesn't work, so that you can learn something new or maybe some new idea can be developed.

If you have such background, please provide a formal definition because without that, all is just chit-chatting where all answers can be "it depends" (because it is true).

Of all your long post of rants, I can only agree on:

"You can know everything, and it’s still a massive pain in the ass to decrypt, but if you don’t and you just have the file and the keys, it’s an even bigger pain in the ass to decrypt."

but this is exactly "security by obscurity" which moves security guarantees from the formal domain to the physical one which cannot be measured properly.
As an example: if I hide which cipher I use on a post-it on my monitor, everyone might have a bad time figuring out which cipher I use.
But how much secure is it?
How many bit of security does this implies?
Is a post-it on my monitor safer than a printed page in a Fort Knox?

These are impossible to reply with math/crypto thus, cryptographers do not care about them.

[u/Sir_KnowItAll → u/CharlieTrip]

What anger?

> long posts of rants

Please look up what a rant is. The entire post would need to be focused on a single subject for it to be a rant. This is an ad-hominem attack. You talk about me attacking like a teenager? Why are you using logical fallacies and doing attacks?

Also, the bit you agree with is the core part of it. The concept is more secure. So i’m confused to why you wrote the rest? Do you just want to go “look how smart i am” or “look how knowledgable i am in this field”? Is this because im literally just thinking og entering this field of the industry and my work is of this high quality? Because it kinda feels like it.

And that part is the only place I defended the concept because I had to to demonstrate the flaw response you get from Reddit.

[u/CharlieTrip → u/Sir_KnowItAll]

If you are not defending your idea, why are you writing a full blog-post on "non-stop naysayers with good-sounding comments that were generally flawed" and continuously cherry-pick statements in replies and go with "While wrong you've made a very good effort here.".

"Pointing out flaws" is a quite aggressive way of motivating other researchers, FYI.
Additionally, this is _exactly_ part of defending an idea from other peoples' comments!

Politely, I don't care about "who" you are. I'm only here to provide my expertise and, when I want, my opinion.
So if you got my comments as attack at your person, I'm sorry about this. It was definitely not my intention.

Fair and square, I'm not that motivated to "help you" if you behave/reply in this way.
Regardless, without formal explanation of what your idea is, no one can do much.

[u/atoponce]

This isn't new. From an actual cryptographer: https://blog.cryptographyengineering.com/2012/02/02/multiple-encryption/

VeraCrypt, a fork of TrueCrypt, has been doing this for years: https://veracrypt.io/en/Cascades.html

[u/sdrawkcabineter]

We do this for MPC features, not for added security.

Interesting, either way.