Re: SSH in ECC Internet Draft

[der Mouse <mouse%Rodents.Montreal.QC.CA@localhost>]

[The message to which I am replying responded to messages from two
different people, pulling them together.  I didn't write all the
two-level quotes here.]

>>>        | Symmetric |  Discreet Log (eg. DSA, DH) |  RSA  |   ECC   |
>> This table is also meaningless unless accompanied by a way of
>> comparing the amount of computation demanded by, say, a 240-bit
>> elliptic curve key with the computation demanded by a 2048-bit RSA
>> key.
> Computation to do what?  (Create the key, crack the key)

Use the keys.  Giving them as "equivalent security" means that the
computation to crack the key is (thought to be) about equal

You cite smaller key sizes in a context that makes it read (at least to
me) like a reason to use elliptic curve algorithms - but smaller key
size, in itself, borders on meaningless; the number of bits involved is
one of the least important attribtues of keys - at least until you get
into many tens of thousands of bits.

> I'm not really sure what [you're] suggesting I do here.

Either reword it so this reads less like an advertisement for elliptic
curve crypto or provide data indicating why (for example) an elliptic
curve key of 240 bits is to be preferred over an RSA key of 2048 bits.

>>>    When lists of curves need to be sent [...]
>> Why is there a hard limit on the size of a list of curves,
>> especially a limit that's a magic number like 12?  Surely it would
>> be better to leave this extensible?
> This was a bit of a cop out because I was unable to find a way to
> specify in ASN.1 syntax how to not put an upper limit on a sequence.

This seems to me like a fairly clear message that ASN.1 is the wrong
tool to use here (quite aside from other problems with it - vide
infra).

>>>   for ECC keys and signatures.  This requires ASN.1 DER encoding
>> Using ASN.1 worries me a little, given the rate at which security
>> holes are found in ASN.1 decoders.
> I understand your concerns, and I do share them, but as far as I know
> the SSL ASN code is being rewritten.

And this is relevant...why?  Are you under some kind of impression that
the result (a) will somehow supplant all other ASN.1 implementations
used by SSH implementations and (b) will itself be free from further
bugs?  I find each part of that...dubious, at best.

> Honestly I don't like using ASN.1 at all, but I feel its a necessary
> evil to stay compliant with ECC standards, which I think is more
> important then software that will be rewritten.

Standards should help, hot hinder.  Standards that hinder rather than
helping should be ignored.

Or at least that's my view of them.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse%rodents.montreal.qc.ca@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B