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

71–80 of 140 posts

Re: The Cryptographic Doom Principle

#71

Post by czinck »

some_furry wrote: post #53
3am wrote: post #41

Earlier quoted context omitted.

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.

Which is part of what's meant. Don't create your own crpyto algorithm and don't write your own implementations of existing algorithms. There are so many gotchas that it would take a lot of effort to get something that's less buggy even than the much-maligned OpenSSL. Someone (I don't remember who) said that even typing the letters "RSA" is too close to rolling your own crypto.

Re: The Cryptographic Doom Principle

#72

Post by c22 »

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…

Why not just use a different mature and trusted cipher on the relaying nodes?

Re: The Cryptographic Doom Principle

#73

Post by exelius »

daeken wrote: post #51
madez wrote: 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…

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

You'd probably be right on any other site; but I'm guessing there are a few people who do this for a living somewhere on HN.

Re: The Cryptographic Doom Principle

#74

Post by madez »

kelson wrote: post #65
madez wrote: post #42

Earlier quoted context omitted.

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

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

I specifically said the RPi does nothing else but CC.

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

The interface from the PC to the RPi should of course have the same security as any internet-facing interface. Thus the remote access to the RPi wouldn't pose a risk for using the protocol beside the obvious risks that you always get in such a scenario.

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

The system I described is not trivially defeated because defeating it implies defeating KC.

Did you read my comments?

> 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 To break my cipher an attacker would need to solve _both_ problems.

My point is that _if_ AES is broken without our knowledge, using the system I described can still make untargeted-surveillance impractical. Isn't that an interesting property for a protocol using a custom cipher?

Re: The Cryptographic Doom Principle

#75

Post by JoachimSchipper »

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.

Don't over-value being able to break crypto, though. Yes, it'll get people to skip the unauthenticated CBC, but exploiting a padding oracle is no guarantee that you'll be able to write e.g. a proper secure boot system, a fast and secure implementation of a low-level primitive, or that you'll get forward-security right - and there are quite a few levels above that...

Re: The Cryptographic Doom Principle

#76

Post by shazow »

superuser2 wrote: post #44
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.

> This is like complaining that nobody will bet on you to defeat Gary Kasparov means there is a culture of elitism in chess.

A closer analogy would be berating everyone who tries to play chess unless they studied it for years and they are professional and renowned chessographers. :)

Edit: If we're going to stretch the chess analogy further, it's important to note that the best chess players come from a very chess-positive culture, where many people grow up playing the game from a very young age.

Re: The Cryptographic Doom Principle

#77

Post by rosser »

kkl wrote: post #57
3am wrote: post #41

Earlier quoted context omitted.

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

I don't know anyone who has ever taken "don't roll your own crypto" to mean "don't write things that use crypto".

Re: The Cryptographic Doom Principle

#78

Post by JoachimSchipper »

kkl wrote: post #57
3am wrote: post #41

Earlier quoted context omitted.

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

Maybe; but handing a MAC to generalist developers is going to end in a timing attack, like http://rdist.root.org/2009/05/28/timing-attack-in-google-key.... (And Keyczar is not amateur hour!)

Re: The Cryptographic Doom Principle

#79

Post by daeken »

exelius wrote: post #73
daeken wrote: post #51

Earlier quoted context omitted.

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

> You do not have the knowledge required to build safe cryptographic protocols. Neither does anyone else on this site. You'd probably be right on any other site; but I'm guessing there are a few people who do this for a living somewhere on HN.

That's actually the point, though. People that do this for a living will agree with me on this. They don't have the knowledge individually to make secure crypto. Secure crypto comes from lots of smart people and a lot of battle testing; the idea of one person making secure crypto protocols/implementations is completely ludicrous.

Re: The Cryptographic Doom Principle

#80

Post by madez »

angry_octet wrote: post #66
kelson wrote: post #27

Earlier quoted context omitted.

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

To fingerprint the connection/data by the used cipher they would need to break KC. If they are able to break KC they can fingerprint you also when you only use KC.
Post reply on HN