From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-11.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 351B7C433E0 for ; Tue, 23 Mar 2021 00:51:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0B53E6199F for ; Tue, 23 Mar 2021 00:51:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231579AbhCWAvV (ORCPT ); Mon, 22 Mar 2021 20:51:21 -0400 Received: from mail.kernel.org ([198.145.29.99]:52238 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231716AbhCWAvI (ORCPT ); Mon, 22 Mar 2021 20:51:08 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 04DC6619A0; Tue, 23 Mar 2021 00:51:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1616460668; bh=0GU+mvpQ6KFpPVwE2ur3Erg8FSP3jRjW/eXtmRXCw7s=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=SRAQIK6VlIa1BVXD5FgNvXzx34HBQ3nVMbX7leQvXvYXSMTtjgk6mWm4fxRtHdXrG Sl+9cOPfdzkSxJI2g2QhbnigL6cSZfMkC0RXNulceHz9OmyPFHKGTbqAKxWTn8/twn EMzv+hHcg9G2Xmp3tGlnPk4bdmyS+lwe3Zw5YlpwukFKZT4m6kIj5geuBLx+pQG1y4 1zJRcn7b5muK8qMSLrlEyTwhClWY39umEzKY43sl4UdqV3ngeHney4bbSaXcYlXV4m SIGJroPcyjPLzcfqW6L4ifaGkbd5OjitKvwFa06caWIHybxlw6K6H+NmicgKjVof6X xrNN0Gkawe9Ig== Date: Mon, 22 Mar 2021 17:51:06 -0700 From: Eric Biggers To: Ard Biesheuvel Cc: Arnd Bergmann , Herbert Xu , "David S. Miller" , "Jason A. Donenfeld" , Arnd Bergmann , Russell King , Catalin Marinas , Will Deacon , Thomas Bogendoerfer , Thomas Gleixner , Ingo Molnar , Borislav Petkov , X86 ML , "H. Peter Anvin" , Arvind Sankar , Masahiro Yamada , Linux Crypto Mailing List , Linux ARM , Linux Kernel Mailing List , "open list:MIPS" Subject: Re: [PATCH] crypto: poly1305: fix poly1305_core_setkey() declaration Message-ID: References: <20210322170542.1791154-1-arnd@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-mips@vger.kernel.org On Mon, Mar 22, 2021 at 07:51:47PM +0100, Ard Biesheuvel wrote: > On Mon, 22 Mar 2021 at 18:05, Arnd Bergmann wrote: > > > > From: Arnd Bergmann > > > > gcc-11 points out a mismatch between the declaration and the definition > > of poly1305_core_setkey(): > > > > lib/crypto/poly1305-donna32.c:13:67: error: argument 2 of type ‘const u8[16]’ {aka ‘const unsigned char[16]’} with mismatched bound [-Werror=array-parameter=] > > 13 | void poly1305_core_setkey(struct poly1305_core_key *key, const u8 raw_key[16]) > > | ~~~~~~~~~^~~~~~~~~~~ > > In file included from lib/crypto/poly1305-donna32.c:11: > > include/crypto/internal/poly1305.h:21:68: note: previously declared as ‘const u8 *’ {aka ‘const unsigned char *’} > > 21 | void poly1305_core_setkey(struct poly1305_core_key *key, const u8 *raw_key); > > > > This is harmless in principle, as the calling conventions are the same, > > but the more specific prototype allows better type checking in the > > caller. > > > > Change the declaration to match the actual function definition. > > The poly1305_simd_init() is a bit suspicious here, as it previously > > had a 32-byte argument type, but looks like it needs to take the > > 16-byte POLY1305_BLOCK_SIZE array instead. > > > > This looks ok to me. For historical reasons, the Poly1305 integration > is based on an unkeyed shash, and both the Poly1305 key and nonce are > passed as ordinary input, prepended to the actual data. > poly1305_simd_init() takes only the key but not the nonce, so it > should only be passed 16 bytes. Well to be more precise, there are two conventions for using Poly1305. One where it is invoked many times with the same 16-byte key and different 16-byte nonces. And one where every invocation uses a unique key *and* nonce, interpreted as a 32-byte "one-time key". So that's why there's a mix of 16 and 32 byte "keys". The naming "POLY1305_KEY_SIZE" assumes the second convention, which is a bit confusing; it really should be called something like POLY1305_ONETIME_KEY_SIZE. I guess the idea was that the one-time key convention is the more common one. Anyway, the patch seems to be fine, as it uses the correct length in each location. You can add: Reviewed-by: Eric Biggers - Eric