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.
Comments
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?).
http://nacl.cr.yp.to/
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.
Something like what the CAESAR competition hopes to achieve: http://competitions.cr.yp.to/caesar.html
Cryptol is a DSL that simplifies the specification of a cryptographic algorithm http://corp.galois.com/cryptol/