2048 bits, damn the electrons! [rt at openssl.org: [openssl.org #2354] [PATCH] Increase Default RSA Key Size to 2048-bits]

[Marsh Ray]

On 09/30/2010 10:41 AM, Thor Lancelot Simon wrote:
> On Wed, Sep 29, 2010 at 09:22:38PM -0700, Chris Palmer wrote:
>>
>> Thor Lancelot Simon writes:
>>> a significant net loss of security, since the huge increase in computation
>>> required will delay or prevent the deployment of "SSL everywhere".
>>
>> That would only happen if we (as security experts) allowed web developers to
>> believe that the speed of RSA is the limiting factor for web application
>> performance.

+1.

Why are multi-core GHz server-oriented CPUs providing hardware 
acceleration for AES rather than RSA?

There may be reasons: AES side channels, patents, marketing, etc..

But if it really were such a big limitation you'd think it'd be a 
feature to sell server chips by now. Maybe in a sense it already is. 
What else are you going to do on that sixth core you stick behind the 
same shared main memory bus?

> At 1024 bits, it is not.  But you are looking at a factor of *9* increase
> in computational cost when you go immediately to 2048 bits.  At that point,
> the bottleneck for many applications shifts, particularly those which are
> served by offload engines specifically to move the bottleneck so it's not
> RSA in the first place.

I could be wrong, but I get the sense that there's not really a high 
proportion of sites which are:

A. currently running within an order of magnitude of maxing out server 
CPU utilization on 1024 bit RSA, and

B. using session resumption to its fullest (eliminates RSA when it can 
be used), and

C. an upgrade to raw CPU power would represent a big problem for their 
budget.

OTOH, if it increased the latency and/or power consumption for 
battery-powered mobile client devices that could be noticeable for a lot 
of people.

> Also, consider devices such as deep-inspection firewalls or application
> traffic managers which must by their nature offload SSL processing in
> order to inspect and possibly modify data before application servers see
> it.  The inspection or modification function often does not parallelize
> nearly as well as the web application logic itself, and so it is often
> not practical to handle it in a distributed way and "just add more CPU".

The unwrapping of the SSL should parallelize just fine. I think the IT 
term for that is "scalability". We should be so lucky that all our 
problems could be solved by throwing more silicon at them!

Well, if there are higher-layer inspection methods (say virus scanning) 
which don't parallelize, well, wouldn't they have the same issue without 
encryption?

> At present, these devices use the highest performance modular-math ASICs
> available and can just about keep up with current web applications'
> transaction rates.  Make the modular math an order of magnitude slower
> and suddenly you will find you can't put these devices in front of some
> applications at all.

Or the vendors get to sell a whole new generation of boxes again.

> This too will hinder the deployment of "SSL everywhere",

It doesn't bother me the least if deployment of dragnet-scale 
interception-friendly SSL is hindered. But you may be right that it has 
some kind of effect on overall adoption.

> and handwaving
> about how for some particular application, the bottleneck won't be at
> the front-end server even if it is an order of magnitude slower for it
> to do the RSA operation itself will not make that problem go away.

Most sites do run "some particular application". For them, it's either a 
problem, an annoyance, or not a noticeable at all. The question is what 
proportion of situations are going to be noticeably impacted.

I imagine increasing the per-handshake costs from, say, 40 core-ms to 
300 core-ms will have wildly varying effects depending on the system. It 
might not manifest as a linear increase of anything that people care to 
measure.

I agree, it does sound a bit hand-wavy though. :-)

- Marsh

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com