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

[Aris Adamantiadis]

Le 2/11/13 12:30, Markus Friedl a écrit :
> Am 02.11.2013 um 11:38 schrieb Aris Adamantiadis <aris at 0xbadc0de.be>:
>
>> RFC4251 describes mpint to be multi-size and with positive values having
>> MSB clear, so it's clearly incompatible with raw string.
>>
>> Since you both agreed on the curve25519 implementation to use, I'll work
>> today on Markus' patch to make the changes Damien wanted.
> What do you want to change in my patch?
>
> I use string encoding for the pub keys both on the wire and for the hash. Only the shared secret uses mpint/bignum (for the hash). 
>
> Should we use mpint everywhere?
> I don't think so as we can require strings if length 32 everywhere. 
>
> So what would the be the consense?
Hi Markus,
I wanted to change the arc4_random thing but just seen you already fixed
it. I do not discuss the string encoding for pubkeys and hash, only for
shared secret. Currently it's mpint, you were discussing of making it
string.
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.

Aris