* Does the library expose block cipher mode choices to callers? It's not high-level.
* Does the library expose IVs to callers? It's not high-level.
* Does the library separate "encryption" from "authentication", offering the choice of doing one without the other? It's not high level.
* Does the library by default allow users to pass in raw buffers as keys? It's not high level.
Don't use OpenSSL directly to do crypto in applications.
Why shouldn't there be a choice to offer separate encryption from authentication?
How does interoperation with other libraries/platforms work. For example trying to interoperate with Java for Diffie Hellman has for instance meant using an library that does BER/DER and decoding the values ourselves because Java uses an older standard compared to the library we are using on the C++ side (Botan). We have to have the ability to manage keys ourselves. All the higher level abstractions create all kinds of issues because the choices made don't let us interoperate because they are different from what the next library chooses.
Because if you're using a high-level interface to cryptography, the handling of the IV is a detail that can easily be hidden from developers without loss of security or, in reality, meaningful flexibility? Meanwhile, asking developers to provide an IV is an invitation to cryptosystem flaws?
Because maybe you shouldn't be doing custom Diffie Hellman in your application to begin with? Is there a pointer to either your Java or C++ code on Github? Do you know how to do DH safely? I don't, but I know some flaws to look for, and that I've found in the real world on pentests.
Instead of talking about BER/DER, how about you talk about the DH pitfalls you avoided and how you avoided them? That way, readers of this thread would get a whiff of maybe why they wouldn't want to come within a mile of a custom DH implementation.
Sure, encryption without authentication is worthless, but what if I want to do the authentication in a different manner? What if I want to encrypt using AES-128/CTR-BE and then sign using public/private key rather than using an HMAC(SHA-256). That choice can be left up to a developer. Also, there still seems to be some debate as to whether you encrypt then HMAC or if you HMAC then encrypt. (I personally prefer encrypt then HMAC).
I don't think you necessarily have to have the developer provide the IV, you can provide a way for the developer to get the generated IV back from the system after the fact that would work just as well. So long as you can get access to it, so you can build it to spec. All this hiding is good for projects where that is possible, interoperability and following gov't requirements can throw a wrench in simply using something like Keyczar.
The biggest issue with DH that we have had to overcome is the different encodings that may be used. You have various different standards for how to share the DH keys. There is an ANS X9 standard that is recommended by the government[1] (and required in our product) and then there is PKCS3.
The biggest issue we ran into is that Java (on Android) only does PKCS3, and Botan doesn't by default decode that so you end up having to implement that functionality yourself. We ended up using PKCS3 but that will most likely have to be changed for gov't approval which means we need to get Java to grok ANS X9.
When doing DH I also suggest using one of the NIST approved DH groups and not generating your own.
Do note that none of this is using a custom DH implementation, it is using the stuff that is available in Botan/Java itself, the biggest issue is finding common ground for finishing the DH key exchange because of the different formats used in the in-between steps.
Also, generating a random key from the DH data is different on various different API's. Botan can generate keys for you, and will use a KDF for you, while Java will simply give you the bytes back in raw format.
So far this isn't a solved problem for us. Since we are not using it for cryptographic purposes we may end up doing our own custom implementation so that we have less to worry about in terms of encoding/decoding various different storage schemes. And any weakness in the system won't be a fatal flaw that could be used/exploited in a meaningful manner, so fixing things at a later date won't be catastrophic.
The biggest issue is that there are so many standards and so many little variations of it in cryptography that trying to get systems to interoperate and work together is a massive undertaking and each time you run up against a wall because something is abstracted away you wish and eventually want access to the lower level primitives.
[1]: http://csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A...
What's your go to solution?
For the situation you describe, a "low-level" crypto library is handy; for instance, very few libraries implement ciphertext stealing, so if you require compatibility with some wacky protocol or file format that uses CTS, OpenSSL EVP is no help either.
That doesn't make OpenSSL's primitive interface a good choice.
If you are designing crypto for your own application, and you find yourself typing "O-p-e-n-S-S-L" or even "A-E-S", you are probably in for a lot of trouble.
I agree with you that Keyczar is good to use for certain use cases, but that isn't always the case. Instead of always telling us to use Keyzcar how about showing us how to use the primitive libraries more correctly to have secure applications YET at the same time allow us developers to have the flexibility to use them as we need to use them for compatibility with other implementations or with government requirements (for those of us in the gov't contracting world).
You are in the unique position that you have seen all of the mistakes and know how to avoid them and thus could help developers avoid those mistakes as well.
