The Cryptographic Doom Principle • Hacker News Board

Re: The Cryptographic Doom Principle

#21

Post by dustyleary » Tue, Apr 14, 2015, 4:45 PM UTC

sirclueless wrote: post #10

madez wrote: post #6

Earlier quoted context omitted.

Rendering KC useless by using CC as I described is equivalent to breaking KC. There is no other way of messing with KC when used the way I said. And you won't break KC by chance with your CC. Many people respond like you did and they simply didn't think about what I've said and repeat old ideas. I hate people.

This is not a true statement. CC may leak information about the plaintext in ways that KC can't handle, even without breaking it. For example, applying CC might deterministically affect the message length. One of my favorite cryptographic attacks ever was of this form, known as the CRIME attack [1]. It was a "partial plaintext" attack, where the "CC" in question was plain old gzip. Basically the attackers controlled…

What you (and the wiki link) are describing is plaintext -> CC (gzip) -> KC.

This is different than the argument you're replying to which is plaintext -> KC -> CC.

Re: The Cryptographic Doom Principle

#22

Post by bradleyjg » Tue, Apr 14, 2015, 4:47 PM UTC

mnw21cam wrote: post #2

I think there's a more fundamental cryptographic principle. Don't implement cryptography, unless you are an absolute top expert. Even then, think twice, and get another absolute top cryptography expert to check your working. Use a pre-existing cryptography package that has been written properly instead.

That's good advice, and I've given it myself, but that doesn't mean you shouldn't read and play around with cryptography if it interests you.

I implemented a simplified version of the referenced Vaudenay attack as part of Dan Boneh's Cryptography I course on courseara+. The course was very interesting, and also fun. I'm not ready to go out and implement my own cryptography, but knowing a bit about the subject makes me a more intelligent consumer of crypto libraries.

While warning people away from implementing their own cryptography we have to make sure we don't scare people off from the subject altogether. After all, absolute top experts have to start somewhere.

+ https://www.coursera.org/course/crypto

Re: The Cryptographic Doom Principle

#23

Post by sirclueless » Tue, Apr 14, 2015, 4:49 PM UTC

madez wrote: post #15

sirclueless wrote: post #10

Earlier quoted context omitted.

This is not a true statement. CC may leak information about the plaintext in ways that KC can't handle, even without breaking it. For example, applying CC might deterministically affect the message length. One of my favorite cryptographic attacks ever was of this form, known as the CRIME attack [1]. It was a "partial plaintext" attack, where the "CC" in question was plain old gzip. Basically the attackers controlled…

Read this thread again. Your statement is not correct since CC never gets to see the plaintext. CC is just a bijective function on (blocksize of KC) bits.

Did you edit your post? I'm not the only one who misread it. If KC is applied first to the plaintext, then assuming you didn't flub anything in implementation the combined scheme won't be less secure than KC, I agree. Applying CC effectively becomes security through obscurity, which is admittedly sometimes helpful.

Re: The Cryptographic Doom Principle

#24

Post by madez » Tue, Apr 14, 2015, 4:51 PM UTC

stouset wrote: post #20

madez wrote: post #3

Earlier quoted context omitted.

This is a common idea and it's flawed. Let KC be a well-known and implemented cipher and CC a custom cipher written by you. Instead of communicating like this: A -> KC-encrypt -> transport -> KC-decrypt -> B You can use: A -> KC-encrypt -> CC-encrypt -> transport -> CC-decrypt -> KC-decrpyt -> B The advantage is it breaks automated cryptoanalysis in case KC is broken. A better idea than the one you stated is: don't r…

Technically, you're correct. In the real world, you're not. This mythical protocol just encrypts a blob and sends it over the wire. But real protocols involving cryptography are significantly more complicated, because they often need to authenticate other parties, cryptographically bind all the messages in a session, preserve forward secrecy, preserve anonymity of one of the communicating parties, etc. Now the proble…

Technically correct is the best way of correct.

I never suggested my proposal for public protocols for communication between two random parties. I first and all wanted to show the root of this thread wrong.

I'd suggest it maybe for highly confidential communication that warrants the trouble.

Re: The Cryptographic Doom Principle

#25

Post by corndoge » Tue, Apr 14, 2015, 4:57 PM UTC

sarciszewski wrote: post #4

mnw21cam wrote: post #2

I think there's a more fundamental cryptographic principle. Don't implement cryptography, unless you are an absolute top expert. Even then, think twice, and get another absolute top cryptography expert to check your working. Use a pre-existing cryptography package that has been written properly instead.

> Use a pre-existing cryptography package that has been written properly instead. Okay, name one that has been written properly that the average web developer is going to encounter. I'm going to focus on PHP because that's what I know best, it has an enormous market share, and I'm not a fan of blowing smoke (which I would be if I tried to speak to, e.g. Perl development). PGP? OTR? Axolotl? These aren't part of your…

Considering that the original comment never specified web developers, you seem to be responding to an argument that wasn't made.

Re: The Cryptographic Doom Principle

#26

Post by Strilanc » Tue, Apr 14, 2015, 4:58 PM UTC

madez wrote: post #3

mnw21cam wrote: post #2

I think there's a more fundamental cryptographic principle. Don't implement cryptography, unless you are an absolute top expert. Even then, think twice, and get another absolute top cryptography expert to check your working. Use a pre-existing cryptography package that has been written properly instead.

This is a common idea and it's flawed. Let KC be a well-known and implemented cipher and CC a custom cipher written by you. Instead of communicating like this: A -> KC-encrypt -> transport -> KC-decrypt -> B You can use: A -> KC-encrypt -> CC-encrypt -> transport -> CC-decrypt -> KC-decrpyt -> B The advantage is it breaks automated cryptoanalysis in case KC is broken. A better idea than the one you stated is: don't r…

Most of the responses seem to be talking about A -> Custom -Strong -> Unstrong -> Uncustom instead of A -> Strong -> Custom -> Uncustom -> Unstrong*.

Some potential problems with applying a custom transform to the cyphertext:

- The custom transform might have effects on cache that create opportunities for timing attacks

- The custom transform might have a buffer-overflow (just like any other excess code)

- The custom transform might support features exploitable in DOS attacks, like run-length encoding

- The custom transform might be slow, costing time and money

- Sometimes applying two transforms is equivalent to encrypting with a different key (e.g. DES has this property). Might create meet-in-the-middle attacks.

- If the custom transform is given the same key as the strong crypto, as a lazy programmer might do, it could leak the key

- Switching the ordering of the transforms is a deadly mistake, but easy to glance over

- If the strong transform starts with an HMAC, as it should, that can be used to break the custom transform's key anyways (see the post we're commenting on)

Mostly those are small things. But the security benefit you get is also small.

Re: The Cryptographic Doom Principle

#27

Post by kelson » Tue, Apr 14, 2015, 4:58 PM UTC

madez wrote: post #19

kelson wrote: post #13

Earlier quoted context omitted.

You're right; I misread your construct as KC(CC(P)). Your construct [CC(KC(P))] shouldn't be weaker than KC, unless information or resources are shared by CC and KC (such as keys). Shared information or resources may introduce side channel attacks. Per the previous link, this is likely only practicable on entirely separate machines. Any entity that can break AES at-scale will undoubtedly find any unreviewed cryptogra…

Thanks for agreeing that we don't lose security when using my construct. > Any entity that can break AES at-scale will undoubtedly find any unreviewed cryptographic protocol trivial to break. Yes, but it would involve highly paid cryptoanalysts. The reason for my first comment is first of all to disprove the root of this thread. Secondly, it makes surveillance more expensive while it's free for us.

> Thanks for agreeing that we don't lose security when using my construct.

I don't agree. The construct may not degrade security under several caveats. Most implementations are extremely likely to share resources, which will introduce weaknesses. I'd wager those weaknesses would degrade security much more than the composition would enhance it, but it'd depend on the exact situation.

> Yes but it would involve highly paid cryptoanalysts. My proposal is first of all to disprove the root of this thread. Secondly, it makes surveillance more expensive while it's free for us. That what's cryptography all about. Making their life harder while not so much for us.

My exact point was that those cryptographers would already need to develop generic attacks for all the non-standard (read: non-secure) cryptosystems out there. Composing a homegrown cipher with a peer-reviewed secure cipher will not make their lives harder. It will make maintaining and improving the system harder. The net result is overwhelmingly likely to be detrimental.

Re: The Cryptographic Doom Principle

#28

Post by bachback » Tue, Apr 14, 2015, 5:04 PM UTC

mnw21cam wrote: post #2

I think there's a more fundamental cryptographic principle. Don't implement cryptography, unless you are an absolute top expert. Even then, think twice, and get another absolute top cryptography expert to check your working. Use a pre-existing cryptography package that has been written properly instead.

what kind of "experts"? like NIST experts or experts at Microsoft? this a non-sensical meme in cryptography. it all comes down to the value at risk. at some price point you can hire people i.e. invest the resources to get it right. the reality is that many security libraries and principles are ancient and infrequently updated, that much of the research in the field is academic and useless. I think its much better to think in terms of risks. good security usually doesn't more value than bad security, until there is a breach.

Re: The Cryptographic Doom Principle

#29

Post by eru » Tue, Apr 14, 2015, 5:05 PM UTC

sarciszewski wrote: post #4

mnw21cam wrote: post #2

I think there's a more fundamental cryptographic principle. Don't implement cryptography, unless you are an absolute top expert. Even then, think twice, and get another absolute top cryptography expert to check your working. Use a pre-existing cryptography package that has been written properly instead.

> Use a pre-existing cryptography package that has been written properly instead. Okay, name one that has been written properly that the average web developer is going to encounter. I'm going to focus on PHP because that's what I know best, it has an enormous market share, and I'm not a fan of blowing smoke (which I would be if I tried to speak to, e.g. Perl development). PGP? OTR? Axolotl? These aren't part of your…

Where did the 83% number come from?

Re: The Cryptographic Doom Principle

#30

Post by stouset » Tue, Apr 14, 2015, 5:07 PM UTC

dustyleary wrote: post #8

jxcl wrote: post #5

Earlier quoted context omitted.

That makes sense intuitively, but you can't approach cryptography intuitively. There are many cases where the intuitive answer is "well, the worst case is that it's just as good as without our custom wrapper... so let's do it." But under cryptographic analysis it is revealed that the custom wrapper renders whatever other good, accepted cryptography that is in play completely useless.

I need to see a citation for this. Something like the parent article exposing how things get mistakenly broken by applying this concept. It's important to be paranoid about implementing your own crypto, true. But it's not good to take this to dogmatic extremes, ie "never trust any code you write that has crypto in the name or you break everything". I would never write and deploy a custom cypher. But if I did, and my…

In madez's case, his construct is provably secure, with some caveats. Specifically, the first cipher must be a secure cipher, and the keys for both ciphers must be independent. If the latter is not the case, the custom cipher could very easily leak bits of the key, which would allow the original cipher to be broken.

But more importantly, it's the implementation of this construct that's likely to introduce weaknesses. As I posted in my direct reply to him, the problem is that no real world protocol is so simple, and he will now have to implement this. See OpenSSL for what can go wrong when implementing ciphers; and that's a highly-used, generally stable project that's had the benefit of multiple eyeballs for years.