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

41–50 of 140 posts

Re: The Cryptographic Doom Principle

#41

Post by 3am »

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…

I could not disagree with you more.

Maybe you could suggest what might be "more helpful" but I personally could not think of anything more useful that than telling people to not do something that puts their customers' and their own critical information at risk.

Good crypto algorithms don't get stale or anything. The point is they're fundamentally difficult.

Perhaps you could give a single decent reason for rolling your own crypto algorithm, vs something as easy as 4096 bit RSA or something.

Re: The Cryptographic Doom Principle

#42

Post by madez »

kelson wrote: post #36
madez wrote: post #31

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*. 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 potent…

Okay, this is how I'd ad-hoc implement the scheme I described without the security problems you are commenting. A and B know each other and exchange the custom cipher securely. Imagine they each have a Raspberry Pi which does nothing else then to take each IP package sent from the other side and reverse the custom transform on the data. For each package that it sends to the other party it applies the custom transform to the data. Now A and B can route their internet traffic through their Raspberry Pi and get security by obscurity for their communication on top of the usual security. Even if the custom transform is simple, it's overwhelmingly probable that no automated TLS-break-tool will be able to break the custom transformed TLS traffic to the other party.

Re: The Cryptographic Doom Principle

#44

Post by superuser2 »

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…

>enforces the culture of elitism in information security

The NSA is elite. Nobody has any business trusting you to outsmart them unless you are also elite.

This is like complaining that nobody will bet on you to defeat Gary Kasparov means there is a culture of elitism in chess. Of course there is. It's a game of skill. Other people are more skilled than you, by a lot, and you're probably going to lose.

Re: The Cryptographic Doom Principle

#45

Post by sarciszewski »

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.

> you seem to be responding to an argument that wasn't made.

I seem to be, but I'm not.

> 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 written towards ALL developers. In the scope of web developers that I reside, this is my rebuttal.

Some crypto experts are quick to demand people use something that isn't necessarily available to the developer. Then the language elitists tell them to switch to their preferred language instead of improving what the developers already know. End result? People just use insecure or badly designed crypto libraries.

We need better libraries. Someone has to write them. Or just make libsodium the standard. I'd be okay with that.

Re: The Cryptographic Doom Principle

#46

Post by angry_octet »

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…

So wrong. Your custom cipher could be leaking key material in the encrypted output, almost certainly leaks the key via timing channels, could be leaking the known cipher key by timing channels and more (and this is assuming separate keys).

The CC decode stage will be subjected to every possible edge case to see if it will do something dumb, like the oracle attacks mentioned in the article. And it could also leak information about the KC decode via timing attacks.

If this was for offline file encryption, where you do the steps separately, maybe okay. But not for online encryption where chosen plaintext is possible.

Re: The Cryptographic Doom Principle

#47

Post by 3am »

bitL wrote: post #40
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 s…

1) Experts in all fields are always wrong sometimes. The nonexperts are wrong more frequently on average and people are less interested in proving them wrong.

2) Saying that implementing your own cryptography usually implies a production environment. I think it's generally assumed that nobody cares what people do with their own time/personal projects.

3) Trite sounds bites don't work in science either, and expert -/-> celebrity.

Re: The Cryptographic Doom Principle

#48

Post by madez »

angry_octet wrote: post #46
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…

So wrong. Your custom cipher could be leaking key material in the encrypted output, almost certainly leaks the key via timing channels, could be leaking the known cipher key by timing channels and more (and this is assuming separate keys). The CC decode stage will be subjected to every possible edge case to see if it will do something dumb, like the oracle attacks mentioned in the article. And it could also leak info…

Read this thread.

CC is a bijective function on (blocksize of KC) bits.

CC knows nothing at all about KC.

Implementation can be done in another computer without security problem while you get obscurity.

Read this thread.

Re: The Cryptographic Doom Principle

#49

Post by tekromancr »

sarciszewski wrote: post #43
tekromancr wrote: post #34

Earlier quoted context omitted.

Rectal-Numerical Generation...

Um, no. http://w3techs.com/technologies/overview/programming_languag... Currently 82%, last time I checked it was 83%.

Looks legit. My apologies. I was unsure of how they would even go about determining that, but after reading their methodology and limitations, it seems that is a somewhat representative number.

Re: The Cryptographic Doom Principle

#50

Post by lvh »

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…

I've tried; http://www.crypto101.io.
Post reply on HN