Some people say longer keys are silly. I think they should be supported by gpg.

[Robert J. Hansen]

On 5/22/12 4:58 AM, tim.kachao at 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.