[curves] Ed448-Goldilocks on NEON; point encoding

[Trevor Perrin]

On Thu, Mar 12, 2015 at 2:17 PM, Michael Hamburg <mike at shiftleft.org> wrote:
>>
>> But there are ergonomic questions about how DH-only and full-format
>> keys would interact [1]:
>> (A) Sign bit omitted when converting full -> DH-only
>> (B) Sign bit ignored when converting full -> DH-only
>> (C) Sign bit always included
>> (D) Sign bit always excluded (Jivsov or Ransom tricks)
>
> What’s the difference between (A), (B) and (C) here?  Is it that (A) erases the sign bit, (B) preserves it but ignores it in ECDH, and (C) demands that the Montgomery ladder produce it?

Yes.  To be more explicit: regarding conversion of full-format public
keys to DH-only, I think the options are roughly:
 (A) Sender MUST omit or zeroize sign bit, receiver (MAY? MUST?)
reject public keys with it set
 (B) Sender MAY omit or zeroize sign bit, receiver MUST ignore it
 (C) Sender MUST include valid sign bit
 (D) Sign bit implied (Jivsov's trick) or both values tolerated (Ransom's trick)

I wrote these up in [1] which I forgot to reference:

[1] https://moderncrypto.org/mail-archive/curves/2015/000392.html


What I'm proposing below is basically (A), but with the twist that the
formats are syntactically different (extra byte) so there's no
ambiguity about whether any particular protocol field or public key is
DH-only or full-format.


>> Since that overloading can't be done in Goldilocks anyways, perhaps a
>> cleaner and more aligned approach would be to *not* overload that bit,
>> and always store the sign bit in a separate byte.  So:
>>
>> DH-only keys:
>> - 32 bytes Curve25519 (mont-X)
>> - 56 bytes Goldilocks (mont-X)
>>
>> Full-format keys:
>> - 33 bytes Curve25519 (mont-X + ed-sign)
>> - 57 bytes Goldilocks (mont-X + ed-sign)
>>
>> This would eliminate ambiguity in protocol specs between whether a
>> DH-only or full-format key was expected, and whether a sign bit is
>> present or not.
>>
>> Thoughts?
>>
>> Trevor
>