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. 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.  https://blog.cryptographyengineering.com/2016/08/24/attack-of-week-64-bit-ciphers-in-tls/