1:04 p.m.
by outgoing.mit.edu (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>
References: <c4dab8cf-66b8-0873-f6a9-9c59a551a155(a)symas.com>
From: Greg Hudson <ghudson(a)mit.edu>
Message-ID: <e9dce464-9d5a-971a-bb8e-d4d95168bcb0(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
Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <c4dab8cf-66b8-0873-f6a9-9c59a551a155(a)symas.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker:
H4sIAAAAAAAAA+NgFnrFIsWRmVeSWpSXmKPExsUixG6nouu3pyfS4MtKU4vb236zWLxd8IDd
gcnjy9JvLB6NCy4zBzBFcdmkpOZklqUW6dslcGXcutfKVLCGv+L37MQGxhM8XYycHBICJhKn
Nv1m7mLk4hASWMwk8a39LyOEs5FRYs7UqSwQzlEmidU/bjCCtAgLqEhc7l7C3sXIwSEiICex
bbcpSFhIwEbiYdsEFhCbTUBZYv3+rSwgJcwC9hL758mChHkFrCR2LHnICmKzCKhKnNw9lwnE
FhWIkHjYuYsdokZQ4uTMJ2BjOAVsJU6u+gm2lVlAXeLPvEvMELa8xPa3c5gnMArMQtIyC0nZ
LCRlCxiZVzHKpuRW6eYmZuYUpybrFicn5uWlFuka6uVmluilppRuYgQFKackzw7GM2+8DjEK
cDAq8fAmiHZHCrEmlhVX5h5ilORgUhLlLf4EFOJLyk+pzEgszogvKs1JLT7EKMHBrCTC67K7
J1KINyWxsiq1KB8mJc3BoiTOK6HRGCEkkJ5YkpqdmlqQWgSTleHgUJLgfbQLqFGwKDU9tSIt
M6cEIc3EwQkynAdouDfY8OKCxNzizHSI/ClGRSlx3j6QZgGQREZpHlwvOImkcpx5xSgO9Iow
bx9IOw8wAcF1vwIazAQ0OMK3E2RwSSJCSqqB0fmdyYtHAlUfV9l5xtzetozfwO/8cbucal6G
sO3fNLNWbfaqYUzW7Jc6sYqnufvuis0mRzTTJkWvfLZl3crXs3/7ZN59evrXcYfpDzdYm+7M
FFHZsS3R62nEw+zN63wc8sS6vvhpLhA25NmcuZLj14FMt9enH1YsSqzXjl310U75+dGQRJX1
0UosxRmJhlrMRcWJANmcCPP9AgAA
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/,
medium
trust [18.9.25.12 listed in list.dnswl.org]
-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information. [URIs: cryptographyengineering.com]
0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60%
[score: 0.4992]
0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines
Cc: "OpenLDAP-devel(a)openldap.org" <OpenLDAP-devel(a)openldap.org>
X-BeenThere: openldap-devel(a)openldap.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OpenLDAP development discussion list <openldap-devel.openldap.org>
List-Unsubscribe: <http://www.openldap.org/lists/mm/options/openldap-devel>;,
<mailto:openldap-devel-request@openldap.org?subject=unsubscribe>
List-Archive: <http://www.openldap.org/lists/openldap-devel/>
List-Post: <mailto:openldap-devel@openldap.org>
List-Help: <mailto:openldap-devel-request@openldap.org?subject=help>
List-Subscribe: <http://www.openldap.org/lists/mm/listinfo/openldap-devel>;,
<mailto:openldap-devel-request@openldap.org?subject=subscribe>
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[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...
2056
days inactive
2056
days old
0 comments
1 participants
participants (1)
-
None