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

[Aris Adamantiadis]

Hi,

That's indeed the case. It is described in
http://git.libssh.org/projects/libssh.git/tree/doc/curve25519-sha256@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