On 5/22/12 4:58 AM, tim.kac...@gmail.com wrote: > I am involved in a local Occupy (bet you thought occupy was kaput eh? > well as it were known it is but that's another story) and frankly we > aren't just up against one intelligence agency, but all intel > agencies put together.
You might want to re-think talking about this in a public forum. This mailing list is open to everyone, including the very people you're talking about. The first rule of good operational security is, "don't draw attention to yourself or your organization." > Secondly I want my communications to remain unread into the > relatively distant future. A 3072-bit key will do that today. Breaking a 3K key would require such technological advances that it would be indistinguishable from science fiction. There's no point in going past a 3K key because if a 3K key were to ever fall we'd have to reconsider the mathematical foundations of cryptography. > I'm 23 now and I take various modest precautions to ensure that I > have the best chance I can to remain in good health when I am 43. Or > 63. A couple hundred extra milliseconds of decryption/encryption > time per message for a key longer than 3072 or 4092 sounds like a > good choice frankly. Is that not what we are looking at? No, it's not. Imagine an automobile. You might say, "well, I'd like an additional hundred horsepower so I want to put a V-8 engine in my automobile: why doesn't my automobile support this?" But if your car is a Fiat 500, well, there's simply not the room for such a large engine, nor is the transmission or powertrain ready for that. For that matter, even the wheels would have to be redesigned: sustained high-speed driving on your average Goodyears will cause them to delaminate and come apart, so you'd need H-rated sport wheels or Pirelli PZero Neros. Changing one component requires changes to a lot of other components. That's what we're facing with changing the maximum key length. The mobile experience would be impacted, the embedded market would be impacted, and even interoperability with other OpenPGP applications would be impacted (since as far as I know none of them save for PGP 6.5.8ckt support such large keys). It's all right to ask for larger keys to be supported, but there are tradeoffs to be made here. > Fourthly a little safety margin never hurt. That safety margin is already present. > I understand that no matter how long the keys are it's still only a > relatively small part of the equation. However I thought it was the > norm to pick something that basically eliminated concern about the > encryption being broken, so one could forget about that part and > focus on the rest.of your security worries. Yes, and 128-bit crypto is plenty sufficient for that. > http://en.wikipedia.org/wiki/Key_length wikipedia says the U.S. > Government requires 192 or 256-bit AES keys for highly sensitive > data. Quoting from that page, "128 bits is currently thought, by many observers, to be sufficient for the foreseeable future." The Wikipedia page is also in error. Per the publicly-available NSA Suite B documents, AES128 is considered sufficient for SECRET data. There is no AES192 requirement in Suite B. _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users