David Shaw wrote:
On Tue, Mar 28, 2006 at 01:04:12PM -0800, "Hal Finney" wrote:
I support David's suggestion to include a SHOULD relating hash size to key
size. But it makes sense to me to extend our current key size SHOULD
recommendations to include advice regarding subgroup size, hash size,
and symmetric cipher key size. This would correspond to Table 2 on page
63 of NIST's SP800-57:
http://csrc.nist.gov/publications/nistpubs/800-57/SP800-57-Part1.pdf
The sizes from that table are:
1024 / 160 / 80
2048 / 224 / 112
3072 / 512 / 256
7680 / 768 / 384
15360 / 1024 / 512
where the 1st column is the RSA, DSA or DH modulus size, the second
column is the hash/subgroup size, and the 3rd column is the symmetric
cipher key size (which is also the strength in bits).
Are you sure that table is correct? I thought it was:
1024 / 160 / 80
2048 / 224 / 112
3072 / 256 / 128
7680 / 384 / 192
15360 / 512 / 256
Yes, sorry, you're right. I transcribed it wrong and doubled when I
should have halved.
I'm not sure this is the right way to go about it. Is balance
actually what we want, or would it be better to just remind people
that the weakest parameter constrains the level of security? There is
nothing invalid about a 8192-bit RSA key making SHA-1 signatures. It
just means that the signature has at most 80 bits of strength. The
signer could have used a 1024-bit RSA key and gotten the same 80 bits
of strength, but that doesn't make the 8192-bit signature wrong (just
large). My suggested wording was more to encourage implementors to
indicate the actual strength, rather than to force balance.
How about this (presumably for the Security Considerations section):
As OpenPGP combines many different asymmetric, symmetric, and hash
algorithms, each with different measures of strength, care should
be taken that the weakest element of an OpenPGP message is still
sufficiently strong for the purpose at hand. Implementations
receiving messages SHOULD indicate to the user the actual strength
of the messages. While consensus about the the strength of a given
algorithm may evolve, at publication time, NIST Special Publication
800-57 [SP800-57] recommended the following list of equivalent
strengths:
[ put table here ]
I like this general direction, but I don't think it will work to indicate
to users the actual strength of message encryptions or signatures.
There is no convenient way to express this information that will be
understandable to the layman. We could say that a DSA1 signature has 80
bits of strength, and a 2048 bit RSA encryption using AES-256 has 112 bits
of strength, but that is too technical and also in most cases too much
information. It's also non-standard practice in crypto implementations
to provide this information, and I don't feel comfortable putting in
a requirement for something this novel, without having experience to
justify it.
I can see that invalidating 2048 bit RSA key signatures that use SHA-1
is not the right thing to do either, which my earlier language proposal
could be interpreted to recommend.
I'm still in favor of making the NIST list a SHOULD for generating
DSA2 keys, of course.
Okay, well, maybe the rest of it is too complex to deal with for now.
Hal