Re: Curve25519/448 key agreement for SSH

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.

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


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

denis bider <[email protected]> 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

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