It does exactly what it says on the tin - it encrypts something so that only the recipient(s) can access it. It is very far from the low-level primitives: it t

It does exactly what it says on the tin - it encrypts something so that only the recipient(s) can access it. It is very far from the low-level primitives: it takes care of generating the symmetric key, implementing the underlying cipher mode (so, for example, if you use a type like EVP_aes_128_gcm() you'll get correctly implemented GCM) and generating the IV. It takes care of padding for the asymmetric encryption step. In short, it protects you from a whole slew of low-level implementation mistakes that await you if you use the low-level primitives. There's also EVP_Sign() which also does what it says on the tin - ensures the message comes from who it says it does, but anyone can read it. You can compose these together as well, to create a message with both properties. What they don't protect you from is designing an insecure protocol* on top, but then NaCl doesn't either: for example it's easy to create a protocol with trivial replay attacks. I believe the classes of errors you allude to fall into this category. Perhaps you think there should be an EVP_Box*() that combines signing and sealing, but regardless it is simply not true that OpenSSL provides nothing between raw AES and full-blown TLS.