I'm not sure this is so much an "or", but maybe, at best, an "and" given the circumstances of source material he is currently working with. I'm not as ready to assume the timing is only routine maintenance.
Who says it has to be "routine" maintenance? It's obviously not; he's changing his key after 16 years. What's more likely is that he's just much more aware of his PGP key now than he was in the preceding years, because of the prominence he's taken in the story and the fact that he's now actively courting leakers.
FWIW, I emailed Bruce who said:
>> It's longer, and as long as I was already creating a new keypair there was no downside.
There are two concerns: 1) Security of email messages in transit, assurance that you're receiving emails from the person who claims to be sending them, etc. 2) Preventing your email service provider (and any MITM) from reading your emails. These concerns are relatively independent of each other. While if you're a die-hard PGP advocate you'll want both 1 and 2, PGP-in-Gmail gives us 1, and that's a pretty great start.…
> If you don't trust Gmail, you shouldn't trust it any less if/when they deploy PGP for it. The problem here might be that people (including Google, I guess) don't want users to trust anything MORE THAN THEY SHOULD, which is a major risk in a case like this. Sometimes security features can be counterproductive since they can lead to the users making bad assumptions and therefore bad decisions that they otherwise woul…
I'm actually suggesting that if we're going to trust Gmail completely anyway, we might as trust them to encrypt-and-decrypt everything server side. No need for any fancy PGP in JS. Gmail still gets to read your emails and generate ads (though it might not be able to do offline analytics to your emails). The point is that with PGP-in-Gmail we can at least trust that the email in transit is much more secure, and furthermore we can verify the identity of anyone sending us messages, too.
I know the fundamental idea behind PGP and related technologies. My question is, if bumping his key from 2048 to 4096 bits will keep him safe until around the year 2020 (as stated by a previous reader, and from keylength.com), why not just use a 8192 bit key, or 16384 bit key and be safe for virtually your lifetime? Does the computing cost to encrypt/decrypt make this impractical?
4096 is the largest key size gpg offers today. It was the largest key size gpg offered in 2009, which is why that's the key size I'm using now. In 1996 the largest key size pgp supported was probably 768 , which is why my first pgp key is that size. I know for sure that in 1999, the largest key I could manage to make was 2048. Looking back at those older keys, I would prefer if I could have chosen larger key sizes fo…
In 1998, the NSA required MIT to subborn their PGP. MIT publicly stated that at the time. NSA simultaneously banned the use of MIT's European confederate's version of PGP by U.S. citizens, and blocked access to that university's FTP from the U.S. Naturally, being overseas at the time, I downloaded the European version and, since it allowed creation of up-to 4096-bit keys with the option of manually-specifying non-standard lengths, I created a very large key which I saved to floppy disk.
Not to be snarky, but have you tried using google? http://www.biglumber.com/ I get a couple requests a year when someone comes through town. It could do with more participation, though. :-)
Not to be snarky but in my original comment I said that I did use BigLumber without much success.