ECDSA SigGen K-409 and K-233 R & S padding?

[mtdownz]

Continuing this thread that was Closed:

#1034

In looking at this further we don't think what you are describing is occurring? The R & S components of an ECDSA signature are not field elements: They are reduced modulo the order of the curve, and the order of K-233 is encoded in 29 bytes rather than 30 bytes (which would be needed to encode a field element):
n = 0x80 00000000 00000000 00000000 00069d5b b915bcd4 6efb1ad5 f173abdf

Any feedback on this would be helpful?

Thanks!

[celic]

The order is 29 bytes. It is difficult to detect the padding is "extra" when it is very unlikely to have a value starting with 0x80. Even though 29 bytes is 232 bits, the name of the curve is a tad misleading (or derived from something else). Using a 233-bit order, the padding would bring it up to 240-bits or 30 bytes. This is what the server is doing behind the scenes... using the 233 value to pad up to the next byte boundary. This is unnecessary in this case and likely for K-409 due to the orders being one bit below the name would suggest.

[celic]

After looking at it a bit more, the order (n) for the curve is 232 bits, which is used as a modulo for the signature (r, s). The issue is that we pad to the next complete byte on 233-bits which is as large as the coordinates of a point on the curve may be. Normally the padding matches up between the curves, but these curves are special cases where a point on the curve may need more bits to be represented than the values within the signature.

[mtdownz]

Hi Chris, thank you again for your feedback. We will take it as this is the correct behavior and move forward.

[Kritner]

@mtdownz we were going to make a correction on our side to not pad the r and s values as we were, they'll just be padded to the next byte of the bitlength of the orderN - so 232 and 408 bits would be the maximum length of either value.

[mtdownz]

Very good. Please let me know when you anticipate this to be corrected and I will inform our vendor so they can make the adjustment? They are looking to validate ECDSA with these curves early November. Thank you.

[Kritner]

We should be able to get a prod release with the fix out prior to then. We'll first be making the change to our demo environment, which should be in the next few days.

Will this be something you'll be able to confirm the fix for on demo?

[Kritner]

This change is on demo in release v1.1.0.13.

[Kritner]

@mtdownz will you have a chance to confirm this change on the demo environment?

[mtdownz]

Hi Russ, I did indeed confirm that the changes were in place. Thank you for making the update. I have handed off the demo vectors to one of our vendors and if there appears to be any further issues I will let you know.

[Kritner]

This change is now on prod in release https://github.com/usnistgov/ACVP-Server/releases/tag/v1.1.0.13