home of the madduck/ blog/ 2009.05.11:gpg-key-mania/
discussion

Why is the RSA key limited to 4 Kibit? I’ve seen longer. Plus the RSA key limitation of PGP v3 keys to effectively 2047 bit should have taught the OpenPGP initiators to not do it again…

Would you care to -v ?

I’ve corrected that. GPG does not allow for longer RSA keys. I don’t actually know where that limitation comes from:

lapse:~|master|% gpg --gen-key
Please select what kind of key you want:
  (1) DSA and Elgamal (default)
  (2) DSA (sign only)
  (5) RSA (sign only)
Your selection? 5
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 8192
RSA keysizes must be in the range 1024-4096


Oh, but everyone knows that gpg —gen-key is useless to generate RSA keys anyway, because it does not allow you to set S+C+E+A caps.

Use $ gpg —gen-key —expert # instead.

Hm, neither that nor gpg2 with the same options allow larger keys, though pgp-2.6.3in from Lutz Donnerhacke does (which is probably what I used for that 5 Kibit key back then… it’s been some time).

Now I wonder where this restriction comes from.

—mirabilos (first comment’s poster too – I was a little confused from this not-quite-blog thing)


Martin, I agree that panicking isn’t the right response. But for people whose primary key is 1024-bit DSA, I do think it’s worth considering making a new OpenPGP key, and transitioning to it over a reasonable timeframe. The page that you link to as a reasonable discussion of GnuPG says:

Again it is recommended that users begin migrating away from the SHA-1 hash and towards longer hashes such as SHA-224 or SHA-256.

RIPEMD-160 hasn’t had the same level of concerted cryptanalysis that SHA-1 has, and it is not a longer hash (both are 160-bits). Since DSA-1 keys are limited to 160-bit hashes, this implies that we should be considering keys that can use longer hashes.

At some point (not today), signatures made over SHA-1 or any 160-bit digest will be considered suspect. It would be nice if we had a functional web of trust based on post-SHA-1 digests.

—dkg


Hey madduck,

I had a slightly similar reaction to you about the “flooding of planet” with new keys, however I do have a slightly different take on the situation than you do. First I do think its reasonable for people to publish their key transition information on a place that they control, and doing so on your blog is one of the better ways to get that information out. That it floods planet is a somewhat ugly by-product of that.

Secondly, I am concerned about your flippant dismissal of the issue as lemming-type behavior. I do agree that it is a bad idea for people to jump off a cliff because other people have, and I also think that people should not take key transitions lightly and should do so in a measured, unhurried manner so that they can consider all the issues involved and act accordingly. However, I disagree with your assertion that this is not worth doing.

Yes there are no demonstrable attacks available for this issue, and in fact the reduction in key space, while significant, still leaves it at a fairly high bar. However, the exact same process that happened with MD5 being eroded over time is happening now with SHA1 and at some point the attacks against SHA1’s collision resistance will be strong enough that signatures based on SHA1 can no longer be trusted. So when the equivalent of the MD5 hashclash rogue CA attack comes out against SHA1 we will be in trouble.

I would wager that this type of attack is probably a few years out. So if its a few years out, why would I want to transition now? Quite simply because being proactive in this case is the right thing to do. A significant majority of the signatures in today’s WoT are made with SHA1 and to transition to something else is going to take a while, especially if it is to be done in a sane way, but to prepare for this inevitable eventuality, we need to start making those steps now, and NOT when that attack is announced.

I agree that I think its worth taking the time to investigate the options. I am curious about your reasons for why you think RSA has problems. Gnupg defaults are being changed to use RSA 2048 by default, and although the limit on RSA keys exists in GnuPG implementations, I suspect that will be changing soon. Although DSA2 keys would also solve this problem, DSA2 is not as widely availably implemented as RSA is, which makes it not a particularly good option. If you are going to do a key transition, then switching to the more widely adopted standard seems like the way to go (although switching to DSA2048 does solve the current problem at hand!) I would like to know any information about why you should prefer DSA over RSA, if you happen to come upon any.

You wrote: “When RSA is broken, will we see a replay of this whole key-replacing frenzy?”

Yes, that is true, but its no more true for RSA than anything else.

You also wrote: “Wouldn’t it make more sense to leverage the current situation and work on pushing/improving the DSA algorithm with larger keys, and to strive towards better algorithms in general, e.g. through SHA-3.”

It sure would be nice to skip SHA2 and jump right into SHA3, but its not there yet, SHA-3 is a while out yet and I dont think it makes sense for people to wait a couple years for that to come out, risking a published “weaponized SHA-1 collision technique”, and then ask people to do this transition. Who is to say that by the time SHA3 comes out (or Camillia for that matter), published attacks for SHA1 wont have been released? I’m not willing to take that risk and rather would prefer to engage in a rational, calm and proactive process now, rather than wait for that. At what point are you willing to make that transition, how long are you willing to wait?

Also, I’m curious about your recommendations for using RIPEMD160. You provide no rationale for that, and I think its an incorrect recommendation. Would you mind providing some information about why you are recommending that?

micah


While it might be nice if the reasons for people to switch were entirely rational what does it matter if people upgrade their key for irrational reasons as long as that is the right thing to do. I suspect that without “lemming like behavior” few people would switch when it became rational to do so. Being a little premature doesn’t appear to do much harm.

William


madduck wrote:

For instance, why would I want to use an RSA key, which is limited in GPG to 4096 bit keys?

I just experimented with this. While the gpg UI limits RSA keysizes to 4096, you can create larger keys using —batch.

For example:

gpg --gen-key --batch <<EOF
Key-Type: RSA
Key-Length: 8192
Key-Usage: sign
Name-Real: Test Key
Name-Comment: DO NOT USE
EOF

—dkg


I think that —expert SHOULD disable that too, if it then works in gpg and/or gpg2.

—mirabilos