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 _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
