Re: [PATCH v3] crypto: riscv/poly1305 - import OpenSSL/CRYPTOGAMS implementation

From: Eric Biggers <ebiggers@kernel.org>
To: Zhihang Shao <zhihang.shao.iscas@gmail.com>
Cc: linux-crypto@vger.kernel.org, linux-riscv@lists.infradead.org,
	herbert@gondor.apana.org.au, paul.walmsley@sifive.com,
	alex@ghiti.fr, appro@cryptogams.org, zhang.lyra@gmail.com
Subject: Re: [PATCH v3] crypto: riscv/poly1305 - import OpenSSL/CRYPTOGAMS implementation
Date: Tue, 10 Jun 2025 12:21:32 -0700	[thread overview]
Message-ID: <20250610192132.GE1649@sol> (raw)
In-Reply-To: <EC8AB5A0-D5C9-4D18-A986-DE66BE46E09A@gmail.com>

On Tue, Jun 10, 2025 at 02:57:29PM +0800, Zhihang Shao wrote:
> 
> >> +void poly1305_blocks_arch(struct poly1305_block_state *state, const u8 *src,
> >> +  unsigned int len, u32 padbit)
> >> +{
> >> + len = round_down(len, POLY1305_BLOCK_SIZE);
> >> + poly1305_blocks(state, src, len, 1);
> >> +}
> >> +EXPORT_SYMBOL_GPL(poly1305_blocks_arch);
> > 
> > This is ignoring the padbit and forcing it to 1, so this will compute the wrong
> > Poly1305 value for messages with length not a multiple of 16 bytes.
> 
> So Does this mean here the argument of poly1305_blocks should be fixed as poly1305_blocks(state, src, len, padbit)?
> But since the padbit is set to 1 in poly1305_blocks_arch according to the implementation in lib/crypto/poly1305.c, 
> it seems to be no difference here.
> 
> Looking forward to your reply.

While the common case is padbit=1, poly1305_final() passes padbit=0 in the case
where the message ends with a partial block.  So both values have to be
supported.

- Eric

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv