Re: Curve25519/448 key agreement for SSH

denis bider <[email protected]> writes:

>> If implementers are interested in "fixing" this while we go
>> through this process, we have that opportunity. There is
>> no direct backwards compatibility problem to care about,
>> since we are registering a new name.  
>
> I agree, but it does seem like it would really require re-specifying K
> to be a "string", and just for these particular algorithms.

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.

So I think we should seriously consider thinking about K as a string,
and specify curve25519 with that view.

James Cloos <[email protected]> writes:

> Given that one of the design goals of the modern curves is to exchange
> the public data as opaque bit strings, the protocol should not use
> anything like a mpint to exchange the keys but instead should exchange
> them as the opaque bit strings they are.

I think the issue is not the messages in the curve25519 dh exchange
itself, but the representation of the *output* of the key exchange.

Regards,
/Niels

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