From mboxrd@z Thu Jan 1 00:00:00 1970 From: Milan Broz Subject: Re: [RFC PATCH v2] md/dm-crypt - reuse eboiv skcipher for IV generation Date: Thu, 8 Aug 2019 14:52:33 +0200 Message-ID: <67b4f0ee-b169-8af4-d7af-1c53a66ba587@gmail.com> References: <20190807055022.15551-1-ard.biesheuvel@linaro.org> <20190808083059.GB5319@sol.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: Pascal Van Leeuwen , Eric Biggers Cc: "herbert@gondor.apana.org.au" , "snitzer@redhat.com" , Ard Biesheuvel , "dm-devel@redhat.com" , "linux-crypto@vger.kernel.org" , "agk@redhat.com" List-Id: dm-devel.ids On 08/08/2019 11:31, Pascal Van Leeuwen wrote: >> -----Original Message----- >> From: Eric Biggers >> Sent: Thursday, August 8, 2019 10:31 AM >> To: Pascal Van Leeuwen >> Cc: Ard Biesheuvel ; linux-crypto@vger.kernel.org; >> herbert@gondor.apana.org.au; agk@redhat.com; snitzer@redhat.com; dm-devel@redhat.com; >> gmazyland@gmail.com >> Subject: Re: [RFC PATCH v2] md/dm-crypt - reuse eboiv skcipher for IV generation >> >> On Wed, Aug 07, 2019 at 04:14:22PM +0000, Pascal Van Leeuwen wrote: >>>>>> In your case, we are not dealing with known plaintext attacks, >>>>>> >>>>> Since this is XTS, which is used for disk encryption, I would argue >>>>> we do! For the tweak encryption, the sector number is known plaintext, >>>>> same as for EBOIV. Also, you may be able to control data being written >>>>> to the disk encrypted, either directly or indirectly. >>>>> OK, part of the data into the CTS encryption will be previous ciphertext, >>>>> but that may be just 1 byte with the rest being the known plaintext. >>>>> >>>> >>>> The tweak encryption uses a dedicated key, so leaking it does not have >>>> the same impact as it does in the EBOIV case. >>>> >>> Well ... yes and no. The spec defines them as seperately controllable - >>> deviating from the original XEX definition - but in most practicle use cases >>> I've seen, the same key is used for both, as having 2 keys just increases >>> key storage requirements and does not actually improve effective security >>> (of the algorithm itself, implementation peculiarities like this one aside >>> :-), as XEX has been proven secure using a single key. And the security >>> proof for XTS actually builds on that while using 2 keys deviates from it. >>> >> >> This is a common misconception. Actually, XTS needs 2 distinct keys to be a >> CCA-secure tweakable block cipher, due to another subtle difference from XEX: >> XEX (by which I really mean "XEX[E,2]") builds the sequence of masks starting >> with x^1, while XTS starts with x^0. If only 1 key is used, the inclusion of >> the 0th power in XTS allows the attack described in Section 6 of the XEX paper >> (https://web.cs.ucdavis.edu/~rogaway/papers/offsets.pdf). >> > Interesting ... I'm not a cryptographer, just a humble HW engineer specialized > in implementing crypto. I'm basing my views mostly on the Liskov/Minematsu > "Comments on XTS", who assert that using 2 keys in XTS was misguided. > (and I never saw any follow-on comments asserting that this view was wrong ...) > On not avoiding j=0 in the XTS spec they actually comment: > "This difference is significant in security, but has no impact on effectiveness > for practical applications.", which I read as "not relevant for normal use". > > In any case, it's frequently *used* with both keys being equal for performance > and key storage reasons. There is already check in kernel for XTS "weak" keys (tweak and encryption keys must not be the same). https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/crypto/xts.h#n27 For now it applies only in FIPS mode... (and if I see correctly it is duplicated in all drivers). Milan