Re: Curve25519/448 key agreement for SSH

[nisse%lysator.liu.se@localhost (Niels Möller)]

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.