I found out recently that OpenSSL is not just for securing network connection. It has a whole library of ready made encryption code that can be used for other purposes.
Probably best not to do this, OpenSSL has the mindset of a collector. Rather than "Here are six things you might want to actually do" OpenSSL says "Here are four hundred things somebody has at some point proposed to do". This is already bad enough in its core competence where OpenSSL historically made it very easy to do stupid things like forget to check the certificates you were given are for the name of the host you were trying to connect to. It's much worse once you start calling APIs somebody last worked on ten years ago.
Also, since it is thinking like a collector, OpenSSL won't even nudge you if you start trying to do something that is inherently a terrible idea, like using an RSA key for encrypting data. It's possible, OpenSSL can help you do it, but you definitely shouldn't.
Libraries focused around solving real problems, such as Tink are less likely to inadvertently allow you to start doing something that everybody who cares already knew was a bad idea before you even began work.
I can’t agree with this post enough. Not only does OpenSSL have a grab-bag of ciphers of varying quality, but it also has an exceedingly confusing and under-documented set of APIs to access them. It is far easier to build something insecure on top of the OpenSSL library than it is to build something secure.
If at all possible, you should use something that directly implements the high-level constructs you need. libsodium does a good job here (and has bindings for most languages), but there are other tools for more nuanced requirements (e.g., the noise protocol suite for bi-directional communication).
In my experience, OpenSSL's API is not bad. It's overwhelming because it includes a lot, but most people just focus on one or two aspects and that API is pretty simple. E.g. for symmetric encryption, it's just couple functions, with fairly high-level constructs.
In term of using it wrong, I don't find it any worse than other libraries. You have to know what you are doing when using crypto API.
Tink has some nice things, like AEAD as a standard interface or the KetSet concept to bundle all the crypto info in one object. But its key management is cumbersome and restrictive. Dealing with keys seems like a headache.
Looking at the doc and browsing the code a bit, I don't see how to do key derivation. Is there a way to do simple key derivation via pbkdf2, scrypt or the variants?
