Hi,
I'm trying to implement chacha20-poly1305 as used by SSH
(https://datatracker.ietf.org/doc/html/draft-ietf-sshm-chacha20-poly1305-04),
which differs from RFC 8439's ChaCha-Poly1035 as implemented by Nettle.
While Nettle internally has the necessary building blocks, it lacks a
public API to directly use poly1305. I think this is fairly
straightforward to add one though. Please see below for my initial
attempt. If you think this is the right approach, I'd be happy to work
on a proper patch including tests and documentation.
#define POLY1305_KEY_SIZE 32
#define POLY1305_DIGEST_SIZE 16
struct poly1305_mac_ctx {
struct poly1305_ctx pctx;
union nettle_block16 s;
uint8_t block[POLY1305_BLOCK_SIZE];
unsigned index;
};
void
poly1305_set_key(struct poly1305_mac_ctx* ctx, const uint8_t *key)
{
_nettle_poly1305_set_key(&ctx->pctx, key);
memcpy(ctx->s.b, key + 16, 16);
ctx->index = 0;
}
void
poly1305_update(struct poly1305_mac_ctx* ctx, size_t length, const
uint8_t *data)
{
ctx->index = _nettle_poly1305_update(&ctx->pctx, ctx->block,
ctx->index, length, data);
}
/* After calling this function, context must be re-keyed before
calling poly1305_update/poly1305_digest again. */
void
poly1305_digest(struct poly1305_mac_ctx* ctx, uint8_t* digest)
{
if (ctx->index > 0)
{
ctx->block[ctx->index] = 1;
memset (ctx->block + ctx->index + 1,
0, POLY1305_BLOCK_SIZE - 1 - ctx->index);
_nettle_poly1305_block (&ctx->pctx, ctx->block, 0);
}
_nettle_poly1305_digest(&ctx->pctx, &ctx->s);
memcpy(digest, ctx->s.b, POLY1305_DIGEST_SIZE);
}
Regards,
Tim
Hi,
I've received a bug report on gostdsa. When the digest is converted to
an integer mod q, the spec says that if that happens to become 0, it
should be replaced by 1 (and using 0 results in private key leakage).
The current code checks for 0 without first reducing mod q, which is
bad. I have a tentative fix on branch
https://git.lysator.liu.se/nettle/nettle/-/tree/fix-gostdsa-zero.
Then there's a related problem in handling of the "UKM" input for
gostdsa_vko, if that happens to equal q or a multiple thereof. I suspect
the UKM is usually rather small, which would help. E.g., if I could do
something like
ukm_max_length = (ecc->q.bit_size - 1) / 8;
assert (ukm_length <= ukm_max_length);
the number would surely be less than q, and current plain check for 0
would be fine.
Is there a specified maximum size? I've looked at
* RFC 4357, which seems to say the UKM is 64 bits
* RFC 9189, which seems to say that the UKM is 128 bits (16 bytes).
* GnuTLS (only user of this function I'm aware of). It's unobvious
to me what size of the nonce/ukm is actually passed down to nettle,
but at least I've found a
#define VKO_GOST_UKM_LEN 8
which seems to indicate 64 bits.
Anyone who's more familiar with how this is used in TLS or elsewhere?
Regards,
/Niels
--
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
Hi,
I've now merge Daiki's ML-KEM implementation, see
https://git.lysator.liu.se/nettle/nettle/-/merge_requests/67.
I think there's some further changes I think I'd like to do before
release:
1. Add more randomized tests, and add assert_maybe for some of the
invariants, in particular for arithmetics.
2. Probably remove the ml_kem_params from the api, and instead use
separate functions for ML-KEM 768 and ML-KEM 1024.
3. Add functions exposing structs for expanded keys. To avoid having to
expand them over and over again if using the same key repeatedly. And
for all-in-one functions, these structs could also be used as the
types for needed scratch space, to make things a bit more
type/alignment safe, and have a natural way to allocate needed
storage without the _itch functions.
Should then be done in a consistent way also for sntrup. (The reason
sntrup api doesn't have any itch function is that its expanded keys
are smaller, and it's more reasonable to just allocate them on the
stack).
4. Micro optimize various internals.
Regards,
/Niels
--
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
I'll be traveling to Montréal over coming weekend and next week.
Tuesday-Thursday I'll attend https://transparency.dev/summit2026/.
I'll be offline much of the time, but if anyone is in the area and want
to meet up, let me know.
Regards,
/Niels
--
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.