[curves] curve25519 public keys with high bit set

[Watson Ladd]

On Wed, Jun 4, 2014 at 7:06 AM, CodesInChaos <codesinchaos at gmail.com> wrote:
> No matter which way is chosen, it's important to get the IETF TLS
> specification for Curve25519 to match what's chosen and to include
> test-vectors for it.

Please, please try to follow the CFRG: that's where this specifying is
going on. If they get it right we are happy.
If not, we aren't. Anyone can contribute: it really does matter.

>
> Personally I prefer ignoring the bit. My effort to change
> LibSodium/Donna was to ensure that all major implementations have the
> same behaviour.

I'm hard pressed to think of a situation where you don't know if you
are doing ECDH or signatures. However, I hear the
argument that one code path can calculate the scalar multiplication
for both if we do this bit trick, and by ignoring the the
top bit interoperate.

The only detail/problem is that you have to mask the top bit of
generated shared keys. This complicates exposing a simple scalarmult
operation.
>
> If we can get all major implementations, including NaCl to ignore the
> bit I'd be happy to follow that path.
> On a related note, DJB's implementations in SUPERCOP recently changed
> from interpreting it as a 256 bit integer to ignoring the top bit.
> But I don't know if NaCl will follow. Somebody should talk with its authors.
>
> Note that you can put a sign into MSB, even with 256 bit integer
> interpretation, it's just a bit annoying.
> _______________________________________________
> Curves mailing list
> Curves at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/curves



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin