Hi, I'd like to argue that the high bit of encoded curve25519 public keys should be masked to zero.
The paper specifies "liberal in what you accept, conservative in what you send" behavior: http://cr.yp.to/ecdh/curve25519-20060209.pdf "The set of Curve25519 public keys is, by definition, {0, 1, ..., 255}^32" ... "Note that Curve25519 is not surjective: in particular, its final output bit is always 0 and need not be transmitted." Some curve25519 implementations masked off the high bit of received public keys, since it should never be set. But it was pointed out that DJB's reference implementation treats the input public key as a full 256-bit value to be reduced mod 2^255-19. So libsodium and curve25519-donna changed to match: http://www.ietf.org/mail-archive/web/cfrg/current/msg04333.html https://github.com/jedisct1/libsodium/issues/78 https://github.com/agl/curve25519-donna/commit/81b6dcb6cf5b983ec6391f36aa061caef07c58ad I think this is bad, we should mask the bit: If some implementations accept full 256-bit keys, then eventually some implementations will start *producing* full 256-bit keys, which will break older libsodium / donna, and require everyone to support full 256-bit values. (Hopefully no-one's producing such awful / noncompliant pubkeys yet, so it's not too late!) Also: reserving the 256th-bit allows the curve25519 encoding to be easily augmented to a "unified encoding" that can encode both curve25519 and ed25519 public keys, using the (montgomery_x, edwards_x_sign_bit) idea that Robert and Watson discussed earlier: https://moderncrypto.org/mail-archive/curves/2014/000002.html Do people agree that masking is the best practice? Trevor _______________________________________________ Curves mailing list [email protected] https://moderncrypto.org/mailman/listinfo/curves
