I don't disagree, and after some consideration and testing, will use the RFC recommendation of 3 iterations, 4 lanes, 64 MiB RAM.
However, it's also important to take note of how the KDF is used, and what is used by comparable solutions in equivalent settings.
For instance, the official extension, sold by the SQLite authors, uses RC4:
“For the "-textkey" option, up to 256 bytes of the passphrase are hashed using RC4 and the hash value becomes the encryption key. Note that in this context the RC4 algorithm is being used as a hash function, not as a cryptographic function, so the fact that RC4 is a cryptographically weak algorithm is irrelevant.”
The textkey= parameter is not really appropriate for interactive use, rather it is a convenient way for a user to specify a key in text form, as a URI parameter, without weakening it (by e.g. making NULs impossible, and reserved characters inconvenient to encode).
If you're taking a password from a user interactively, you should really be using your own password hashing, then using hexkey=. I'll try to make this clearer in the documentation.
> However, it's also important to take note of how the KDF is used
Agree completely. I'm glad that t=3 works for your usage requirements. Was hoping it wouldn't introduce an intolerable amount of latency.
> and what is used by comparable solutions in equivalent settings.
I interpreted the above and the linked documentation snippet as trying to say: "Yes, the KDF was sub-par, but alternatives are worse". Is this what you were trying to convey?
The fact that the official encryption extension is using sub-par KDF(the sentence about it being a hash and not a "cryptographic" function is insane, btw) has no bearing on your project or its implementation.
Yes, the fact that they're using crappy encryption doesn't excuse me.
But (IMO) context matters, and I can't really use something that causes opening a connection to take 1s on a low(er) end server. That would be appropriate for interactive use (i.e. ask a human user for a password), but not every time a connection drops and your server needs another one. And I'm weary to add caching at the library level and risk exposing a side channel.
I mean, caching the KDF result at the library level, without leaking that (e.g.) two databases share a key (that's the first one that came to mind, and why I removed the feature, instead of plugging the hole just to find another one).
However, it's also important to take note of how the KDF is used, and what is used by comparable solutions in equivalent settings.
For instance, the official extension, sold by the SQLite authors, uses RC4:
“For the "-textkey" option, up to 256 bytes of the passphrase are hashed using RC4 and the hash value becomes the encryption key. Note that in this context the RC4 algorithm is being used as a hash function, not as a cryptographic function, so the fact that RC4 is a cryptographically weak algorithm is irrelevant.”
The textkey= parameter is not really appropriate for interactive use, rather it is a convenient way for a user to specify a key in text form, as a URI parameter, without weakening it (by e.g. making NULs impossible, and reserved characters inconvenient to encode).
If you're taking a password from a user interactively, you should really be using your own password hashing, then using hexkey=. I'll try to make this clearer in the documentation.
reply