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

[Chris Palmer]

Thor Lancelot Simon writes:

> > believe that the speed of RSA is the limiting factor for web application
> 
> 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.

In my quantitative, non-hand-waving, repeated experience with many clients in
many business sectors using a wide array of web application technology
stacks, almost all web apps suffer a network and disk I/O bloat factor of 5,
10, 20, ...

There are these sites where page-loads incur the creation of 30 TCP
connections. Pages have 20 tiny PNGs for navigation elements, all served
over non-persistent HTTP connections with the Cache-Control: header set to
no-cache. Each page view incurs a re-load of these static images. Take a
look at those images: why are they 35KB each? Oh, they have unoptimized
color palettes and 500 bytes of worthless comments and header junk and
actually they are twice as large as they appear on screen (the developer
shrinks them on the page with height= and width= attributes). To speed up
page loads, they serve the images from 10 distinct hostnames (to trick the
browser into parallelizing the downloads more). "What's spriting?"

How long does it take the browser to compile your 500KB of JavaScript? To
run it?

Compression is not turned on. The database is choked. The web is a front-end
for an oversubscribed and badly-implemented SOAP service. (I've seen backend
messaging services where the smallest message type was 200KB.) The 80KB
JavaScript file contains 40KB of redundant whitespace and is
dynamically-generated and so uncacheable. (I usually find a few XSS bugs
while I'm at it --- good luck properly escaping user data in the context of
arbitrary JavaScript code, but never mind that...)

The .NET ViewState field and/or the cookies are huge, like 20KB (I've seen
100KB) of serialized object state. It seems fine in the office, but from
home on my asymmetric cable line, performance blows --- it takes too long to
get the huge requests to the server! And yeah, your 20 PNGs are in the same
domain as your cookie, so that huge cookie goes up on every request. Oops...

I'm sure Steven's friend is competent. A competent web developer, or a
competent network architect? I have indeed seen this 12x cost factor before.
Every single time, it was a case where nobody knew the whole story of how
the app works. (Layering and encapsulation are good for software designs,
but bad for people.) Every single time, there were obvious and blatant ways
to improve page-load latency and/or transaction throughput by a factor of 9
or 12 or more. It translates directly into dollars: lower infrastructure
costs, higher conversion rates. Suddenly SSL is free.

I'm still fully with you; it's just that of all the 9x pessimalities, the
I/O ones matter way more.

Recommended reading:

http://oreilly.com/catalog/9780596529307

http://gmailblog.blogspot.com/2008/05/need-for-speed-path-to-faster-loading.html

"""...a popular network news site's home page required about a 180 requests
to fully load... [but for Gmail] it now takes as few as four requests from
the click of the "Sign in" button to the display of your inbox"""

Performance is a security concern, not just for DoS reasons but because you
have to be able to walk the walk to convince people that your security
mechanism will work.


The concern about the impact of 2048-bit RSA on low-power devices is
well-placed. But there too, content-layer concerns dominate overall, perhaps
even moreso.

Again, I'm not waving hands: I've measured. You can measure too, the tools
are free.


-- 
http://noncombatant.org/

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