Linux-Crypto Archive on lore.kernel.org
 help / color / Atom feed
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

  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 publically 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 linux-crypto@archiver.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