> 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).
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.