Re: Suggested changes for DSA2
hal@finney.org ("Hal Finney") Wed, 29 March 2006 00:09 UTC
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOOFZ-0001zO-UG for openpgp-archive@lists.ietf.org; Tue, 28 Mar 2006 19:09:25 -0500
Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOOFY-0006QQ-HO for openpgp-archive@lists.ietf.org; Tue, 28 Mar 2006 19:09:25 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2SNqaFu001864; Tue, 28 Mar 2006 16:52:36 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2SNqaAx001863; Tue, 28 Mar 2006 16:52:36 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2SNqZ5N001857 for <ietf-openpgp@imc.org>; Tue, 28 Mar 2006 16:52:35 -0700 (MST) (envelope-from hal@finney.org)
Received: by finney.org (Postfix, from userid 500) id 9FD9857FAE; Tue, 28 Mar 2006 15:50:58 -0800 (PST)
To: dshaw@jabberwocky.com, hal@finney.org
Subject: Re: Suggested changes for DSA2
Cc: ietf-openpgp@imc.org
Message-Id: <20060328235058.9FD9857FAE@finney.org>
Date: Tue, 28 Mar 2006 15:50:58 -0800
From: hal@finney.org
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976
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
- Suggested changes for DSA2 David Shaw
- Re: Suggested changes for DSA2 "Hal Finney"
- Re: Suggested changes for DSA2 David Shaw
- Re: Suggested changes for DSA2 Ben Laurie
- Re: Suggested changes for DSA2 "Hal Finney"
- Re: Suggested changes for DSA2 David Shaw
- Re: Suggested changes for DSA2 Ian G
- Re: Suggested changes for DSA2 David Shaw
- Re: Suggested changes for DSA2 David Shaw
- Re: Suggested changes for DSA2 Daniel A. Nagy
- Re: Suggested changes for DSA2 Jon Callas
- Re: Suggested changes for DSA2 "Hal Finney"
- Re: Suggested changes for DSA2 David Shaw
- Re: Suggested changes for DSA2 "Hal Finney"
- Re: Suggested changes for DSA2 David Shaw
- Re: Suggested changes for DSA2 Daniel A. Nagy
- Re: Suggested changes for DSA2 "Hal Finney"
- Re: Suggested changes for DSA2 "Hal Finney"
- Re: Suggested changes for DSA2 David Shaw
- Re: Suggested changes for DSA2 David Shaw
- Cost-benefit analysis of algorithm substitution Ian G