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

[John Clizbe]

tim.kachao at gmail.com wrote:
> I think it should be okay to dredge up this topic ever couple years.  From 
> what I am reading, links below,  I do not feel comfortable with the key 
> length and algorithmic security offered by GPG's defaults.

[I think I write this same email on one list or another at least once per year]

That is your right. Come back with the math if you wish to convince many of us
of your position.

> I have not been able to figure out how to get keylengths greater than 3072 
> for DSA/elgmal or >4094 rsa, so I conclude that generating them is 
> unsupported by GPG although GPG can use them.  I have seen many people 
> saying that these types of key lengths are way more than anyone could 
> reasonably need, but I am skeptical.

You do what has been done in the past, you hack the source. BTW, the NSA whose
second primary mission is securing the communication of the US Gov't says
2048-3072 is as far as that technology goes. At that length the switch should
be made to ECC. NIST who sets the standards for the rest of the Gov't and much
of business agree.
> 
> 
> 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?

Pssst, they're not going to try to break your encryption, they have easier
methods of stalking and watching you.

> And yes I recognize that it would be a lot easier for them to plant spyware 
> on my computers than break the keys, however they can't plant spyware on 
> everone's computer. without people noticing  They do slurp up and 
> probably store indefinitely all text -and many other- communications on 
> the internet (carnivore etc.).  In the future, data they don't have they 
> can't use.  There is always a substantial probability that they will not 
> get my keys with spyware, and I would like capitalize (If you'll pardon 
> me) on that.
> 
> Fourthly a little safety margin never hurt. 

Except when they're are easier ways to achieve equal or better security
> 
> I think it should be easier to pick longer keys.  Also info should be 
> included in the compendium regarding practical aspects of key choice, 
> like a table that shows how long it takes to encrypt a symmetric key with 
> 2048, 4092 etc.  Or event just a table in which you select your 
> adversary, then your time horizon, and it tells you what key lengths are 
> suitable, with due warnings and notes regarding the possibility of 
> quantum computers, mathematical advances etc.

4092 bit keys will never come into vogue except among a small group of people
who think they are "better".

> 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.
> 
> My trust in GPG has been disturbed by this state of affairs.  I thought I 
> could just trust the defaults but I am finding that they may not really 
> include the safety margin that people desire. I shudder to think of 
> people who are doing more serious stuff in the class war than little ol' 
> me (which isn't hard).

The defaults in GnuPG are quite safe. You're understanding of them needs a bit
of work.

> Links:
> http://en.wikipedia.org/wiki/RSA_%28algorithm%29
> -http://www.schneier.com/essay-368.html < note that this was written in 1998
> http://www.rsa.com/rsalabs/node.asp?id=2004  this one in particular makes 
> it clear that it is not unreasonable for someone in my position to choose 
> a 4096 bit key.

Specific predictions about Cryptography far in the future should be taken with
a LARGE grain of salt. Most of the RSA 8192 ideas come from Schneier's Applied
Crypotograthy. Bruce Schneier has done a lot of great work, but relying on
14-year-old advice for RSA key sizes ignores current work and best practice
thought in cryptography Over the summer (2010), readers of the [Cryptography]
mailing list were reminded that in 1993 folks thought that 1024-bit RSA
'should be ok (safe from key-factoring attacks) for "a few decades".' 1.75
decades later it's essentially history.


> http://en.wikipedia.org/wiki/Key_length wikipedia says the U.S. Government 
> requires 192 or 256-bit AES keys for highly sensitive data.  A 3072 bit 
> RSA or elGamal key is about equivalent to 128 bit symmetric key, right?  
> And a 256 bit key length equivalent public key is abut 15,387 bits..  I 
> think if people want to use the same level of encryption for their data 
> that the government uses shouldn't that be supported at least in command 
> line mode?
> http://www.win.tue.nl/~klenstra/aes_match.pdf good paper on equivalencies 
> in computation and cost of public key vs. symmetric.

past RSA key sizes of 2048-3072, the migration is to Elliptic Curve
Crypto (ECC). Huge RSA keys do not scale for most Internet usages (PKI/TLS/SSL).

NO ONE is recommending 4096 RSA or DSA, not because it's unsafe but it's
computationally unwieldy, especially on small devices. At asymmetric key sizes
of 3072 bits, the smart money is moving to Elliptic Curve Cryptography (ECC).

How does ECC compare to RSA _today_?

>From the National Institutes of Science and Technology (one of the gold
standards for engineering know-how):

  RSA    ECC    Sym
 1024    160     80
 2048    224    112
 3072    256    128
 7680    384    192
15360    512    256

(One may add a 'Hash' column by doubling the values in the Symmetric
Encryption column.) These recommendations can be found on page 63 of NIST
Special Publication 800-57, Recommendations for Key Management, Part I. 2nd
Revision, 8 Mar, 2007.
[http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Mar08-2007.pdf]
All three parts of SP800-57 are available at
http://csrc.nist.gov/publications/PubsSPs.html

The NSA's 2010 Suite-B
[http://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml]
recommendations are:
    Type   Symmetric   Elliptic Curve    Hash
   Secret     128         256             256
  Top Secret  256         384             384

A key aspect of Suite B is its use of elliptic curve technology instead of
classical public key technology. During the transition to the use of elliptic
curve cryptography in ECDH and ECDSA, DH, DSA and RSA can be used with a
2048-bit modulus to protect classified information up to the _secret_ level
[http://www.keylength.com/en/6/].

So, depending on the source, a consensus seems to be forming that beyond a
2048 or 3072 bit modulus for DSA2 or RSA, folks need to switch to ECC.

2048-RSA is the current default in GnuPG. OpenPGP cards will support up to
3072-bit RSA; GnuPG up to 4096-bit RSA and 3072-bit DSA2. ECC in OpenPGP is on
its way toward becoming a RFC and being included in OpenPGP. Larger and larger
RSA keys aren't the solution, ECC is. The balance of power has tipped away
from RSA and toward ECC.

The Internet Draft for ECC in OpenPGP
[https://tools.ietf.org/html/draft-jivsov-openpgp-ecc-11] is in the Final
Comment period with comments due by 2012-04-09. I imagine it will be voted on
soon, and approved. ECC is already mostly in place in GnuPG 2.0.

Feel free to ignore everything I've told you. There's no reason you should
trust me. But by all means, keep asking questions and read the /authoritative/
articles and documents.

-- 
John P. Clizbe                      Inet: John (a) Gingerbear DAWT net
SKS/Enigmail/PGP-EKP                  or: John ( @ ) Enigmail DAWT net
FSF Assoc #995 / FSFE Fellow #1797  hkp://keyserver.gingerbear.net  or
     mailto:pgp-public-keys at gingerbear.net?subject=HELP

Q:"Just how do the residents of Haiku, Hawai'i hold conversations?"
A:"An odd melody / island voices on the winds / surplus of vowels"