7 ms·

OK, I get it. Encryption is hard. But just look at that post--there's so many acronyms and tech-talk that my head is spinning and I'm not halfway through. Ho

by acabal 14y ago

OK, I get it. Encryption is hard. But just look at that post--there's so many acronyms and tech-talk that my head is spinning and I'm not halfway through. How can you expect anyone to do encryption properly when it's presented like that? In fact I'd say this post is literally useless FUD for anyone without a crypto background. It's unreadable unless you're an enthusiast. Worse still is the huge amount of conflicting advice and methods available on the internet. If you had asked me today if AES-256 was the best there was, I would have said yes, because that's what I've read, and I'm not a crypto expert; but now this posts makes it seem like I'm wrong. The truth is that now I have no idea. Crypto is hard, but it's so important today that it shouldn't be presented in such an obtuse way. There should be one resource that in big, bold headings and simple sentences outlines the best available crypto methods for each particular use case. Hashing password? Bcrypt. Asymmetrically encrypting plaintext? Algo XXX. Etc. Bonus points for step-by-step instructions on how to use those methods in common programs like GPG. Without a human-readable, trusted, official resource, it's just going to be crypto scientists shoving acronyms down our throats till we don't care any more. Please simplify it and eliminate the bad choices for us, because you know better! I want to be as secure as possible, but it's outrageously hard to do with the way things are presented today.

tptacek 14y ago
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.
- acabal 14y ago
  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.
  - tptacek 14y ago
    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.
    - wam 14y ago
      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.)
      - acabal 14y ago
        That's precisely what I'm trying to say, but worded much more elegantly. Thanks!
- phogster 14y ago
  Yeah, acabal. Fuck you for trying to learn anything.
  - lifeisstillgood 14y ago
    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.
- tomjen3 14y ago
  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.
  - tptacek 14y ago
    Or, you know, build incompetent systems that real people will depend on that those egotistical security people will be able to break trivially.
    - wam 14y ago
      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.
      - tptacek 14y ago
        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.
        wam 14y ago
        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.
Nursie 14y ago
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.
- troymc 14y ago
  "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
  - tptacek 14y ago
    Yes. Definitely go with epigrams from works of fiction to guide engineering decisions.
    - lawn 14y ago
      You do not really understand something unless you can explain it to your grandmother. - Albert Einstein
      - Nursie 14y ago
        "The problem with quotes from the internet is it is hard to verify their authenticity" - Abraham Lincoln
        lifeisstillgood 14y ago
        Totally worth a T-shirt http://www.cafepress.co.uk/cp/customize/product2.aspx?from=CustomDesigner&number=726533417 http://www.cafepress.co.uk/cp/customize/product2.aspx?from=C...
        deleted 14y ago
jarrett 14y ago
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.
- Nursie 14y ago
  "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.
  - tptacek 14y ago
    A safe, fun, and especially effective way to learn crypto is to actually implement the attacks.
- acabal 14y ago
  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".

by acabal 14y ago

tptacek 14y ago

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.

acabal 14y ago
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.
- tptacek 14y ago
  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.
  - wam 14y ago
    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.)
    - acabal 14y ago
      That's precisely what I'm trying to say, but worded much more elegantly. Thanks!
phogster 14y ago
Yeah, acabal. Fuck you for trying to learn anything.
- lifeisstillgood 14y ago
  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.
tomjen3 14y ago
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.
- tptacek 14y ago
  Or, you know, build incompetent systems that real people will depend on that those egotistical security people will be able to break trivially.
  - wam 14y ago
    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.
    - tptacek 14y ago
      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.
      - wam 14y ago
        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.

Nursie 14y ago

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.

troymc 14y ago
"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
- tptacek 14y ago
  Yes. Definitely go with epigrams from works of fiction to guide engineering decisions.
  - lawn 14y ago
    You do not really understand something unless you can explain it to your grandmother. - Albert Einstein
    - Nursie 14y ago
      "The problem with quotes from the internet is it is hard to verify their authenticity" - Abraham Lincoln
      - lifeisstillgood 14y ago
        Totally worth a T-shirt http://www.cafepress.co.uk/cp/customize/product2.aspx?from=CustomDesigner&number=726533417 http://www.cafepress.co.uk/cp/customize/product2.aspx?from=C...
      - deleted 14y ago

jarrett 14y ago

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.

Nursie 14y ago
"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.
- tptacek 14y ago
  A safe, fun, and especially effective way to learn crypto is to actually implement the attacks.
acabal 14y ago
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".