-
Notifications
You must be signed in to change notification settings - Fork 70
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ECDSA SigGen K-409 and K-233 R & S padding? #1037
Comments
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 |
After looking at it a bit more, the order ( |
Hi Chris, thank you again for your feedback. We will take it as this is the correct behavior and move forward. |
@mtdownz we were going to make a correction on our side to not pad the |
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. |
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? |
This change is on demo in release v1.1.0.13. |
@mtdownz will you have a chance to confirm this change on the demo environment? |
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. |
This change is now on prod in release https://github.com/usnistgov/ACVP-Server/releases/tag/v1.1.0.13 |
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!
The text was updated successfully, but these errors were encountered: