zeekayandHanzo Dev e204581312 The deterministic signer takes its arguments in its siblings' order ...

mldsa65_sign_ctx_det took the context before the message; mldsa65_sign_ctx and
mldsa65_verify_ctx take the message before the context. It arrived that way in
v1.20.10, ported from a local snapshot of this library whose whole _ctx pair is
in the other order, and its own comment claimed it matched.

Nothing catches this. The four parameters are (char*, int) pairs, so every
permutation compiles, links, and runs; the wrong one just hands a transcript to
the library as a FIPS 204 context. A context over 255 bytes is illegal, so the
symptom is that signing succeeds for messages up to 255 bytes and returns -2
for everything longer -- which reads like a message-size limit and is nothing
of the kind. Measured against this build:

  message length     1  100  254  255  256  512  3199  6512  9615  16384
  correct order      0    0    0    0    0    0     0     0     0      0
  swapped            0    0    0    0   -2   -2    -2    -2    -2     -2

with the same numbers for verification, which is how a post-quantum handshake
of about 6.5 KB fails at every length while every known-answer test around it
passes.

Nothing in Go can guard the order; only a C caller can. The consumer that found
this now round-trips sign and verify through the ABI with a 6512-byte message,
and asserts that a 255-byte one proves nothing -- 255 is the longest input the
two orders agree on.

Co-authored-by: Hanzo Dev <[email protected]>

2026-09-08 01:55:53 -07:00

..

main.go

The deterministic signer takes its arguments in its siblings' order

2026-09-08 01:55:53 -07:00