armfazh / rfc7748_precomputed Goto Github PK

I'd like to use this in WireGuard, and by extension, in the Linux kernel. I've already imported it and gotten it ready for the kernel's environment, as well as reducing input points mod 2^255-19 and accounting for the various different CPU flags at runtime. However, right now it lives in this unhappy branch, which I can't yet merge to master, because this project appears to be LGPLv3+, whereas the kernel requires GPLv2.

Would you consider re-licensing this project to something compatible with GPLv2? This would include things like:

• GPLv2 itself.
• GPLv2+
• LGPLv2+
• GPLv2 and GPLv3
• LGPLv2 and LGPLv3
• BSD
• MIT
• Public domain
• Many other good candidates

Doing so will get this code some real world usage and deployment.

I reviewed the field implementation in fp25519_x64 and either I'm missing something or both the add_EltFp25519_1w_x64 and sub_EltFp25519_1w_x64 have incomplete carry handling.

e.g. I can't see why this line would never carry, since RAX could hold any value, and this line is (possibly) adding 38 to it:

I think a similar logic also applies for:

I don't see any tests specifically for add_/sub_. They are covered e.g. by the "mul/sqr" test, but random inputs with 64-bit limbs are very unlikely to catch carry handling errors, especially since random_EltFp25519_1w_x64 is only generating 255-bit values, while add_/sub_ apparently support 256-bit values (?).

I only briefly checked fp448_x64 for comparison, but I believe add_EltFp448_1w_x64 and sub_EltFp448_1w_x64 also have similar errors, probably even less likely to be detected by random inputs.

Brief: It is possible that carry propagation is not performed properly in addition/suibtraction/reduction.
This issue was previously observed in #5 for GF(2^255 -19).

Help wanted:

• Include more tests for arithmetic operations.
• Proper carry handling for the worst case, i.e. numbers of 2^448 bits.