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.