From: Pascal Van Leeuwen <pvanleeuwen@verimatrix.com> To: Milan Broz <gmazyland@gmail.com>, Eric Biggers <ebiggers@kernel.org> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>, "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>, "herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>, "agk@redhat.com" <agk@redhat.com>, "snitzer@redhat.com" <snitzer@redhat.com>, "dm-devel@redhat.com" <dm-devel@redhat.com> Subject: RE: [RFC PATCH v2] md/dm-crypt - reuse eboiv skcipher for IV generation Date: Thu, 8 Aug 2019 13:23:10 +0000 Message-ID: <MN2PR20MB29739B9D16130F5C06831C92CAD70@MN2PR20MB2973.namprd20.prod.outlook.com> (raw) In-Reply-To: <67b4f0ee-b169-8af4-d7af-1c53a66ba587@gmail.com> > -----Original Message----- > From: Milan Broz <gmazyland@gmail.com> > Sent: Thursday, August 8, 2019 2:53 PM > To: Pascal Van Leeuwen <pvanleeuwen@verimatrix.com>; Eric Biggers <ebiggers@kernel.org> > Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>; linux-crypto@vger.kernel.org; > herbert@gondor.apana.org.au; agk@redhat.com; snitzer@redhat.com; dm-devel@redhat.com > Subject: Re: [RFC PATCH v2] md/dm-crypt - reuse eboiv skcipher for IV generation > > On 08/08/2019 11:31, Pascal Van Leeuwen wrote: > >> -----Original Message----- > >> From: Eric Biggers <ebiggers@kernel.org> > >> Sent: Thursday, August 8, 2019 10:31 AM > >> To: Pascal Van Leeuwen <pvanleeuwen@verimatrix.com> > >> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>; 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). > I never had any need to look into FIPS for XTS before, but this actually appears to be accurate. FIPS indeed *requires this*. Much to my surprise, I might add. Still looking for some actual rationale that goes beyond suggestion and innuendo (and is not too heavy on the math ;-) though. > Milan Regards, Pascal van Leeuwen Silicon IP Architect, Multi-Protocol Engines @ Verimatrix www.insidesecure.com
next prev parent reply index Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-08-07 5:50 Ard Biesheuvel 2019-08-07 7:28 ` Pascal Van Leeuwen 2019-08-07 13:17 ` Ard Biesheuvel 2019-08-07 13:52 ` Pascal Van Leeuwen 2019-08-07 15:39 ` Ard Biesheuvel 2019-08-07 16:14 ` Pascal Van Leeuwen 2019-08-07 16:50 ` Ard Biesheuvel 2019-08-07 20:22 ` Pascal Van Leeuwen 2019-08-08 8:30 ` Eric Biggers 2019-08-08 9:31 ` Pascal Van Leeuwen 2019-08-08 12:52 ` Milan Broz 2019-08-08 13:23 ` Pascal Van Leeuwen [this message] 2019-08-08 17:15 ` Eric Biggers 2019-08-09 9:17 ` Pascal Van Leeuwen 2019-08-09 17:17 ` Eric Biggers 2019-08-09 20:29 ` Pascal Van Leeuwen 2019-08-09 20:56 ` Eric Biggers 2019-08-09 21:33 ` Pascal Van Leeuwen 2019-08-09 22:04 ` Eric Biggers 2019-08-09 23:01 ` Pascal Van Leeuwen 2019-08-07 8:08 ` Milan Broz 2019-08-08 11:53 ` Milan Broz 2019-08-09 18:52 ` Ard Biesheuvel
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=MN2PR20MB29739B9D16130F5C06831C92CAD70@MN2PR20MB2973.namprd20.prod.outlook.com \ --to=pvanleeuwen@verimatrix.com \ --cc=agk@redhat.com \ --cc=ard.biesheuvel@linaro.org \ --cc=dm-devel@redhat.com \ --cc=ebiggers@kernel.org \ --cc=gmazyland@gmail.com \ --cc=herbert@gondor.apana.org.au \ --cc=linux-crypto@vger.kernel.org \ --cc=snitzer@redhat.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Linux-Crypto Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-crypto/0 linux-crypto/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-crypto linux-crypto/ https://lore.kernel.org/linux-crypto \ linux-crypto@vger.kernel.org public-inbox-index linux-crypto Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-crypto AGPL code for this site: git clone https://public-inbox.org/public-inbox.git