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
