Re: ECC in SSH draft version -01

[Joseph Galbraith <galb-list%vandyke.com@localhost>]

Ben Harris wrote:
> In article <1161018566.28037.13.camel%merlot.certicom.com@localhost> you write:
>> Specifically I addressed the problems with double negotiation within the
>> protocol and in doing so, made the ASN.1 in the document redundant, so I
>> moved away from ASN.1 messages. 
>>
>> I'm would appreciate any comments you have on the revised version of the
>> draft.
> 
> The changes generally seem quite sensible, and in particular they 
> address a problem I hadn't even got around to articulating with the old 
> draft -- that a server's host key might use a curve not supported by the 
> client.
> 
>> 4.2.  Implementation
>>
>>   This document is concerned with describing the implementation of ECDH
>>   in SSH, not the specification of the algorithm itself.  The algorithm
>>   used for shared key generation is ECDH, the full specification of
>>   which can be found in Section 3.3.2 of SEC1 [6].
> 
> I feel that it might be worth referring to the primitive specified in 
> that section by name, especially since it's not the one that SEC1 calls 
> "elliptic curve Diffie-Hellman".
> 
> I note that the output of ECDH is a field element, so you should
> probably specify how that gets transformed into the integer K required
> by SSH.  I'd guess that you use the FieldElement-to-Integer conversion
> in section 2.3.9 of SEC1, but you don't seem to say so.
> 
> The same applies to ECMQV.
> 
>>   The server's host keys are used in shared key generation; therefore,
>>   the named curve used to generate them is the curve that must be used
>>   by the ECMQV algorithm.  Care should be taken that the server's host
>>   key is sufficiently strong to ensure that the ECMQV algorithm isn't
>>   the weakest point in the SSH encryption suite.
> 
> _Something_ has to be the weakest point.  Why shouldn't it be ECMQV?
> 
>>   "secg-ecc-standard" tells the server that the clients local security
>>   policy has not disabled any of the required curves specified in
>>   Appendix A and is analogous to sending "secg-ecc-1.3.132.0.37,secg-
>>   ecc-1.3.132.0.34,secg-ecc-1.3.132.0.16,secg-ecc-1.2.840.10045.3.1.7".
>>
>>   "secg-ecc-extended" tells the server that the client supports all of
>>   the curves specified in Appendix A and is analogous to sending "secg-
>>   ecc-1.3.132.0.38,secg-ecc-1.3.132.0.35,secg-ecc-1.3.132.0.37,secg-
>>   ecc-1.3.132.0.36,secg-ecc-1.3.132.0.34,secg-ecc-1.3.132.0.16,secg-
>>   ecc-1.2.840.10045.3.1.7,secg-ecc-1.3.132.0.27,secg-ecc-
>>   1.3.132.0.26,secg-ecc-1.3.132.0.33,secg-ecc-1.2.840.10045.3.1.1,secg-
>>   ecc-1.3.132.0.1".
> 
> I'm a little suspicious of these.  They make it harder to use existing 
> code for processing algorithm lists for the sake aof a few bytes in each 
> KEXINIT, which I think is a poor trade-off.

I thought there was a ceiling on the length of the name-list
strings during key exchange (something like 256), but I can't
find it now.

If I'm blind and not dreaming, then the string above is probably
a bit on the long side...

If I dreaming and not blind on the other hand, than I think
I agree... the 'meta-names' will just make implementation
more difficult.

Thanks,

Joseph