Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp3603034ybv; Mon, 10 Feb 2020 03:05:08 -0800 (PST) X-Google-Smtp-Source: APXvYqyg2fRUfHLpuOVduV4L77fpVZa1OTnbhcR06pSwArdxzjL0cElm0Re5YVU76OGbexATq5hY X-Received: by 2002:a05:6830:1042:: with SMTP id b2mr626540otp.306.1581332707939; Mon, 10 Feb 2020 03:05:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581332707; cv=none; d=google.com; s=arc-20160816; b=HmOP6tWIRFGZXg9iXHPx5nbL38IDjehyh/Sr7eTPjEH+hEpAB9LTd4rwxW2+/RK1vR hQK+H17Ubrofj2Hhr28EMX3jO/lp9AVZD4Bq3QGVMOiRKDkvLdxPu1xLYEDLdh29znCc 5/myDLvVCmPkTNNRj9i4k+TyJST30P5w/4faMOtPBHEzofrhq/hALktw4xYTJMd97JyF KJwKpUoS/K4/doso8gxNrCeiWvqLdkSp9T3WZC7DKY1gEcvlxOBuUhDkK39Mi3wnIAyk q6dFd6Lrk5PuwFfGwbl80dlhdGvR9VeOVKLM/lEnFYZKIBhnaOwIa5grbwdQbMtufMgG 8myQ== 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=alOJHPsQsE8Vuocbp2sW09cDcf5fNcW1eN93Addh8k4=; b=UrzV/hLfGQaW6JEi/XAT7yKS76hQmBts52ZX1i7s0yFW/Mudqpr2AazSGIKVAj91ZH fmdqPgAz/ern55jP5wvhgNGFHNeRYj0iCyjh8jxiB2gBGuZV7Bw9kLYVCbfwHTBwqPyx UlB+FjjzDEUPHU8WfrdgkW4smBPNn8URyTQKk6QZZcF5ITdX6Q/dLsonplYzSZYx4AZy 919Q6hZwlvgVr4KXMkHQQ/qLxgAdSDPAuPXa6cEidejtgEtNfpHLO2Lq4bmUh4FIsCrk CFYwSI3KjNTdyySBHX2yzqt8DexX3+f5DbQhzH/I0dH96O7Oc9w1cjn0XPwZpIBfnW1x orGQ== 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 w4si43211otq.144.2020.02.10.03.04.47; Mon, 10 Feb 2020 03:05:07 -0800 (PST) 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 S1727003AbgBJLEn (ORCPT + 99 others); Mon, 10 Feb 2020 06:04:43 -0500 Received: from helcar.hmeau.com ([216.24.177.18]:32912 "EHLO deadmen.hmeau.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726796AbgBJLEn (ORCPT ); Mon, 10 Feb 2020 06:04:43 -0500 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 1j16rn-0002aQ-CC; Mon, 10 Feb 2020 19:04:39 +0800 Received: from herbert by gondobar with local (Exim 4.89) (envelope-from ) id 1j16rf-00051U-QY; Mon, 10 Feb 2020 19:04:31 +0800 Date: Mon, 10 Feb 2020 19:04:31 +0800 From: Herbert Xu To: Eric Biggers Cc: Gilad Ben-Yossef , Stephan Mueller , Linux Crypto Mailing List , Geert Uytterhoeven , David Miller , Ofir Drang Subject: Re: Possible issue with new inauthentic AEAD in extended crypto tests Message-ID: <20200210110431.mhn7hlkmp3usad7s@gondor.apana.org.au> References: <20200128023455.GC960@sol.localdomain> <20200128033824.p3z3jhc7mp7wlikp@gondor.apana.org.au> <20200128211229.GA224488@gmail.com> <20200207072709.GB8284@sol.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200207072709.GB8284@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 Thu, Feb 06, 2020 at 11:27:09PM -0800, Eric Biggers wrote: > > Yes, for rfc4106 the tests don't pass the same IV in both places. This is > because I wrote the tests from the perspective of a generic AEAD that doesn't > have this weird IV quirk, and then I added the minimum quirks to get the weird > algorithms like rfc4106 passing. > > Since the actual behavior of the generic implementation of rfc4106 is that the > last 8 bytes of the AAD are ignored, that means that currently the tests just > avoid mutating these bytes when generating inauthentic input tests. They don't > know that they're (apparently) meant to be another copy of the IV. > > So it seems we need to clearly define the behavior when the two IV copies don't > match. Should one or the other be used, should an error be returned, or should > the behavior be unspecified (in which case the tests would need to be updated)? > > Unspecified behavior is bad, but it would be easiest for software to use > req->iv, while hardware might want to use the IV in the scatterlist... > > Herbert and Stephan, any idea what was intended here? I think unspecified would be OK here to give the hardware the maximum latitude. However, we also don't want it to crash or do something funny so perhaps generate the test vectors as you do now but compare it against the generic using two IV values? Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt