-
Notifications
You must be signed in to change notification settings - Fork 179
Fix todo in edwards25519 #592
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
Conversation
|
🔒 Could not start CI tests due to missing safe PR label. Please contact a DEDIS maintainer. |
1 similar comment
|
🔒 Could not start CI tests due to missing safe PR label. Please contact a DEDIS maintainer. |
var_mod.go and const_mod.go now have a NewUint() method to create a mod from a uint64
Accordingly adapt hashToField, expandMessageXDM and expandMessageXOF
6b7afe6 to
01e3fba
Compare
|
I would try to remove the line kyber/.github/workflows/tests.yml Line 7 in 570c22f
|
jbsv
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
fix failing tests on 32B architectures
Problem
i2OSP converts x > 0 to a byte string of the specified length xLen. To obtain the bytes, the int was converted into a
compatible.IntandBytes()was called on it using a temporarycompatiblemod.Mod. The TODO requested to review this modulo used.Indeed, the modulo is a problem: in the case of x = 256 and xLen=2, the program shoud return the byte array [1,0] but panics. This is because the modulo used is 127 and thus
Bytes()panics because the Int (256) is larger than the modulus (127).The first problem is that any value that fits on more than 1 byte passed as input will cause the program to panic, no matter the value of xLen.
The second problem is that in the context of an bad input (i.e. some x that requires more bytes than xLen), the program will panic (for the same reason) instead of returning an error. This is not an acceptable behaviour since depending on the inputs, the program will sometimes panic and sometimes return an error for the same reason. For backward compatibility, the program should never crash if the inputs are bad but return an error instead.
Fix
The modulus is now the largest value representable on xLen bytes. This ensures that as long as the input value x can fit on xLen bytes, the program will never panic.
This does not entirely fix the problem because, in the case of bad inputs (i.e x not representable on xLen) bytes, the modulo created will be too small and
Bytes()will panic. We also need to check ifx > mod. We can do this easily since both are uint64 and it automatically implies that x requires more than xLen (since the modulo created is the largest representable value with xLen bytes)Thus:
(1 << (8 * xLen)) -1compatiblemod.Mod,const_modandvar_modnow implement a methodNewUint()to create a modulus from a uint64