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

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

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

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

On Sat, 2 Nov 2013, Markus Friedl wrote:
> 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).
You're right - sorry I misread.

-d