10 ms·

Is there a repository or central location of the established and well tested solutions for developers to use? Where does one start?

fredsted 13y ago
Wikipedia perhaps?
Osmium 13y ago
Some ideas, depending on what you need (I can't say how good these are): http://www.keyczar.org http://www.keyczar.org http://nacl.cr.yp.to http://nacl.cr.yp.to https://github.com/jedisct1/libsodium https://github.com/jedisct1/libsodium http://www.gnupg.org http://www.gnupg.org
- normalfaults 13y ago
  Thanks. These are straight crypto frameworks which are a good start.
betterunix 13y ago
One of the problems with cryptography is that "solutions" are not as generally applicable as one might want. There are a lot of assumptions that are made, and violating those assumptions is usually a disaster. For example, when it comes to encryption, it is typically assumed that all messages are the same length. If your application does not make this guarantee, encryption may not provide you with any security. You could wind up in this situation: https://news.ycombinator.com/item?id=2661890 https://news.ycombinator.com/item?id=2661890 Think of it this way: asking for a list of tried-and-true crypto solutions is like asking for a list of tried-and-true database schemas. There might be cases where it will work, but for the most part you need to put some thought into what you are doing.
- normalfaults 13y ago
  That makes sense in terms of no standard libraries. But how about design patterns for common scenarios, eg. securing REST apis, User authentication/Login/Signup, Payment information handling etc, all in one place. Does it become less secure if everyone follows standard design patterns?
  - betterunix 13y ago
    No, of course it does not become less secure. In the worst case, slapping some crypto onto a system would have no effect at all; it is hard to see how it could make things worse, other than to give people a false sense of security. An example is Hushmail. Your mail is signed, it is encrypted, you're using the tried-and-true PGP...and the DEA can walk into court with a pile of DVDs full of the plaintext of some defendant's email. Hushmail is, at best, only marginally more secure than GMail. So while we might come up with good practices for using cryptography, it is inevitable that organizational practices will render the cryptography pointless. Solutions need to be tailored to the specific needs of an organization or a system. That is where the real problem lies: we do not have something like SQL for cryptography. We do not have a good way to specify organization needs and design (or even verify the security of) a cryptosystem that meets those needs.

fredsted 13y ago

Wikipedia perhaps?

Osmium 13y ago

Some ideas, depending on what you need (I can't say how good these are): http://www.keyczar.org http://www.keyczar.org http://nacl.cr.yp.to http://nacl.cr.yp.to https://github.com/jedisct1/libsodium https://github.com/jedisct1/libsodium http://www.gnupg.org http://www.gnupg.org

normalfaults 13y ago
Thanks. These are straight crypto frameworks which are a good start.

betterunix 13y ago

One of the problems with cryptography is that "solutions" are not as generally applicable as one might want. There are a lot of assumptions that are made, and violating those assumptions is usually a disaster. For example, when it comes to encryption, it is typically assumed that all messages are the same length. If your application does not make this guarantee, encryption may not provide you with any security. You could wind up in this situation: https://news.ycombinator.com/item?id=2661890 https://news.ycombinator.com/item?id=2661890 Think of it this way: asking for a list of tried-and-true crypto solutions is like asking for a list of tried-and-true database schemas. There might be cases where it will work, but for the most part you need to put some thought into what you are doing.

normalfaults 13y ago
That makes sense in terms of no standard libraries. But how about design patterns for common scenarios, eg. securing REST apis, User authentication/Login/Signup, Payment information handling etc, all in one place. Does it become less secure if everyone follows standard design patterns?
- betterunix 13y ago
  No, of course it does not become less secure. In the worst case, slapping some crypto onto a system would have no effect at all; it is hard to see how it could make things worse, other than to give people a false sense of security. An example is Hushmail. Your mail is signed, it is encrypted, you're using the tried-and-true PGP...and the DEA can walk into court with a pile of DVDs full of the plaintext of some defendant's email. Hushmail is, at best, only marginally more secure than GMail. So while we might come up with good practices for using cryptography, it is inevitable that organizational practices will render the cryptography pointless. Solutions need to be tailored to the specific needs of an organization or a system. That is where the real problem lies: we do not have something like SQL for cryptography. We do not have a good way to specify organization needs and design (or even verify the security of) a cryptosystem that meets those needs.