Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp1315335ybi; Wed, 19 Jun 2019 18:14:21 -0700 (PDT) X-Google-Smtp-Source: APXvYqxWOvTUvK45U3XBIfiBuTs+8Fc58dh/GLQ43SrVw1STtsf6T7TWZx0CeoGWS32VydIbqXLR X-Received: by 2002:a65:6241:: with SMTP id q1mr10237375pgv.24.1560993261176; Wed, 19 Jun 2019 18:14:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560993261; cv=none; d=google.com; s=arc-20160816; b=h/btc0TjLzBvnQ+EH4hViskpaQRIUn0XLZONZ7Ca/PxehgJn0Mz6rfR/cpw0ReKiSg hENGj00vUUh0UDtQQ4w0C6YwF9fScBSbitmLH5a7tbZ9sTk1PPRqRBZvBKTc7XXlO4yT YpSdVQ4SP0Yg7uRZuUEhIl9mYLe2DHwnMWG/mJPr9QySnwLNG3uLELnVFxKPjlwMwZbm ZL0HY1rLFBLNMYcjz+SuxgknSbCzv4SCmllTaJcJNgEclecW1D4VTg+cFydkj7j3lBKl wg4S0Cq0sM+mwssF4svL9yot9EMmnGMD02H4A2Ru+2UBkQ9DlzC1I9T+CxdnKBUP6vAd WAVA== 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=82LzBs/yOrVkqnOMIRTxCLSfFR+N6LqAP5FicVCsabg=; b=FlV1w8McP1PDa8JixQ9LvaPEYzZtU042yTHny0YGD88BG2W10mgRDR7I4+oyUPuuRc bH6F3wcUi/wgtMykj7PQAVW187K/Xzq7mXtK/QMnmXmt6Qh/LVYiRz1hRlxVgoYhjcRm FGe46IuZjRBrQ2YNuSfjYnyg5i8aOcetQ/XNH2ZV3MgrOqy5sbCm0OvYpXOvChgIsL5x 4m4YHZtpIzPjq+ardm4MBcVlcs0EpzGLxchpEWVz5yVMCTkbYWUEMxE5pKqiMaWz2vwo 5ucpRyLdZ22prsj40P+pvWuf0MmtaRaeaNAHKZL3JfTSjpLA+kUTc6gparh/oA4QahnD iDNQ== 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 k11si2594841pjs.73.2019.06.19.18.14.06; Wed, 19 Jun 2019 18:14:21 -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 S1730896AbfFTBOC (ORCPT + 99 others); Wed, 19 Jun 2019 21:14:02 -0400 Received: from helcar.hmeau.com ([216.24.177.18]:50312 "EHLO deadmen.hmeau.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730815AbfFTBOC (ORCPT ); Wed, 19 Jun 2019 21:14:02 -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 1hdleI-0005Sl-Mh; Thu, 20 Jun 2019 09:13:58 +0800 Received: from herbert by gondobar with local (Exim 4.89) (envelope-from ) id 1hdldl-0006f1-NM; Thu, 20 Jun 2019 09:13:25 +0800 Date: Thu, 20 Jun 2019 09:13:25 +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: <20190620011325.phmxmeqnv2o3wqtr@gondor.apana.org.au> References: <20190619162921.12509-1-ard.biesheuvel@linaro.org> <20190619162921.12509-2-ard.biesheuvel@linaro.org> <20190620010417.GA722@sol.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190620010417.GA722@sol.localdomain> 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 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? Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt