LWN: Comments on "Upgrading Debian's keys"

Upgrading Debian's keys

kroeckx — Thu, 06 Mar 2014 18:40:10 +0000

Since 2010 the keyring maintainers have a policy of only accepting 2048 and recommending 4096 keys.

NIST has since 2005 been recommending that you should stop using 1024 keys by 2010.

Upgrading Debian's keys

eean — Mon, 03 Mar 2014 08:03:39 +0000

Yea exactly this. It's for sure good to verify that this person has this legal identity, but at the same time the trust given to Debian maintainers is built on their online actions not their government id cards.

Upgrading Debian's keys

ras — Fri, 28 Feb 2014 02:48:39 +0000

Well if that's the worry, they should stop accepting new keys signed only by 1024 bit keys. As far as I know they haven't.

Currently they prefer new keys to have several signatures. They could formalise that slightly and award points for signatures. A signature from a 1024 bit key gets less points than a 2048 one. Once you get enough points, you are in.

I'm not a huge fan of the WoT. Insisting that every interaction for 6 months (post to a Debian list, or upload) be signed by a key you intend to use would be far better. When they accept you as a DD, it is your past history in interacting with Debian they are judging you on. Whether you have taken 10 minutes out of your life to have a DD sign your key proves very little.

Upgrading Debian's keys

jwarnica — Thu, 27 Feb 2014 20:04:19 +0000

Well, then *today* you have a problem: you have compromised DD shipping bad code. If the WoT is compromised, and able to be compromised, then it gets worse daily.

If you, for example, give 30 days to upgrade to larger keys, by signing with current (bad) ones, then it at least ends the windows of introducing new evil into the WoT.

I know that crypto geeks think that they can make things perfect, but operationally here in the real world, the best you can do is something finite. The can is open, the worms are everywhere.

Putting a hard deadline will provide an actual, if imperfect, level of trust. Letting those striving for perfection wait for perfection means that you have unlimited imperfection, for ever.

Upgrading Debian's keys

talex — Thu, 27 Feb 2014 17:24:23 +0000

That may be the case now (I don't know), but it wasn't five years ago when this problem was first noticed. Seems like rejecting simple key transitions (in favour of requiring new in-person signatures) has had the effect of reducing security here.

Upgrading Debian's keys

mathstuf — Thu, 27 Feb 2014 15:32:40 +0000

The worry seems to be that the keys may be too easy to brute force *today*, not in the near future.

Upgrading Debian's keys

talex — Thu, 27 Feb 2014 14:40:35 +0000

I don't understand why Debian can't accept new keys that are just signed by the old ones. I have two GPG keys: a 2048 bit key (generated in 2009), which I use for most things, and an old 1024 bit key (from 2002), which I use only for uploading Debian packages.

If Debian trusts my old key to upload new packages, why can't they trust it to vouch for the new key?

If I believe that keyA1 belongs to A, and keyA1 and keyA2 sign a transition document saying that keyA2 also belongs to A, then I should believe that keyA2 belongs to A, no? Why shouldn't I then be willing to sign keyA2 myself to say "I verified this key transition was correct on <date before cracking keyA1 was feasible>"?

Upgrading Debian's keys

hmh — Thu, 27 Feb 2014 13:29:57 +0000

This post is also interesting:
https://www.void.gr/kargig/blog/2013/12/02/creating-a-new...

Upgrading Debian's keys

hmh — Thu, 27 Feb 2014 13:16:39 +0000

You can use the defaults on new gnupg just fine, but these are bound to the key when it is created, so if they change you have to update the key (and upload it to keyservers) to get the new defaults anyway. (gpg --edit-key, subcommand "setprefs" without options).

Avoid SHA1, MD5 and RIPEMD160.

Also, read this:
https://wiki.debian.org/Subkeys

Create the new "master" key in an offline box. That key (the full private key, aka KSK or master key) should *NEVER* be accessed online. Store it safely. It will only be needed to sign other keys (for the web of trust), and to create subkeys, which should be done on a offline, trusted computer.

This protocol may allow you to avoid revoking the entire key in case of a partial compromise (one where the offline copies of the full key were not compromised).

You will normally use the mangled private key (generated by gpg --export-secret-subkeys). If this mangled private key is exposed, you just have to revoke all subkeys and create new ones, thus not losing any key signatures (because the KSK -- the master private key -- was not exposed/compromised).

Obviously, if the master private key is suspect of being compromised, or if it is lost, you have to revoke everything and create a new key, thus losing all web-of-trust signatures.

Upgrading Debian's keys

ovitters — Thu, 27 Feb 2014 09:13:39 +0000

Any recommendations from moving from an "old" GPG key to a new one? I still want to be able to read the various content that is encoded with the previous GPG key. So ideally the "old" key would still stay active, but just not used by default.

I've found http://keyring.debian.org/creating-key.html and I'm a bit hesitant to override defaults like this. IMO upstream should fix the default. I'm wary of overriding defaults and then figuring out many years later that the current upstream default is more secure than whatever I put in there.