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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 61822C433EF for ; Wed, 16 Feb 2022 23:17:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=0Yb4KfchbZa60MkfEQTOX3lnjqz82jiR33dnjgcdoCM=; b=lW+qkYm4OmcM1D iYn1tzk9ARv//5urGCyx6DJ09oC1VxxQOV0jr4NX+XfpG+JWMa8INXuTpoBfN4u0jm8YR7Zo/kxxJ SMY1XJyfXYZC4O+DR3PfC6KFOU2+Ol7DMUuQz7KN4z3tpAR7fnpVn1YuM6X5KvIeSiiW9g7ILNolh FTAjSjF17jjT5EAcXvHtZbzociKSvvyFD582LgpT5us/VSxHQjme55PmHXqJM3Fjo0GEBZyAw9FsN iP+UK47F4jJCo47mxPLj6DV0HZJz4O68blP1Dg2oKyMquaG2/if699k5vi806X3UnjDT/CuH0+mAs o8CJwlP8vXrwURlsBYyw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nKTX0-008W2S-TF; Wed, 16 Feb 2022 23:16:19 +0000 Received: from ams.source.kernel.org ([145.40.68.75]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nKTWw-008W1q-RW for linux-arm-kernel@lists.infradead.org; Wed, 16 Feb 2022 23:16:16 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 5C9E9B820C2; Wed, 16 Feb 2022 23:16:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EA33EC004E1; Wed, 16 Feb 2022 23:16:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1645053372; bh=aXuxrBm/LtfHFLRXKof35rtSKzLSnLYy94QzKTOQMGU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=HLJTVhbXW2PGub1rks7Gy+ddyPGjF2tVwT0900QQ1y2spLoulfHw0uMmXAIddlkRI P+1m9sAoIrzIyNEk9cOyCWHb1xKNcX3A4m9AY9ifEbnK1iZhP0bEjioUfzhH2sawwB PXG5BWLJWViIFygpn+HxuwlNGqOa3Qg07A5e1WRbHbc04GC9Nb2pgiLotK7VMrsQlQ NTr4Sk4OATjdGHTQh5HnTkSyo3y1sloqemsE2q52T2Q48BLnPp2kC38ZgeoffqXOBx AmnuST//hRdg+FjtEebYxIjnNjx8cimDGpx3LGB3VQXI5HOpJWMFQAJknJn51qxd5l 2gGD1h/gjmMNA== Date: Wed, 16 Feb 2022 15:16:10 -0800 From: Eric Biggers To: Nathan Huckleberry Cc: linux-crypto@vger.kernel.org, Herbert Xu , "David S. Miller" , linux-arm-kernel@lists.infradead.org, Paul Crowley , Sami Tolvanen , Ard Biesheuvel Subject: Re: [RFC PATCH v2 2/7] crypto: polyval - Add POLYVAL support Message-ID: References: <20220210232812.798387-1-nhuck@google.com> <20220210232812.798387-3-nhuck@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220210232812.798387-3-nhuck@google.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220216_151615_233413_C8FC8BCF X-CRM114-Status: GOOD ( 26.14 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Feb 10, 2022 at 11:28:07PM +0000, Nathan Huckleberry wrote: > +config CRYPTO_POLYVAL > + tristate > + select CRYPTO_GF128MUL > + select CRYPTO_HASH > + help > + POLYVAL is the hash function used in HCTR2. It is not a general-purpose > + cryptographic hash function. As with XCTR: as this option is no longer user-selectable, no one will see this help text. I think it should just be removed. > +static int polyval_update(struct shash_desc *desc, > + const u8 *src, unsigned int srclen) > +{ > + struct polyval_desc_ctx *dctx = shash_desc_ctx(desc); > + const struct polyval_tfm_ctx *ctx = crypto_shash_ctx(desc->tfm); > + u8 *dst = dctx->buffer; The dst variable doesn't seem to serve a purpose. It would be clearer to just write dctx->buffer directly (or &dctx->buffer[...], etc). > + u8 *pos; > + u8 tmp[POLYVAL_BLOCK_SIZE]; > + int n; > + > + if (dctx->bytes) { > + n = min(srclen, dctx->bytes); > + pos = dst + dctx->bytes - 1; > + > + dctx->bytes -= n; > + srclen -= n; > + > + while (n--) > + *pos-- ^= *src++; > + > + if (!dctx->bytes) > + gf128mul_4k_lle((be128 *)dst, ctx->gf128); I thought I mentioned this on v1, but the cast to be128 is violating alignment rules. If the alignment to be128 is needed then a union should be used, e.g.: struct polyval_desc_ctx { union { u8 buffer[POLYVAL_BLOCK_SIZE]; be128 buffer128; }; u32 bytes; }; > +static int polyval_final(struct shash_desc *desc, u8 *dst) > +{ > + struct polyval_desc_ctx *dctx = shash_desc_ctx(desc); > + const struct polyval_tfm_ctx *ctx = crypto_shash_ctx(desc->tfm); > + u8 *buf = dctx->buffer; > + > + if (dctx->bytes) > + gf128mul_4k_lle((be128 *)buf, ctx->gf128); > + dctx->bytes = 0; > + > + reverse_block(buf); > + memcpy(dst, buf, POLYVAL_BLOCK_SIZE); > + > + return 0; > +} Same issues as polyval_update(). > + > diff --git a/include/crypto/polyval.h b/include/crypto/polyval.h > new file mode 100644 > index 000000000000..fd0c6e124b65 > --- /dev/null > +++ b/include/crypto/polyval.h > @@ -0,0 +1,22 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +/* > + * Common values for the Polyval hash algorithm > + * > + * Copyright 2021 Google LLC > + */ > + > +#ifndef _CRYPTO_POLYVAL_H > +#define _CRYPTO_POLYVAL_H > + > +#include > +#include > + > +#define POLYVAL_BLOCK_SIZE 16 > +#define POLYVAL_DIGEST_SIZE 16 > + > +struct polyval_desc_ctx { > + u8 buffer[POLYVAL_BLOCK_SIZE]; > + u32 bytes; > +}; > + > +#endif As-is, polyval_desc_ctx is only used by crypto/polyval-generic.c, so it shouldn't be in this header. Either it should be moved to polyval-generic.c, or all implementations should be made to use the same struct. - Eric _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel