4 ms·

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

by 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".
- tptacek 14y ago
  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.
  - jarrett 14y ago
    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.
bascule 14y ago
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/ http://www.keyczar.org/

by jarrett 14y ago

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

tptacek 14y ago
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.
- jarrett 14y ago
  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.

bascule 14y ago

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/ http://www.keyczar.org/