NIST P256 Point Encode/Decode about kyber

[bford]

Uh oh! Not good, thanks for finding; obviously that's another test we should have had in test.testGroup() - can you add one, verify that the problem only crops up with the NIST suite, and (obviously) verify whether it's Go's fault or ours? (My quick look at the code seems to confirm what you're seeing; I don't see how that would be happening in our code.)

[jackowitz]

I only found it after adding test cases to test.testGroup. NIST is the only suite that has failed. Can confirm that it's in Go - elliptic.Marshall uses big.Int.SetBytes which interprets the slice as an unsigned value (see https://golang.org/pkg/math/big/#Int.SetBytes). Whether that's the proper behavior or a bug in Go...

[bford]

Ah, wait - I'm guessing it's probably our (my) fault. Go's elliptic routines probably assume that coordinates are never "negative" at least as seen by the big.Int package, and that's probably a reasonable assumption given that the arithmetic is all supposed to be modulo a big prime. What might be going on is that we're mistakenly causing a y-coordinate to be "negative" as a big.Int for some reason. I don't offhand see what would do that, as for example the Neg() function uses a pretty brain-damaged method of getting the inverse of a point but even that brain-damaged method shouldn't produce a literally negative big.Int y-coordinate as far as I can see.

[bford]

Aha - oops, looks like genPoint might. Does the y.Neg(y) need to be changed to y.Neg(y).Mod(y, p.c.p.P)?

B

[bford]

Or more efficiently, perhaps y.Sub(p.c.p.P, y)?