Re: Curve25519/448 key agreement for SSH

[denis bider <ietf-ssh3%denisbider.com@localhost>]

In a new algorithm, yes. But in this case, I am inclined to be against changing the K encoding, simply because:

- I consider the encoding to be a non-issue, as long as it's unambiguously specified; and
- this would be a departure from the existing libssh and OpenSSH implementations; which is not a huge deal, cause it's a new algorithm name; but it's awkward anyway.

This is unless Damien comes out with a new finding - for example, that their existing conversion from byte string X to mpint K is broken in 1/256 of cases. If it turned out that the existing implementation is adding a leading zero if high bit of X is set; but is not removing the leading zero if the 9 high bits of X are NOT set; then this would make it something that follows the rules of neither mpint, nor string. If that were the case, I would be highly inclined to fix that.

I have no reason to believe that's the case, however. And in that case, as long as it is reasonable, which I believe it is, I'm inclined to support whatever their current implementation is doing.


----- Original Message -----
From: Niels "Möller" 
Sent: Monday, November 16, 2015 14:50
To: denis bider 
Cc: Simon Josefsson ; ietf-ssh%netbsd.org@localhost ; djm%mindrot.org@localhost 
Subject: Re: Curve25519/448 key agreement for SSH

nisse%lysator.liu.se@localhost (Niels Möller) writes:

> That sounds a bit awkward, but maybe it's not a big deal to actually
> implement? Do we ever do any integer operations of K? (Except internal
> to the key exchange). And for the old dh key exhange algorithms, we're
> converting the integer to a string, and it shouldn't be a big deal if we
> think of "K" as the value before or after that conversion.

I've now reread RFC 4253, section 7.2, and my corresponding source code,
to have a closer look.

: The key exchange produces two values: a shared secret K, and an
: exchange hash H.

Here, H is clearly a string, and it's construction depends on the key
exchange method. That K is an integer is stated in a parenthesis,

:    o  Initial IV client to server: HASH(K || H || "A" || session_id)
:       (Here K is encoded as mpint and "A" as byte and session_id as raw
:       data.  "A" means the single character A, ASCII 65).

So K's contribution to the hash input is a length field, followed by
network-byte order bytes, following ssh rules on how to deal with sign
bit, etc. (The specification really isn't crystal clear, e.g., I think H
too is "raw data", not preceded by a length field like a string).

I don't see any serious practical problem if we for curve25519 specify
that we do HASH(K || H || ...) where K is encoded as a string, i.e.,
four octets length, 0,0,0,32, followed by the curve25519 fixed-size
output string (which happens to be an x-coordinate in little-endian
order, iirc).

My implementation actually represents K as a string already, with the
conversion from integer to string done in the dh code, not in the
generic key exchange code, which I think at least shows that there
should be no great difficulty in treating K as a string.

I think I'd prefer that we do the right thing here, even if that means
we specify something not quite compatible with
curve25519-sha256%libssh.org@localhost. Other opinions?

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.