[PATCH] curve25519-sha256 at libssh.org key exchange proposal

Markus Friedl mfriedl at gmail.com
Sun Nov 3 01:20:38 EST 2013


On Sat, Nov 02, 2013 at 10:33:16PM +1100, Damien Miller wrote:
> I guess the question is this: do we treat curve25519 as a specific case
> of RFC5656 or as something different?

I think we should treat it as a special case, pubkeys encoded as
raw curve25519 strings>

> Seen this way, I feel less strongly that the shared_secret should be a
> string.

shared_secret should be an mpint/bignum in the hash, since
this is what the RFC requires for 'K', c.f. the SSH-ECDH RFC:

http://tools.ietf.org/html/rfc5656#section-4
	The elliptic curve public keys (points) that must be transmitted are
	encoded into octet strings before they are transmitted.  The
	transformation between elliptic curve points and octet strings is
	specified in Sections 2.3.3 and 2.3.4 of [SEC1]; point compression
	MAY be used.  The output of shared key generation is a field element
	xp.  The SSH framework requires that the shared key be an integer.
	The conversion between a field element and an integer is specified in
	Section 2.3.9 of [SEC1].
where [SEC1] == http://www.secg.org/download/aid-780/sec1-v2.pdf

And Aris just wrote:

> I just pointed out that RFC5656 tells:
> 
>    The hash H is formed by applying the algorithm HASH on a
>    concatenation of the following:
> 
>       string   V_C, client's identification string (CR and LF excluded)
>       string   V_S, server's identification string (CR and LF excluded)
>       string   I_C, payload of the client's SSH_MSG_KEXINIT
>       string   I_S, payload of the server's SSH_MSG_KEXINIT
>       string   K_S, server's public host key
>       string   Q_C, client's ephemeral public key octet string
>       string   Q_S, server's ephemeral public key octet string
>       mpint    K,   shared secret
> 
> So even tough public keys are points (x + y coordinates), the shared
> secret (x coordinate) is hashed as an mpint. If we look at curve25519 as
> a special case of RFC5656, the point and the x coordinate are the same.

so I think we should keep the encodings from the patch...

-m


More information about the openssh-unix-dev mailing list