RE: ssh-ed25519 implementations

[Daniel Migault <daniel.migault%ericsson.com@localhost>]

I believe it is nicer to have Curve25519 and Curve448 should be coherent.  The text is clarifying.

-----Original Message-----
From: ietf-ssh-owner%NetBSD.org@localhost [mailto:ietf-ssh-owner%NetBSD.org@localhost] On Behalf Of Mark D. Baushke
Sent: Thursday, May 11, 2017 9:33 AM
To: Eric Rescorla <ekr%rtfm.com@localhost>; Ron Frederick <ronf%timeheart.net@localhost>; Brian Smith <brian%briansmith.org@localhost>; denis bider <denisbider.ietf%gmail.com@localhost>; Simon Tatham <anakin%pobox.com@localhost>
Cc: ietf-ssh%NetBSD.org@localhost; curdle%ietf.org@localhost
Subject: Re: ssh-ed25519 implementations 


Hi Eric & Ron & Brian & Simon,

Given input from folks so far, I think it would be better if both
Curve25519 and Curve448 continued to use the "mpint" format for K when generating a hash even though this is not what RFC7748 suggests.

Would it make sense to include the following text to the end of section
2.1 of https://tools.ietf.org/html/draft-ietf-curdle-ssh-curves-04 ?

    When performing the X25519 or X448 operations, the integer values
    there will be encoded into byte strings by doing a fix-length
    unsigned litle-endian conversion, per [RFC7748]. It is only later
    when these byte strings are then passed to the ECDH code in SSH that
    the bytes are re-interpreted as a fixed-length unsigned big-endian
    integer value K, and then later that K value is encoded as a
    variable-length signed "mpint" before being fed to the hash
    algorithm used for key generation.

to help clarify the differences between RFC7748 and what is happening in SSH?

Much of this text is borrowed from what Ron Frederick has written to me, any remaining confusion is my fault.

I think that the above text should help clear up the confusion that Eric noted in this section of code.

If there are no problems with this text, I will release the -05 draft with it.

	Thank you,
	-- Mark