Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp1319086ybi; Wed, 19 Jun 2019 18:19:01 -0700 (PDT) X-Google-Smtp-Source: APXvYqwziUQRicNJbEDgfllTbzokQC8ZAtfYHyTemiJymCrkxJvbggXaWoxU+kREWixcNR3unKSq X-Received: by 2002:a17:902:44a4:: with SMTP id l33mr42605859pld.174.1560993541659; Wed, 19 Jun 2019 18:19:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560993541; cv=none; d=google.com; s=arc-20160816; b=o/59f+fiBJ8T+BjIbMwV3Qxsbp+atEblNSuz8w2vGXix7nC8pSNobyWMwKNONyc2tO 2S8LASFEsjFV9TcHh1gFD2/UskwJKxhcz4aB1hynwHdk/fETtCqFIHkU0Q3UnzGQ0brh ce6w2rOLEYj5L/HJmOvCezzHvp78U14AGjkxx9+y1Hl0/T4DH+oHfPs4ZWA3ad66akeX Lt5k6nWaOObLKcv2VXCytms5sVirE/JKk8At3/yWHpsHgHMq7S47/MVP+3mf/Z44jeNb x5UBzfdPQww9IeL1zwpHhuG7EHZ6cp4CvkKAlcF9kCGGuakUcJpU1elf4Gtew6AgJShE NtNw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=HWeEYeB4R/eO/ROLYoC0JRPeKR3iXNVeL00zjig6FwU=; b=rssRk3W8AEh0sv14WCLvdiw4rZEx0wF9lE3SjuaBb/wJwAFNTox50WDM4F4Z0ediJg cQnJazyKXz94VmXxp2iyuh7Y4IxhEfGYCxhUXpbL6VKMAhf+GqmLZ3owOFZSyzrByGGY bu95o94XGkJqETYOJlnRC3tS1gBeNen33OkOvmBJ2hG94yKxwHpWDhmyOJNSFqhPgkSV GvBo18nudYFKYFG0b3W49sR37c3lWiTyVrYR/U53KqdXI3k1ozHjN7mOz7LHpcGS5ZNx fvOIeFrNFSU7CtwGs7UJCjWbjy2wVHiSfmjcFUiQACklZEuh/tBeICSbs7m0kjugdOTt PNhw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q39si2675128pjc.55.2019.06.19.18.18.47; Wed, 19 Jun 2019 18:19:01 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731073AbfFTBS2 (ORCPT + 99 others); Wed, 19 Jun 2019 21:18:28 -0400 Received: from helcar.hmeau.com ([216.24.177.18]:50496 "EHLO deadmen.hmeau.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726211AbfFTBS2 (ORCPT ); Wed, 19 Jun 2019 21:18:28 -0400 Received: from gondobar.mordor.me.apana.org.au ([192.168.128.4] helo=gondobar) by deadmen.hmeau.com with esmtps (Exim 4.89 #2 (Debian)) id 1hdlia-0005Vu-LJ; Thu, 20 Jun 2019 09:18:24 +0800 Received: from herbert by gondobar with local (Exim 4.89) (envelope-from ) id 1hdli5-0006fe-4U; Thu, 20 Jun 2019 09:17:53 +0800 Date: Thu, 20 Jun 2019 09:17:53 +0800 From: Herbert Xu To: Eric Biggers Cc: Ard Biesheuvel , linux-crypto@vger.kernel.org, dm-devel@redhat.com, linux-fscrypt@vger.kernel.org, Gilad Ben-Yossef , Milan Broz Subject: Re: [PATCH v3 1/6] crypto: essiv - create wrapper template for ESSIV generation Message-ID: <20190620011752.et6clrrrbl5llgr2@gondor.apana.org.au> References: <20190619162921.12509-1-ard.biesheuvel@linaro.org> <20190619162921.12509-2-ard.biesheuvel@linaro.org> <20190620010417.GA722@sol.localdomain> <20190620011325.phmxmeqnv2o3wqtr@gondor.apana.org.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190620011325.phmxmeqnv2o3wqtr@gondor.apana.org.au> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Thu, Jun 20, 2019 at 09:13:25AM +0800, Herbert Xu wrote: > On Wed, Jun 19, 2019 at 06:04:17PM -0700, Eric Biggers wrote: > > > > > +#define ESSIV_IV_SIZE sizeof(u64) // IV size of the outer algo > > > +#define MAX_INNER_IV_SIZE 16 // max IV size of inner algo > > > > Why does the outer algorithm declare a smaller IV size? Shouldn't it just be > > the same as the inner algorithm's? > > In general we allow outer algorithms to have distinct IV sizes > compared to the inner algorithm. For example, rfc4106 has a > different IV size compared to gcm. > > In this case, the outer IV size is the block number so that's > presumably why 64 bits is sufficient. Do you forsee a case where > we need 128-bit block numbers? Actually this reminds me, the essiv template needs to be able to handle multiple blocks/sectors, as otherwise this will still only be able to push a single block/sector to the hardware at a time. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt