On Thu, May 12, 2011 at 05:32:06AM -0400, Berkant Ustaoglu wrote:
There may be an alternative form of validation: instead of computing X^y and X^b, the shared secret can be set as X^8y and X^8b. The results is verified to not match identity point (assuming X \in G of course). This will kill any multiples coming from the cofactor 8. If I recall correctly something along these lines is going on in SP800-56A for ECMQV.
Indeed, private keys for curve25519 _must_ be multiples of 8, for exactly this reason. So b and y will already be multiples of 8, and if the client's X is on the twist curve, it still ends up with large prime order, and all is OK.
I think this suggestion merits examination, though:
However, I'd still suggest to keep the check X \in G* if at least to serve as warning should there be a decision to move away from curve25519.
Indeed, any "optimizations" we do knowing we're using special properties of curve25519 need to be thoroughly documents, preferably both as inline comments and in the spec documentation.
- Ian