Is there any reason to use OpenSSL over Common Crypto if I’m targeting macOS? Up until now I’ve been attempting to statically link OpenSSL’s libcrypto.a when I compile libsqlcipher.a, but that is turning into a world of pain. When I in-turn build node-sqlite3 bindings and statically link libsqlcipher.a, encryption just seems to not work. However, if I dynamically link Common Crypto, everything “just works”.
Is Common Crypto the official recommendation for macOS?
Is OpenSSL via static linking (I’m building a desktop app) viable at all or should I just drop that idea?
Thanks for the work you do on SQLCipher.
Hello @aguynamedben. Both Common Crypto and OpenSSL are supported for macOS but you’ll likely have an easier time using Common Crypto. There are some cases where using OpenSSL on macOS is preferable, but they tend to be situations where an application already has other dependencies on OpenSSL, targets old versions of macOS, or has special security requirements (e.g. FIPS 140-2). For the general case Common Crypto is easier to work with.
Cool, thanks for the feedback. I now compile SQLCipher from source against Common Crypto.
[I pasted this in my other thread but figured I’d copy it here for posterity]
With OpenSSL, I was able to get SQLCipher to compile using OpenSSL via static linking (i.e. link libcrypto.a), but when I went on to compile node-sqlite3 bindings everything would appear to work, but encryption would simply not work. I’m happy to help walk through the steps if y’all are every trying to debug macOS+OpenSSL+node-sqlite3 bindings.