Measuring SSL performance: RSA keys

[nailer]

https://certsimple.com/blog/measuring-ssl-rsa-keys

[nailer]

Author here. Hope this is useful: not so much for my own results, but for the techniques you can use to measure this on your own infrastructure.

For example, the distance between your clients and your datacenters will have a large impact on your handshake latency.

[sandstrom → nailer]

Cool service, I'll likely use it for our next EV.

Some thoughts:

1. Add details on re-issuing. Heartbleed, sha1 -> sha2, etc. It happens now and then. Useful to know if there is a charge etc.

2. Mention Certificate Transparency (I guess you are covered here, if you use DigiCert).

3. Pricing on adding multiple names to a multi-domain EV, e.g. 5 or 10.

[nailer → sandstrom]

Thanks Sandstrom! All excellent suggestions, I'll post back here when they're complete. FYI reissuing is free, but I'll add that (and details) to the FAQ.

[sandstrom → nailer]

Also, I'd consider changing the name. It took me a mere ~10 min to forget the domain, and I tried googling simple cert only to end on `simplecert.co`.

Could be my bad memory, but perhaps there is another name, that would be more memorable? Your current is a mix of two pretty generic words -- it's reminds me of General Atlantic[1], only that you'd like yours to actually be memorable :)

[1] https://www.quora.com/How-did-General-Atlantic-Partners-get-...

[nailer → sandstrom]

I'll consider it - I do like CertSimple - there's BankSimple for banking (though they're now just Simple) and DNSimple for DNS, and also: the domain was available! That said, if you think of anything better feel free to email me - mike@certsimple.com

[xyzzy123 → nailer]

So GNFS is actually a factoring algorithm. Lenstra's estimates of RSA strength are based on the expected runtime of that algorithm.

So it's kind of misleading to say that you implemented GNFS for node. You implemented a node module which outputs a GNFS complexity estimate in bits.

[nailer → xyzzy123]

You're right, it's the complexity of the GNFS, not the GNFS - I'll correct that part of the article & the module README - thanks xyzzy123.

[CHY872]

Who actually needs the extra security? 112 bits of security is enough for everyone, bar none. If you have a 2^32 processors and they can crack 32 bits of encryption every second (unreasonable in each case), then it's still going to take you 9 million years before you can crack it.

If someone finds a new attack, it'd invalidate that number, but it could just as easily break any RSA based system, and it's not thought that such an attack is on the horizon at the moment (I think), or known by any entity (government or otherwise).

Meanwhile the performance difference is measurable and considerable; it's 10% of your loadtime if you're targeting 250ms.

I don't get why people set their security levels so high at all; it's like getting alien abduction insurance or downloading a bootlegged film in uncompressed AVI.

[nailer → CHY872]

I think that 'whatever breaks 2048 bit RSA will also likely break 4096 bit RSA' is pretty reasonable. I know at least one person using 4096 bit just for the SSL Labs score.

That said, do measure this on your own kit, particularly for SSL handshake latency: eg latency caused by additional CPU work during handshaking will likely be worse on a mobile site. Or someone might be reading this in 2019 and handshaking performance has increased significantly.

[jhh]

Seems very balanced and well argued.