SQLCipher's codebase contains two non-standard, but historically supported, cryptographic providers:

• crypto_libtomcrypt (Bindings for LibTomCrypt)
• crypto_nss (Bindings for NSS)

Neither one of these providers gets a lot of use these days. We were previously aware of a few major projects using them, but those have either been discontinued/abandoned or moved to other crypto providers.

Because these do not get a lot of use or testing, the SQLCipher team is planning to deprecate them and remove them from the codebase as packaged providers in a future release. Removing these from the source tree will mitigate the perception of support within the core. The current plan is to continue to include them in the upcoming release of 4.11.0, but then remove them in version 4.12.0 or later.

That said, SQLCipher fully supports "custom" providers which may be supplied by an application. That means that any remaining applications currently using these providers can import and integrate one of these providers into their own codebase, compile it, and set it as the default provider at build time.

Developers would only be using one of these providers if they are building SQLCipher from source. You can tell if your build is using one of these providers by examining the compile time macros for SQLCIPHER_CRYPTO_LIBTOMCRYPT or SQLCIPHER_CRYPTO_NSS.

To use an externally maintained provider. for example, one could:

1. copy the external crypto_libtomcrypt.c file into the root of the sqlcipher source tree before building
2. add the following to the ./configure CFLAGS: -DSQLCIPHER_CRYPTO_LIBTOMCRYPT -DSQLCIPHER_CRYPTO_CUSTOM=sqlcipher_ltc_setup"
3. provide crypto_libtomcrypt.c via the extra EXTRA_SRC parameter to make, i.e. make EXTRA_SRC=crypto_libtomcrypt.c

Alternately, users of those cryptographic provider could consider switching over to one of the other default and support providers, OpenSSL or CommonCrypto.