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:
/* There are two key halves r and s */ #define POLY1305_HALFKEY_SIZE 16
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);
If we promote [...] _nettle_poly1305_update, and _nettle_poly1305_digest, then what's missing is a utility for the digest-time padding of a partial block.
I would not promote the current functions. The caller shouldn't have to worry about handling partials blocks and the correct padding of the last block, the update/digest function itself should take care of it, just like with other mac types in Nettle.
Another option is to add an implementation of the specific openssh construction, if we don't foresee any need for additional variants building on the poly1305 primitive.
I think the API requirements for the SSH-specific construction are a bit more complex. In any case I would want to use wrappers around _nettle_poly1305_update and _nettle_poly1305_digest to make the code easier to understand.
Regards, Tim