As for the library problem, I'm teaming up with Alex Gaynor, Hynek Schlawack, Donald Stufft and Christian Heimes to write a better cryptography library for Python: https://github.com/alex/cryptography
New contributors very welcome!
On the other side of the coin, I agree that cryptography education is very lacking. That's why I presented Crypto 101 last year at PyCon, which was an attempt at teaching just enough crypto in 45 minutes. Obviously, that's pretty near trying to square the circle: it's a best-effort attempt, but that's about it. (If you're still interested, the recording is available for free: http://pyvideo.org/video/1778/crypto-101)
That's why I'm also writing the book version of Crypto 101. Early draft stages right now, but getting there. After listening to tptacek say it so many times, I've come to agree: if you want to teach crypto well, you probably want a bunch of exercises that teach you how to break it. As a result, both the exercises and the text-adventure game I'm adding to the book rely on breaking real-world crypto: everything from bad password storage to MITMing SSL handshakes to stream compression :)
Additionally, a significant portion of the book will be devoted to when (i.e. rarely ;)) and how to write crypto. I would hope that your journey would've been a lot less painful if you had had access to the book. Perhaps for future programmers? :)
If you'd like to review, there's a reviewers mailing list, feel free to shoot me an e-mail explaining why you think you'd be a good reviewer, and I'll probably sign you up :)
I think it's pretty ridiculous that whenever a "non crypto" person tries to use crypto the security folks go lambast them, yet there is simply not a truly usable crypto api out there! Please go out and make this the right way; I'm looking forward to it :)
All I do is break into software; I do vulnerability research, and that's pretty much it right now.
As a vulnerability researcher, it's not on me to provide you with a good crypto library. People like us write software in order to find vulnerabilities. We're specialized so that we can be very good at doing that by dedicating all our time and attention to that one problem.
But much more importantly: like vuln researchers, don't like vuln researchers, it doesn't matter. When vuln researchers complain about crypto libraries, they are informing you of facts. You can ignore those facts and probably be vulnerable, or accept them and act on them and not be vulnerable.
Having said all that, there are in fact good crypto APIs. You can use Keyczar, which was a Google project. You can use NaCL, which is Daniel Bernstein's project; it even has a Ruby port now. You can use Peter Guttman's cryptlib.
However that's not the case whenever some project on HN claims to use cryptography. The answer usually is: "you don't know what you're doing, so don't use cryptography." While that is "safe", for many it's not actionable: sometimes we actually do need to use it and not everyone can afford a security consultant. I wish instead there was a recommendation for some library out of the box that would handle everything from key management to supporting my specific use cases.
Said a different way: I want an API that is simply giveMeANewKey() and encryptSecretMessage() and decryptSecretMessage() and the library takes care of both secrecy and integrity with strong defaults.
You can't expect it to make the whole system secure of course, but I think a better API that makes it harder to shoot yourself in the foot (both by having sane defaults and being very opinionated to the point where it affects your system design) would go a long way, no?
EDIT: looks like the stuff you linked to is more what I am looking for. I wish I had heard of them sooner!
The lower level APIs we are exposing will hopefully be more easy to use as well, but they will not offer the same protections against mistakes the same as the higher level API would.
NaCl gets a lot more attention these days, but I'm convinced both are fine. On the one hand, NaCl is pretty hardcore DJB-ware (poly1305-aes, salsa20...), and normally I'd err on the side of conservatism. OTOH, it's also really really good DJB-ware, so I can't blame anyone for using it :)
I personally prefer sodium's Python versions. Whether to deliver libraries in the Python packages or to use shared libs remains an open problem: I am somewhat convinced the former's better, but I can certainly see the cases where it'd go wrong.
I don't know if I am being muddle-headed in thinking of the initial counter value as an IV, but I was a little annoyed with pycrypto. Couldn't it throw
an error if it's given an IV in CTR mode,"
API creators have to stop this bullshit of putting death traps in their code.
This is not about go RTFM, or "you're incompetent".
If you allow it to be used in a wrong manner, it's your liability as well.
If your IV sometimes goes into one field, but in another occasion goes in another field, THROW AN ERROR IF IT'S NOT USED CORRECTLY
(Of course, Salt had no business being anywhere near an API that had the letters R-S-A in it, but I digress...)
* Undocumented error conditions (actually in general the documentation is atrocious for crypto libraries, "crypto is easy, why would you need docs"?)
* ECB as the default mode for block ciphers
* Ignoring invalid parameters
* Allowing you to provide parameters which basically your cryptography a no-op (e=1)
* Modes whose purpose is undocumented, merely "This mode should not be used"
And finally, absolutely NO python crypto libraries expose AES GCM. (This is all to say nothing of the myriad of other issues I have)
This book helps with teaching crypto and python at the same time... http://inventwithpython.com/hacking/
The state of crypto in Python is horrendous, hence the new library.
The time-insensitive method is to XOR every bit of HMAC_0 with HMAC_1 (keep going even if they are not of equal lengths use 0s) and then (not before) check if the lengths are equal.
the link given in the advice you point to includes a fairly detailed discussion / comparison - https://www.isecpartners.com/blog/2011/february/double-hmac-...
Also the source code looks like encrypted text. I can't figure out what much of it does, or why it does it by reading it.
Also, I think the API is not the best, because it asks for a password. Where are people storing the password? This promotes easy mistakes... like for example, saving it to a file, or reading it from a web input form.
however, i was quite proud of the source - https://github.com/andrewcooke/simple-crypt/blob/master/src/...
edit: i've added some warnings to the project page - https://github.com/andrewcooke/simple-crypt#warnings