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
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. :)
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.
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.
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.
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.
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.
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
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 :)
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.
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.
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.
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).