Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Cryptographic Doom Principle

thoughtcrime.org

Post reply on HN
Print view View original

31–40 of 140 posts

Re: The Cryptographic Doom Principle

#31

Post by madez »

Strilanc wrote: post #26
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…

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…

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

Yes :(

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

This are for the point of my comment irrelevant implementation details. You could apply the custom transform on another computer.

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

The custom transform ought to be a bijective function on (blocksize of Strong) bits.

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

It was never meant as a suggestion for wide-spread usage.

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

The custom transform shouldn't know at all about anything of the strong cipher. Another implementation detail.

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

Another implementation detail.

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

I just wanted to show the common idea of "cryptography is black magic, you should never touch it, you can only do bad things" wrong.

My scheme adds security through obscurity which may be worth the trouble.

Re: The Cryptographic Doom Principle

#32

Post by madez »

sirclueless wrote: post #23
madez wrote: post #15

Earlier quoted context omitted.

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.

No, sirclueless, I didn't change the scheme I wrote about.

Yes, it adds security through obscurity without losing security through well-known recommended ciphers.

Re: The Cryptographic Doom Principle

#33

Post by madez »

kelson wrote: post #27
madez wrote: post #19

Earlier quoted context omitted.

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…

We don't agree on the effectiveness of security through obscurity.

Re: The Cryptographic Doom Principle

#34

Post by tekromancr »

eru wrote: post #29
sarciszewski wrote: post #4

Earlier quoted context omitted.

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

Rectal-Numerical Generation...

Re: The Cryptographic Doom Principle

#35

Post by kkl »

The "Don't roll your own crypto" mantra is overly ambiguous and enforces the culture of elitism in information security. I hope that something displaces this regurgitated "advice" with something more helpful. I know Moxie's article is a few years old but it is a step in the right direction regardless.

--EDIT--

I don't think I was perfectly clear in my original comment. I attempted to expand on my position in a follow-up comment: https://news.ycombinator.com/edit?id=9376131

Re: The Cryptographic Doom Principle

#36

Post by kelson »

madez wrote: post #31
Strilanc wrote: post #26

Earlier quoted context omitted.

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…

> Most of the responses seem to be talking about A -> Custom -Strong -> Unstrong -> Uncustom instead of A -> Strong -> Custom -> Uncustom -> Unstrong*. Yes :( > 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 cod…

> I just wanted to show the common idea of "cryptography is black magic, you should never touch it, you can only do bad things" wrong.

Per the other thread, this is overwhelmingly likely to decrease overall security without any practical benefit.

> My scheme adds security through obscurity which may be worth the trouble.

It adds potential side channels and likely no benefit over KC alone. You've sidelined many potential problems by focusing on "if the composition is properly implemented," but that's a huge problem. The likelihood of properly implementing the composition is vanishingly small. It is very likely to be improperly implemented and provide less security than KC alone (and it costs more!)

Re: The Cryptographic Doom Principle

#37

Post by anon4 »

corndoge wrote: post #25
sarciszewski wrote: post #4

Earlier quoted context omitted.

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

His point does bear consideration - the expert-written libraries are only expert-usable. You can still badly mess up encryption even if your basic building blocks are written perfectly. It's not just the algorithms that need to be expertly written, it's the way they're combined that also needs to be expertly written and the latter part doesn't exist. OpenSSL allows you to shoot yourself in the foot pretty easily, like choosing very weak ciphers, calculating the mac of the plaintext, etc.

OpenSSL is still too low-level for the generic developer. You want things like HTTPS, using which is still too complicated for most people (hello certificate management), but you can get it right more easily by following an online tutorial. Basically anything that is more complicated than "open socket to destination, here's my certificate" is doomed to be misused by non-experts. Oh, and it better have strong default settings so it won't pick RC4 as the cipher or something.

Re: The Cryptographic Doom Principle

#38

Post by madez »

kkl wrote: post #35

The "Don't roll your own crypto" mantra is overly ambiguous and enforces the culture of elitism in information security. I hope that something displaces this regurgitated "advice" with something more helpful. I know Moxie's article is a few years old but it is a step in the right direction regardless. --EDIT-- I don't think I was perfectly clear in my original comment. I attempted to expand on my position in a follow…

This.

The problem is that in this community you are witch-hunted if you talk about crypto and you are not a famous cryptographer.

People start with the assumption that what you are saying is wrong (this is a good thing). But then many don't have the competence to judge what you are saying (no problem. we all are ignorant in many subjects). And then, they react as if you were really wrong (this is a huge problem).

Re: The Cryptographic Doom Principle

#39

Post by angry_octet »

bachback wrote: post #28
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…

Yeah, you got it, the people at NIST and M$ are going to do better than you.

'Academic and useless' research huh? Go read DJB's website some day, it is far from inapplicable. All the research that publicly disclosed HUGE holes in SSL? I think it's incredibly important.

As to good security being of little value, maybe ask Sony and Adobe (and even NSA) if they wished they had better security.

Re: The Cryptographic Doom Principle

#40

Post by bitL »

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.

Even experts can go terribly wrong; there are known embarrassing attacks that invalidated algorithms considered rock-solid for 10 years by some bright 15-year old students. Would you prevent those brights from tackling on better ways to do crypto because they aren't "top experts" yet? Most likely they will just run away in disgust and park their capabilities in less hostile field.

Celebritism doesn't really work in science; it only prevents progress.

Post reply on HN