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

61–70 of 140 posts

Re: The Cryptographic Doom Principle

#61

Post by tptacek »

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…

The modern argument isn't "don't roll your own crypto". It's "don't build with crypto until you've learned how to break crypto". There are plenty of resources for people to learn how to do that online. Skipping that step and then shipping weak crypto is inexcusable.

Re: The Cryptographic Doom Principle

#62

Post by bitL »

3am wrote: post #47
bitL wrote: post #40

Earlier quoted context omitted.

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

Ad 2) most groundbreaking projects you know originated as messy ad-hoc personal projects and not in production-sanitized environments (look even at GPG, embarrassingly for crypto community with one almost bankrupt developer). Crypto-logy/graphy is an art, someone has a bright idea while lacking in other dimensions; the crypto community instead of embracing this idea and helping this person to bring something excellent to the world, shoots them instead down and point to obvious flaws that can be fixed in minutes by someone experienced, while keeping the new idea intact. The crypto requires such an enormous amount of talent that it is bright individuals, not companies, that make things move there, and quite often the more people involved, the worse results.

Re: The Cryptographic Doom Principle

#63

Post by rudolf0 »

stouset wrote: post #30
dustyleary wrote: post #8

Earlier quoted context omitted.

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

Exactly. And if the first cipher is a secure cipher, with no obvious sign it'll be broken any time soon (like AES), why not just use it instead of wrapping it over some homebrew solution?

Re: The Cryptographic Doom Principle

#64

Post by kkl »

tptacek wrote: post #61
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…

The modern argument isn't "don't roll your own crypto". It's "don't build with crypto until you've learned how to break crypto". There are plenty of resources for people to learn how to do that online. Skipping that step and then shipping weak crypto is inexcusable.

I agree but you are the first person I've seen frame it in that way. I see people spew "don't roll your own crypto" often. Hopefully some variation of your "modern argument" becomes more prevalent in the near future. It is certainly more meaningful.

Re: The Cryptographic Doom Principle

#65

Post by kelson »

madez wrote: post #42
kelson wrote: post #36

Earlier quoted context omitted.

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

Was CC and KC both performed on the Pi? That introduces side channel attacks.

Does CC include implementation flaws enabling remote access? An attacker may use the Pi to enhance attacks against the system executing KC.

Does the Pi include any remotely exploitable flaws? See before.

If assume a perfect/non-exploitable CC/Pi, we may not degrade the security of KC. That key word, may, is the problem professional cryptographers spent years analyzing though. If we spent a month thinking about this, we might identify other requirements needed to avoid weakening KC. This is not recommended.

Systems which rely upon cipher-obscurity are not secure. Most amateur cryptosystems are trivially defeated without any knowledge of their internals (FBI has some nice articles on cryptanalysis of criminal ciphers). Advising amateurs to rely upon homegrown ciphers is unprofessional and encourages bad risk mitigation strategies.

We also disagree about the difficulty of breaking non-keyed bijections (trivial) versus AES-at-scale ("not trivial"). The cost of the latter easily exceeds $1B. The former would take a trained cryptanalyst less than a month. Is your data worth <$10,000?

Re: The Cryptographic Doom Principle

#66

Post by angry_octet »

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…

And it has the added benefit from the NSA's point of view that your connection/data is precisely fingerprinted as 'homebrew-crypto-1629: refer to analysis cell 2865JQ'.

Then the computer is sub basement 19 goes 'ding!' and sends an automated SWAT team to your house.

Re: The Cryptographic Doom Principle

#67

Post by tptacek »

kkl wrote: post #64
tptacek wrote: post #61

Earlier quoted context omitted.

The modern argument isn't "don't roll your own crypto". It's "don't build with crypto until you've learned how to break crypto". There are plenty of resources for people to learn how to do that online. Skipping that step and then shipping weak crypto is inexcusable.

I agree but you are the first person I've seen frame it in that way. I see people spew "don't roll your own crypto" often. Hopefully some variation of your "modern argument" becomes more prevalent in the near future. It is certainly more meaningful.

Ok, and thank you for listening to me, but let me just add that in every instance I know of where someone has been berated for shipping crypto without having a background in it, those people also hadn't taken the time to learn how to break crypto.

So agree that the argument you're calling out has the potential to be harmful in the long run, but do not agree that it has harmed anyone we know of, and would add that it has --- to the extent it's warded people off things like Cryptocat --- helped end-users.

Re: The Cryptographic Doom Principle

#68

Post by [deleted] »

bitL wrote: post #62
3am wrote: post #47

Earlier quoted context omitted.

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

Ad 2) most groundbreaking projects you know originated as messy ad-hoc personal projects and not in production-sanitized environments (look even at GPG, embarrassingly for crypto community with one almost bankrupt developer). Crypto-logy/graphy is an art, someone has a bright idea while lacking in other dimensions; the crypto community instead of embracing this idea and helping this person to bring something excellen…

[deleted]

Re: The Cryptographic Doom Principle

#69

Post by madez »

stouset wrote: post #54
madez wrote: post #24

Earlier quoted context omitted.

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.

Technically correct is usually the least useful kind of correct. The root of this thread is extremely sound advice. Don't touch your own crypto unless you're an expert. If you're at the point where your security requirements are so sensitive that you can't possibly risk a break in an underlying well-known cipher, you should hire a real cryptographer and not dick around with inventing your own laughably-broken ciphers…

So I think it comes down to whether the root

> I think there's a more fundamental cryptographic principle. Don't implement cryptography, unless you are an absolute top expert.

is a sound advice.

I disagree with this advice strongly. Tinkering around with cryptography can teach you a lot. Especially if you are not a top expert.

Furthermore, I described a relatively simple protocol that monotonically increases the security of a communication by applying a custom cipher. I didn't add the restrictions that CC must not know anything about KC anything because I though that would be clear.

Interestingly, you get security through obscurity on top of the previous security from my scheme even when CC is trivial like swapping the nibbles in bytes and then xoring a constant. This makes untargeted mass-surveillance in case of broken KC a lot harder. Depending on the CC it's relatively easy to make it totally impractical.

I think my scheme is interesting because it's unintuitive that it adds any security.

Re: The Cryptographic Doom Principle

#70

Post by madez »

rudolf0 wrote: post #63
stouset wrote: post #30

Earlier quoted context omitted.

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

Exactly. And if the first cipher is a secure cipher, with no obvious sign it'll be broken any time soon (like AES), why not just use it instead of wrapping it over some homebrew solution?

Because you get obscurity which makes automated cryptoanalysis of your communication a lot harder (if not impossible) which in turn makes untargeted surveillance more expensive.
Post reply on HN