Received: by 2002:ac0:8c9a:0:0:0:0:0 with SMTP id r26csp492316ima; Thu, 31 Jan 2019 21:29:34 -0800 (PST) X-Google-Smtp-Source: ALg8bN6pIX7ctTAKBbvdMLsyG97wih+wPJzEI0X5GjkQdst3JIJAaMJXm57Fg58IPW5cvZHJsQzB X-Received: by 2002:a62:546:: with SMTP id 67mr37082958pff.99.1548998974422; Thu, 31 Jan 2019 21:29:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548998974; cv=none; d=google.com; s=arc-20160816; b=jdxNlGBj9C9d5Uj1eomwibN1Ioa41P+BSqXDH3xoxtvWmAbXmKegqnCvVzc8WMBEZc Mf1/zKsAKvoNI7hNP91wfVdHhWqrSxDdvvOLyNC+j2ObDkBdczUe1RUUgJzgftQ9VgVi nO5nkOSPsPcXT9OGXkyNEFIoQMufIvE4B/t/kotOProR+1Jof8cnDd58YXzcfcGEgL2j VmLsmMnb7QctGGChI695X+zAxjx/g68kgyty+R1uBiruRbGy+Z6Ul04QBLPYOMIZigEJ efgPCSKj29jC/HprgVbI8FHd0226M5O2FhVtuFWKBYEors+8qst20DW5tJl8K9CVATt1 itdA== 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:dkim-signature; bh=6ddjyo+f0jor+1esfwNmBOpBNjKaS5qE5CBKoENI1Yw=; b=Tr/qG7hyyTgNMXzV6oppUv5cy2aJvguDrpkRj7jA5ppp5LGEigP3EbZo/8WdpzxbAP 6IMDjxmLxeooYFVv/wW0zrmmIcxgNDCL+CTxD2ZCyQLt47fXw4TKYPPOxS5HzaikyFY0 zwRpURP2w4HVUy16BbzMxK2RNEE4CwIIqSI+eRqjyQioxoGuirSrjTjvpkACveQ4mxOL k7iLZkyoPKOQ9iXR5CJNFNz96uo9z3zo8Q+9dsxkcRJ6yzFS57/q80fQMq6K6fougLA2 riR/JofHIcn6/3EMd79lejvvDifx5Pf6qguBXNUAr1qUE2Oxrm15wFFBZG+P/hlCvo07 6yXw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="GsRP/ACn"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 92si6785551pld.84.2019.01.31.21.29.19; Thu, 31 Jan 2019 21:29:34 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="GsRP/ACn"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726655AbfBAFZS (ORCPT + 99 others); Fri, 1 Feb 2019 00:25:18 -0500 Received: from mail.kernel.org ([198.145.29.99]:48552 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725963AbfBAFZS (ORCPT ); Fri, 1 Feb 2019 00:25:18 -0500 Received: from sol.localdomain (c-107-3-167-184.hsd1.ca.comcast.net [107.3.167.184]) (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 266A82084A; Fri, 1 Feb 2019 05:25:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1548998717; bh=HWgZm++3GNATO7e8ZSZpoIEFfmURVVW3OSVLvfQptX8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=GsRP/ACnduBE4mZjSpkh6KvFzS/cPe7TlWBg0qPfCrNshPxBCl8i0aWgHYm/zvChj Us+iWSjmeuVUPK9C1Gr5aC5mTPpGOBISe915aQb3jp6YCmTVVxKlCZ1eAbRIJNP8sq qsxUZ/PA2tvsGEFVVfPlbY7UvR/6c7VxxOPBPS/Q= Date: Thu, 31 Jan 2019 21:25:07 -0800 From: Eric Biggers To: Ondrej Mosnacek Cc: linux-crypto@vger.kernel.org, Herbert Xu , Linux kernel mailing list , "Jason A . Donenfeld" , stable@vger.kernel.org Subject: Re: [RFC/RFT PATCH 02/15] crypto: morus - fix handling chunked inputs Message-ID: <20190201052506.GA765@sol.localdomain> References: <20190123224926.250525-1-ebiggers@kernel.org> <20190123224926.250525-3-ebiggers@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.2 (2019-01-07) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 31, 2019 at 10:05:17AM +0100, Ondrej Mosnacek wrote: > Hi Eric, > > On Wed, Jan 23, 2019 at 11:52 PM Eric Biggers wrote: > > From: Eric Biggers > > > > The generic MORUS implementations all fail the improved AEAD tests > > because they produce the wrong result with some data layouts. Fix them. > > > > Fixes: 396be41f16fd ("crypto: morus - Add generic MORUS AEAD implementations") > > Cc: # v4.18+ > > Cc: Ondrej Mosnacek > > Signed-off-by: Eric Biggers > > --- > > crypto/morus1280.c | 13 +++++++------ > > crypto/morus640.c | 13 +++++++------ > > 2 files changed, 14 insertions(+), 12 deletions(-) > > > > diff --git a/crypto/morus1280.c b/crypto/morus1280.c > > index 3889c188f266..b83576b4eb55 100644 > > --- a/crypto/morus1280.c > > +++ b/crypto/morus1280.c > > @@ -366,18 +366,19 @@ static void crypto_morus1280_process_crypt(struct morus1280_state *state, > > const struct morus1280_ops *ops) > > { > > struct skcipher_walk walk; > > - u8 *dst; > > - const u8 *src; > > > > ops->skcipher_walk_init(&walk, req, false); > > > > while (walk.nbytes) { > > - src = walk.src.virt.addr; > > - dst = walk.dst.virt.addr; > > + unsigned int nbytes = walk.nbytes; > > > > - ops->crypt_chunk(state, dst, src, walk.nbytes); > > + if (nbytes < walk.total) > > + nbytes = round_down(nbytes, walk.stride); > > > > - skcipher_walk_done(&walk, 0); > > + ops->crypt_chunk(state, walk.dst.virt.addr, walk.src.virt.addr, > > + nbytes); > > + > > + skcipher_walk_done(&walk, walk.nbytes - nbytes); > > } > > Hm... I assume the problem was that skcipher_walk may give you nbytes > that is not rounded to the algorithm's walksize (aka walk.stride) even > in the middle of the stream, right? I must have misread the code in > skcipher.c and assumed that it automatically makes every step of a > round size, with the exception of the very last one, which may include > a final partial block. Thinking about it now it makes sense to me that > this isn't the case, since for stream ciphers it would mean some > unnecessary memcpy'ing in the skcipher_walk code... > > Maybe you could explain the problem in one or two sentences in the > commit message(s), since the contract of skcipher_walk doesn't seem to > be documented anywhere and so it is not obvious why the change is > necessary. > > Thank you for all your work on this - the improved testmgr tests were > long needed! > Yes, that's correct. I'll add an explanation to the commit messages. I'm actually not convinced that this behavior should be the default (vs. allowing the caller to opt-in to it if needed), but this is how it works now... A while back I also started work on a documentation patch for the skcipher_walk functions, but it's still pretty incomplete. I'll see if I can get it in a state to send out. - Eric