On Sun, Sep 6, 2026 at 12:10 PM Niels Möller nisse@lysator.liu.se wrote:
Maamoun TK maamoun.tk@googlemail.com writes:
I'm debugging the issue using gdb. Apparently, ecc->q.bit_size takes 2 values (256 and 512),
That is as expected. I think it makes sense to use gostdsa is only with one of the gost curves, gc256b (both p and q 256 bits) and gc512a (both p and q 512 bits).
the error occurs when bit_size is 512 and eventually it produces a bad_alloc in TLS when one goes further through the calling chain. Let me know if the issue needs further debugging.
Can you give a bit more context of what case you are debugging? For gostdsa proper, the intention of changes on the fix-gostdsa-zero branch is that it should
fix the bug with how an input digest that equals q is handled.
hit an assertion failure for obscure cases (q->bit_size not a multiple of 8, and an input digest size that is larger. E.g., if one attempts to use gostdsa with the secp521 curve, and and a digest size of 66 octets or larger, e.g., based on shake).
Any other changes in behavior are unintentional and likely bugs...
For gostdsa_vko, I haven't yet made any changes. If you're debugging use of gostdsa_vko in gnutls, I'm interested to know which values of ukm_length can occur when it calls nettle's gostdsa_vko function.
For a 256-bit q, a ukm_length up to 34 sustains a valid path, beyond which unstable TLS behavior occurs. At some point, we need to verify these procedures with pre/post-conditions and lemmas to ensure the math behind is identical to the specification.
Regards, /Niels
-- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance.