Removing Barriers to Encryption: the Need for High-performance SSL

As the recent buzz around Firesheep demonstrated, while SSL is proven, it is not deployed everywhere by default.  Some of the reason behind this includes slow performance and difficulty of implementation.

Slow SSL

One important reason why SSL isn't everywhere is that the initial SSL handshake, which involves public/private key operations, takes many CPU cycles.  With SSL enabled, rather than spending server CPU cycles on the functionality for the end user, CPU cycles are spent on cryptographic operations… and functionality usually trumps security.   

Organizations hosting web sites or running SAAS operations must therefore choose between:

• Slower performance.   SSL enabling a page will cause that page to load more slowly in the browser.  This is a difficult choice since there is a direct correlation between speed of page load and user satisfaction or conversion rate down the funnel.
• Higher infrastructure costs:  Making a corresponding increase in the number of servers in their datacenter to handle the peak load with SSL enabled.  The hardware cost (or increased monthly fee in a hosted or cloud setting) coupled with increased maintenance costs, and increased software costs can be prohibitive. 

 Likewise, organizations building embedded devices or software for RTOS must choose between:
 

• Slower performance. The more SSL is relied upon for connections to other devices or servers, the more CPU cycles it will take, and the greater impact this will have on the speed with which the device performs its intended function.
• Greater battery drain.   
• Higher cost of goods sold, higher weight: Mitigating the effects of SSL's impact can result in more expensive and heavier components in an embedded system. 

 The concern about SSL performance is only growing as NIST and others are recommending organizations increase the key size used with the RSA algorithm in most SSL implementations from 1024bits to 2048bits.  The increase in key size will make SSL handshakes take five times as long – for organizations that do a lot of handshakes, this is a significant performance hit.

Fast SSL

There aren’t a lot of choices in public-key algorithms embedded in SSL libraries. Security Innovation has recently partnered with yaSSL to deliver CyaSSL+, an OpenSSL-comptible SSL library that incorporates the very fast, very small NTRU algorithm. Using this in place of RSA-enabled SSL can improve performance dramatically and we are encouraging users to try it for free under the GPL open source license model. 

CyaSSL fully implements SSL 3, TLS 1.0, 1.1, 1.2, with SSL client libraries, an SSL server, API's, and an OpenSSL-compatibility interface.  It is optimized for embedded and RTOS environments; however, it is also widely used in standard operating environments.  By itself its fast.  CyaSSL's optimized code runs standard RSA asymmetric crypto 4 times faster than openSSL.  As mentioned above, CyaSSL+ adds an additional assymetric algorithm, NTRU.  NTRU is an alternative asymmetric algorithm to RSA and ECC.  It is based on a different math (approximate close lattice vector problem, if you’re interested) that makes it much faster and resistant to quantum computers’ brute force attacks, something both RSA and ECC are susceptible to.

At comparable cryptographic strength, NTRU performs the costly private key operations much faster than RSA.  In fact, CyaSSL+NTRU runs between 20x to 200x faster than openSSL RSA.