Tim Kosse tim.kosse@filezilla-project.org writes:
On 2026-08-13 Thu 10:05 AM, Niels Möller wrote:
I think it's desirable that the new poly1305 functions are defined in such a way that current poly1305_aes and chacha_poly1305 api:s could build on top of it
struct poly1305_mac_ctx { struct poly1305_ctx pctx; union nettle_block16 s; uint8_t block[POLY1305_BLOCK_SIZE]; unsigned index; };
Having s in this struct implies some impedance mismatch if we try to use it in the implementation of poly1305_aes (there, s is aes_k(nonce), and the nonce is kept in the context struct to support autoincrement). I think I'd prefer passing s as an argument at digest time.
That makes sense, that way the caller can change s for each invocation.
I'd also change poly1306_set_key in that case though to only accept the first half of the key and change the define:
Do you plan to make an updated patch? In addition to the code, also needs tests and docs. I'm starting to think about a 4.1 release, and if any more features should get in.
/* There are two key halves r and s */ #define POLY1305_HALFKEY_SIZE 16
I wonder if we can come up with a better name. I think it may help with some names for the two parts, first half is the point where the polynomial is evaluated, and the second part is a kind of blinding.
void poly1305_set_key(struct poly1305_mac_ctx* ctx, const uint8_t *r);
void poly1305_digest(struct poly1305_mac_ctx* ctx, uint8_t* digest, const uint8_t *s);
I think I'd order the arguments with s (part of the key) before the output digest argument.
Regards, /Niels