Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp58419imu; Thu, 15 Nov 2018 22:03:43 -0800 (PST) X-Google-Smtp-Source: AJdET5cvv3CEwht9ZWbgq7G9cQTxK6Z8JUoNWrnaTR0kvTLYt/3MxKK8vDgHhXUToHoRyCtMDnq1 X-Received: by 2002:a17:902:744a:: with SMTP id e10mr7755292plt.304.1542348223235; Thu, 15 Nov 2018 22:03:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542348223; cv=none; d=google.com; s=arc-20160816; b=i3ENO5/D5W2/WCKG+79Y60v1XorvmERVchmWww4vp10F7nqD0EVhz/g7Sc2LHpZNDR u/v8A8pM3GS8KlKQ9eg+f/nwT9wpeQprj7nJlSp2LCCfRyf5IyKPZ7kaUpMkZnJ47N/V IKaO1d3AH8poyJVaY5NQfGy7ZGJ0XHqVrmr2/RPeEL3iDWIdJGsa5qnDbmRxXhpzdrYz 6RMnJyJycfIvj7LBjye33uSBB50Dfn79YGmwD8amFAu9va/fkVIwXEteQsvPRegRSRft 4NyoAhXoc/TwQwuyNI5XvBnwHR656TbaxNnE23toCNk8TxLL0t6gwAqbWrvOpAdmGVJE kbkg== 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=8BC3P/mrNP7TAJJwRKq0ZcHs4QOZcCuxbECyPvDxuPA=; b=Fb1+zhXPu+eOYkXDnRzY//OSRJUHkk/V0WXLeeyMhqiZysQCrP0sskbMaEWBB7Ju+N LJyDFRQ4s9y2WsB0fIcjdP2L+s+dDm16gPD4oyZM6uGwK78VTynkSw0fy99pFH7Y7LiN K4VpQEva2Xg1kI5SR9EDACNhVCxMxiFeyr4pTwzx4PDNL5CWMyZaDrEyHytd01Weivze OVpiwY8mlyFgcD7LBQcJ428TXE4xVOClUMCp6iVPfDqFLssrqfSq11D/ck+19lGLljPS PsU3ZTnbDDNeG/TfHcLI+D/YP484q3XqO8Ea7CkvNEauRWbdnW8iYYmDnEOrWer3mUUh OvGA== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b8-v6si12061958plx.76.2018.11.15.22.03.27; Thu, 15 Nov 2018 22:03:43 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727451AbeKPQNj (ORCPT + 99 others); Fri, 16 Nov 2018 11:13:39 -0500 Received: from orcrist.hmeau.com ([104.223.48.154]:37548 "EHLO deadmen.hmeau.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727353AbeKPQNj (ORCPT ); Fri, 16 Nov 2018 11:13:39 -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 1gNXDA-0004on-2K; Fri, 16 Nov 2018 14:02:36 +0800 Received: from herbert by gondobar with local (Exim 4.89) (envelope-from ) id 1gNXD1-0007Gm-Lc; Fri, 16 Nov 2018 14:02:27 +0800 Date: Fri, 16 Nov 2018 14:02:27 +0800 From: Herbert Xu To: Eric Biggers Cc: Ard Biesheuvel , "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" , linux-fscrypt@vger.kernel.org, linux-arm-kernel , Linux Kernel Mailing List , Paul Crowley , Greg Kaiser , "Jason A . Donenfeld" , Samuel Neves , Tomer Ashur Subject: Re: [RFC PATCH v3 10/15] crypto: poly1305 - use structures for key and accumulator Message-ID: <20181116060227.hwu4igi6bp26ddpi@gondor.apana.org.au> References: <20181105232526.173947-1-ebiggers@kernel.org> <20181105232526.173947-11-ebiggers@kernel.org> <20181112185816.GA8663@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181112185816.GA8663@gmail.com> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Eric: On Mon, Nov 12, 2018 at 10:58:17AM -0800, Eric Biggers wrote: > > I prefer separate types so that the type system enforces that a key is never > accidentally used as an accumulator, and vice versa. Then the poly1305_core_* > functions will be harder to misuse, and the Poly1305 MAC implementations harder > to get wrong. > > The key also has certain bits clear whereas the accumulator does not. In the > future, the Poly1305 C implementation might use base 2^32 and take advantage of > this. In that case, the two inputs to each multiplication won't be > interchangeable, so using the same type for both would be extra confusing. > > Having a poly1305_val nested inside poly1305_key and poly1305_state would work, > but seemed excessive. So it looks like there are no more unresolved issues with this patch series. Please let me know when you want it to go in. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt