Live data from Hacker News

The Cryptographic Doom Principle

thoughtcrime.org

51–60 of 140 posts

Re: The Cryptographic Doom Principle

#51
post #38
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).

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

I've been dealing with crypto on a near-daily basis for the last 15 years. I'm well within the top percentile of understanding of the subject, from a theoretical and practical standpoint, having worked to break cryptographic protocols for most of my life. I wouldn't trust myself to design a crypto protocol for grocery lists, let alone anything important.

This isn't false modesty or elitism or ignorance. It's recognizing that even if every smart person I know looks at it and says it's fine, it probably isn't. Crypto isn't hard to get right -- that's actually not the argument that anyone will make -- but it's impossible to know if you did get it right or not.

You do not have the knowledge required to build safe cryptographic protocols. Neither does anyone else on this site.

Re: The Cryptographic Doom Principle

#52
post #41
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 yo…

Excuse my ignorance, but why aren't there options for salting / seeding / external RNG alternatives to crypto algorithms?

Re: The Cryptographic Doom Principle

#53
post #41
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 yo…

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

I would not characterize implementing RSA safely as an "easy" task.

Re: The Cryptographic Doom Principle

#54
post #24
post #20

Earlier quoted context omitted.

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.

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.

And once you have that cryptographer under your employ, you can feel free to break the rule of not rolling your own crypto. Although that cryptographer is infinitely more likely to simply compose well-known strong ciphers over deploying their own unpublished ones.

Re: The Cryptographic Doom Principle

#55
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 m…

Thank you for the link and the review. I start my CS degree in the Fall; i hope i can start and finish this before then.

Re: The Cryptographic Doom Principle

#57
post #41
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 yo…

I certainly agree with you. I just think the "don't roll your own crypto" advice is overly ambiguous. Ironically, I think my original comment was ambiguous as well. Let me clarify. I'm not endorsing rolling your own cryptosystem (e.g. a replacement for RSA). Rather, I think the advice should often be paired with additional insight on what "rolling your own" means. When building some sort of software, not everyone (currently) has the luxury of a cryptographic library that handles everything painlessly.

For example, I think most would say that I'm not "rolling my own crypto" if I'm implementing some piece of functionality in my application leveraging the use of some API with "mac", "encrypt", and "decrypt" functions. There are still ways I can screw up using these functions, but I'm arguably not "rolling my own" crypto. So in this situation, the mantra is confusing at best.

Re: The Cryptographic Doom Principle

#58
post #6
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.

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.

If you use the same key for KC and CC, CC can (and hell, in all likelihood probably does) leak bits of the key.

So yes, there is a way of breaking this construct when used the way you said.

Re: The Cryptographic Doom Principle

#59
post #48

Earlier quoted context omitted.

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.

You don't mention separate computers until now. It's a big difference. I thought we were discussing implementing crypto, not some theoretical properties you achieve when conditions are just right.

I'm not saying trust the Windows implementation of AES, you can put it through some other cipher with a strong implementation as well, but don't just make up your own one.

Re: The Cryptographic Doom Principle

#60
post #51
post #38

Earlier quoted context omitted.

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

> 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). I've been dealing with crypto on a near-daily basis for the last 15 years. I'm well within the top percentile of understanding of t…

I think to say we can't build safe cryptographic protocols is too strong. I'd say that it's very hard to design safe systems from the ground up. But it's still possible to realistically and practically work around certain threats without opening another vulnerability.
Post reply on HN