Re: speaking of keys

[Russ Housley <housley@vigilsec.com>]

Marcus:

>One could put some guidance in the document about relative performance
>   and security merits of the mandated groups.  Or even actual numbers
>   ("at the time of writing, here's the deal on performance").  I think
>   that the best we can accomplish is to provide guidance to the developers
>   trying to cut code for this standard. It's up to them to determine how
>   to best "package" this for the ultimate consumer.
>
>I really don't have a problem with MUSTing a couple of groups at
>   least.
>
>     1024 - fast, but somewhat less secure
>     15xx - slower, but rather more secure

I think that Paul Hoffman was the first to suggest the more than one MUST 
approach. I think it offers a good way forward.  Of course, whatever sizes 
we select, a paragraph is needed in the security considerations.  With the 
advance of time, bigger values will be needed.

I think that 1024 should be one of the MUST implement sizes.  Hugo and 
David Wagner have both said that they could live with this size, and the 
draft NIST guidelines say that this is sufficient for protecting sensitive 
information until 2015.  Further, there is some hardware the supports 1024, 
then uses software if a larger key is provided.  Finally, 1024 performance 
is quite reasonable in software.

As for picking the right value for the next MUST implement size, I have 
less clarity.  We have learned that more and more hardware supports 2048, 
and the draft NIST guidelines say that this is sufficient for protecting 
sensitive information until 2035.  Yet, the software performance, 
especially on small processors, is quite poor.  I think that a smaller 
value is a better choice.

The draft NIST guidelines do not offer an recommendations on values between 
1024 and 2048.  However, some interpolation is possible.  I think that we 
should consider 1280 and 1536.

Russ