From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Biggers Subject: Re: [RFC PATCH v2] md/dm-crypt - reuse eboiv skcipher for IV generation Date: Thu, 8 Aug 2019 10:15:10 -0700 Message-ID: <20190808171508.GA201004@gmail.com> References: <20190807055022.15551-1-ard.biesheuvel@linaro.org> <20190808083059.GB5319@sol.localdomain> <67b4f0ee-b169-8af4-d7af-1c53a66ba587@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Content-Disposition: inline In-Reply-To: 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 Cc: "herbert@gondor.apana.org.au" , "snitzer@redhat.com" , Ard Biesheuvel , "dm-devel@redhat.com" , "linux-crypto@vger.kernel.org" , Milan Broz , "agk@redhat.com" List-Id: dm-devel.ids T24gVGh1LCBBdWcgMDgsIDIwMTkgYXQgMDE6MjM6MTBQTSArMDAwMCwgUGFzY2FsIFZhbiBMZWV1 d2VuIHdyb3RlOgo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0KPiA+IEZyb206IE1pbGFu IEJyb3ogPGdtYXp5bGFuZEBnbWFpbC5jb20+Cj4gPiBTZW50OiBUaHVyc2RheSwgQXVndXN0IDgs IDIwMTkgMjo1MyBQTQo+ID4gVG86IFBhc2NhbCBWYW4gTGVldXdlbiA8cHZhbmxlZXV3ZW5AdmVy aW1hdHJpeC5jb20+OyBFcmljIEJpZ2dlcnMgPGViaWdnZXJzQGtlcm5lbC5vcmc+Cj4gPiBDYzog QXJkIEJpZXNoZXV2ZWwgPGFyZC5iaWVzaGV1dmVsQGxpbmFyby5vcmc+OyBsaW51eC1jcnlwdG9A dmdlci5rZXJuZWwub3JnOwo+ID4gaGVyYmVydEBnb25kb3IuYXBhbmEub3JnLmF1OyBhZ2tAcmVk aGF0LmNvbTsgc25pdHplckByZWRoYXQuY29tOyBkbS1kZXZlbEByZWRoYXQuY29tCj4gPiBTdWJq ZWN0OiBSZTogW1JGQyBQQVRDSCB2Ml0gbWQvZG0tY3J5cHQgLSByZXVzZSBlYm9pdiBza2NpcGhl ciBmb3IgSVYgZ2VuZXJhdGlvbgo+ID4gCj4gPiBPbiAwOC8wOC8yMDE5IDExOjMxLCBQYXNjYWwg VmFuIExlZXV3ZW4gd3JvdGU6Cj4gPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQo+ID4g Pj4gRnJvbTogRXJpYyBCaWdnZXJzIDxlYmlnZ2Vyc0BrZXJuZWwub3JnPgo+ID4gPj4gU2VudDog VGh1cnNkYXksIEF1Z3VzdCA4LCAyMDE5IDEwOjMxIEFNCj4gPiA+PiBUbzogUGFzY2FsIFZhbiBM ZWV1d2VuIDxwdmFubGVldXdlbkB2ZXJpbWF0cml4LmNvbT4KPiA+ID4+IENjOiBBcmQgQmllc2hl dXZlbCA8YXJkLmJpZXNoZXV2ZWxAbGluYXJvLm9yZz47IGxpbnV4LWNyeXB0b0B2Z2VyLmtlcm5l bC5vcmc7Cj4gPiA+PiBoZXJiZXJ0QGdvbmRvci5hcGFuYS5vcmcuYXU7IGFna0ByZWRoYXQuY29t OyBzbml0emVyQHJlZGhhdC5jb207IGRtLWRldmVsQHJlZGhhdC5jb207Cj4gPiA+PiBnbWF6eWxh bmRAZ21haWwuY29tCj4gPiA+PiBTdWJqZWN0OiBSZTogW1JGQyBQQVRDSCB2Ml0gbWQvZG0tY3J5 cHQgLSByZXVzZSBlYm9pdiBza2NpcGhlciBmb3IgSVYgZ2VuZXJhdGlvbgo+ID4gPj4KPiA+ID4+ IE9uIFdlZCwgQXVnIDA3LCAyMDE5IGF0IDA0OjE0OjIyUE0gKzAwMDAsIFBhc2NhbCBWYW4gTGVl dXdlbiB3cm90ZToKPiA+ID4+Pj4+PiBJbiB5b3VyIGNhc2UsIHdlIGFyZSBub3QgZGVhbGluZyB3 aXRoIGtub3duIHBsYWludGV4dCBhdHRhY2tzLAo+ID4gPj4+Pj4+Cj4gPiA+Pj4+PiBTaW5jZSB0 aGlzIGlzIFhUUywgd2hpY2ggaXMgdXNlZCBmb3IgZGlzayBlbmNyeXB0aW9uLCBJIHdvdWxkIGFy Z3VlCj4gPiA+Pj4+PiB3ZSBkbyEgRm9yIHRoZSB0d2VhayBlbmNyeXB0aW9uLCB0aGUgc2VjdG9y IG51bWJlciBpcyBrbm93biBwbGFpbnRleHQsCj4gPiA+Pj4+PiBzYW1lIGFzIGZvciBFQk9JVi4g QWxzbywgeW91IG1heSBiZSBhYmxlIHRvIGNvbnRyb2wgZGF0YSBiZWluZyB3cml0dGVuCj4gPiA+ Pj4+PiB0byB0aGUgZGlzayBlbmNyeXB0ZWQsIGVpdGhlciBkaXJlY3RseSBvciBpbmRpcmVjdGx5 Lgo+ID4gPj4+Pj4gT0ssIHBhcnQgb2YgdGhlIGRhdGEgaW50byB0aGUgQ1RTIGVuY3J5cHRpb24g d2lsbCBiZSBwcmV2aW91cyBjaXBoZXJ0ZXh0LAo+ID4gPj4+Pj4gYnV0IHRoYXQgbWF5IGJlIGp1 c3QgMSBieXRlIHdpdGggdGhlIHJlc3QgYmVpbmcgdGhlIGtub3duIHBsYWludGV4dC4KPiA+ID4+ Pj4+Cj4gPiA+Pj4+Cj4gPiA+Pj4+IFRoZSB0d2VhayBlbmNyeXB0aW9uIHVzZXMgYSBkZWRpY2F0 ZWQga2V5LCBzbyBsZWFraW5nIGl0IGRvZXMgbm90IGhhdmUKPiA+ID4+Pj4gdGhlIHNhbWUgaW1w YWN0IGFzIGl0IGRvZXMgaW4gdGhlIEVCT0lWIGNhc2UuCj4gPiA+Pj4+Cj4gPiA+Pj4gV2VsbCAu Li4geWVzIGFuZCBuby4gVGhlIHNwZWMgZGVmaW5lcyB0aGVtIGFzIHNlcGVyYXRlbHkgY29udHJv bGxhYmxlIC0KPiA+ID4+PiBkZXZpYXRpbmcgZnJvbSB0aGUgb3JpZ2luYWwgWEVYIGRlZmluaXRp b24gLSBidXQgaW4gbW9zdCBwcmFjdGljbGUgdXNlIGNhc2VzCj4gPiA+Pj4gSSd2ZSBzZWVuLCB0 aGUgc2FtZSBrZXkgaXMgdXNlZCBmb3IgYm90aCwgYXMgaGF2aW5nIDIga2V5cyBqdXN0IGluY3Jl YXNlcwo+ID4gPj4+IGtleSAgc3RvcmFnZSByZXF1aXJlbWVudHMgYW5kIGRvZXMgbm90IGFjdHVh bGx5IGltcHJvdmUgZWZmZWN0aXZlIHNlY3VyaXR5Cj4gPiA+Pj4gKG9mIHRoZSBhbGdvcml0aG0g aXRzZWxmLCBpbXBsZW1lbnRhdGlvbiBwZWN1bGlhcml0aWVzIGxpa2UgdGhpcyBvbmUgYXNpZGUK PiA+ID4+PiA6LSksIGFzICBYRVggaGFzIGJlZW4gcHJvdmVuIHNlY3VyZSB1c2luZyBhIHNpbmds ZSBrZXkuIEFuZCB0aGUgc2VjdXJpdHkKPiA+ID4+PiBwcm9vZiBmb3IgWFRTIGFjdHVhbGx5IGJ1 aWxkcyBvbiB0aGF0IHdoaWxlIHVzaW5nIDIga2V5cyBkZXZpYXRlcyBmcm9tIGl0Lgo+ID4gPj4+ Cj4gPiA+Pgo+ID4gPj4gVGhpcyBpcyBhIGNvbW1vbiBtaXNjb25jZXB0aW9uLiAgQWN0dWFsbHks IFhUUyBuZWVkcyAyIGRpc3RpbmN0IGtleXMgdG8gYmUgYQo+ID4gPj4gQ0NBLXNlY3VyZSB0d2Vh a2FibGUgYmxvY2sgY2lwaGVyLCBkdWUgdG8gYW5vdGhlciBzdWJ0bGUgZGlmZmVyZW5jZSBmcm9t IFhFWDoKPiA+ID4+IFhFWCAoYnkgd2hpY2ggSSByZWFsbHkgbWVhbiAiWEVYW0UsMl0iKSBidWls ZHMgdGhlIHNlcXVlbmNlIG9mIG1hc2tzIHN0YXJ0aW5nCj4gPiA+PiB3aXRoIHheMSwgd2hpbGUg WFRTIHN0YXJ0cyB3aXRoIHheMC4gIElmIG9ubHkgMSBrZXkgaXMgdXNlZCwgdGhlIGluY2x1c2lv biBvZgo+ID4gPj4gdGhlIDB0aCBwb3dlciBpbiBYVFMgYWxsb3dzIHRoZSBhdHRhY2sgZGVzY3Jp YmVkIGluIFNlY3Rpb24gNiBvZiB0aGUgWEVYIHBhcGVyCj4gPiA+PiAoaHR0cHM6Ly93ZWIuY3Mu dWNkYXZpcy5lZHUvfnJvZ2F3YXkvcGFwZXJzL29mZnNldHMucGRmKS4KPiA+ID4+Cj4gPiA+IElu dGVyZXN0aW5nIC4uLiBJJ20gbm90IGEgY3J5cHRvZ3JhcGhlciwganVzdCBhIGh1bWJsZSBIVyBl bmdpbmVlciBzcGVjaWFsaXplZAo+ID4gPiBpbiBpbXBsZW1lbnRpbmcgY3J5cHRvLiBJJ20gYmFz aW5nIG15IHZpZXdzIG1vc3RseSBvbiB0aGUgTGlza292L01pbmVtYXRzdQo+ID4gPiAiQ29tbWVu dHMgb24gWFRTIiwgd2hvIGFzc2VydCB0aGF0IHVzaW5nIDIga2V5cyBpbiBYVFMgd2FzIG1pc2d1 aWRlZC4KPiA+ID4gKGFuZCBJIG5ldmVyIHNhdyBhbnkgZm9sbG93LW9uIGNvbW1lbnRzIGFzc2Vy dGluZyB0aGF0IHRoaXMgdmlldyB3YXMgd3JvbmcgLi4uKQo+ID4gPiBPbiBub3QgYXZvaWRpbmcg aj0wIGluIHRoZSBYVFMgc3BlYyB0aGV5IGFjdHVhbGx5IGNvbW1lbnQ6Cj4gPiA+ICJUaGlzIGRp ZmZlcmVuY2UgaXMgc2lnbmlmaWNhbnQgaW4gc2VjdXJpdHksIGJ1dCBoYXMgbm8gaW1wYWN0IG9u IGVmZmVjdGl2ZW5lc3MKPiA+ID4gZm9yIHByYWN0aWNhbCBhcHBsaWNhdGlvbnMuIiwgd2hpY2gg SSByZWFkIGFzICJub3QgcmVsZXZhbnQgZm9yIG5vcm1hbCB1c2UiLgoKU2VlIHBhZ2UgNiBvZiAi Q29tbWVudHMgb24gWFRTIjoKCglOb3RlIHRoYXQgaiA9IDAgbXVzdCBiZSBleGNsdWRlZCwgYXMg ZigwLCB2KSA9IHYgZm9yIGFueSB2LCB3aGljaAoJaW1wbGllcyDPgSA9IDEuIE1vcmVvdmVyLCBp ZiBqID0gMCB3YXMgYWxsb3dlZCwgYSBzaW1wbGUgYXR0YWNrIGJhc2VkIG9uCgl0aGlzIGZhY3Qg ZXhpc3RlZCwgYXMgcG9pbnRlZCBvdXQgYnkgWzZdIGFuZCBbM10uIEhlbmNlIGlmIFhFWCBpcyB1 c2VkLAoJb25lIG11c3QgYmUgY2FyZWZ1bCB0byBhdm9pZCBqIGJlaW5nIDAuCgpUaGUgcGFydCB5 b3UgcXVvdGVkIGlzIG9ubHkgdGFsa2luZyBhYm91dCBYVFMgKmFzIHNwZWNpZmllZCosIGkuZS4g d2l0aCAyIGtleXMuCgo+ID4gPgo+ID4gPiBJbiBhbnkgY2FzZSwgaXQncyBmcmVxdWVudGx5ICp1 c2VkKiB3aXRoIGJvdGgga2V5cyBiZWluZyBlcXVhbCBmb3IgcGVyZm9ybWFuY2UKPiA+ID4gYW5k IGtleSBzdG9yYWdlIHJlYXNvbnMuCgpJdCdzIGJyb2tlbiwgc28gaXQncyBicm9rZW4uICBEb2Vz bid0IG1hdHRlciB3aG8gaXMgdXNpbmcgaXQuCgo+ID4gCj4gPiBUaGVyZSBpcyBhbHJlYWR5IGNo ZWNrIGluIGtlcm5lbCBmb3IgWFRTICJ3ZWFrIiBrZXlzICh0d2VhayBhbmQgZW5jcnlwdGlvbiBr ZXlzIG11c3Qgbm90IGJlCj4gPiB0aGUgc2FtZSkuCj4gPiAKPiA+IGh0dHBzOi8vZ2l0Lmtlcm5l bC5vcmcvcHViL3NjbS9saW51eC9rZXJuZWwvZ2l0L3RvcnZhbGRzL2xpbnV4LmdpdC90cmVlL2lu Y2x1ZGUvY3J5cHRvL3h0cy5oIwo+ID4gbjI3Cj4gPiAKPiA+IEZvciBub3cgaXQgYXBwbGllcyBv bmx5IGluIEZJUFMgbW9kZS4uLiAoYW5kIGlmIEkgc2VlIGNvcnJlY3RseSBpdCBpcyBkdXBsaWNh dGVkIGluIGFsbAo+ID4gZHJpdmVycykuCj4gPiAKPiBJIG5ldmVyIGhhZCBhbnkgbmVlZCB0byBs b29rIGludG8gRklQUyBmb3IgWFRTIGJlZm9yZSwgYnV0IHRoaXMgYWN0dWFsbHkgYXBwZWFycwo+ IHRvIGJlIGFjY3VyYXRlLiBGSVBTIGluZGVlZCAqcmVxdWlyZXMgdGhpcyouIE11Y2ggdG8gbXkg c3VycHJpc2UsIEkgbWlnaHQgYWRkLgo+IFN0aWxsIGxvb2tpbmcgZm9yIHNvbWUgYWN0dWFsIHJh dGlvbmFsZSB0aGF0IGdvZXMgYmV5b25kIHN1Z2dlc3Rpb24gYW5kIGlubnVlbmRvIAo+IChhbmQg aXMgbm90IHRvbyBoZWF2eSBvbiB0aGUgbWF0aCA7LSkgdGhvdWdoLgoKQXMgSSBzYWlkLCB0aGUg YXR0YWNrIGlzIGV4cGxhaW5lZCBpbiB0aGUgb3JpZ2luYWwgWEVYIHBhcGVyLiAgQmFzaWNhbGx5 IHRoZQphZHZlcnNhcnkgY2FuIHN1Ym1pdCBhIGNob3NlbiBjaXBoZXJ0ZXh0IHF1ZXJ5IGZvciB0 aGUgZmlyc3QgYmxvY2sgb2Ygc2VjdG9yIDAKdG8gbGVhayB0aGUgZmlyc3QgIm1hc2siIG9mIHRo YXQgc2VjdG9yLCB0aGVuIHN1Ym1pdCBhIGNob3NlbiBwbGFpbnRleHQgb3IKY2lwaGVydGV4dCBx dWVyeSBmb3IgdGhlIHJlbWluZGVyIG9mIHRoZSBzZWN0b3Igc3VjaCB0aGF0IHRoZXkgY2FuIHBy ZWRpY3QgdGhlCm91dHB1dCB3aXRoIDEwMCUgY2VydGFpbnR5LiAgKFRoZSBzdGFuZGFyZCBzZWN1 cml0eSBtb2RlbCBmb3IgdHdlYWthYmxlIGJsb2NrCmNpcGhlcnMgc2F5cyB0aGUgb3V0cHV0IG11 c3QgYXBwZWFyIHJhbmRvbS4pCgotIEVyaWMKCi0tCmRtLWRldmVsIG1haWxpbmcgbGlzdApkbS1k ZXZlbEByZWRoYXQuY29tCmh0dHBzOi8vd3d3LnJlZGhhdC5jb20vbWFpbG1hbi9saXN0aW5mby9k bS1kZXZlbA== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FSL_HELO_FAKE,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8C711C0650F for ; Thu, 8 Aug 2019 17:15:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 50C2D21880 for ; Thu, 8 Aug 2019 17:15:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1565284514; bh=kyGM/qQKhDJIBrPc+j1pg6hHWKXYr9tMgkcFnysFN74=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=QAB8i1Vt7myhOuOn8XU+6pP0ymq93CeWSgrX1vS4LciaJjNjVhivU7b0fHOI0NIG3 YiKSGHif3LwSb4yK4j95MgeieJWwRwG8qXfJe1Rt42VuuMPw1QqBq4rWLgInk4QVVP dDAhlmNE5LrHC8fwp87IUc+QDiWIezNEGWvhjA+o= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404079AbfHHRPN (ORCPT ); Thu, 8 Aug 2019 13:15:13 -0400 Received: from mail.kernel.org ([198.145.29.99]:40288 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728020AbfHHRPN (ORCPT ); Thu, 8 Aug 2019 13:15:13 -0400 Received: from gmail.com (unknown [104.132.1.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 021E92184E; Thu, 8 Aug 2019 17:15:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1565284512; bh=kyGM/qQKhDJIBrPc+j1pg6hHWKXYr9tMgkcFnysFN74=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=L/AUcgekcAa7FaOUC3I52nk2J7FozQrmXzSY5K0YJO02HLbXWWmF4MAj/sQpNLcDt j85pchv/GzqFwmQkofIYd3qj7AyxPhWGJxFUIhySd28nPKcgI9q1wa4W0KmBOk+W7z Y0qUS3HM+qIqVbRigJO68to35ZCul45HwEZvLLy4= Date: Thu, 8 Aug 2019 10:15:10 -0700 From: Eric Biggers To: Pascal Van Leeuwen Cc: Milan Broz , Ard Biesheuvel , "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 Message-ID: <20190808171508.GA201004@gmail.com> Mail-Followup-To: Pascal Van Leeuwen , Milan Broz , Ard Biesheuvel , "linux-crypto@vger.kernel.org" , "herbert@gondor.apana.org.au" , "agk@redhat.com" , "snitzer@redhat.com" , "dm-devel@redhat.com" References: <20190807055022.15551-1-ard.biesheuvel@linaro.org> <20190808083059.GB5319@sol.localdomain> <67b4f0ee-b169-8af4-d7af-1c53a66ba587@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Thu, Aug 08, 2019 at 01:23:10PM +0000, Pascal Van Leeuwen wrote: > > -----Original Message----- > > From: Milan Broz > > Sent: Thursday, August 8, 2019 2:53 PM > > To: Pascal Van Leeuwen ; Eric Biggers > > Cc: Ard Biesheuvel ; 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 > > >> 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". See page 6 of "Comments on XTS": Note that j = 0 must be excluded, as f(0, v) = v for any v, which implies ρ = 1. Moreover, if j = 0 was allowed, a simple attack based on this fact existed, as pointed out by [6] and [3]. Hence if XEX is used, one must be careful to avoid j being 0. The part you quoted is only talking about XTS *as specified*, i.e. with 2 keys. > > > > > > In any case, it's frequently *used* with both keys being equal for performance > > > and key storage reasons. It's broken, so it's broken. Doesn't matter who is using it. > > > > 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. As I said, the attack is explained in the original XEX paper. Basically the adversary can submit a chosen ciphertext query for the first block of sector 0 to leak the first "mask" of that sector, then submit a chosen plaintext or ciphertext query for the reminder of the sector such that they can predict the output with 100% certainty. (The standard security model for tweakable block ciphers says the output must appear random.) - Eric