Jens Alfke <j...@mooseyard.com> writes: >> And any non-opensource crypto should be taken with triple caution. Or >> even opensource, but not widely-used or otherwise not known to be >> carefully peer-reviewed (FWIW, I looked at e.g. wxsqlite crypto code, it >> looks not exactly promising too). > > What do you think of SQLCipher?
Disclaimer: I'm not a real cryptographer ^_^, while I can notice some outright problematic things, but easily miss others. From quick overview: *) they had sense to avoid self-coding crypto primitives, and use openssl, tomscrypt or (macs?) commoncrypto; *) with openssl, they appear to support any cipher supported by openssl (but they deprecated `PRAGMA cipher` in recent releases, so it is aes-256-cbc by default); *) with other backends, no flexibility at all: only aes-256-cbc supported; *) use crypto provider's [strong] random for IV; *) for (optional) integrity, uses HMAC-SHA1; AFAIK, while SHA1 is getting more and more broken, HMAC-SHA1 is not broken yet; but it would be good if they had a plan ahead. *) don't support AEAD modes (such as AES-{GCM,CCM} or CHACHA20-POLY1305); *) for kdf, uses PBKDF2-HMAC-SHA1 by default (same: it is not broken yet, but). *) don't appear to be able to keep key in system-provided secure device/enclave; *) don't appear to be able to easily change passphrase (only by re-encrypting whole database) or use several passphrases (see LUKS for comparison). *) nitpick, but I don't like how they love to constantly re-init cipher (and hmac) context on reading/writing each page (key setup is not exactly inexpensive thing; with some cipher [e.g. blowfish], it is outright SLOW). (And slow crypto is *also* a security problem: if crypto is expensive, people tends to avoid it). *) error handling looks problematic in a lot of places (no error checks, there are memory/resource leaks on error paths). _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users