SQLCipher support accepting a password, which by default with be run through PBDKF2 using an iteration length of 64,000 (by default, but configurable) to compute the key used for encryption/decryption. Alternatively, if you have a source that has already performed some key derivation/generation process, where the key is generated and/or stored out of band from SQLCipher, you can provide a raw key, that is a blob literal, formatted as a 64 character hex string in which the standard key derivation process is skipped. A raw key will be converted into 32 bytes of key data.
When encrypted, the entire database file appears to contain random data.
When viewing the raw hex content of a plain-text SQLite database, you can see the literal schema and content of the database. Alternatively, when viewing the hex content content of a SQLCipher encrypted database, all content from the file appears random. An illustrated example can be found here:
What random data is contained after encrypting ?
The entire contents of the file appear random, as opposed to the structured view of the raw content.
What source of entropy do you use for random data and salt?
This depends on the crypto provider that SQLCipher was built with. By default, SQLCipher will attempt to build with OpenSSL in which we will use
RAND_bytes. If compiled with CommonCrypto we utilize
SecRandom, and finally
fortuna_read for LibTomCrypt.