[openssl-users] Openssl Performance with and without Cryptodev
Hi Team, I want to test openssl performance with and without using cryptodev driver.I tried 2 things but my both cases are fluctuating. *1. Openssl speed test with and without HW* When i am running openssl speed test using the below command, openssl speed -evp aes-128-cbc *I am getting outstanding improved performance difference in openssl while using with the cryptodev engine*.Below are the the numbers. Without Cryptodev === The 'numbers' are in 1000s of bytes per second processed. 64B Bytes = 27056.32k 256 Bytes = 28244.65k 1024 Bytes = 28558.34k 8192 Bytes = 28639.23k With Cryptodev === The 'numbers' are in 1000s of bytes per second processed. 64B Bytes = 77508.52k 256 Bytes = 428194.13k 1024 Bytes = 1285770.97k 8192 Bytes = 32507084.80k *2. Openssl encryption test with and without HW* I tried running this openssl command on my box: date ; cat bigfile | openssl enc -e -aes-128-cbc -bufsize 8192 -pass pass:testing123 /dev/null ; date where 'bigfile' is some large file of 2 GB in size. Then i rerun it using date ; cat bigfile | openssl enc *-engine cryptodev* -e -aes-128-cbc -bufsize 8192 -pass pass:testing123 /dev/null ; date and compare the results of the dates of 'before' and 'after'. Below are the results i got. *Without HW it takes 4secs only. **with cryptodev it takes 3min 15 secs* Looks like in *first case cryptodev is increasing the performance but in second case it is decreasing it.* If some body knows this issue,can you please point me to the source code path where i can tweak something to improve performance with cryptodev case. I am using below versions of the sources. *OpenSSL 1.0.1g 7 Apr 2014* *Cryptodev 1.6 version* Please help me on this. Thanks Rahul Arora ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL performance issue
From: openssl-users On Behalf Of Michael Wojcik Sent: Thursday, December 18, 2014 21:27 From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Kurt Roeckx Sent: Thursday, December 18, 2014 16:36 To: openssl-users@openssl.org Subject: Re: [openssl-users] OpenSSL performance issue So the differnce here is that jave picks a DHE ciphersuite while otherwise you didn't. DHE gives you forward secrecy but is slower. And if DH parameters have not been set, OpenSSL will have to generate them on the fly, which can be *very* slow (relative to normal conversation establishment). I think this is new in trunk; in all released versions of OpenSSL server it won't use DHE/A and or ECDHE/A if parameters have not been set. And the case here is OpenSSL client to Java proxy acting as server. JSSE server uses hardcoded parameters, from some standard -- I vaguely recall it being Oakley but don't remember details. ___ openssl-users mailing list openssl-users@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL performance issue
From: openssl-users On Behalf Of Kurt Roeckx Sent: Thursday, December 18, 2014 16:36 On Fri, Dec 19, 2014 at 02:30:07AM +0530, Prabhat Puroshottam wrote: *** This is for *Client - Agent* *** [...] Version 3.1 [...] cipherSuite TLS_RSA_WITH_AES_256_CBC_SHA [...] *** This is for *Client - Proxy Server* *** cipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA So the differnce here is that jave picks a DHE ciphersuite while otherwise you didn't. DHE gives you forward secrecy but is slower. Good catch, I missed that. But, it shouldn't be many *seconds* unless this is very poor hardware. Especially since Java 7 (and IIRC 6) uses, as you can see later in the trace, 768 bits. (Except export suites use 512 per RFC. Java 8 defaults DHE to 1024 and offers some new options for better.) Although that reminds me, on the *first* session in a process, there might be delay to initialize SecureRandom, depending on the platform and options/environment. But not for all sessions. To OP: assuming this delay happens on non-initial sessions more than rarely, can you try putting jconsole or the newer (but more complicated) Java Mission Control tools on the JVM running the proxy server while driving it with as many requests as you can, to get some (rough) idea what's going on: is it CPU bound? which threads? if you can capture stacks, which methods? Is it swapping? One other thought: normally JSSE server uses a key manager that is preloaded from a JKS. Are you using an unusual key manager like a PKCS#11 token, or even a custom one that does something costly like fetching from LDAP? You're also not using session resumption which might speed up the whole process. It at least looks like that proxy server might support that. I assumed OP's traces are the first session. Besides OpenSSL client doesn't cache by default; you must code to enable it. You also seem to be using an old version of openssl that only supports TLSv1, I suggest you upgrade. Good in general, but very unlikely to change JSSE-server performance. ___ openssl-users mailing list openssl-users@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL performance issue
On 19/12/2014 00:10, Prabhat Puroshottam wrote: I am trying to summarize the problem again, since the previous mail seems confusing to some of you. It might help you quickly understand the problem I am facing: We have a product, where Client connects to Server (Proxy Server in my earlier mail). Client is implemented in C and uses OpenSSL, while Server is implemented using Java code with BufferedInputStream and BufferedOutputStream. The following are my observations: 1. There is inordinate delay during connection establishment. 2. Using ssldump it was found that SSL handshake response from Server is taking most of the time. Rest of the application data transfer and processing hardly takes fraction of a second. The response from SSL handshake by Server comes after anywhere between 2 to 13 seconds after initial response sent by Client. 3. Subsequent analysis of the code showed that it was the first Buffered Read/Write which was taking inordinate amount of time. 4. Understanding that first Buffered Read/Write was hung on SSL connection completion, I introduced SSLConnect::startHandshake() so that I can explicitly see where is the problem. It was observed that now startHandshake() blocked for as much time as first Read/Write did. Further none of the Read/Write calls block, and returned data almost immediately. I would like to understand why startHandshake() is taking so long. I understand that it is a asynchronous call, but still the time delay is too much IMO. Is it something to do with the socket configuration/cipher/encryption used? Using ssldump I found there was absolutely no data transfer between the sending of client's hello request and subsequent response from server, so apparently all the time startHandshake() is busy doing something or may be nothing - what I have no idea. FWIW, this is not a network latency issue, 1) all the boxes are on the same network, 2) all other data transfers combined takes less than 0.4s. Can somebody kindly suggest what might be wrong or what can be done to fix this? Could it be some Socket or SSL setting, encryption/cipher used, or something else? From the traces in your previous questions, and the answers you have already given, I guess this is what happens: 1. The difference is in how long the Java code spends during the initial key exchange. 2. The SSL code in the proxy, (but not the one in your own server) is configured to support Ephemeral Diffie-Hellman (DHE) handshake, which is safer, but potentially slower. The slowness of DHE happens only during the handshake, because the data transmission part is the same. For example RSA_AES256_SHA256 and DHE_RSA_AES_SHA256 use the same transmission phase, but different handshakes. The safety of DHE is that it protects you if someone tapes the encrypted connection and later steal the private key of the proxy/server. 3. The slowest part of doing a DHE exchange is choosing a (non-secret) prime, which can be used again and again for many connections. This is only done by the server end of a TLS/SSL connection. The prime (and a few related numbers is known as the DH group parameters. 4. If you were to enable DHE in an OpenSSL based server/proxy, the standard solution is to choose the non-secret prime during server startup, before any connection arrives. Some programs even choose it while configuring the server program, storing the prime in a file. 5. From the long time spent by the Java code generating its ServerHello, I suspect it is generating the prime during the handshake, and choosing a new prime for each connection, thus wasting a lot of time. 6. Maybe there is a way to tell the Java SSL library to generate the DH group parameters for needed key lengths (1024, 2048 or whatever you need) during proxy startup, so it is ready by the time the client connects. 7. If you upgrade to OpenSSL 1.0.1 or later (remember to only use the latest letter-suffix security update of whatever version), you could also use an ECDHE_RSA_xxx crypto mode, these don't currently allow the server/proxy to generate their own group parameters, but force you to choose from a short list of parameters generated by professional spying agencies such as the NSA (the NIST curves) or someone else (the X9.62 curves, the SECG curves and the WTLS curves). So your computers don't spend time generating the parameters, and you just have to trust the professionals who chose them for you. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ openssl-users mailing list openssl-users@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL performance issue
On 19/12/2014 12:11, Jakob Bohm wrote: On 19/12/2014 00:10, Prabhat Puroshottam wrote: I am trying to summarize the problem again, since the previous mail seems confusing to some of you. It might help you quickly understand the problem I am facing: We have a product, where Client connects to Server (Proxy Server in my earlier mail). Client is implemented in C and uses OpenSSL, while Server is implemented using Java code with BufferedInputStream and BufferedOutputStream. The following are my observations: 1. There is inordinate delay during connection establishment. 2. Using ssldump it was found that SSL handshake response from Server is taking most of the time. Rest of the application data transfer and processing hardly takes fraction of a second. The response from SSL handshake by Server comes after anywhere between 2 to 13 seconds after initial response sent by Client. 3. Subsequent analysis of the code showed that it was the first Buffered Read/Write which was taking inordinate amount of time. 4. Understanding that first Buffered Read/Write was hung on SSL connection completion, I introduced SSLConnect::startHandshake() so that I can explicitly see where is the problem. It was observed that now startHandshake() blocked for as much time as first Read/Write did. Further none of the Read/Write calls block, and returned data almost immediately. I would like to understand why startHandshake() is taking so long. I understand that it is a asynchronous call, but still the time delay is too much IMO. Is it something to do with the socket configuration/cipher/encryption used? Using ssldump I found there was absolutely no data transfer between the sending of client's hello request and subsequent response from server, so apparently all the time startHandshake() is busy doing something or may be nothing - what I have no idea. FWIW, this is not a network latency issue, 1) all the boxes are on the same network, 2) all other data transfers combined takes less than 0.4s. Can somebody kindly suggest what might be wrong or what can be done to fix this? Could it be some Socket or SSL setting, encryption/cipher used, or something else? From the traces in your previous questions, and the answers you have already given, I guess this is what happens: 1. The difference is in how long the Java code spends during the initial key exchange. 2. The SSL code in the proxy, (but not the one in your own server) is configured to support Ephemeral Diffie-Hellman (DHE) handshake, which is safer, but potentially slower. The slowness of DHE happens only during the handshake, because the data transmission part is the same. For example RSA_AES256_SHA256 and DHE_RSA_AES_SHA256 use the same transmission phase, but different handshakes. The safety of DHE is that it protects you if someone tapes the encrypted connection and later steal the private key of the proxy/server. 3. The slowest part of doing a DHE exchange is choosing a (non-secret) prime, which can be used again and again for many connections. This is only done by the server end of a TLS/SSL connection. The prime (and a few related numbers is known as the DH group parameters. 4. If you were to enable DHE in an OpenSSL based server/proxy, the standard solution is to choose the non-secret prime during server startup, before any connection arrives. Some programs even choose it while configuring the server program, storing the prime in a file. 5. From the long time spent by the Java code generating its ServerHello, I suspect it is generating the prime during the handshake, and choosing a new prime for each connection, thus wasting a lot of time. Dave Thompson (who knows more than I do) pointed out that if this is the SSL library included with Oracle Java, then it doesn't do that, but it does waste time on another operation (random number generator setup), which is the same for all handshake methods. 6. Maybe there is a way to tell the Java SSL library to generate the DH group parameters for needed key lengths (1024, 2048 or whatever you need) during proxy startup, so it is ready by the time the client connects. If the problem is really initializing the Java secure random number generator, you could probably force it to initialize earlier by simply adding Java code that asks for one byte of cryptographically strong bits, then throws it away, thus forcing the Java runtime to initialize its random number library at that time (before the connection arrives). 7. If you upgrade to OpenSSL 1.0.1 or later (remember to only use the latest letter-suffix security update of whatever version), you could also use an ECDHE_RSA_xxx crypto mode, these don't currently allow the server/proxy to generate their own group parameters, but force you to choose from a short list of parameters generated by professional spying agencies such as the NSA (the NIST curves) or someone else (the
Re: [openssl-users] OpenSSL performance issue
On Fri, Dec 19, 2014 at 02:30:07AM +0530, Prabhat Puroshottam wrote: As you can see the big time difference between the two executions - which actually involve the same application level data. The largest chunk of time is spent waiting for handshake from *Proxy Server*. The response time of *Proxy Server* in replying back with ServerHello, varies greatly between 1.5 to 11 seconds across different runs. In the present case it is nearly 3.3 seconds - which IMO is not acceptable. Is Client providing a certicate? Perhaps Proxy is spending time checking CRLs. That would involve Proxy reaching out to one or more URLs, with the attendant latencies of DNS resolution, TCP session setup, and HTTP requests. Do you have any intrumentation showing you what activity Proxy is doing between ClientHEllo and ServerHello? Thanks, for reading through such a lengthy email. If anybody can kindly provide his inputs, or even point me in the right direction, I shall be highly grateful. Any other comments or suggestions are also highly welcome. Thanks for your patience, ? Prabhat. ___ openssl-users mailing list openssl-users@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-users -- Brian Reichert reich...@numachi.com BSD admin/developer at large ___ openssl-users mailing list openssl-users@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL performance issue
On 19/12/14 15:17, Brian Reichert wrote: On Fri, Dec 19, 2014 at 02:30:07AM +0530, Prabhat Puroshottam wrote: As you can see the big time difference between the two executions - which actually involve the same application level data. The largest chunk of time is spent waiting for handshake from *Proxy Server*. The response time of *Proxy Server* in replying back with ServerHello, varies greatly between 1.5 to 11 seconds across different runs. In the present case it is nearly 3.3 seconds - which IMO is not acceptable. Is Client providing a certicate? Perhaps Proxy is spending time checking CRLs. That would involve Proxy reaching out to one or more URLs, with the attendant latencies of DNS resolution, TCP session setup, and HTTP requests. Client certificates are not provided as part of the ClientHello, so I don't think this is the problem. Matt ___ openssl-users mailing list openssl-users@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL performance issue
On Fri, Dec 19, 2014, Dave Thompson wrote: From: openssl-users On Behalf Of Michael Wojcik Sent: Thursday, December 18, 2014 21:27 From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Kurt Roeckx Sent: Thursday, December 18, 2014 16:36 To: openssl-users@openssl.org Subject: Re: [openssl-users] OpenSSL performance issue So the differnce here is that jave picks a DHE ciphersuite while otherwise you didn't. DHE gives you forward secrecy but is slower. And if DH parameters have not been set, OpenSSL will have to generate them on the fly, which can be *very* slow (relative to normal conversation establishment). I think this is new in trunk; in all released versions of OpenSSL server it won't use DHE/A and or ECDHE/A if parameters have not been set. I'm not aware of any version of OpenSSL that generates DH parameters on the fly. If no DH parameters are set then ephemeral DH ciphersuites are disabled. It's a similar story for ECDH. OpenSSL 1.0.2+ supports auto ECDH which will look up ECDH parameters on the fly but that's just look up which is a cheap operation. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ___ openssl-users mailing list openssl-users@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL performance issue
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Dr. Stephen Henson Sent: Friday, December 19, 2014 11:37 To: openssl-users@openssl.org Subject: Re: [openssl-users] OpenSSL performance issue On Fri, Dec 19, 2014, Dave Thompson wrote: From: openssl-users On Behalf Of Michael Wojcik Sent: Thursday, December 18, 2014 21:27 And if DH parameters have not been set, OpenSSL will have to generate them on the fly, which can be *very* slow (relative to normal conversation establishment). I think this is new in trunk; in all released versions of OpenSSL server it won't use DHE/A and or ECDHE/A if parameters have not been set. I'm not aware of any version of OpenSSL that generates DH parameters on the fly. If no DH parameters are set then ephemeral DH ciphersuites are disabled. It's a similar story for ECDH. OpenSSL 1.0.2+ supports auto ECDH which will look up ECDH parameters on the fly but that's just look up which is a cheap operation. Thanks for the correction. There's a comment somewhere in our OpenSSL-invoking code about DH parameters being generated on the fly, but I guess that was based on a misunderstanding. (The code actually sets DH parameters; the comment was something along the lines of we want to do this to avoid possible runtime delays when using DH suites.) -- Michael Wojcik Technology Specialist, Micro Focus This message has been scanned for malware by Websense. www.websense.com ___ openssl-users mailing list openssl-users@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
[openssl-users] OpenSSL performance issue
Hi, I think my last email was somehow lost in transition between the mail servers so I am starting afresh if somebody can help. If you have already taken pains to read through this mail, kindly skip to the bottom of the mail. Thanks for your patience. First let me state upfront that I am relatively very new to OpenSSL. Also please forgive me if this is not the correct mailing list for this issue. We have a product which uses OpenSSL to connect and transfer application level data. There are two ways to connect, and get the application level data from *Agent* to *Client* 1. Client (C/C++) - Agent (C/C++) 2. Client (C/C++) - Proxy Server (Java) - Agent (C/C++) *Client* and *Agent* are implemented in C, while *Proxy Server* uses Java code (This shouldn't really matter). But might be helpful for you to know. The issue is, connecting *Client* to *Agent* is very fast (that is relatively). While connecting *Client* to *Proxy Server* is very slow - that is orders of magnitudes slow. I was trying to determine the root cause. From my analysis is appears that, maximum time on the *Client* side is taken by SSL_Connect during connection establishment, while the actual application level data transfer takes very small time. Similarly, on the *Proxy Server* side (Java Code), maximum time is taken in the first read/write whichever happens first. Further, I don't think this is a network latency issue, as the problem is very pronounced and all the three boxes are on the same network. Also, the *Client* code seems to be similar, whether we connect to *Agent* (method 1 above) or *Proxy Server* (method 2 above). So, the issue is with *Proxy Server*, IMHO. To further locate the issue, I did some tests using ssldump command, *** This is for *Client - Agent* *** 1 1 0.0023 (0.0002) CS Handshake ClientHello Version 3.1 cipher suites TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_IDEA_CBC_SHA TLS_RSA_WITH_RC4_128_SHA Unknown value 0xff compression methods NULL 1 2 0.0091 (0.0068) SC Handshake ServerHello Version 3.1 session_id[0]= cipherSuite TLS_RSA_WITH_AES_256_CBC_SHA compressionMethod NULL 1 3 0.0091 (0.) SC Handshake Certificate 1 4 0.0091 (0.) SC Handshake CertificateRequest certificate_types rsa_sign certificate_types dss_sign ServerHelloDone 1 5 0.0104 (0.0013) CS Handshake Certificate 1 6 0.0104 (0.) CS Handshake ClientKeyExchange 1 7 0.0104 (0.) CS ChangeCipherSpec 1 8 0.0104 (0.) CS Handshake 1 9 0.0159 (0.0054) SC Handshake TLS_RSA_WITH_RC4_128_MD51 10 0.0159 (0.) SC ChangeCipherSpec 1 11 0.0159 (0.) SC Handshake 1 12 0.0163 (0.0004) CS application_data 1 13 0.0174 (0.0011) SC application_data 1 14 0.0176 (0.0001) CS application_data 1 15 0.0186 (0.0010) SC application_data 1 16 0.0189 (0.0002) CS application_data 1 17 0.0200 (0.0010) SC application_data 1 18 0.0203 (0.0002) CS application_data 1 0.0205 (0.0002) CS TCP FIN 1 19 0.0207 (0.0001) SC Alert 1 0.0209 (0.0001) SC TCP FIN *** This is for *Client - Proxy Server* *** 1 1 0.0025 (0.0025) CS Handshake ClientHello Version 3.1 cipher suites TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_IDEA_CBC_SHA TLS_RSA_WITH_RC4_128_SHA Unknown value 0xff compression methods NULL 1 2 3.2949 (3.2923) SC Handshake ServerHello Version 3.1 session_id[32]= 54 76 ca 2c bd 84 37 f9 98 7a b1 57 1f 61 9a 3d 40 89 58 89 e6 14 5f 39 8b 96 62 87 8f a9 30 8f cipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA compressionMethod NULL Certificate ServerKeyExchange ServerHelloDone 1 3 3.3135 (0.0186) CS Handshake ClientKeyExchange DiffieHellmanClientPublicValue[96]= 9c 38 d3 b5 10 3f 4d a6 54 a9 84 02 b3 f2 25 79 e1 f0 6e 6f 56 35 44 73 13 40 4e c0 6b 2a e7 64
Re: [openssl-users] OpenSSL performance issue
*Client* and *Agent* are implemented in C, while *Proxy Server* uses Java code (This shouldn't really matter). But might be helpful for you to know. The issue is, connecting *Client* to *Agent* is very fast (that is relatively). While connecting *Client* to *Proxy Server* is very slow - that is orders of magnitudes slow. Why do you say it shouldn't matter? The new Java proxy server is most likely the cause. Do some packet captures, between ClientAgent and ClinetProxy. L ook at the timing, and see if the client ends up waiting for packets from the proxy. ___ openssl-users mailing list openssl-users@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL performance issue
On Fri, Dec 19, 2014 at 02:30:07AM +0530, Prabhat Puroshottam wrote: *** This is for *Client - Agent* *** [...] Version 3.1 [...] cipherSuite TLS_RSA_WITH_AES_256_CBC_SHA [...] *** This is for *Client - Proxy Server* *** cipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA So the differnce here is that jave picks a DHE ciphersuite while otherwise you didn't. DHE gives you forward secrecy but is slower. You're also not using session resumption which might speed up the whole process. It at least looks like that proxy server might support that. You also seem to be using an old version of openssl that only supports TLSv1, I suggest you upgrade. Kurt ___ openssl-users mailing list openssl-users@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL performance issue
Why do you say it shouldn't matter? The new Java proxy server is most likely the cause. Do some packet captures, between ClientAgent and ClinetProxy. L ook at the timing, and see if the client ends up waiting for packets from the proxy. Sorry may be I wasn't able to convey it. The java proxy server is our code as well. The problem isn't application data transfer, but that Java Server takes inordinate amount of time before sending ServerHello. The application data transfer itself takes very less time. ___ openssl-users mailing list openssl-users@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL performance issue
So the differnce here is that jave picks a DHE ciphersuite while otherwise you didn't. DHE gives you forward secrecy but is slower. Being relatively new to OpenSSL and security programming in general, obviously I need to read into these, but could it cause the delay in sending ServerHello by Java Server. From your above statement I can make out that it might make overall communication slower, but I believe application data transfer is not the concern (at least not now), but only inordinate delay while performing SSL handshake. You're also not using session resumption which might speed up the whole process. It at least looks like that proxy server might support that. Thanks, that was the next step I was going to work on. Would you be so kind as to point out to me how you figured out that proxy server might support session resumption? Sorry if this is a very naive question. ___ openssl-users mailing list openssl-users@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL performance issue
So the differnce here is that jave picks a DHE ciphersuite while otherwise you didn't. DHE gives you forward secrecy but is slower. Being relatively new to OpenSSL and security programming in general, obviously I need to read into these, but could it cause the delay in sending ServerHello by Java Server. From your above statement I can make out that it might make overall communication slower, but I believe application data transfer is not the concern (at least not now), but only inordinate delay while performing SSL handshake. You're also not using session resumption which might speed up the whole process. It at least looks like that proxy server might support that. Thanks, that was the next step I was going to work on. Would you be so kind as to point out to me how you figured out that proxy server might support session resumption? Sorry if this is a very naive question. ___ openssl-users mailing list openssl-users@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL performance issue
I am trying to summarize the problem again, since the previous mail seems confusing to some of you. It might help you quickly understand the problem I am facing: We have a product, where Client connects to Server (Proxy Server in my earlier mail). Client is implemented in C and uses OpenSSL, while Server is implemented using Java code with BufferedInputStream and BufferedOutputStream. The following are my observations: 1. There is inordinate delay during connection establishment. 2. Using ssldump it was found that SSL handshake response from Server is taking most of the time. Rest of the application data transfer and processing hardly takes fraction of a second. The response from SSL handshake by Server comes after anywhere between 2 to 13 seconds after initial response sent by Client. 3. Subsequent analysis of the code showed that it was the first Buffered Read/Write which was taking inordinate amount of time. 4. Understanding that first Buffered Read/Write was hung on SSL connection completion, I introduced SSLConnect::startHandshake() so that I can explicitly see where is the problem. It was observed that now startHandshake() blocked for as much time as first Read/Write did. Further none of the Read/Write calls block, and returned data almost immediately. I would like to understand why startHandshake() is taking so long. I understand that it is a asynchronous call, but still the time delay is too much IMO. Is it something to do with the socket configuration/cipher/encryption used? Using ssldump I found there was absolutely no data transfer between the sending of client's hello request and subsequent response from server, so apparently all the time startHandshake() is busy doing something or may be nothing - what I have no idea. FWIW, this is not a network latency issue, 1) all the boxes are on the same network, 2) all other data transfers combined takes less than 0.4s. Can somebody kindly suggest what might be wrong or what can be done to fix this? Could it be some Socket or SSL setting, encryption/cipher used, or something else? -Prabhat ___ openssl-users mailing list openssl-users@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL performance issue
I would like to understand why startHandshake() is taking so long. Somebody else pointed out the differences in ciphers. You should take the time to understand that message. ___ openssl-users mailing list openssl-users@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL performance issue
Date: Thu, 18 Dec 2014 22:36:08 +0100 From: k...@roeckx.be To: openssl-users@openssl.org Subject: Re: [openssl-users] OpenSSL performance issue On Fri, Dec 19, 2014 at 02:30:07AM +0530, Prabhat Puroshottam wrote: *** This is for *Client - Agent* *** [...] Version 3.1 [...] cipherSuite TLS_RSA_WITH_AES_256_CBC_SHA [...] *** This is for *Client - Proxy Server* *** cipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA So the differnce here is that jave picks a DHE ciphersuite while otherwise you didn't. DHE gives you forward secrecy but is slower. Being relatively new to OpenSSL and security programming in general, obviously I need to read into these, but could it cause the delay in sending ServerHello by Java Server. From your above statement I can make out that it might make overall communication slower, but I believe application data transfer is not the concern (at least not now), but only inordinate delay while performing SSL handshake. You're also not using session resumption which might speed up the whole process. It at least looks like that proxy server might support that. Thanks, that was the next step I was going to work on. Would you be so kind as to point out to me how you figured out that proxy server might support session resumption? Sorry if this is a very naive question. ___ openssl-users mailing list openssl-users@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL performance issue
Date: Thu, 18 Dec 2014 22:36:08 +0100 From: k...@roeckx.be To: openssl-users@openssl.org Subject: Re: [openssl-users] OpenSSL performance issue On Fri, Dec 19, 2014 at 02:30:07AM +0530, Prabhat Puroshottam wrote: *** This is for *Client - Agent* *** [...] Version 3.1 [...] cipherSuite TLS_RSA_WITH_AES_256_CBC_SHA [...] *** This is for *Client - Proxy Server* *** cipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA So the differnce here is that jave picks a DHE ciphersuite while otherwise you didn't. DHE gives you forward secrecy but is slower. Being relatively new to OpenSSL and security programming in general, obviously I need to read into these, but could it cause the delay in sending ServerHello by Java Server. From your above statement I can make out that it might make overall communication slower, but I believe application data transfer is not the concern (at least not now), but only inordinate delay while performing SSL handshake. You're also not using session resumption which might speed up the whole process. It at least looks like that proxy server might support that. Thanks, that was the next step I was going to work on. Would you be so kind as to point out to me how you figured out that proxy server might support session resumption? Sorry if this is a very naive question. ___ openssl-users mailing list openssl-users@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL performance issue
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Kurt Roeckx Sent: Thursday, December 18, 2014 16:36 To: openssl-users@openssl.org Subject: Re: [openssl-users] OpenSSL performance issue So the differnce here is that jave picks a DHE ciphersuite while otherwise you didn't. DHE gives you forward secrecy but is slower. And if DH parameters have not been set, OpenSSL will have to generate them on the fly, which can be *very* slow (relative to normal conversation establishment). The OP might benefit from reading https://wiki.openssl.org/index.php/Diffie_Hellman https://wiki.openssl.org/index.php/Diffie-Hellman_parameters -- Michael Wojcik Technology Specialist, Micro Focus This message has been scanned for malware by Websense. www.websense.com ___ openssl-users mailing list openssl-users@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
RE: OpenSSL performance issue
From: owner-openssl-us...@openssl.org On Behalf Of Prabhat Puroshottam Sent: Tuesday, December 02, 2014 07:04 We have a product which uses OpenSSL to connect and transfer application level data. There are two ways to connect, and get the application level data from *Agent* to *Client* 1. Client (C/C++) - Agent (C/C++) 2. Client (C/C++) - Proxy Server (Java) - Agent (C/C++) *Client* and *Agent* are implemented in C, while *Proxy Server* uses Java code (This shouldn't really matter). But might be helpful for you to know. The issue is, connecting *Client* to *Agent* is very fast (that is relatively). While connecting *Client* to *Proxy Server* is very slow - that is orders of magnitudes slow. I was trying to determine the root cause. From my analysis is appears that, maximum time on the *Client* side is taken by SSL_Connect during connection establishment, while the actual application level data transfer takes very small time. Similarly, on the *Proxy Server* side (Java Code), maximum time is taken in the first read/write whichever happens first. Further, I don't Both the OpenSSL and Java (SSLSocket) APIs have the feature that you can do the handshake explicitly (SSL_connect/accept or .startHandshake) or implicitly on the first read or write (set_connect/accept_state, default). It appears you use explicit in Client but implicit in Proxy. This is valid but may be confusing if you don't keep it firmly in mind. think this is a network latency issue, as the problem is very pronounced and all the three boxes are on the same network. Also, the *Client* code seems to be similar, whether we connect to *Agent* (method 1 above) or *Proxy Server* (method 2 above). So, the issue is with *Proxy Server*, IMHO. It does look like that, see below. And Proxy is Java not OpenSSL, which somewhat reduces the suitability of this group to help. To further locate the issue, I did some tests using ssldump command, snip long data As you can see the big time difference between the two executions - which actually involve the same application level data. The largest chunk of On the trace of Client-Proxy connection, once the (delayed) handshake completes Proxy sends some initial data to Client without waiting for data from Client, but Client-Server doesn't. That is not quite the same. time is spent waiting for handshake from *Proxy Server*. The response time of *Proxy Server* in replying back with ServerHello, varies greatly between 1.5 to 11 seconds across different runs. In the present case it is nearly 3.3 seconds - which IMO is not acceptable. Yes ServerHello is nearly all of your delay, and that is in Proxy. What does Proxy code do between accepting on the [SSL]ServerSocket (which is Java's way of representing the listen-ing socket) and the first read or write -- apparently write? One particular thing, is it using BufferedReader/Writer on the socket streams? Java code often does buffered because it is more efficient than going to OS each time (at least for real I/O rather than ByteArray Streams). In that case for output you need .flush() to actually send. Or you could try doing .startHandshake() explicitly as soon as convenient after the .accept() and see what difference that makes (although it may only move the problem elsewhere). __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
OpenSSL performance issue
Hi, First let me state upfront that I am relatively very new to OpenSSL. Also please forgive me if this is not the correct mailing list for this issue. We have a product which uses OpenSSL to connect and transfer application level data. There are two ways to connect, and get the application level data from *Agent* to *Client* 1. Client (C/C++) - Agent (C/C++) 2. Client (C/C++) - Proxy Server (Java) - Agent (C/C++) *Client* and *Agent* are implemented in C, while *Proxy Server* uses Java code (This shouldn't really matter). But might be helpful for you to know. The issue is, connecting *Client* to *Agent* is very fast (that is relatively). While connecting *Client* to *Proxy Server* is very slow - that is orders of magnitudes slow. I was trying to determine the root cause. From my analysis is appears that, maximum time on the *Client* side is taken by SSL_Connect during connection establishment, while the actual application level data transfer takes very small time. Similarly, on the *Proxy Server* side (Java Code), maximum time is taken in the first read/write whichever happens first. Further, I don't think this is a network latency issue, as the problem is very pronounced and all the three boxes are on the same network. Also, the *Client* code seems to be similar, whether we connect to *Agent* (method 1 above) or *Proxy Server* (method 2 above). So, the issue is with *Proxy Server*, IMHO. To further locate the issue, I did some tests using ssldump command, *** This is for *Client - Agent* *** 1 1 0.0023 (0.0002) CS Handshake ClientHello Version 3.1 cipher suites TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_IDEA_CBC_SHA TLS_RSA_WITH_RC4_128_SHA Unknown value 0xff compression methods NULL 1 2 0.0091 (0.0068) SC Handshake ServerHello Version 3.1 session_id[0]= cipherSuite TLS_RSA_WITH_AES_256_CBC_SHA compressionMethod NULL 1 3 0.0091 (0.) SC Handshake Certificate 1 4 0.0091 (0.) SC Handshake CertificateRequest certificate_types rsa_sign certificate_types dss_sign ServerHelloDone 1 5 0.0104 (0.0013) CS Handshake Certificate 1 6 0.0104 (0.) CS Handshake ClientKeyExchange 1 7 0.0104 (0.) CS ChangeCipherSpec 1 8 0.0104 (0.) CS Handshake 1 9 0.0159 (0.0054) SC Handshake TLS_RSA_WITH_RC4_128_MD51 10 0.0159 (0.) SC ChangeCipherSpec 1 11 0.0159 (0.) SC Handshake 1 12 0.0163 (0.0004) CS application_data 1 13 0.0174 (0.0011) SC application_data 1 14 0.0176 (0.0001) CS application_data 1 15 0.0186 (0.0010) SC application_data 1 16 0.0189 (0.0002) CS application_data 1 17 0.0200 (0.0010) SC application_data 1 18 0.0203 (0.0002) CS application_data 1 0.0205 (0.0002) CS TCP FIN 1 19 0.0207 (0.0001) SC Alert 1 0.0209 (0.0001) SC TCP FIN *** This is for *Client - Proxy Server* *** 1 1 0.0025 (0.0025) CS Handshake ClientHello Version 3.1 cipher suites TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_IDEA_CBC_SHA TLS_RSA_WITH_RC4_128_SHA Unknown value 0xff compression methods NULL 1 2 3.2949 (3.2923) SC Handshake ServerHello Version 3.1 session_id[32]= 54 76 ca 2c bd 84 37 f9 98 7a b1 57 1f 61 9a 3d 40 89 58 89 e6 14 5f 39 8b 96 62 87 8f a9 30 8f cipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA compressionMethod NULL Certificate ServerKeyExchange ServerHelloDone 1 3 3.3135 (0.0186) CS Handshake ClientKeyExchange DiffieHellmanClientPublicValue[96]= 9c 38 d3 b5 10 3f 4d a6 54 a9 84 02 b3 f2 25 79 e1 f0 6e 6f 56 35 44 73 13 40 4e c0 6b 2a e7 64 ff 4a a0 7a 34 82 1e d9 35 70 d1 43 f8 c5 18 c4 56 54 a6 32 33 bc 1a 35 62 fe 36 cc 33 f4 a0 15 6d 7a ea 5e a6 f5 d6 d7 21 45 16 30 08 2b bc e9 4c 25 32 64 b3 a3 b9 21 db 26 b1 6c 4c 92 34 aa 1 4 3.3135 (0.) CS
openSSL performance
Hello again,It doesn’t sound like you did profile, but rather a stop-watch at start and stop. That’s more coarse-grained than I think you need to do. For example,you need to measure time to do the key exchange, time to do the encryption, time to put the traffic over the network. For example, try with aNULL and eNULL and see what numbers you get. Then turn each on, separately, and see what you get.I'm using a third-party library (Qt) that masks initial handshake message exchanges steps and data encryption. I could instrument Qt's internal methods to know how much time encryption takes versus data sending/receiving but that's pretty useless given that the client/server project I'm working on is not SSL-ed, my work consists in adding security. Therefore my profiling consisted in comparing times with encrypted and non-encrypted versions of the project, which gives me a rough estimation of encryption time. For handshake, I know that this phase is short because I know when it ends, I just didn't took the time to measure it precisely but I can easily come back with precise figures, I will have a look at it. As a general design principle, the crypto algorithm is not the weak spot. Forexample, how hard is it to break into the client device?Well that's always a compromise and this is what I'm curently trying to reach by reducing my requirements in terms of key length for example. I partially agree with you in that no system is proven to be 100% reliable but my work is not to care about things I cannot handle like access to host device. On the other side, my work is to use the most secure cipher suite I can afford relatively to performance issue. Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net
openSSL performance
Aside: this message was pretty garbled, and in richtext which my Outlook won't fix sensibly. I've tried to manually reformat what I can, but it would be easier if you posted plaintext. Really sorry for that, I saw it only once message was already posted. Thanks for taking the time anyway. Do you mean no or yes? If you do use client-auth and RSA, then the handshake is slower (costlier). But my only affects handshake was agreeing that your problem probably *isn't* handshake. I meant: yes, I'm using client-auth. Not really at least for 3DES. Nobody is going to bruteforce any =112 bit cipher in my lifetime or yours. Not even NSA, everybody's bete du jour (if not de l'annee, or whatever the correct spelling is). RC4 is the most endangered technically; it does have distinguishers (which don't matter for SSL/TLS which usually exposes the algorithm choice already, and in any case has relatively few choices available) and there has been progress against it when used for massively repeated data which your described application of file transfer wouldn't have. If the adversary can break the key-exchange, or actively the authentication, or the RNG, those are just as effective against AES256 as against old single DES. Very interesting indeed. I seriously consider using 3DES but, using a third-party library (Qt), I was for the moment unable to force usage of a given cipher suite (unlike with openssl tool). I don't know anything about that specific hardware, maybe someone else does. In general, if it's just an accelerator and architecture specific, like AES-NI on Intel, it may be enough to do assembler that is conditionally invoked when available and maybe enabled. Otherwise yes the 'engine' architecture in OpenSSL is the way to use hardware or encapsulated crypto primitives. Ok; I'm afraid this wouldn't be the only work I would have to achieve, I would probably also needed a dedicated kernel patch or KLM for managing the low-level access to the crypto- accelerator's registers. Need to check if ST provides it already. 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. Actually I double checked and the cipher suite used by default is ECDHE-RSA-AES256-GCM- SHA384. So I actually use GCM already if I understand correctly. Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
openSSL performance
(sorry for duplicating the thread, I did'nt receive any answer in my mailbox as I expected, I only saw them through the mail archive...?) Are you sure that the key exchange is not a factor? Have you measured SSL setup times compared to post-setup transfer times?4K RSA is computationally expensive. Are you sure that the rest of your system is secure enough to justify that instead of 2K RSA? Hi Rich, I've started with a 1K key and later on switched on 4K but I didn't do any profiling with 1K key (unlike 4K one).I'm sending hundreds of megabytes of data and it takes more than a minute to get it done, so I doubt that the initial handshake will have any influence on it, what do you think ? About your last question, I believe my system could live with a 2K RSA for now, I'm not sure this will still be the case in five years or so... Best regardsLaurent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net
openSSL performance
RSA key size only affects handshake, and should be costly client side only if using client-auth; are you?No; as client and server code is under my responsability, I chosed to also asked for client-auth. Still, I don't see how this could be the reason for my slowdown given the overall data transmission length; I will anyways give a try with a smaller key but I'm pretty sure that it will have no influence. Data handling speed will normally be affected by encryption *and* MAC (usually HMAC). True, in my case, SHA is negociated; don't really know why HMAC is not selected BTW, any idea ? You could certainly try different data (symmetric) cipher, such as 3DES or RC4. They are less secure than AES256 (that I'm using), but I guess I will have to make a compromise so yes I believe that's the most obvious hint.I don’t know for Atom and ARM Ok; what about engines, is there anyone for SPEAr320 (the ARM-based SoC I will use along with Atom) ? It has its own cryptographic accelerator that supports AES but I hardly understand how I can use it; I only get that engines should be the way, but then I probably need a Linux kernel driver also right ?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. By 'MAC' you mean hashing operation right ? I will see if I can do this also.Thanks a lot for answering,Best regardsLaurent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net
RE: openSSL performance
Ø (sorry for duplicating the thread, I did'nt receive any answer in my mailbox as I expected, I only saw them through the mail archive...?) It’s common (and many would say, the correct behavior) for mailing list replies to go to the mailing list. Ø I've started with a 1K key and later on switched on 4K but I didn't do any profiling with 1K key (unlike 4K one). It doesn’t sound like you did profile, but rather a stop-watch at start and stop. That’s more coarse-grained than I think you need to do. For example, you need to measure time to do the key exchange, time to do the encryption, time to put the traffic over the network. For example, try with aNULL and eNULL and see what numbers you get. Then turn each on, separately, and see what you get. Ø I'm sending hundreds of megabytes of data and it takes more than a minute to get it done, so I doubt that the initial handshake will have any influence on it, what do you think ? I have no idea, that’s why you have to do measurements. ☺ About your last question, I believe my system could live with a 2K RSA for now, I'm not sure this will still be the case in five years or so... As a general design principle, the crypto algorithm is not the weak spot. For example, how hard is it to break into the client device? /r$ -- Principal Security Engineer Akamai Technology Cambridge, MA
RE: openSSL performance
Aside: this message was pretty garbled, and in richtext which my Outlook won't fix sensibly. I've tried to manually reformat what I can, but it would be easier if you posted plaintext. From: owner-openssl-us...@openssl.org On Behalf Of laurent.boll...@laposte.net Sent: Tuesday, October 08, 2013 04:51 [I wrote] RSA key size only affects handshake, and should be costly client side only if using client-auth; are you? No; as client and server code is under my responsability, I chosed to also asked for client-auth. Still, I don't see how this could be the reason for my slowdown given the overall data transmission length; I will anyways give a try with a smaller key but I'm pretty sure that it will have no influence. Do you mean no or yes? If you do use client-auth and RSA, then the handshake is slower (costlier). But my only affects handshake was agreeing that your problem probably *isn't* handshake. Data handling speed will normally be affected by encryption *and* MAC (usually HMAC). True, in my case, SHA is negociated; don't really know why HMAC is not selected BTW, any idea ? All the ciphersuite names that use a hash (MD5, SHA, SHA256, SHA384) actually mean HMAC using the identified hash -- except 'SHA' really means SHA1; at the time those suites were defined and named, SHA-0 had been withdrawn and SHA-1 was the only SHA in use. The only TLS ciphersuites that don't use HMAC with some hash for integrity are the new TLSv1.2 ones that use GCM (see below). In case you aren't clear, HMAC is not one algorithm; it is a construction that uses a hash algorithm to construct a MAC algorithm. See Wikipedia and the RFC. SSL/TLS uses HMAC using different hashes, but until TLSv1.2 always the same HMAC construction, so it's only the hash that was named. (Somewhat similarly, the SSL 3 and TLS 1 and 1.1 protocols used one KDF for all key exchanges. Only in 1.2 do we explicitly identify the KDF to allow for a choice, and unless I've missed something recently no one has actually made another choice yet.) You could certainly try different data (symmetric) cipher, such as 3DES or RC4. They are less secure than AES256 (that I'm using), but I guess I will have to make a compromise so yes I believe that's the most obvious hint. Not really at least for 3DES. Nobody is going to bruteforce any =112 bit cipher in my lifetime or yours. Not even NSA, everybody's bete du jour (if not de l'annee, or whatever the correct spelling is). RC4 is the most endangered technically; it does have distinguishers (which don't matter for SSL/TLS which usually exposes the algorithm choice already, and in any case has relatively few choices available) and there has been progress against it when used for massively repeated data which your described application of file transfer wouldn't have. If the adversary can break the key-exchange, or actively the authentication, or the RNG, those are just as effective against AES256 as against old single DES. I don’t know for Atom and ARM [but AES is generally fast] Ok; what about engines, is there anyone for SPEAr320 (the ARM-based SoC I will use along with Atom) ? It has its own cryptographic accelerator that supports AES but I hardly understand how I can use it; I only get that engines should be the way, but then I probably need a Linux kernel driver also right ? I don't know anything about that specific hardware, maybe someone else does. In general, if it's just an accelerator and architecture specific, like AES-NI on Intel, it may be enough to do assembler that is conditionally invoked when available and maybe enabled. Otherwise yes the 'engine' architecture in OpenSSL is the way to use hardware or encapsulated crypto primitives. 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. By 'MAC' you mean hashing operation right ? I will see if I can do this also. MAC is any kind of integrity check. Sometimes it can be just a protected hash, but not in SSL/TLS. HMAC is one kind of MAC, and the only one used in SSL/TLS until recently. GCM is a relatively new cipher mode that provides both encryption and MAC in one operation, generically called AEAD Authenticated Encryption with Additional Data. (Some other AEAD modes have been created, but not adopted for TLS.) Real performance may vary quite a bit by platform, but generally since GCM needs to do more work than just encryption alone, but somewhat less than encryption plus separate HMAC, it might be faster. OTOH if you have special hardware, GCM is new enough it may well not be in the hardware. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager
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 Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net
RE: openSSL performance
Are you sure that the key exchange is not a factor? Have you measured SSL setup times compared to post-setup transfer times? 4K RSA is computationally expensive. Are you sure that the rest of your system is secure enough to justify that instead of 2K RSA? /r$ -- Principal Security Engineer Akamai Technology Cambridge, MA
RE: openSSL performance
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
iOS 6 SDK OpenSSL Performance
Hey guys, So I've been running into an issue when using OpenSSL 1.0.1c with the new iOS 6 SDK. I compiled the app using openssl-xcode project on GitHub which is part of the sqlcipher project. I have been using the same OpenSSL functions for the lifetime of my app (mainly SHA-256 hashing and RSA encrypt / decrypt). What I have noticed is that when I compile the app using the iOS 6 SDK the OpenSSL functions I'm using take almost twice the amount of time to complete as they did when the app was compiled from the iOS 5 SDK. It now takes nearly double the amount of time to compute hashes and sign data using RSA_sign. Has anyone else experienced this? Also if I were to ditch the openssl-xcode project and compile manually what are the steps to compile and optimize for armv7 / armv7s arch?
Re: openssl performance
try typing openssl s_time ? raj H wrote: *[safeTgram (optim1) receive status: NOT encrypted, NOT signed.]* Thanks Jimmy! This command looks to help me for the performance! Only thing is I have to get it working. I keep on getting errors. Anyways, thanks! I will go through and get it running. Any inputs on session reuse? On Thu, Apr 3, 2008 at 12:39 PM, jimmy bahuleyan [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: raj H wrote: Thanks Marek for your comments! [snip] I am sorry these questions are really vague and not of challenge for the technical personals. But I believe these are the questions any solution developer or openssl user would have. Isn't the OpenSSL publishes any numbers? Have you tried the command $ openssl s_time -jb -- Real computer scientists don't comment their code. The identifiers are so long they can't afford the disk space. __ OpenSSL Project http://www.openssl.org http://www.openssl.org/ User Support Mailing List openssl-users@openssl.org mailto:openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: openssl performance
Hi raj, Try openssl speed Best regards, On Fri, Apr 4, 2008 at 5:48 AM, raj H [EMAIL PROTECTED] wrote: Thanks Jimmy! This command looks to help me for the performance! Only thing is I have to get it working. I keep on getting errors. Anyways, thanks! I will go through and get it running. Any inputs on session reuse? On Thu, Apr 3, 2008 at 12:39 PM, jimmy bahuleyan [EMAIL PROTECTED] wrote: raj H wrote: Thanks Marek for your comments! [snip] I am sorry these questions are really vague and not of challenge for the technical personals. But I believe these are the questions any solution developer or openssl user would have. Isn't the OpenSSL publishes any numbers? Have you tried the command $ openssl s_time -jb -- Real computer scientists don't comment their code. The identifiers are so long they can't afford the disk space. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] -- Badra
Re: openssl performance
Hello, [EMAIL PROTECTED] wrote on 04/03/2008 04:18:42 AM: Anybody any comments? On Tue, Apr 1, 2008 at 11:56 PM, raj H [EMAIL PROTECTED] wrote: Hi Experts, OpenSSL 9.8b. We are facing some performance issues with it. I heard that doing session reuse or using some other ciphers can help improve the performance significantly. I would like to know - 1. Is using the session reuse with ssl handshake is advisable? I read somewhere that session reuse with openssl is controversial with memory usage. It might have some memory leaks. Is that true? What are other issues with ssl session reuse? Does anyone has any numbers on performance gain with session reuse? This is method improves handshake performance when your client connects/disconnects many times to your server in short time (like https client connections with HTTP/1.0). In this case handshake exchanges only 6 packets (without RSA encryption in case where RSA certificates are used) instead of 9/10/12 (depending of authorization scheme). 2. Does changing cipher used improve performance? We use the default one. Is there any numbers on this too? I plan to use one of - In general: use AES instead of DES3, its faster. Best regards, -- Marek Marcola [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: openssl performance
Thanks Marek for your comments! When you say, session reuse improves the handshake performance, what factor? If normal handshake takes 1 second, how long it will take to negotiate session re-use? What about the other issues such as memory leaks and security concerns with session re-use? Does anyone has any performance numbers on encrption with cipher suites using AES / 3DES and others? David, Here are more details - I am running on HP NonStop system. It is an mainframe application. But I dont think anybody would have performance number on this so I didn't mentioned the platform. I am interested in knowing the gain factors on other platforms so that I can co-relate those numbers on nonstop platform. Currently it takes around 1 second of cpu time for handshake. Kalyan, I would surely help you with the code snippet in C. Email me! I am sorry these questions are really vague and not of challenge for the technical personals. But I believe these are the questions any solution developer or openssl user would have. Isn't the OpenSSL publishes any numbers? On Thu, Apr 3, 2008 at 2:15 AM, [EMAIL PROTECTED] wrote: Hello, [EMAIL PROTECTED] wrote on 04/03/2008 04:18:42 AM: Anybody any comments? On Tue, Apr 1, 2008 at 11:56 PM, raj H [EMAIL PROTECTED] wrote: Hi Experts, OpenSSL 9.8b. We are facing some performance issues with it. I heard that doing session reuse or using some other ciphers can help improve the performance significantly. I would like to know - 1. Is using the session reuse with ssl handshake is advisable? I read somewhere that session reuse with openssl is controversial with memory usage. It might have some memory leaks. Is that true? What are other issues with ssl session reuse? Does anyone has any numbers on performance gain with session reuse? This is method improves handshake performance when your client connects/disconnects many times to your server in short time (like https client connections with HTTP/1.0). In this case handshake exchanges only 6 packets (without RSA encryption in case where RSA certificates are used) instead of 9/10/12 (depending of authorization scheme). 2. Does changing cipher used improve performance? We use the default one. Is there any numbers on this too? I plan to use one of - In general: use AES instead of DES3, its faster. Best regards, -- Marek Marcola [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: openssl performance
raj H wrote: Thanks Marek for your comments! [snip] I am sorry these questions are really vague and not of challenge for the technical personals. But I believe these are the questions any solution developer or openssl user would have. Isn't the OpenSSL publishes any numbers? Have you tried the command $ openssl s_time -jb -- Real computer scientists don't comment their code. The identifiers are so long they can't afford the disk space. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: openssl performance
Thanks Jimmy! This command looks to help me for the performance! Only thing is I have to get it working. I keep on getting errors. Anyways, thanks! I will go through and get it running. Any inputs on session reuse? On Thu, Apr 3, 2008 at 12:39 PM, jimmy bahuleyan [EMAIL PROTECTED] wrote: raj H wrote: Thanks Marek for your comments! [snip] I am sorry these questions are really vague and not of challenge for the technical personals. But I believe these are the questions any solution developer or openssl user would have. Isn't the OpenSSL publishes any numbers? Have you tried the command $ openssl s_time -jb -- Real computer scientists don't comment their code. The identifiers are so long they can't afford the disk space. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
openssl performance
Hi Experts, OpenSSL 9.8b. We are facing some performance issues with it. I heard that doing session reuse or using some other ciphers can help improve the performance significantly. I would like to know - 1. Is using the session reuse with ssl handshake is advisable? I read somewhere that session reuse with openssl is controversial with memory usage. It might have some memory leaks. Is that true? What are other issues with ssl session reuse? Does anyone has any numbers on performance gain with session reuse? 2. Does changing cipher used improve performance? We use the default one. Is there any numbers on this too? I plan to use one of - SSL_RSA_WITH_3DES_EDE_CBC_SHA SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_DH_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA TLS_DH_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA Thanks for your help! Raj
Re: openssl performance
Anybody any comments? On Tue, Apr 1, 2008 at 11:56 PM, raj H [EMAIL PROTECTED] wrote: Hi Experts, OpenSSL 9.8b. We are facing some performance issues with it. I heard that doing session reuse or using some other ciphers can help improve the performance significantly. I would like to know - 1. Is using the session reuse with ssl handshake is advisable? I read somewhere that session reuse with openssl is controversial with memory usage. It might have some memory leaks. Is that true? What are other issues with ssl session reuse? Does anyone has any numbers on performance gain with session reuse? 2. Does changing cipher used improve performance? We use the default one. Is there any numbers on this too? I plan to use one of - SSL_RSA_WITH_3DES_EDE_CBC_SHA SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_DH_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA TLS_DH_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA Thanks for your help! Raj
RE: openssl performance
On Tue, Apr 1, 2008 at 11:56 PM, raj H [EMAIL PROTECTED] wrote: Anybody any comments? It's really hard to help you because your question is so vague. What platform are you using? What performance are you seeing? What performance did you expect? Is the problem with session setup rate or connection throughput or what? DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: openssl performance
On Monday 09 July 2001 13:52, Steven A. Bade wrote: OK Stupid question Where can one find SWAMP??? There's a downloadable tarball at; http://www.geoffthorpe.net/crypto/ However, expect a heavily revamped version soon ... Cheers, Geoff __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: openssl performance
Ah, big difference. It is running much, much faster, and now runs pretty much even with the apache/mod_ssl server. Thanks Geoff. Chris On Monday 09 July 2001 11:17 am, you wrote: On Mon, 9 Jul 2001, C. Gould wrote: I've created some server code based on openssl 0.9.6 that seems to be running fine. The only problem I've encountered is the noticible difference between the speed of my code running on a P866 and the speed of mod_ssl code running on another P833. Both of these machines are running linux-mandrake 8. Using Geoff Thorpe's swamp utility my code handles around 12 transactions in a second. To my surprise, the mod_ssl/openssl/apache server does around 18-20 transactions in a second. Is such a large difference in speed common? Are there steps I could have used to increase the speed during the configuration of openssl. Please share your experiences if you get a chance. I can guess what the problem is ... did you check the notes in the 'swamp' package? I recall sticking a note there about what I think this is - ephemeral cipher suites. I wouldn't be surprised if adding the -cipher RC4-MD5 command-line switch to swamp speeds things up a bit?? If that is the problem, the moral of the story is simple - if you simply *must* have the server go faster than EDH cipher-suites allow, disable EDH cipher-suites on the web server (see mod_ssl's manual). Bear in mind also however that those numbers are all *new* SSL sessions - try using the -session switch to generate test traffic that also uses resumes to see how the system profiles as a result. Cheers, Geoff __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
OpenSSL Performance stats.
Hi, Has anyone done any performance measuring of OpenSSL and published it on the WWW ? I'm not particularly fussed about hardware (that can be factored in). I'm interested in measurements of kB/sec encryption and connections/sec setup/accept for 3DES+MD5. Darren __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
