Justus Winter writes:
> What happens if that restriction is violated? As the function cannot
> signal an error, does it lead to silent corruption of the data stream?
> Or does it assert that restriction?
It triggers an assert. Likewise, if you call gcm_update after
gcm_encrypt that also
Hi Niels :)
Niels Möller writes:
> While looking at extended tests of the aead update function (for the
> associated data), I stumbled on a restriction of gcm_update that is
> different from most (all?) other update functions in Nettle. According
> to the docs,
>
> -- Function: void gcm_update
While looking at extended tests of the aead update function (for the
associated data), I stumbled on a restriction of gcm_update that is
different from most (all?) other update functions in Nettle. According
to the docs,
-- Function: void gcm_update (struct gcm_ctx *CTX, const struct gcm_key
Hello Niels,
Niels Möller writes:
> Daiki Ueno writes:
>
>> When I'm trying to implement ML-KEM (Kyber), I realized that the current
>> API for SHAKE (sha3_256_shake) is a bit too limited: while ML-KEM uses
>> SHAKE128 as a source of pseudorandom samples[1], the the current API
>> requires the
Niels Möller writes:
> Below patch seems to fix this issue, but not entirely sure that's the
> way I want to do it.
I've pushed a fix, along the same lines, see
https://git.lysator.liu.se/nettle/nettle/-/commit/99e62003c3916fdef04a2d3327281f8f498b609e
I believe that should fix all hash update
