So, sure. I'll admit that I'm bad at cryptography.
You win!
But the problem is, the world needs more, not less, crypto.
We need to integrate crypto into more places, not run and hide and declare it too hard every time we come across it.
Is it easy to screw up? Sure. So is manually allocating memory. But we use higher level languages to help protect us from ourselves.
So too can we use higher-level libraries to help protect us from some mistakes we can make with crypto.
I'm working on an app which uses crypto heavily- In initial versions, I used manual RSA keys, but I recognize that no matter how smart I think I am (not very), it's easy to mess stuff up.
I can screw up the padding, I can screw up the implementation. Other clients which interop with me can screw up...
So Instead, I've swapped to using GPG keys. Is it perfect? Heck no! But it reduces the code that I have to get right. It outsources the parts that are most likely to be screwed up to a place where they're more likely to be reviewed, more likely to be written by non-fuckups.
There are lots of higher level libs, gpg is just one of them. keyczar, etc are also ways to solve this problem.
But we shouldn't run in fear everytime someone mentions the word Crypto, just because we have a chance of messing up.
What we really need is a cryptography language, to do for cryptography what SQL does for databases. I should be able to say, "Messages have this form, and they need to be encrypted end-to-end with authentication and without surreptitious forwarding," and have the right components assembled for me. Unfortunately, our understanding of cryptography is not well-developed enough to create such a system, and so we still fumble around and usually produce systems that are vulnerable (did you remember to have a good source of entropy? did you make sure your messages are all the same length? does your system compose well with others?).
NaCl is well implemented cryptographic functions designed to be easy to use and fast. As opposed to something like OpenSSL that gives you nine million options, NaCl just does what is best.
NaCl and Keyczar are both good options. We also tend to recommend that people simply use PGP for data at rest, and TLS for data in motion. Neither are perfect, but both are subjected to intense scrutiny by researchers.
> We also tend to recommend that people simply use PGP for data at rest, and TLS for data in motion
When I complain about bad crypto (in API auth in particular) and my clients really really push for me to give them advice, I repeat this line verbatim.
They hate it because TLS with client-side certs for authentication (where you become the CA) is unfamiliar and has too many moving parts for them. They go and develop their hand-rolled API auth, I proceed to shoot holes in it and come across as a bit of dick (to be fair, I'm not hired as a security consultant, just a regular developer).
I can normally get a few developers on board, but have yet to convince a client to use TLS in this way in production.
I do not think the problem is with how many options we are presented with, but rather with the difficulty of figuring out what primitives are actually needed to solve a particular problem, and how to compose those primitives. Do you need digital signatures? Do you need a hash function? Do you need to establish a common random string before the system can be used? It is very easy to assemble a system that appears secure (it's encrypted and signed!) but that does not actually provide any meaningful security (oh no, we actually needed non-malleable commitments!).
A high-level language could help quite a bit, because it would help programmers abstractly specify the needs of the system rather than getting lost in the details of which operations to choose. Maybe you really only need to sign and encrypt your messages. Maybe you need to sign, encrypt, then sign again. Maybe you do not need signatures at all, but you need to use a non-malleable cipher and a few rounds of communication (e.g. to make a deniable authentication protocol). The next generation of security problems will not be solved by slapping on encryption and digital signatures; we are going to need to pay increasing attention to higher-level issues.
Even if we had such a language it would probably not be high level enough because understanding what security you know is still a hard problem. Instead I'd suggest a high level library that gives you a complete security package with defaults that can't be easily changed.
The world needs more broken crypto like a dissident strapped to a chair in a concrete cell in South America needs another car battery alligator clipped to their fingers.
How about, if the world really needs more cryptography, the people who bring it to us take the time to become just a little bit literate in how crypto is actually attacked, instead of pretending like they understand it just because they were able to produce intelligible outputs from OpenSSL's AES?
You're using raw RSA. How much practicing have you done of attacks on RSA? How literate are you in RSA? If the answer is "not at all", why are you allowing yourself to use RSA? How is that not negligent?
(I don't know you, or didn't read your name closely enough to detect that I do, so maybe you have done this legwork; in which case, share with us why you think everyone else shouldn't do the same work?)
There's something that strike me as a bit off in what you write. I'm having trouble pinning it down, so here are some vague thoughts:
* The world does need more crypto. There's market demand for keeping stuff safe/hidden/whatever.
* It is hard to get crypto right. People like the author, and if I'm not mistaken, yourself, keep pounding that point home. Ok, we're convinced... but people still need to do this stuff, and not all of us have the money to hire you.
* "just a little bit literate ", given the above, seems kind of dangerous, no? It seems that way to me. Why bother learning just enough to get yourself into trouble?
* Given the above demand, people are going to try this stuff one way or the other. It seems the best thing is to give them the safest building blocks. The cited example in the article seems indicative: the companies were all trying to do more or less the same thing, which was not something complicated. Why wasn't it easier for them to do the right thing?
* I think what the world needs is easier, clearer, proven open source solutions/recipes to common problems.
Also, another thought that is not related to you or what you wrote, or write: is it just me or do a lot of security discussions turn into dick waving contests? Why is that?
The world might need more working crypto. The world doesn't need more broken crypto.
Broken crypto isn't just a step on the path to working crypto; it's an opportunity for people to get hurt.
The bet I'm making right now is that if people get a little bit of crypto literacy, they'll stop being so excited about deploying crypto in their applications. Implementing a bunch of crypto attacks has the effect of making you paranoid about cryptography. If generalist developers have one key problem with cryptography, it's that they're not paranoid about it --- in fact, the opposite: when they write crypto features, the crypto makes them feel safer. That's not how the crypto professionals I know feel about cryptography!
I strongly agree: things like NaCl and Keyczar are a great solution to this problem. Take the knobs away from the developers and just give them something that is likely to work, designed conservatively. Unfortunately, NaCl and Keyczar have nothing resembling the popularity of "I found this RSA implementation in Ruby and now I'm going to build an application with it". How do we fix that? I think part of the solution has to be to convince developers they should be more afraid of DIY crypto.
As for security: you should understand that when we write about it, we're writing about a competition. Attackers vs. defenders. Writing about competitions (or, in some of our cases, actively participating in those competitions) does something to the tone of your writing.
The software security field can be annoyingly competitive and status-oriented, too.
After having this debate with you two or three times now, I'm starting to realize that we both want the same thing: Good libraries like Keyczar that just do the right thing by default.
I would argue that there is a second side to the solution: Authors of more low-level crypto libraries (like OpenSSL) should very prominently warn users that said libraries are easy to misuse, and they should point users in the direction of the high-level libraries.
In my travels around the web, I've not often encountered such a warning. For example, as of today, the top Google hit for "ruby encrypt string" is a StackOverflow post. Its highest-voted answer advocates an OpenSSL wrapper.
I think labeling 'expert' is almost like an attractant for many of the folks that shouldn't bother. Likewise, there are some good users of OpenSSL, the rumors of it being "bad" or "insecure" would be damaging.
I'm not saying it's a bad idea exactly, just if you discover the way to word the warning to prevent people who don't understand that they're newbies from doing newbie stuff with it, you'll be on to something. I say you put that label on C compilers too.
This library exposes a very complex API. It is intended for expert users only. If you have any doubts about your knowledge of the underlying cryptographic primitives, we strongly recommend against using this library. Doing so without advanced knowledge of cryptography could compromise your security. Instead, we recommend you use a high-level crypto library, such as Keyczar or NaCl, both of which are designed to "just work" in the hands of developers who lack specialize expertise in crypto.
Honestly, one of the big problems is that people confuse crypto primitives with crypto schemes. Developers need schemes, not primitives. Some people, who know what they're doing, need the primitives, but they are by far and away the exception.
AES is a crypto primitive, AES-CTR-CBCMAC (aka, AES-CCM, but spelled out to emphasize the complexity of it) is a scheme. And even then you have key distribution problems, which is essentially clipping on another two or three car batteries.
> AES is a crypto primitive, AES-CTR-CBCMAC (aka, AES-CCM, but spelled out to emphasize the complexity of it) is a scheme.
In this particular example, the 'schemes' you point out didn't fair that well in pretty much every single codebase I've seen them implemented in after I finished set two of the crypto challenges.
I'm not using RSA - As I mentioned, I migrated to GPG specifically because I can't promise I know what I'm doing. I encourage others to do similarly (calling out Keyczar), rather than using primitives.
Re-reading, I can see how I could have been more clear and to the point, I did meander a bit in my original post.
But the problem is, the world needs more, not less, crypto. We need to integrate crypto into more places, not run and hide and declare it too hard every time we come across it.
Is it easy to screw up? Sure. So is manually allocating memory. But we use higher level languages to help protect us from ourselves.
So too can we use higher-level libraries to help protect us from some mistakes we can make with crypto.
I'm working on an app which uses crypto heavily- In initial versions, I used manual RSA keys, but I recognize that no matter how smart I think I am (not very), it's easy to mess stuff up.
I can screw up the padding, I can screw up the implementation. Other clients which interop with me can screw up...
So Instead, I've swapped to using GPG keys. Is it perfect? Heck no! But it reduces the code that I have to get right. It outsources the parts that are most likely to be screwed up to a place where they're more likely to be reviewed, more likely to be written by non-fuckups.
There are lots of higher level libs, gpg is just one of them. keyczar, etc are also ways to solve this problem.
But we shouldn't run in fear everytime someone mentions the word Crypto, just because we have a chance of messing up.