[145936] in cryptography@c2.net mail archive
Re: 2048 bits, damn the electrons! [rt@openssl.org: [openssl.org #2354] [PATCH] Increase Default RSA Key Size to 2048-bits]
daemon@ATHENA.MIT.EDU (Steven Bellovin)
Thu Sep 30 20:44:55 2010
From: Steven Bellovin <smb@cs.columbia.edu>
In-Reply-To: <20100930154118.GA23692@panix.com>
Date: Thu, 30 Sep 2010 12:02:26 -0400
Cc: cryptography@metzdowd.com
To: Thor Lancelot Simon <tls@rek.tjls.com>
On Sep 30, 2010, at 11:41 18AM, Thor Lancelot Simon wrote:
> On Wed, Sep 29, 2010 at 09:22:38PM -0700, Chris Palmer wrote:
>> Thor Lancelot Simon writes:
>>=20
>>> a significant net loss of security, since the huge increase in =
computation
>>> required will delay or prevent the deployment of "SSL everywhere".
>>=20
>> 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.
>=20
> 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.
>=20
> 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=20
> 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".
>=20
> 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.
>=20
> This too will hinder the deployment of "SSL everywhere", 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.
>=20
While I'm not convinced you're correct, I think that many posters here
underestimate the total cost of SSL. A friend of mine -- a very =
competent
friend -- was working on a design for a somewhat sensitive website. He
really wanted to use SSL -- but the *system* would have cost at least =
12x
as much. There were many issues, but one of them is that the average =
dwell
time on a web site is very few pages, which means that you have to =
amortize
the cost of the SSL negotiation over very little actual activity. =20
>=20
--Steve Bellovin, http://www.cs.columbia.edu/~smb
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
