(8.13.8/8.12.4) with ESMTP id v7AK4Rlv006874
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT);
Thu, 10 Aug 2017 16:04:29 -0400
Subject: Re: LMDB encryption support
To: Howard Chu <hyc(a)symas.com>
From: Greg Hudson <ghudson(a)mit.edu>
Date: Thu, 10 Aug 2017 16:04:27 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
Content-Type: text/plain; charset=utf-8
X-Spam-Score: -1.5 (-)
X-Spam-Report: Spam detection software,
running on the system "gauss.openldap.net", has
identified this incoming email as possible spam. The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: 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. [...]
Content analysis details: (-1.5 points, 5.0 required)
pts rule name description
-2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/
trust [22.214.171.124 listed in list.dnswl.org
-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
for more information. [URIs: cryptographyengineering.com
0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60%
0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines
Cc: "OpenLDAP-devel(a)openldap.org" <OpenLDAP-devel(a)openldap.org>
List-Id: OpenLDAP development discussion list <openldap-devel.openldap.org>
X-List-Received-Date: Thu, 10 Aug 2017 20:04:40 -0000
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
* 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.