Subject: Re: Curve25519/448 key agreement for SSH

From: [email-masked] (Niels Möller)
Date: Tue, 17 Nov 2015 16:26:57 +0100

denis bider <[email-masked]> writes:

> You've described that in your implementation K encoding is
> method specific.

Then I was unclear. The key exchange output is *always* represented as a
string, even for the plain dh exchange methods. I view any integer-ness
as an internal detail of the keyexchange mechanism.

> Overall, though, it seems to be a bikeshed issue - it doesn't really matter either way.

I agree it's not terribly important, but I'm going to get a bit annoyed
when I implement curve25519 key exchange, if I have to tweak the length
of K depending on contents of the secret value.

I'd really like to hear more opinions.

Regards,
/Niels

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

---

From: denis bider <[email-masked]>
Date: Tue, 17 Nov 2015 13:15:48 +0000

Yes, but:

- Other kex methods use mpint, so you need to support K as mpint anyway. You've described that in your implementation K encoding is method specific. But maybe in another implementation K encoding is common between methods, and it now needs to have a special case for when K is string. This adds complexity to that implementation.

- If libssh and OpenSSH have to implement two subtly different versions of the same algorithm, that's implementation complexity for no technical benefit also.

----- Original Message -----
From: Niels "Möller" 
Sent: Monday, November 16, 2015 23:46
To: denis bider 
Cc: Simon Josefsson ; [email-masked] ; [email-masked] 
Subject: Re: Curve25519/448 key agreement for SSH

denis bider <[email-masked]> writes:

> 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

Do you agree that it adds a little implementation complexity, for no
technical benefit? 

Regards,
/Niels

---

From: Matt Johnston <[email-masked]>
Date: Wed, 18 Nov 2015 22:05:44 +0800

> I'd really like to hear more opinions.

Dropbear implements [email-masked]. My 2c is
to stick with K as an mpint just to avoid unnecessary
change/confusion with RFC 4253 (7.2, deriving keys) and 5656. 
In terms of implementation a fixed 32 byte string would have
been simpler, but not worth changing. 

A small thing, 'k' in draft-josefsson-ssh-curves-01 should
probably be upper case? 

Is it worth keeping the "Verify that client public key length is 32 bytes" (or 56)
text of [email-masked] ?

Cheers,
Matt

https://git.libssh.org/projects/libssh.git/tree/doc/[email-masked]

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 18 Nov 2015 21:30:36 +0100

> been simpler, but not worth changing. 

Agreed.

> A small thing, 'k' in draft-josefsson-ssh-curves-01 should

Yep, fixed.

> text of [email-masked] ?

I added it.

/Simon