[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ECC curve ID
On Fri, 16 May 2008 08:59, openpgp@xxxxxxxxxxxx said:
> 2. Different curve is not the same as different RSA key size.
What I want to express withn that comparision is that we already have a
wide range of parameters in addtion to the algorithm ID. The curve ID
is just another parameter, or well a short-name for the curve
> performance reasons. Implementations will achieve better performance
> by tuning the code for each underlying field at compile time, or, in
> case of hardware, this may be done by the manufacturing time.
They may still do this. I can't see that as an argument pro or con a
fixed list of curves.
> Conversely, even when RSA is implemented in hardware, a parameter to
> RSA key size is almost certainly a variable in software. There is
> nothing to gain by separately implementing RSA 2048 and RSA 4096
I disagree. Even pure software implementations are often tuned for
certain key sizes (e.g. to use the Karatsuba algorithm only for certain
sizes). With hardware you even need to decide whether the hardware of
software implementation is faster for a certain size.
> support any other curve. Compare this with RSA support. To put this
Or compare that with DSA support. How that we have DSA-2 many
implemtations fail because they can't cope with >1k DSA keys. That is a
similar interoperability issue as with new curve IDs.
> base, while my RSA implementation is capable of handling any key size
> within a reasonable range.
And what about DSA implementations?
> A: Keep current text regarding the procedure to approve new curves
> B: Keep current method to encode curve IDs as numeric IDs
> C: Need extension mechanism specified in the draft to add other
> A: for
> B: for
> C: against
D: Use an OIDs instead of an algorithm ID and define the NIST curves as MUST.
A: for (as long as that does not forbit other curves)
C: for (as second best choice)
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.