Received: by 2002:a25:ef43:0:0:0:0:0 with SMTP id w3csp335452ybm; Fri, 29 May 2020 01:07:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwFo3QppjhCKiLlNchgrV1LpTaTrSktAuqSRs62D6kbCDgAWsx0qnr/f6dKrML9v2vzlpWs X-Received: by 2002:a17:906:1513:: with SMTP id b19mr5309822ejd.1.1590739630627; Fri, 29 May 2020 01:07:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590739630; cv=none; d=google.com; s=arc-20160816; b=QN9TU4QWjD7d+TU1p0EctYz6KMqVRPZGs/+mYJVGu7pQ4GwDIViKVOkUex3rjx1Xzw yfK/vfolOZwPk9hW4wDUr3h2RtdgZ+HazKYGdpBUwTL/vZyFXow+i2vCmQ5ZnpqgYH3l QviHJoISihwE8V6ZauMxVdkVAF2PYIKcc7Vszc+3cWGyDP+eURozVovtDF3BNYJTbWio jRE+F96wqDOstxHTaXvUk4hw+weD5nHCZUNqoT0JlKOjlb43n5SjmRLXElIpWQmygIvl f8YrLou4enqsnkq6qVM8ItBmNO7hqik5NqJ9Qt8CPOWm24fpzTzLo5RnwsXS5mpH47HV RPKg== 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=p7KpObfKgb2OtG5wYp9GZJo9+piz683sfmoo4u803Is=; b=fQO3DOJUmSpM6lcIXiNzjBMXo+5c2t99s5A0EvEEQBjIWCiq+oL4m8JNxjWWbmxXrx D4ZVhXeZGg1k39qwwjl5VrRlSJhJlVdVnVngR815+801oBvZpl/kOBHvUOeeX7Ymtjlb GSWD/VBn2xmdofUcbS3rSFpLDw4NvhqH9I0FHKNdkKOHjBboSwrCklqZQxpZMI8xdl6q mLx0Tmt+iCxYULNeB+xSyDhNG0fmm3E1De/TFGJ4oljsDtPObgoWLJz80igJQ0h+8mfC 0iuQgXerHo5X4Fkv+QURyVDhnrXlWwf87f7Kso79E1JH86aG7C965eAH9NogQjbC7upd Dtvg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i64si5395310edd.574.2020.05.29.01.06.36; Fri, 29 May 2020 01:07:10 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725601AbgE2IFR (ORCPT + 99 others); Fri, 29 May 2020 04:05:17 -0400 Received: from helcar.hmeau.com ([216.24.177.18]:40314 "EHLO fornost.hmeau.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725306AbgE2IFQ (ORCPT ); Fri, 29 May 2020 04:05:16 -0400 Received: from gwarestrin.arnor.me.apana.org.au ([192.168.0.7]) by fornost.hmeau.com with smtp (Exim 4.92 #5 (Debian)) id 1jea0q-00009x-S2; Fri, 29 May 2020 18:05:09 +1000 Received: by gwarestrin.arnor.me.apana.org.au (sSMTP sendmail emulation); Fri, 29 May 2020 18:05:08 +1000 Date: Fri, 29 May 2020 18:05:08 +1000 From: Herbert Xu To: Ard Biesheuvel Cc: Linux Crypto Mailing List , Linux ARM , Eric Biggers , Stephan Mueller Subject: Re: [RFC/RFT PATCH 0/2] crypto: add CTS output IVs for arm64 and testmgr Message-ID: <20200529080508.GA2880@gondor.apana.org.au> References: <20200519190211.76855-1-ardb@kernel.org> <20200528073349.GA32566@gondor.apana.org.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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, May 28, 2020 at 10:33:25AM +0200, Ard Biesheuvel wrote: > > The reason we return output IVs for CBC is because our generic > implementation of CTS can wrap any CBC implementation, and relies on > this output IV rather than grabbing it from the ciphertext directly > (which may be tricky and is best left up to the CBC code) No that's not the main reason. The main user of chaining is algif_skcipher. > So if you are saying that we should never split up algif_skcipher > requests into multiple calls into the underlying skcipher, then I > agree with you. Even if the generic CTS seems to work more or less as > expected by, e.g., the NIST validation tool, this is unspecified > behavior, and definitely broken in various other places. I was merely suggesting that requests to CTS/XTS shouldn't be split up. Doing it for others would be a serious regression. However, having looked at this it would seem that the effort in marking CTS/XTS is not that different to just adding support to hold the last two blocks of data so that CTS/XTS can support chaining. I'll work on this. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt