On 08/10/2017 11:55 AM, Howard Chu wrote:
> Thoughts? Hardcode 1 algorithm, or leave it pluggable?
Some thoughts, without advocating for either option:
* If support isn't built-in, then generic LMDB tools (including
mdb_copy/dump/load/stat) can't operate on encrypted databases, if they
need plaintext pages to work.
* Built-in support doesn't necessarily mean hardcoding an algorithm for
all time, if the meta pages can include an algorithm selector. One of
the selector values could even mean "use application callbacks".
* Is the page size guaranteed to be a multiple of 16 bytes? 32 bytes?
I would assume yes to both; documenting that would make it easier to use
block ciphers since ciphertext expansion isn't allowed.
* Application writers are more likely to get encryption callbacks wrong
than Howard is. They could ignore the IV (making it easy to detect
duplicate initial blocks within a page) or even do pure ECB encryption
(making it easy to detect duplicate blocks anywhere). Less egregiously,
applications might not make the ideal choice of cipher mode. I would
personally have to think about the best choice to use. If I were using
a block cipher, CBC with the provided ivec seems like it should be okay,
but assuming 128-bit cipher blocks, after around 2^64 blocks one would
expect to experience a block collision which reveals the XOR of the
plaintexts of the preceding two blocks[1]. Deriving a key with
HKDF(key, ivec) and using counter mode might be safer, unless I'm
missing something, which I easily could be. If I were using a stream
cipher, I would have to do research to figure out how to incorporate the
ivec.
* Not wanting to depend on crypto libraries seems like a valid concern.
Teaching the LMDB code how to dynamically load encryption plugins
doesn't necessarily seem attractive either.
[1]
https://blog.cryptographyengineering.com/2016/08/24/attack-of-week-64-bit-ciphers-in-tls/
