Quite a few of the replies to acabal's comment amount to "yes, it's hard, suck it up and learn it."

But the crypto community has told us time and again that we shouldn't be trying to learn the fine details of crypto. If we are, it's a warning sign we're wading into the dangerous world of actually implementing crypto. We're just supposed to use pre-built, peer-reviewed crypto systems and understand at a very high level how they work. E.g. knowing what a hash is versus symmetric keys vs asymmetric keys, knowing which algorithms are still acceptable (Bcrypt) and which aren't (md5). And this, I think, is the right message for developers.

But the OP has a valid point. If it's true that many of the high-level, crypto-layman-friendly libraries do bad things like using all-zero IVs, then we have a real problem. But here's where I disagree with the OP: It should not fall on the average developer to understand this stuff and override a crypto library's insecure defaults.

Instead, authors of crypto libraries need to step up and implement secure defaults, as well as provide solid documentation on the do's and don'ts of their libraries. (Assuming of course the OP is correct about the flawed defaults in existing libraries.)

In any case, the solution is not to urge normal developers to learn crypto at the level the OP describes. I'm a smart guy, but I know better than to trust myself with things like initialization vectors. This is, after all, what the broader crypto community has been telling people.

I agree with you completely, and perhaps to clarify my comment (the one you've replied to): As you say, developers shouldn't have to worry about the fine details of crypto. What I mean by that is: Common tasks like hashing a password, creating a secure http connection, encrypting plaintext asymmetrically, etc., should be obvious, clear, and as secure as technology allows.

But, there are so many different crypto libraries with so many varied defaults, that in the end, we need some basic education on what is secure and what isn't. This particular blog post states in the 3rd sentence that developers using libraries are already making a grave mistake. How can we know which libraries to trust? If we can't trust libraries, what can we trust? Which magic combination of alphabet-soup abbreviations is the most secure, and how can I, a layman, be sure? For example: For asymmetric encryption, GPG on Ubuntu 12.04 defaults to the CAST5 algorithim. Is this better or worse than AES-256? I hear about AES-256 all the time, but I've never heard of CAST5. How can I, a layman, know it's the best default choice, considering that I only hear about more popular algorithms?

I feel like there should be a single best answer for most possible use cases. For example, today the best answer to storing password hashes would be to use the bcrypt library for your language of choice. But there's just so many options and so little clarification and consensus to a lot of these things (for regular developers, at least), that it's nigh-impossible to be confident about what you're doing. People are still MD5'ing passwords to this day--and it's not because they're idiots, because even knowing about MD5 means they had to have the initiative to Google "how to hash a password".

If I've misread the intention of this blog post, then perhaps I'm arguing the wrong point. If I am, I submit that this blog post might be better located in "crypto-researcher-news", not "hacker-news".

Keyczar is sound.

NACL is sound.

Using straight-up TLS with OpenSSL or your platform default is fine as long as you test that you're validating certificates.

PGP/GPG is fine.

Everything else is extremely suspect.

Does that mean Bcrypt is extremely suspect? If so, then we have a real communication problem, because lots of people who claim to know crypto sing Bcrypt's praises.

We aren't talking about password hashes.

"But the crypto community has told us time and again that we shouldn't be trying to learn the fine details of crypto."

I really disagree with this, and there are now good free courses available online.

Implementing as anything other than a toy is dangerous, but learning should never be discouraged. Besides which it's fascinating.

A safe, fun, and especially effective way to learn crypto is to actually implement the attacks.

While I think that people should learn the cryptographic primitives as much as possible, the point of my post was to use a well-reputed open source authenticated encryption library. In addition to NaCl, there's also Keyczar: http://www.keyczar.org/

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 encrypt some text?

Answer: Use PGP, Keyczar, or NACL.

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

That's precisely what I'm trying to say, but worded much more elegantly. Thanks!

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.

Honestly, fuck that.

Or, you know, build incompetent systems that real people will depend on that those egotistical security people will be able to break trivially.

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.

But in such a case, engineering trumps social.

Can you be more specific about which case you're referring to?

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.

Yeah, acabal. Fuck you for trying to learn anything.

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.

Crypto is hard.

The point of this is you shouldn't even be using algorithms directly. If you need to touch crypto at all you need to learn about it, and the more you learn about it the more you'll realise just how damned hard it is.

Absolutely use common programs like GPG and common libraries like OpenSSL. In fact don't use anything else, and don't even think about implementing this stuff yourself.

I agree some sort of authoritative set of info would be good. Very hard to do though.

"Dr. Hoenikker used to say that any scientist who couldn't explain to an eight-year-old what he was doing was a charlatan."

- from Kurt Vonnegut's novel Cat's Cradle

Yes. Definitely go with epigrams from works of fiction to guide engineering decisions.

You do not really understand something unless you can explain it to your grandmother.

- Albert Einstein

"The problem with quotes from the internet is it is hard to verify their authenticity"

- Abraham Lincoln

Totally worth a T-shirt

http://www.cafepress.co.uk/cp/customize/product2.aspx?from=C...

It does not then follow that when someone refuses to explain something to you like you are their grandmother that they do not really understand what they're talking about.

Also I'm pretty sure that's Diablo Cody's quote, not Einstein's.

There's a difference between explaining to an eight-year-old what you're doing and instructing that eight-year-old in how to do the same thing safely without spending a long time on his education.

Correction, absolutely do not use OpenSSL.

Except that one point in this article seems to be that you're still screwed even if you're using a well-respected library.

The real problem is the software libraries are just as hard.

Take OpenSSL for example... it's almost easier to learn the crypto than to figure out the API. Here's a good one: an SSL read/write operation can fail with more than one error, and if you don't clear or loop through all the errors then the next operation will fail because of the previous errors -- even if it succeeded. Or just try getting it to work with non-blocking sockets, you finally believe it is working and surprise it fails only once the network gets saturated. Or hours later when it renegotiates the crypto.

And you still have to know all the crypt terms to use it. What's a PEM? A BIO? PKCS? DHparams? What's "ASCII armor"? X509? Did SSL_library_init() add weak algorithms? Why do I have to know this just to create a secure connection?

Most of blame for crypto problems belongs to the libraries not the developers using them.

Don't use OpenSSL, don't use Crypto++, don't use CommonCrypto, don't use CryptoAPI. Those are expert interfaces and you'll get them wrong.

Instead, use NACL or Keyczar. Those are high-level interfaces designed to help generalist developers not make mistakes.