utelle
commented
6 years ago I'd like to add a few comments:
-
Preliminary note I'm not in favor of SQLCipher - in the contrary, I maintain a separate self-contained SQLite encryption extension (as part of my project wxSQLite3) myself since 2007. Nevertheless, I think it is important to make a fair, unbiased comparison as far as this is possible for a developer of a separate SQLite encryption extension.
-
Lines of codes 3000 lines (SQLCipher) vs 1300 lines (sqleet) seems to indicate that sqleet is far more compact than SQLCipher. IMHO this comparison gives a false impression. There are reasons for the higher amount of code: support for 3 different crypto providers, support for run-time configuration via pragmas, and last but not least a lot of trace statements for debugging.
-
Dependencies SQLCipher depends on an external crypto provider library. That's true, but it is not limited to OpenSSL. At the developer's discretion it is also possible to use LibTomCrypt or Apple's CommonCrypto instead of OpenSSL. And further crypto providers could be added - even your own implementation, since SQLCipher is open source, after all. For many users it is important however that the crypto provider is FIPS-validated - and this is the case for OpenSSL (FIPS validation). Whether this offers better security is a different question. Fact is, that decision makers in companies often rely on FIPS validation and the like.
-
Run-time Configurability SQLCipher offers some options to configure it at run-time (via pragmas). However, several of them are only required to allow backward compatibility with earlier SQLCipher encryption scheme versions. sqleet will face a similar problem, when the encryption scheme is changed in a future version - i.e. in issue #3 you mention Argon2 as a replacement for PBKDF2. BTW, it wouldn't be a big deal to add run-time configurability (like changing the number of PBKDF2 iterations) for sqleet using SQLite's user-defined functions.
-
Compatibility You claim that SQLCipher does not offer backward/forward version compatibility. This is simply not true. The version compatibility is more or less the same as for SQLite itself. Of course, if the encryption scheme changes - as was the case between SQLCipher version 1 and 2 -, databases encrypted with the older version have to be converted to the new scheme. However, this will be true for sqleet as well, as soon as you add Argon2 as an alternative or replacement for PBKDF2. A real problem of SQLCipher is that upgrading to a new SQLite version is a major effort, since several adjustments to individual SQLite source files have to be done, instead of just dropping in the latest SQLite amalgamation.
resilar
A brief comparison of SQLCipher and sqleet features. Last updated: 2019-02-17
General
Cryptographic primitives (default configuration)
Cryptographically wise, they implement pretty much the exact same functionality but using different primitives. ChaCha20-Poly1305 makes sqleet probably a better choice for embedded systems and mobile devices with slow CPUs, but there is not much else to say about the cryptographic primitive choices. PBKDF2 iteration count and cipher are run-time configurable in SQLCipher, while sqleet supports only easy configuration of PBKDF2 iterations at compile time.
Practicalities
SQLCipher offers no backward/forward source version compatibility, that is, upgrading SQLite3 version always requires major adjustments to the code of SQLCipher (there are typically one or two SQLCipher releases in a year; thus, SQLCipher users might have to wait up to 1 year for support of the latest SQLite3 version). In comparison, sqleet's backward/forward compatibility usually spans several SQLite3 versions, that is, the current version of sqleet source code most likely works with the upcoming SQLite3 versions without any modifications (just drop in the new SQLite3 amalgamation).
Additionally, the crypto of sqleet has been implemented from scratch and not validated, which simplifies compiling & linking (especially in embedded environments) but is a red flag to some people. The cryptographic primitives implemented in sqleet are reasonably resistant to side channel attacks (ChaCha20 and PBKDF2-HMAC-SHA256 by design, and the Poly1305 implementation is constant time).