8192+ bit RSA keys in OS X | Hacker News Reader

8192+ bit RSA keys in OS X

shizmob.tumblr.com

72 pointsrobbiet48031 comments

8192 bit RSA key is one or two notches above overkill. 2048 is expected to last many more decades, and I haven't seen 4096 outside tin-foil hat environments. I know our national root certification authority uses 4096, for example.

I propose such a key actually decreases security because it is less compatible with existing software, training the users to further ignore warnings or dangerously tinker with their security settings.

Which one is more likely? NSA being able to break 4096 keys, but not 8192, or your user accepting an invalid certificate because "the key is probably just too big", or "it drains too much battery"? Which one will have more impact down the line?

Besides, if you are worried about such sophisticated attackers, your priority should be securing side channels and protecting yourself from rubber-hose cryptanalysis (http://en.wikipedia.org/wiki/Rubber-hose_cryptanalysis).

It's extravagant, and doesn't provide meaningful security. How much do you pay the armed guards that stand watch over your laptop 24/7?

"Using encryption on the Internet is the equivalent of arranging an armored car to deliver credit card information from someone living in a cardboard box to someone living on a park bench." — Gene Spafford

(Hat tip to schoen: http://www.loyalty.org/~schoen/rsa/)

Surely Spaf has recanted by now.

If I read this recent (post-Snowden) blog post of spaf's correctly, he hasn't: https://www.cerias.purdue.edu/site/blog/post/just_sayin/

Though he notes that his armored car quip is approaching 20 years old, dating back to the dark days of Windows 95. Perhaps the better way to think about it is: encryption is necessary but not sufficient. If the NSA has extruded its tentacles into sufficient endpoints (operating systems? firmware? antivirus software?) that's a problem that encryption won't by itself solve.

Hey, I'm channeling RMS: free software is the real solution! Unless the NSA's tentacles extend to the compiler you use to compile the free software. :)

Or, channeling Ken Thompson: Unless the tentacles extend to the compiler you use to compile the compiler you use to compile the free software.

(Lather. Rinse. Repeat.)

Source for 2048 being good for "many more decades"? I thought it was getting close (10 years?) to the point where you might not want to use it, particularly without PFS setup, for anything requiring long-term use.

The http://www.keylength.com website mentions various standards suggesting key lengths. For example, from ECRYPT II Recommendations (2012) there's a mention of 2432 bit giving reasonable protection up to the year 2030.

There's also a nice answer on the crypto stack exchange: http://crypto.stackexchange.com/a/1982

Reviewing the sources, I admit "many more decades" might be an overestimation, maybe "a couple decades" would be a more accurate statement.

Still, the current factorization record is only 768 bit, and even the lowly 1024 bit key is orders of magnitude stronger than that.

What is the relative cost in cpu/memory of encrypting with 8192 bit vs. 2048 bit RSA?

According to the article, it ranges from 16x more time-complex to 256x more time-complex, depending on what you're doing with it.

This is a good analysis as well: http://security.stackexchange.com/questions/41937/pgp-rsa-ke...

Note that with HTTPS, the actual data is not encrypted with the RSA keys. They are only used to negotiate a shared symmetric key, with which everything is encrypted. So it's only the initial handshake that takes longer.

It's also pointless because there are top-level CAs that use smaller keys. Hence if your key is bigger, hackers would go after the smaller and easier-to-factorise keys, gaining you nothing.

Indeed, there are still 21 CA certs in debian ca-certificates with 1024-bit keys. Deploying anything stronger for endpoint keys is a tremendous waste of computation.

Only if your certificate is going to expire before those 21 do.

Good point. Here are the expiration dates for the 21 certs:

  Not After : Jan 14 16:29:17 2007 GMT
  Not After : Aug 13 23:59:00 2018 GMT
  Not After : Aug 22 16:41:51 2018 GMT
  Not After : Dec  9 19:47:26 2018 GMT
  Not After : Dec 10 18:40:23 2018 GMT
  Not After : Feb 20 14:08:11 2019 GMT
  Not After : Feb 20 14:10:22 2019 GMT
  Not After : May 25 16:39:40 2019 GMT
  Not After : Jun 23 12:14:45 2019 GMT
  Not After : Jun 25 22:23:48 2019 GMT
  Not After : Jun 26 00:19:54 2019 GMT
  Not After : Jun 26 00:22:33 2019 GMT
  Not After : Jun 21 04:00:00 2020 GMT
  Not After : Jun 21 04:00:00 2020 GMT
  Not After : Dec 31 23:59:59 2020 GMT
  Not After : Dec 31 23:59:59 2020 GMT
  Not After : Aug  1 23:59:59 2028 GMT
  Not After : Aug  1 23:59:59 2028 GMT
  Not After : Aug  1 23:59:59 2028 GMT
  Not After : Aug  2 23:59:59 2028 GMT
  Not After : Aug  2 23:59:59 2028 GMT

It's somewhat surprising that one of the certificates has already expired, but is still in ca-certificates.

This is false. 2048 bit is expected to last only 6 more years by cautious projections, and only until 2030 by conservative projections:

    Method          Date      Symmetric Asymmetric  Discrete Key    Logarithm Group Elliptic Curve  Hash
    Lenstra/Verheul 2023       88       2054 1632   155             2054            166             175
    Lenstra Updated 2030       88       1698 2063   176             1698            176             176
    ECRYPT II       2016-2020  96       1776        192             1776            192             192
    NIST            2011-2030 112       2048        224             2048            224             224
    ANSSI           2010-2020 100       2048        200             2048            200             200
    RFC3766         -         103       2056        206             2056            192             -
    BSI (sig. only) > 2020    -         1976        256             2048            250             256

Source: http://www.keylength.com/

I agree that 8192 is overkill. GNUtls 3.0.28: certtool -p --sec-param=high comes out to 3248 bits.

Is he going to have to tell everyone who uses these affected versions of OS X to run these commands / change these preferences in order to view his site? This is much worse than he expressly states... How many people are going to put in the effort to contact the site author, or investigate the error, instead of writing off the site entirely? My takeaway from this is not to update a machine to be able to view a site with large certificates, it is to not use large certificates until Apple releases a fix for this.

For reference, this is how fast OpenSSL is with various key sizes on my Core i5, 2.6GHz:

                      sign    verify    sign/s verify/s
    rsa  512 bits 0.000192s 0.000014s   5209.8  72185.6
    rsa 1024 bits 0.000909s 0.000037s   1100.4  27318.3
    rsa 2048 bits 0.004911s 0.000109s    203.6   9180.2
    rsa 4096 bits 0.030147s 0.000413s     33.2   2419.1

Thanks for posting this. I've always wondered what the numbers were. 4096 bits does appear to add a significant work factor.

Extrapolating a bit, the numbers for 8kb keys should be about 5 sign/sec, 500 verify/sec.

Note that iOS has the same issue, except there's no way to change the relevant setting (AFAIK), and in general 8k keys are likely to be prohibitively slow on mobile.

Alternatively one could use Elliptic Curve Cryptography to mitigate potential DOS issues as it less computationally intensive. For example a 409 ECC key is equivalent to a 7680 RSA key. For more on this read "ECC Cipher Suites for TLS", RFC 4492. http://www.ietf.org/rfc/rfc4492.txt

Be sure to take note of which curves to use as only some are supported by the TLS standard: http://stackoverflow.com/questions/16334662/some-elliptic-cu...

So what's the actual limit it is set to by default? If I get a certificate, I'm not exactly going to tell everyone to run a sudo command before opening the site :)

Just looked, couldn't even find the file.

/Library/Preferences/com.apple.security

OSX 10.9

com.apple.security isn't a file, it's a preferences domain. Preference domains are stored in ~/Library/Preferences/<domain>.plist for per-user domains, and /Library/Preferences/<domain>.plist for system domains. In this case, it's stored in /Library/Preferences/com.apple.security.plist.

If a preferences domain doesn't exist (or if the key doesn't exist within the domain), the app or system default is used.

4096 according to the code linked to in the article - http://opensource.apple.com/source/Security/Security-55471/l...

I noticed the Certificate Assistant UI in Keychain Access only lets you choose as high as 2048 bits if you're generating certs that way.

Too funny -- I just went through this same exercise to see what the limits were and figured nobody would actually care about it since > 2048 bits is a little bit crazy.

I also found that TLS1.2 is not supported in Mail.app on Mavericks, even though it is supported in Safari. I wanted to see if I could enable TLS1.2-only AES-GCM on everything and quickly found the SMTP/IMAP TLS support is lacking.

Annoyingly, StartSSL doesn't support ECDSA (well say they are less than the required 1024 bits, which they are but are more secure comparably).

Doesn´t it take 10^100 universes to crack 8192 bit RSA?

> Doesn´t it take 10^100 universes to crack 8192 bit RSA?

That's easy to test:

a = 2^8192 ≅ 1.09 * 10^2466 (http://www.wolframalpha.com/input/?i=2%5E8192)

b = 10^100 universes

If we assume one universe can only crack one value, then we need many more than 10^100 universes. But it's reasonable to assume that one universe can crack more than one encrypted value. Let's say that each universe can crack a million values. Then 10^100 universes is too many.

Reply on news.ycombinator.com