RSA key size only affects handshake, and should be costly client side only if 
using client-auth; are you?

 

Data handling speed will normally be affected by encryption *and* MAC (usually 
HMAC).

 

You could certainly try different data (symmetric) cipher, such as 3DES or RC4. 
I don’t know for Atom and ARM 

specifically, but one factor in Rijndael being chosen as AES was good 
performance in software on several CPUs,

so I wouldn’t have high hopes of improvement. 

 

If you have 1.0.1 at both ends, or otherwise have TLSv1.2 at both ends, you 
could try the GCM ciphersuites, 

which combine encryption with MAC into one operation.

 

 

From:  <mailto:owner-openssl-us...@openssl.org> owner-openssl-us...@openssl.org 
[ <mailto:owner-openssl-us...@openssl.org> 
mailto:owner-openssl-us...@openssl.org] On Behalf Of  
<mailto:laurent.boll...@laposte.net> laurent.boll...@laposte.net
Sent: Monday, October 07, 2013 02:05
To:  <mailto:openssl-users@openssl.org> openssl-users@openssl.org
Subject: *** Spam *** openSSL performance

 

Hello,

 

I'm using openSSL on a low-end embedded processor: an Intel Atom running at 
1.1Ghz.

Using SSL divides down my transfer speed by two so I try to figure out how I 
can improve performance.

 

For information I'm using 1.0.1e release, recompiled for Win32 (my embedded 
system uses an XP embedded) with MSVC2010.

I checked the compilation flags and all optimizations are there. I tried asm 
version and no-asm versions but no difference.

 

Still for information, SSL algorithms cipher suite is RSA (with 4096 bits key) 
for authentication, AES256 for transfer. I know that key length influences 
protocol negociation before the actual transfer, but I'm implementing a 
proprietary file transfer protocol over TCP that does not require continuous 
disconnect/reconnect phases: only one connection is enough therefore slowdown 
is rather due to data encryption rather than key exchange.

 

Do you have any advice, whether it can be related to compiler configuration, 
protocol choice for transmission, anything else than specific code tuning for 
Intel Atom ? Eventually that protocol will run also on ARM-based platforms so 
I'd rather avoid doing anything specific for a given architecture if I can 
avoid it...

 

 

Thanks in Advance

 

 



 <http://www.laposte.net/Archiver/index.jsp> 
http://webmail.laposte.net/webmail/fr_FR/panels/images/Pied_de_Mail_DGP.gif

<<image001.gif>>

Reply via email to