Re:We Don't Generate Elliptic Curves Every Day
by tptacek on Tuesday October 24, 2023 @04:38PM
(#38005196)
I agree with you, and am reassured by cryptosystems that use 25519 and put on edge by those that use the P-curves (not because of backdoor conspiracy theories, which are silly, but because the P-curves are easy to mess up). But cryptography engineers increasingly disagree with me.
Re:We Don't Generate Elliptic Curves Every Day
by tptacek on Wednesday October 25, 2023 @05:15PM
(#38018497)
(oh, also: yes, that's my understanding too, that you're still stuck validating incoming curve points in ECDH, but I think the anti-cofactor people have a corresponding argument for signature schemes.)
If I remember correctly, part of the reason for the cofactor in 25519 is because Montgomery curves have to have a cofactor and only those curves have the nice x-only Montgomery Ladder, which basically rules out invalid curve attacks (so long as the curve is twist-secure — not all the NIST curves are IIRC). Do the complete addition formulas for short Weierstrass curves also fix this? Invalid curve attacks are a major danger for NIST curves.
I know you can use compressed point representation to get the same benefit, but that seems very rare in NIST curve implementations (because old now-expired patents). The landscape of NIST prime-order curve implementations is not great. If all those libraries were going to actually switch to complete addition formulas and compressed public keys then I might feel better about them enjoying a renaissance.