Intros and courses and books
Libraries
- http://nacl.cr.yp.to/
- http://www.gnupg.org/ , http://www.gnupg.org/related_software/libraries.html
- /dev/urandom (note: apparently there is a debate whether to use /dev/random or /dev/urandom: see https://news.ycombinator.com/item?id=7359992 . The summary is: /dev/random blocks if it guesses that there is not enough 'entropy', /dev/urandom just returns a random number immediately no matter what. Sometimes the unpredictable blocking behavior of something build on top of /dev/random leads users to use workarounds which are even less secure than just using /dev/urandom. For many applications, low entropy isn't a huge problem anyways. So for most applications, /dev/urandom is preferred except when generating long-lived keys. However, in GNU/Linux, during startup, there is actually too little entropy for almost anything, yet /dev/urandom still returns something; for something that many be run near startup, /dev/urandom is dangerous (then again, so is unpredictable blocking).
Advice
comment on that:
" sdevlin 1 day ago
That is a pretty good list of recommendations, but I have a couple criticisms.
The recommendations are mostly low-level. None of them are wrong, but they put undue burden on developers to get details right. For example, the AES-CTR recommendation doesn't talk about nonce management, but this is critical to the security of the construction. Application developers should always use the highest-level cryptographic constructions they can get away with. As such, many of these bullet points could be replaced with a recommendation to use PGP or NaCl?.
Also, the list skimps on random number recommendations. It talks a bit about how big numbers should be, but it doesn't discuss sources. This is really important as RNG is a weak point in many systems. Short answer: use /dev/urandom.
reply "
-- https://news.ycombinator.com/item?id=7431469
Services
![[Home]](http://www.bayleshanks.com/cartoonbayle.png)
