Re: Curve25519/448 key agreement for SSH
[email protected] (Niels Möller)
| Newsgroups | gmane.ietf.secsh |
|---|---|
| Message-ID | <[email protected]> |
[email protected] (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 [email protected]. Other opinions? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.