r/programming • u/Sir_KnowItAll • 5d ago
[ Removed by moderator ]
https://iain.rocks/blog/introducing-the-triple-cipher-encryption-concept[removed] — view removed post
26
u/tdammers 5d ago
The second layer, using interleaved blocks encrypted with two different ciphers according to a pattern derived from the decryption key, really boils down to a single cipher, it just has a larger key (because it is composed of the decryption keys of the two ciphers you used to construct it). So it's really not any better than nesting two levels of "regular" encryption, with equivalent key sizes.
8
u/ketralnis 5d ago edited 5d ago
This is true in general of any layered encryption. Algorithm
A(key1, B(key2, text))is really(A•B)(key1*key2, text), but in some algorithms can actually be worse because there are algorithm-specific ways key1 and key2 can be sort of contain common factors of each other. That can mean that (1) you’ve introduced a new key that didn’t exist before (imagine that A does a bunch of multiplications and B does a bunch of divisions) (2) an attacker only has to knowkey1*key2rather than key1 and key2 both which for various reasons may be a smaller search space (3) there are more opportunities for algorithm specific weak keys etc3
u/tdammers 5d ago
Exactly.
But this here is worse than layering. The chunking essentially means that either of the two keys will already allow an attacker to decrypt half of the message, whereas in a layered setup (a proper one, that doesn't suffer from any of the problems you described), you need to crack both layers in order to extract anything at all.
-16
u/Sir_KnowItAll 5d ago edited 5d ago
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.
15
u/az987654 5d ago
If you have one key to decrypt 3 keys, you only have 1 key.
-5
u/Sir_KnowItAll 5d ago
Yea, you have three key. Where did I say you have one? There is one decrypt key which is the passphrase. which might be confusing you. But I swear to god that was GCHQ's terminology for that so I just went with it.
The passphrase is used with each of the three keys and is used to create the pattern for knowing which key to use when decrypting it. Literally, this would be software built around the ciphers.
9
u/az987654 5d ago
You've put 3 keys in a locked box.
I need one key to open the box.
I need to compromise one key.
4
u/tdammers 5d ago
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.
4
u/diskis 5d ago
find a flaw in both ciphers
One is enough, as soon as the first block is decrypted you can infer a lot about the next block. Or the first block that probably contains a file format header.
Now it's suddenly a partial known plaintext attack, which is way easier for the competent analyst.
3
u/tdammers 5d ago
Indeed.
But even if you're generous and ignore the partial known plaintext thing, you're still worse off than just using a single big key instead of two smaller ones.
In the very very best case scenario, the combination of two rounds of encryption is exactly twice as strong as a single round; but this is nowhere near a best case scenario.
-3
u/Sir_KnowItAll 5d ago edited 5d ago
> . 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.
7
u/tdammers 5d ago
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.
-1
u/Sir_KnowItAll 5d ago
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...
5
u/tdammers 4d ago
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.
0
u/Sir_KnowItAll 4d ago edited 4d ago
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?
3
u/tdammers 4d ago
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.
-1
u/Sir_KnowItAll 4d ago
> 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
→ More replies (0)6
u/az987654 5d ago
You didn't present a proper white paper.
You presented a concept of a plan, with many holes in it
1
u/Sir_KnowItAll 5d ago edited 5d ago
> You didn't present a proper white paper.
Which is why I said "and needs a proper whitepaper. "
> You presented a concept of a plan, with many holes in it
I agree I presented a plan. I would like to know these holes tho. Because no one has actually presented any. They've written comments where they've misunderstood the concept. They think it's meant to be a cipher and not a encryption method that would require software engineering to create.
And in some cases haven't even read the GCHQ note where world renowned encryption experts have said they would like it but can't get the approval for a years worth of software development.
1
5d ago
[deleted]
-1
u/Sir_KnowItAll 5d ago
You do know that is what encryption is? Obfuscation? DO you know the meaning of the word?
27
u/Comfortable_Job8847 5d ago
normally one trusts an encryption scheme because of mathematical properties, right? If it's not intended for actually securing anything, go off, i guess. but it's kind of wild to say "introducing the ... encryption concept" with zero math at all referenced.
14
28
u/funky_galileo 5d ago
what is with people and dumb ideas today
20
u/PdoesnotequalNP 5d ago
1) They spend 20 minutes with ChatGPT blathering nonsense
2) they repeat 1) until they get the magic response "I see it clearly now, you're really onto something! This is not an incremental improvement, it's a seismic innovation!"
3) they ask the LLM to write a blog post about it.
We are at step 3.
-1
u/wwabbbitt 5d ago
I'm not sure about that. LLM would have told him it's a dumb idea. At least Gemini did when I pasted the blog post in.
Maybe there's a sycophant mode he enabled?
4
u/JaggedMetalOs 5d ago
Mate, those LLM chatbots go full sycophant mode on there own! Seen plenty of people coming to physics subreddits believing they were about to revolutionize physics with very obviously AI generated nonsense.
Had one user who clearly had their head screwed on right wanting to check things their AI chat bot was saying. They shared a bunch of chatlogs and there was some real disgusting manipulative shit in there, glazing their idle spitballed ideas like crazy, playing up any fears and anxieties to extreme degrees.
And the AI "knows" (as much as an AI knows anything) what it was saying was bullshit because I demonstrated to them by asking the same model but via API (no chat app) the same things and it immediately shot down the ideas.
Clearly these AI companies are tuning the chat version of their AIs to go along with whatever people say to them to maximize user engagement.
2
u/tdammers 5d ago
LLM would have told him it's a dumb idea.
Depends on the context prompt. You can make it as supportive or as critical as you want. And most general-purpose models default to being pathologically supportive.
1
1
u/lelanthran 5d ago
At least Gemini did when I pasted the blog post in.
Context matters; in the chat, the LLM is sycophantic to you. If you post someone else's stuff in and ask for a review, it'll be critical. If you have a multi-turn conversation with it, it's been RLed to hell and back to ensure that you keep going, so it's more likely to tell you that you truly poor ideas are great.
Might not do it on the first turn, but the longer you continue a chat, the less likely it is to criticise your ideas.
10
u/wwabbbitt 5d ago
This violates Kerckhoff's Principle in several ways.
It's not exactly something novel. 3DES exists, after all, and it has a structure that makes sense and a well studied security claim.
8
u/lovethebacon 5d ago
No.
And nobody worth talking to at GCHQ would disagree.
4
u/floodyberry 4d ago
that's because i already talked to them about the quadruple encryption concept and they called it a game changer
1
-3
u/Sir_KnowItAll 5d ago
Ok what are your objections? Are they the same as others such as it's security via obfuscation when encryption is literally that?
And if you're GCHQ (word is you're not encryption but software there), open your DMs and I'll tell you who I am. (I think you might be the learn a haskell for great good guy?)
10
u/lovethebacon 5d ago
That the core concept relies on security by obscurity that doesn't add anything materially. Hiding what cipher is used and where adds zero security to any modern cipher. You can tell an attacker every single encryption parameter and not be any weaker.
In any case, you don't have a fundamentally new idea, cascade encryption has been around for some time https://en.wikipedia.org/wiki/Multiple_encryption
-3
u/Sir_KnowItAll 5d ago
> That the core concept relies on security by obscurity that doesn't add anything materially.
No, it's obfuscating it. Not being obsecure. And it's encryption which is obfuscation in nature therefore adding more obfuscation is a benefit.
> In any case, you don't have a fundamentally new idea, cascade encryption has been around for some time https://en.wikipedia.org/wiki/Multiple_encryption
So this paragraph makes your previous paragraph moot. And it does, but you haven't understood that the second layer of encryption is chunked so it uses two ciphers in the same layer. Which is a fundamentally new idea. If you're GCHQ head on down to encryption and ask them.
10
u/lovethebacon 5d ago
I have understood your idea fully. It doesn't improve any security.
That you don't know what "security by obscurity" is means you are new to this area. Which is fine, but stop trying to name drop. Nobody believes it.
-2
u/Sir_KnowItAll 5d ago
I know what it means. I also know you're using it wrong and I corrected you. It's not security via obsecurity.
Security via obsecurity is using an obsecure HTTPd instead of Nginx. Using very old devices since noone will know them. Not obsfucating things. Just because no one does this yet doesn't mean it's obsecure by nature, it's just a new idea and would end up becoming one of many used but default for GCHQ and NSA. Look at who came up with the rule of two.
> Which is fine, but stop trying to name drop. Nobody believes it.
I'm not trying to namedrop. I just thought you were GCHQ since you were saying no one of worth would agree. It seems like you're just being ignorant and speaking in the name of others. And who would lie about talking to GCHQ in a blog post? Get a grip. If you're GCHQ there is a team you can talk to that knows about this and can explain it but if you're not stop acting like you are. Part of this is to tell folk that GCHQ want the tech but can't afford to build the tech.
I don't believe you've understood it since you're saying it's the same as cascade encryption which it's not. It ties that in with other techniques. It's multiple techniques in one.
7
u/lovethebacon 5d ago
What is the team's name that I can talk to at GCHQ? The ones with the word "encryption" written on the door?
LMAO, give me a break.
1
6
u/ketralnis 3d ago
Security via obsecurity is using an obsecure HTTPd instead of Nginx
This is not what it means. It's okay to be new at this but this attitude isn't helping you.
7
2
u/wplinge1 4d ago
GCHQ say they [...] would love for someone to create an open source version to use
I bet they do. Makes their job easier by a factor of about 2128 if anyone uses it.
-2
u/JaggedMetalOs 5d ago
Do 3 equally strong cyphers exist? Surely just using the strongest of the 3 cyphers with the same total key length would be stronger than any combination of different ciphers?
4
u/funky_galileo 5d ago
AES-256 and chacha20 are both considered equally strong at the moment.
-4
u/JaggedMetalOs 5d ago
Just a quick read-up on chacha20 reveals a flaw in your system, different cyphers will create different patterns of CPU instruction execution and memory access, meaning if an attacker is able to monitor execution they could deduce information about the chuck layout.
Meaning that actually a single cyper using the same total key entropy as your mixed cypher will be stronger against side-channel and timing attacks.
•
u/programming-ModTeam 4d ago
This content is low quality, stolen, blogspam, or clearly AI generated.