That's the point. The post is hard to read because the subject is hard. If that post --- which is pretty breezy --- is too hard for you to grok, the message you should be taking away with it is "I shouldn't be designing systems with crypto". The headline is good enough for you.
Yeah but how do I use systems with crypto? What if I want to encrypt some text? Do I worry about a MAC? Does GPG do MACs? How do I know? Do I worry about EAX? GCM? CCM? AES-CTR? CMAC? OMAC1? AEAD? NIST? CBC? CFB? CTR? ECB?
Programmers have to use crypto libraries all the time. The 3rd sentence in this post is "Chances are whenever you have tried to use a cryptographic library you made some sort of catastrophic mistake." Crypto is hard, but humans have to use it--this post is ridiculously complex and utterly unhelpful for anyone who's not already an expert, and that's not uncommon in crypto documentation, I think.
That's not how it should be. Something so important and widespread should be written about and explained in a human manner. My point is we need some resource to de-obfusticate the technobabble for those of us who need security but have day jobs that aren't developing the latest and greatest hash algorithm.
Question: What if I want to use EAX? GCM? CCM? AES-CTR? CMAC? OMAC1? AEAD? NIST? CBC? CFB? CTR? ECB?
Answer: You will perish in flames.
Smart cryptographers already grappled with the problem you're talking about here, concluded that non-crypto-engineers were never going to get these details right (professional crypto engineers don't even get it right, and there's a whole academic field dedicated to why), and designed high-level libraries that don't expose primitives like cipher cores, block modes, and MACs. You need to be using those high-level libraries. You need to start treating things like "CTR" and "OMAC" like plutonium, instead of like AA batteries.
Ok, we're getting closer, but I think acabal's point was that it's hard for us to tell on a general basis which acronyms matter and which don't. i.e. the question isn't really "what do I use?" it's "how do I know what to use when I don't have the knowledge to evaluate the different options? or even to tell which options matter?"
There's a disconnect here. Perhaps to you it seems like you're pounding the same simple point over and over again, trying every which way to explain it, and we always keep bringing up things that we really shouldn't be concerning ourselves with because we'll just screw them up.
But the community needs a better starting point. A lot of us know that there's a universe of stuff that we don't know about crypto, and we don't blithely imagine that we're secure because we used XCZ or LSA-j14(3). What we know is that Bob said to use XLQ and everyone says Bob is an expert, so we're gonna use XLQ. But we often come to this information in the middle of a hacker news thread, or on a website that looks like it was designed in 1993. There's no good general starting point that gives us a way to make good security decisions without knowing what we don't know. Does that make sense?
(There are actually a lot of resources that try to be starting points, but without the tools to do a meta-evaluation of which of these is expert and trustworthy, we're back to the same problem.)
And with that attitude nobody ever learns anything.
To me it sounds like a bad excuse for security guys to stroke their own egos. 'Puny mortal, you are nothing. Repent your ways of sin and obey your gods.
Both of these comments are wrong and right. I think tomjen3's comment accurately conveys how some people feel about an article that starts off with "All the crypto code you’ve ever written is probably broken." "YOU did something WRONG" is a crappy way to educate people. But on the other hand, as engineers/developers we have to learn to separate the tone from the soundness of the advice, because we work with other engineers.
Meanwhile, tptacek makes the very good point that if you ignore this advice because you're offended by it, you're going to end up building insecure systems that will endanger other people's data and possibly worse. But it's an impatient answer and it actually does come off as pretty egotistical. Isn't there some room between "secure" and "incompetent?"
Sorry for being all third-persony. I think you both make valid points, despite the negative tone.
I'm not sure why we should even dignify questions about egotism or how we're discouraging developers from learning. Those issues just aren't relevant. You either built a system that resists attacks or you don't. As Daniel J. Bernstein once said, that may sound harsh, but that's engineering.
They're relevant because security is social as well as technical. If you want the systems that your friends or relatives use to be more secure, then you can't just dismiss someone who may be implementing those systems. Okay, fine, if they're just insulting you, keep moving.
I responded to dignify it because I thought that in spite of the invective, there's a valid point about whether the article is helpful to the people it's meant to reach. The title is needlessly insulting to the reader. The tl;dr is pretty useless. You don't learn to do things right by cargo culting a mantra that you don't understand. The content of the tl;dr should be the block quote starting under "That said, what modes should you be using?"
Yes, you're right, this is actually pretty irrelevant to the content of the article and the question of whether a particular system is secure. I think it connects to a larger issue about security education that's lurking out there, though, and the article is clearly meant to educate.
So tptacek, you've currently got 37 comments on this story. Why? What are you trying to accomplish here today? If you have it in mind that you're educating people or improving the community, maybe take a step back. Your tone is condescending and combative. It reads like you're just arguing on the internet, and it's bringing down the general level of discourse. "tptacek" is normally a name that I associate with thoughtful comments so I take it that you're having a bad day.
Pretty much any software being built that touches the internet involves cryptography. So pretty much any software. It's an important subject for any software engineer, and there's a lot of good available to be done by helping educate engineers at every level of experience.
People write comments that say things like "pretty much ay software being built that touches the internet involves cryptography". In the context of the thread, that statement is not just wrong, but dangerously wrong. So I write a comment saying why.
Most of the time, it is easier to dash off a short comment that says something wrong, like, "pretty much any software" is going to involve grappling with cryptosystems, than it is to write a comment that thoroughly refutes that wrongness.
Also, the space of possible wrong things you could write, like, "there's a lot of good available to be done by helping educate engineers" about how to write bespoke custom cryptosystems, is much larger than the space of things you can write that are even strictly speaking correct. So I'm at a double disadvantage.
Ultimately, while I am happy to hear that you find my other comments helpful, I just do not care that you find my condescending, combative, or overly prolific on this thread. Deciding what to say based on what might or might not make random anonymous HN users happy is simply no way to be.
I don't know why you're talking if you don't care how it is received.
I'm a professional software engineer. I work on a system that occasionally passes secrets through untrusted contexts, encrypted with AES-256-CBC. Is that a good idea? Could we improve it? Would it be worth the effort? I'm open to learning, but this article isn't teaching, it's browbeating. So are your comments.
I don't think anybody is saying that you shouldn't strive to understand crypto. I think the overall message is don't build systems with crypto unless you understand it, or have someone in your employ who does. If you don't understand crypto, you will likely implement it incorrectly. It's as simple as that.
That's unfair - there are two things to learn here
1. How does the basics and intricacies of crypto work? acabal can hit up coursera for that, and the cryto guys here will probably help him with his homework for free.
2. How do I implement a user authentication mechanism from scratch? well, thats the one where you cannot learn it. dont try it seems to be the advice.
(in fact the simplest advice is on here too - authenticate once, hand over a random number, look it up at the back end.)
I assume that includes Time it out, count it out and then go read about CSRF protection.
