Skip to content
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

Mask most significant bit in from_bytes #1820

Open
0x0ece opened this issue Feb 9, 2024 · 2 comments
Open

Mask most significant bit in from_bytes #1820

0x0ece opened this issue Feb 9, 2024 · 2 comments

Comments

@0x0ece
Copy link

0x0ece commented Feb 9, 2024

The function from_bytes, at least for curve25519, doesn't mask the most significant bit:

x1 = ((uint64_t)(arg1[31]) << 44);

In practice, this function is often used as part of point decompression, where the most significant bit is set to determine the sign of the other coordinate, so it'd be nice to "disregard" the msb.

The fix is straightforward:

x1 = ((uint64_t)(arg1[31] & 0x7F) << 44);
                          ^^^^^^

In addition, right now this limitation forces the caller to either make the input buffer writeable (to zero the bit), or to copy the buffer (example in dalek). Both seem undesirable.

@andres-erbsen
Copy link
Contributor

The proposed change is compatible with the current spec which already assumes truncated input. I don't have a clear intuition about where to apply it though. Do you think the same concept should also be applied to other finite fields, or is this a curve25519 special?

@0x0ece
Copy link
Author

0x0ece commented Feb 9, 2024

To my knowledge that's a typical way to encode points, not just for curve25519, but also for secp, secp256k1, etc. Also, it shouldn't hurt even if one is just using the field.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants