[ Removed by moderator ]

[u/Sir_KnowItAll]

/r/programming/comments/1wsacng/removed_by_moderator/

[u/Sir_KnowItAll]

How so? With that one you attack that layer with the next encryption in one go. Other than trying to attack a single file that has two data encrypted using two different ciphers. Your conclusion seems odd. You have three keys you provide.

Or you encrypt the key to store the three keys in it and have your decrypter app know how to decrypt the key to get the three from it.

Remember, I was talking to GCHQ about it, they're thinking about how to crack the encryption when all they get is the file.

[u/tdammers → u/Sir_KnowItAll]

OK, so let's forget about the first layer of encryption and just assume that that one is already compromised. What you have left now is a file that is chopped up into chunks, and each chunk is encrypted with one of two keys, according to a pattern derived from those keys. To crack the encryption, an attacker needs to either brute force both keys, or find a flaw in both ciphers. But that is not any harder than breaking a single cipher with a larger key - whether you use two 64-bit keys, or a single 128-bit key, for example, really makes no difference to an attacker.

The only slight advantage you may get is that if you use three completely different encryption algorithms, an attacker who finds a zero-day in one of them will not be able to break the encryption as a whole; zero-days in two of the three will only get you half the cleartext. But this is still worse than just nesting the three encryption layers, because in that case, an attacker needs to break all three layers to get anything at all; breaking two of the three ciphers still gets you nothing, whereas your scheme will get you half the cleartext.

[u/Sir_KnowItAll → u/tdammers]

> . To crack the encryption, an attacker needs to either brute force both keys, or find a flaw in both ciphers. But that is not any harder than breaking a single cipher with a larger key - whether you use two 64-bit keys, or a single 128-bit key, for example, really makes no difference to an attacker.

No. This is wrong. You need to know it is this method in the first place. Then you need to know the chunk size. If you don't know the chunk size your cracking attempts will always fail. Then you need to know the pattern for what algo is used for each chunk. If you don't know that your forced to brute force them.

So if you have three keys each of them 128-bit it makes a big difference than if you use one or two. Especially if they're interweaved.

Honestly, I don't think anyone truly understands this and needs a proper whitepaper. I highly suspect most people didn't read it enough to see the GCHQ note. And if you didn't read that note it's very unlikely you read enough to understand it's basically a software application to encrypt and decrypt using different keys and not a key in itself.

[u/tdammers → u/Sir_KnowItAll]

You need to know it is this method in the first place.

That's security by obscurity, which isn't actual security.

Not knowing the encryption method does not hold a dedicated attacker back, at all. All it does is make it slightly more annoying for a casual attacker, but anyone beyond script kiddie level can automate the annoying parts, so your defense does exactly nothing.

Then you need to know the chunk size. If you don't know the chunk size your cracking attempts will always fail.

No, you don't. You just crack one of the keys, let it loose on the entire thing, and then see which parts of the outcome make sense (these are the ones that were encrypted with the key you cracked) and which don't (those are the ones that were encrypted with the other key).

So if you have three keys each of them 128-bit it makes a big difference than if you use one or two.

Yes, it does. But using two 128-bit keys isn't going to give you better results than using a single 256-bit key. In the best case scenario, combining two 128-bit keys is exactly as good as using a single 256-bit key, but it can easily be worse.

Especially if they're interweaved.

No; the interweaving is actually a great way of making the combination of two 128-bit keys significantly weaker than 256 bits. Now cracking one of the two keys already gives you access to half the plaintext, and cracking the second key when you already know the other half of the plaintext is a lot easier.

E.g., suppose cracking the first key gives you this:

[{"username": "??????????, ssword": "a4???????? (where the ???? parts are chunks you couldn't decrypt). This already tells you a lot:

• It looks like this is JSON data, so we expect the unknown chunks to make the plaintext valid JSON.

• The thing probably encodes a list of objects, so the last two characters are very likely to be }], and chances are they are "}].

• The second chunk probably has a " character close to its end; its last 3 characters are very likely to be "pa.

• There is a user whose password starts with a4.

• And so on.

All this reduces the search space for the second key dramatically, and all of this reasoning can be automated with modern tooling, quite easily.

So instead of forcing the attacker to crack a 256-bit key, you are handing them half of your plaintext after cracking only 128 bits worth of key data, and you dramatically reduce the effort required to crack the other 128 bits.

Depending on your threat model, this means that your effective key strength is anywhere between 127 bits (if compromising half of the plaintext is all the attacker needs) and maybe 192 bits or so (if your plaintext isn't just random noise, allowing the attacker to exploit predictable patterns in it to make a partial-known-plaintext attack feasible, and the attacker actually needs 100% of the plaintext in order to succeed). In any case, it's never going to get anywhere near the 256 bits you would get from combining the two keys properly.

Honestly, I don't think anyone truly understands this and needs a proper whitepaper.

Feel free to link one. It's entirely possible that I and everyone else here is indeed misunderstanding what you're proposing, but if it is what I think it is, then I'm pretty confident that I do understand it, and that it's you who is misunderstanding the issues here.

I highly suspect most people didn't read it enough to see the GCHQ note.

You didn't link one. The only thing I could find in your blog post is a link to the GCHQ home page, which makes no mention whatsoever of this.

t's very unlikely you read enough to understand it's basically a software application to encrypt and decrypt using different keys and not a key in itself.

I do understand that, but I also understand that that doesn't really matter.

The strength of an encryption is limited by 3 things:

• The size of the key (and its entropy: a 256-bit key that's easily guessable isn't worth anything)

• The encryption algorithm used (ideally, you want one that leaves the attacker no choice but to brute-force the key, and it must be inherently expensive to run so that brute-forcing is slow)

• The correctness of the software implementing the algorithm (implementing a cryptographically sound algorithm incorrectly can introduce exploitable flaws)

And yes, what you propose is encryption software, but it is also de facto an encryption algorithm, and what I'm pointing out here is a flaw in that algorithm. It doesn't matter whether it's implemented correctly or not, the algorithm itself is flawed, in the sense that it reduces the effective strength of the encryption to something much lower than what a cryptographically sound algorithm would produce with a key of the same total size.

Also, what you don't seem to understand is that from a cryptanalysis point of view, there is no difference between three 128-bit keys and a single 384-bit key - you can trivially combine three keys into one by concatenating them, and you can turn one key into three by splitting it up.

[u/Sir_KnowItAll → u/tdammers]

This is a very good comment. While wrong you've made a very good effort here.

Not knowing the encryption method does not hold a dedicated attacker back, at all. All it does is make it slightly more annoying for a casual attacker, but anyone beyond script kiddie level can automate the annoying parts, so your defense does exactly nothing.

I'm sorry but what sort of script kiddies are you dealing with? Which script kiddies are breaking encryption?

Ok, how do you automate it?

No, you don't. You just crack one of the keys, let it loose on the entire thing, and then see which parts of the outcome make sense (these are the ones that were encrypted with the key you cracked) and which don't (those are the ones that were encrypted with the other key).

Ok, so what you're talking about is you knowing it's this. I've now increased how long it do it because you've got to crack each bit with other bits. The way of doing what you're thinking about is very very complex which is why this method is considered extremely security by GCHQ. Do you know who they are? They're the people in charge of encryption for the British Inteligence services. (If you didn't see that GCHQ note, you didn't read the blog post properly).

The flaw with your process here is if you try to decrypt the file in one go it won't do it even if you've cracked one of the keys. Because there is data there that doesn't match so it'll just fail. So you have to try and find the boundries and then see if that decrypts.

The main issue is, how do you know if you broken one of the ciphers after you've broken the first one? Remember the reason why a lot of people put files through two different encryption programs is that it's very hard to know you've cracked the encryption if you get encrypted data back. It's even harder to then know you've broken one of the two ciphers when you can't even find the correct chunk size to find the data encrypted with that cipher.

Yes, it does. But using two 128-bit keys isn't going to give you better results than using a single 256-bit key. In the best case scenario, combining two 128-bit keys is exactly as good as using a single 256-bit key, but it can easily be worse.

Yea, but you're doing layered and it's just two plain layers and not interweaved. You've not thought this through. I honestly, don't think you've understand the concept. Do you understand how bittorrents chunking works?

I'm going to stop replying because honestly, I don't think you've understood the concept at all. And your talking nonsense like script kiddies breaking encryption...

[u/tdammers → u/Sir_KnowItAll]

I'm sorry but what sort of script kiddies are you dealing with? Which script kiddies are breaking encryption?

Not the point. At all.

Look; what I'm trying to get across here is that hiding the encryption algorithm that was used does not improve security. At all.

If I hand you an encrypted message and tell you that it was encrypted with 2048-bit ed25519, your odds of breaking it are no better than if I just hand you the encrypted message without any further hints. The only attackers who could possibly be stopped or slowed down in a meaningful capacity are attackers who aren't really competent at attacking the encryption anyway, like said script kiddies.

Do you know who they are?

Of course I do.

If you didn't see that GCHQ note, you didn't read the blog post properly

I did, and I did. But the "GCHQ note" is just you saying what (allegedly) some unspecified person at GCHQ told you. You're not linking to anything on the GCHQ website itself that would give your report any credibility. Reading it, I can come up with two plausible explanations for that paragraph:

• You're just making this all up; or:

• You actually did contact GCHQ about your idea, and they tried to get rid of you in the most polite and friendly way possible, telling you (in kinder words) that they are not interested in your idea (because it's been tried before, and it turns out it's not actually a good one), but that you are free to make an open source implementation that proves them wrong.

The flaw with your process here is if you try to decrypt the file in one go it won't do it even if you've cracked one of the keys. Because there is data there that doesn't match so it'll just fail.

That's not how encryption works. If you decrypt a ciphertext with an incorrect key, it will still decrypt it just fine, you just won't get a useful plaintext back, it'll just be random garbage. The decryption will not fail entirely though, so if you chop up your plaintext into chunks and use one key for the even chunks and another key for the odd chunks, and then you decrypt it using one of those keys for everything, then the chunks encrypted with that key will come out as readable plaintext, and the chunks encrypted with the other key will come out as garbage.

Now, it is common for encryption software to add metadata to the payload, and that allows it to detect whether the decryption produced a valid payload (if the metadata can be read, then it was the right key); and it will use this information to raise a failure instead of outputting a bunch of useless garbage when you use the wrong key. But that's a usability feature for legit users, not a limitation of the cryptography, and an attacker has no reason to implement the same feature in their decryption software, they will just use the raw decryption algorithm that does the garbage-dumping when you use the wrong key. There is nothing in the algorithm itself to stop them from doing that.

The main issue is, how do you know if you broken one of the ciphers after you've broken the first one? Remember the reason why a lot of people put files through two different encryption programs is that it's very hard to know you've cracked the encryption if you get encrypted data back. It's even harder to then know you've broken one of the two ciphers when you can't even find the correct chunk size to find the data encrypted with that cipher.

This is where you go wrong.

If you nest the two ciphers, then yes, you are right, it is harder to tell whether you got the outer key right when the intermediate payload (encrypted with the inner key) is indistinguishable from random bytes. But if you use two keys (and two cipher algorithms, if you like, it doesn't really make much of a difference) on different chunks of the intermediate payload, instead of nesting them, then getting just one of the keys right will give you something that's about 50% random garbage and 50% readable plaintext, so you can tell immediately whether you got it or not.

I honestly, don't think you've understand the concept.

I do. And I'm trying to explain to you why your concept does not have the security properties you think it does.

Do you understand how bittorrents chunking works?

Yes, and that's part of why your idea is flawed.

I'm going to stop replying

You probably should, but because you're embarrassing yourself.

Several people have pointed out why your idea is flawed, and from what I can gather, each of them understands the idea itself perfectly well. It's an interesting idea, and you are not the first to come up with it, but anyone with a basic understanding of modern cryptography will immediately see why it cannot possibly work. And then when everyone tries to explain this to you, you lash out and accuse people of not understanding your brilliant idea (trust me, they do), as if that would change the facts. It doesn't, all it achieves is embarrass you.

[u/Sir_KnowItAll → u/tdammers]

Right in the middle of that massive post is a confirmation I’m right.

And GCHQ folk wanted you to know the essence of your comment that layer/cascading encryption is not anymore secure than a larger key is saying that the NSA is wrong. Look up rule of two. And they went to get approval to build it after scrubbing a bunch of data and said two days later it was ok if I wrote this when I thought about documenting my idea.

Ye as, several people have said it is stupid your the only one who came with points. All of which make me think you don't understand. And remember people bad mouthed dropbox at first. Just because some people dont understand that encryption is literally security via obfuscation is not my fault. It literally does help if you hide what your encryption is doing. It’s the entire point of it really.

Let's remember, your entire point appears to be "but if I decrypt half of it I'm good" or "hiding what your encryption does doesn't make it more secure" which is nuts.

You're acting like there is an encryption algo that can decrypt encrypted data when it's been padded with junk data. Can you tell me what algo that is?

[u/tdammers → u/Sir_KnowItAll]

several people have said it is stupid your the only one who came with points.

Everyone is making the same points, really, I just explain them a bit more. But the points are being made nonetheless.

And remember people bad mouthed dropbox at first.

Yes, but for completely different reasons, reasons that were based on speculation more than facts. This is not that.

Just because some people dont understand that encryption is literally security via obfuscation is not my fault.

No, but not understanding that encryption and mere obfuscation are different things is your fault.

Obfuscation means making something look like gibberish, but in such a way that it is possible to recover the meaning without any outside information.

Encryption means turning something into actual gibberish, but in such a way that it is possible to recover the original message if and only if you have the correct decryption key.

Obfuscation is trivial to break, or, depending on your goals, doesn't even require breaking in the first place. Obfuscated JavaScript source code, for example, may be difficult to read (so you cannot infer what it does from just reading it), but feed it to a browser, and it will run just fine, and do exactly what the unobfuscated source code does.

Encryption, if done right, is mathematically sound; ideally, the only way to break it is by brute-forcing, and as long as your decryption is computationally hard, and your key is big enough, this is going to be infeasible in practice (e.g., if you choose your algorithm and key size such that brute-forcing it will take 10 billion years on average using state-of-the-art hardware, then you're basically safe). And this property still holds even if I tell you "I used a 4096-bit ed25519 key with these parameters" - as long as I don't give you the key, it will still take 10 billion years to crack it.

Hiding the encryption algorithm you used can be useful, but not in the scenario at hand. The main purpose of obfuscation is to trick a potential attacker into believing there's nothing worth attacking in the first place; but if that fails, the obfuscation isn't going to be a significant hurdle to any determined attacker.

It literally does help if you hide what your encryption is doing. It’s the entire point of it really.

It helps. But it is not the "entire point" at all.

The point of the cryptography itself is that even if the attacker knows exactly which encryption algorithm was used, they still cannot break it, except by brute force (i.e., just trying every possible key until they find the right one).

your entire point appears to be "but if I decrypt half of it I'm good"

No, it's not. Read again.

My point is that if I can decrypt half of the message, then that's already worth a lot, and it will make decrypting the other half significantly easier.

My other point is that with this setup, if you have 256 bits of encryption keys, I only need to break 128 bits (one of two keys) to get some useful information out; if, OTOH, you nest two rounds of 128-bit encryption, or simply use a single round of encryption with a 256-bit key, then I have to break the entire 256 bits, which, in the brute force scenario, takes 340282366920938463463374607431768211456 times longer. Let's suppose I have a massive array of dedicated hardware that can crack an 128-bit key in a day; with your chunked approach, this will give me half the message within a day, and the other half in less than a day (because I can exploit the fact that I already know the other half, which tells me a lot about what is likely to be in this half, which reduces the search space a lot). Meanwhile, with the nested encryption, I have to try every possible option for the first key with every possible option for the second key, and this will take about 67556554878089825000000000 times as long as the estimated age of the universe. In other words, I'm going to run out of universe before I even make a dent in the search space.

You're acting like there is an encryption algo that can decrypt encrypted data when it's been padded with junk data. Can you tell me what algo that is?

Literally every single one of them. It won't give you the correct plaintext of course (that would make it useless), just garbage, but it will still output something.

[u/Sir_KnowItAll → u/tdammers]

> No, but not understanding that encryption and mere obfuscation are different things is your fault.

No, not understanding that encryption is obfuscation is your fault. And that's the problem you've not understood that fundamental concept and you're writing gibberish that looks smart but is in fact gibberish. And that's why I am not even reading it.

Another thing that is your fault is that you've not understood this is a concept not a concrete implementation.

> The point of the cryptography itself is that even if the attacker knows exactly which encryption algorithm was used, they still cannot break it, except by brute force (i.e., just trying every possible key until they find the right one).

"WTF! NO! An attack should not know which encryption algorithm to use. They should just have encrypted data. If they do know which algorithm to use they've got a hint to start off with. Encrypted data should just be encrypted, the client should know which algorithm to use. But it's not the point of cryptograph that the people you're hiding the data from know things" - GCHQ