If you copy (vendor) an encryption/decryption algorithm into your source code, then you are relying on more than libc. So perhaps you could expand your dependencies to libraries with acceptable licensing or to libraries that are widely available. For example, OpenBSD 6.2 provides blowfish. Also, GnuPG libgcrypt is far more involved than you require, but it is still appropriately licensed.
I can't help myself from adding to the distracting tangents. pw by Dashamir Hoxha has some of the features of present discussion. http://dashohoxha.fs.al/pw/man/ It is derived from password-store. It stores passwords in an encrypted tarball instead of inside the normal filesystem. Like pass-tomb, this has the effect that file hierarchy doesn't show up in the filesystem. It still uses gpg, but it forces a particular simplified style of usage that should be very easy for many people to learn: Only gpg symmetric encryption is allowed, so you do not need to understand the concept of asymmetric cryptography; also, it includes in a shell that remembers the decryption password, so you can have it remember your password without relying on gpg-agent being properly installed, and you can easily have it forget your password without understanding that gpg-agent exists. This is technically still gpg, but the encryption software could easily be replaced by something else, like encrypted zip files, the user doesn't need to know that it is gpg. Another alternative is to rely on filesystem encryption. For example, you could use tomb without password-store. I once used used normal, cleartext files in an encrypted vnd device (You could use tomb for that as well.) that I mounted and umounted. The point is that you wouldn't need gpg. You might write some utilities that mount and umount the device and ensure correct permissions.
