>Ann & Lynn Wheeler wrote: > the original requirement for SSL deployment was that it was on from the > original URL entered by the user. The drop-back to using SSL for only small > subset ... was based on computational load caused by SSL cryptography .... in > the online merchant scenario, it cut thruput by 90-95%; alternative to handle > the online merchant scenario for total user interaction would have required > increasing the number of servers by factor of 10-20. > > One possibility is that the institution has increased the server capacity ... > and/or added specific hardware to handle the cryptographic load.
Moore's law helped immensely here. In the last 5 years systems have gotten about 8 times faster, reducing the processing cost of crypto a lot. I'm familiar with one site that has 24 servers evenly divided across three geographical areas. To entirely SSL-enable their site required only one new server at each site. Meanwhile, load-balancing SSL terminator/accelerators have improved even faster due to improvements in load-balancing, network compression, etc. So putting one of them in front of a previously naïve load-balancing scheme, like basic round-robin would provide enough offloading to SSL-enable an entire site. The big drawback is that those who want to follow NIST's recommendations to migrate to 2048-bit keys will be returning to the 2005-era overhead. Dan Kaminsky provided some benchmarks in a different thread on this list  that showed 2048-bit keys performing at 1/9th of 1024-bit. My own internal benchmarks have been closer to 1/7th to 1/8th. Either way, that's back in line with the above stated 90-95% overhead. Meaning, in Dan's words "2048 ain't happening." There are some possibilities, my co-workers and I have discussed. For purely internal systems TLS-PSK (RFC 4279) provides symmetric encryption through pre-shared keys which provides us with whitelisting as well as removing asymmetric crypto. Or, possibly stepping up the key-size in accordance with Moore's law, which would take several years to reach 2048-bit, but each time a certificate expired the new certificate could be issued with the next higher keylength. Besides, I think we all know that NIST's 2010 algorithm transaction isn't going to happen on schedule. At the IEEE key management summit back in May (IIRC) Elaine Barker from NIST presented a back-off talk in which NIST only "strongly recommends" 110-bit security by 2011, and pushes the real deadline out to the end of 2013. That was subsequently released as a draft SP800-131; available for comments  Of course, the industry had five years to plan for this, and no major vendors seem to be ready. Most comments are essentially vendors sighing with relief.  http://email@example.com/msg11245.html  http://csrc.nist.gov/publications/drafts/800-131/draft-sp800-131_spd-june2010.pdf Eric Lengvenis InfoSec Arch. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com