openssh unix dev - Nov 2013 - [PATCH] curve25519-sha256@libssh.org key exchange proposal

Hi,

That's indeed the case. It is described in
http://git.libssh.org/projects/libssh.git/tree/doc/curve25519-sha256 at
libssh.org.txt
The libssh code currently uses a bignum for k, but it can be modified if
we reach a consensus. (curve25519 in libssh is in git master and did not
yet make it into a release). I published this code here for feedback on
the specs too so it is not to late to change.

The reason I chose to encapsulate k into a bignum is because the
procedure to generate the session keys, described in RFC 5656 point 4
and RFC4253 point 8.0 both describe K as a bignum. Now that I am reading
the specs I notice I overlooked the others parameters to be either mpint
(DH) or string (ecdh) depending on the situation.

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.

Aris

Le 2/11/13 10:07, Markus Friedl a ?crit :
> if I understand
http://git.libssh.org/projects/libssh.git/commit/?id=4cb6afcbd43ab503d4c3d3054b96a1492605ea8d
> correctly, then the shared secret is encoded as a bignum,
> probably because the rest of the code assumes it's a bignum
> (e.g. for key derivation, etc). however, the DH public keys
> are always encoded as strings (both in my patches and
> in the libssh.org code).
>
>
> Am 02.11.2013 um 07:57 schrieb Markus Friedl <mfriedl at gmail.com>:
>
>> It should be compatible with the original patch. However I think that
the shared secret should be encoded as a string, too. What does libssh do?
>>
>>
>>
>>> Am 02.11.2013 um 05:46 schrieb Damien Miller <djm at
mindrot.org>:
>>>
>>>> On Fri, 1 Nov 2013, Markus Friedl wrote:
>>>>
>>>> Here are three versions (patch against openbsd cvs)
>>>>
>>>> 1) repace nacl w/libsodium, so i could test
>>>> 2) curve25519-donna
>>>> 3) Matthew's public domain reference implementation.
>>>>
>>>> i'd vote for #3
>>> Yes, me too.
>>>
>>> One thing: this patch will be incompatible with Aris' since we
calculate
>>> the hash over the DH values encoded as strings rather than (as he
does)
>>> bignums.
>>>
>>> IMO they should be strings because they aren't ever sent as
bignums on
>>> the wire, but if the Curve25519 support is widely deployed then it
might
>>> be too late to change. I don't think the encoding makes any
appreciable
>>> difference to security - the bignum encoding is unambiguous.
>>>
>>> -d

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?