The way in which SSL is used – the ciphers, the certificate key lengths, the scale – has a profound impact on whether or not “computationally expensive” is an accurate statement or not. And as usual, it’s not just about speed – it’s also about the costs associated with achieving that performance. It’s about efficiency, and leveraging resources in a way that enables scalability.

...

While NIST is not a standards body can require compliance or else, they can and do force government and military compliance and have shown their influence with commercial certificate authorities. All commercial certificate authorities now issue only 2048-bit keys. This increase has a huge impact on the capacity of a server to process SSL and renders completely inaccurate the statement that SSL is not computationally expensive anymore. A typical server that could support 1500 TPS using 1024-bit keys will only support 1/5 of that (around 300 TPS) when supporting modern best practices, i.e. 2048-bit keys.

NIST recommends ephemeral Diffie-Hellman - not RSA - for key exchange, and per TLS 1.0 specification, AES or 3DES-EDE-CBC, not RC4. These ciphers are much less “easy” than RC4 and they are also more computationally intense. Lori also adds that this is not the only issue to consider when architecting an SSL based system:

Certificate Management: the more servers you have, the more certificates you need to deploy. The costs associated with management of those certificates – especially in dynamic environments – continues to rise and the possibility of missing an expiring certificate increase with the number of servers on which certificates are deployed.

Certificate/Security protection : the sensitive nature of keys and certificates and regulatory compliance issues may require hardware-based storage and management of those keys regardless of where they are deployed

Loss of Visibility/Security/Agility: Encrypted traffic cannot be evaluated or scanned threats or routed based on content by any upstream device.

Having a brick and mortar store is a lot more expensive than getting the hardware to do SSL.

As the web gets more and more volatile and business critical, you can't just SSL the login page or the shopping cart: the entire session (on security critical sites of course. Your blog probably doesn't need it) starts needing to to be encrypted.

Get the hardware, even if it means dedicated appliances, and just do it. Yeah, its not free, but doing business isn't cheap. Thats how it worked hundreds of years ago, its how it works today.

The article complains that every last image needs to be encrypted, but what does that have to do with 1024/2048 keys? Those are PKI keys, only used for handshakes. User data is encrypted symmetrically, using much shorter keys.

Am I getting this wrong, or is that article just mixing up symmetric and assymetric key lengths?

If this explains the relationship between the 1024/2048/4096 bit table and the computational load after the handshake (which the article seems to imply), I fail to see it. What's TPS anyway? Do transactions include a handshake? What was measured, and how? There's a lot of talk in that article, but only these numbers to support it, which are not explained.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our architect newsletter?

Subscribe to our industry email notices?

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.