RECENT BLOG NEWS

Do you have a processor and compiler which support Intel’s AES-NI? If so, you can take advantage of the increase in performance provided by AES-NI in CyaSSL and wolfCrypt.

wolfSSL has worked with Intel to publish a white paper describing how Intel’s AES-NI can be used with the CyaSSL embedded SSL library. This paper provides a brief overview of the Intel AES-NI instructions and demonstrates the performance gains realized when Intel AES-NI is used in place of a more traditional software-only based AES implementation. The CyaSSL embedded SSL library is used as a test bed in the white paper to perform the comparison as it can be built with either traditional software-based AES or hardware-based AES-NI support at compile time. As a secondary goal to demonstrating Intel AES-NI performance, this paper explains how to determine if a pre-built SSL library (static or shared) offers built-in support for the Intel Advanced Encryption Standard New Instructions.

The white paper can be downloaded directly from the wolfSSL website at the following location. If you have any questions about using CyaSSL on Intel hardware, please contact us at facts@wolfssl.com.

CyaSSL AES-NI White Paper: wolfSSL White Papers (http://yassl.com/yaSSL/cyassl-embedded-ssl-white-papers.html)

Did you know that the CyaSSL lightweight SSL library has support for hardware-based cryptography and random number generation offered by the STM32 processor? Supported cryptographic algorithms include AES (CBC, CTR), DES (ECB, CBC), 3DES, MD5, and SHA1. For details regarding the STM32 crypto and hash processors, please see the STM32F2xx Standard Peripheral Library document (linked below).

Devices using the STM32 with CyaSSL can see substantial speed improvements when using hardware crypto versus using CyaSSL’s software crypto implementation. The following benchmarks were gathered from the CTaoCrypt benchmark application (ctaocrypt/benchmark/benchmark.c) running on the STM3221G-EVAL board (STM32F2) using the STM32F2 Standard Peripheral Library and FreeRTOS.

CyaSSL Software Crypto, Normal Big Integer Math Library

AES 1024 kB took 0.822 seconds,   1.22 MB/s
ARC4 1024 KB took 0.219 seconds,   4.57 MB/s
DES       1024 KB took 1.513 seconds,   0.66 MB/s
3DES     1024 KB took 3.986 seconds,   0.25 MB/s

MD5         1024 KB took 0.119 seconds,   8.40 MB/s
SHA         1024 KB took 0.279 seconds,   3.58 MB/s
SHA-256  1024 KB took 0.690 seconds,   1.45 MB/s

RSA 2048 encryption took 111.17 milliseconds, avg over 100 iterations
RSA 2048 decryption took 1204.77 milliseconds, avg over 100 iterations
DH  2048 key generation   467.90 milliseconds, avg over 100 iterations
DH  2048 key agreement   538.94 milliseconds, avg over 100 iterations

STM32F2 Hardware Crypto, Normal Big Integer Math Library

AES        1024 kB took 0.105 seconds,   9.52 MB/s
ARC4     1024 KB took 0.219 seconds,   4.57 MB/s
DES       1024 KB took 0.125 seconds,   8.00 MB/s
3DES     1024 KB took 0.141 seconds,   7.09 MB/s

MD5           1024 KB took 0.045 seconds,  22.22 MB/s
SHA           1024 KB took 0.047 seconds,  21.28 MB/s
SHA-256  1024 KB took 0.690 seconds,   1.45 MB/s

RSA 2048 encryption took 111.09 milliseconds, avg over 100 iterations
RSA 2048 decryption took 1204.88 milliseconds, avg over 100 iterations
DH  2048 key generation  467.56 milliseconds, avg over 100 iterations
DH  2048 key agreement   542.11 milliseconds, avg over 100 iterations

To enable STM32 hardware crypto and RNG support, define STM32F2_CRYPTO and STM32F2_RNG when building CyaSSL. For a more complete list of defines which may be required, please see the CYASSL_STM32F2 define in /cyassl/ctaocrypt/settings.h.

If you would like to use CyaSSL with STM32 hardware-based cryptography or RNG, or have any questions, please contact us at facts@wolfssl.com for more information. The latest stable release of CyaSSL is available for download under the GPLv2 direct from the wolfSSL website.

CyaSSL embedded SSL library: http://wolfssl.com/yaSSL/Products-cyassl.html
STM32: http://www.st.com/internet/mcu/class/1734.jsp
STM32F2 Standard Peripheral Library documentation: http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/USER_MANUAL/DM00023896.pdf

The bi-monthly release of CyaSSL, 2.8.0, is now ready to download from our website.  New features include:

– AES-GCM and AES-CCM use AES-NI

– NetX default IO callback handlers

– IPv6 fixes for DTLS Hello Cookies

– The ability to unload Certs/Keys after the handshake, CyaSSL_UnloadCertsKeys()

– SEP certificate extensions

– Callback getters for easier resource freeing

– External CYASSL_MAX_ERROR_SZ for correct error buffer sizing

– MacEncrypt and DecryptVerify Callbacks for User Atomic Record Layer Processing

– Public Key Callbacks for ECC and RSA

– Client now sends blank cert upon request if doesn’t have one with TLS <= 1.2

Please see the README and our on-line documentation for more information or feel free to contact us.

Earlier this month, Google announced that a security compromise had been found which affects applications that improperly initialize, or fail to initialize completely, the PRNG (pseudorandom number generator) before using it for key generation, signing, or random number generation.

On the Android Developers Blog, Alex Klyubin, Android Security Engineer, stated that “We have now determined that applications which use the Java Cryptography Architecture (JCA) for key generation, signing, or random number generation may not receive cryptographically strong values on Android devices due to improper initialization of the underlying PRNG. Applications that directly invoke the system-provided OpenSSL PRNG without explicit initialization on Android are also affected”, but also noted that “Applications that establish TLS/SSL connections using the HttpClient and java.net classes are not affected as those classes do seed the OpenSSL PRNG with values from /dev/urandom.”

The Android Developers Blog link provides Android developers with a workaround, suggesting that the PRNG be initialized with entropy from /dev/urandom or /dev/random.

For our wolfSSL and wolfCrypt users on Android, applications should not be affected as wolfSSL and wolfCrypt seed their PRNG from /dev/urandom or /dev/random by default. When using crypto directly through wolfCrypt, this happens when the application calls InitRng(). When using SSL/TLS through wolfSSL, the PRNG is automatically seeded.

For users who want to write their own seed generation code, wolfSSL and wolfCrypt allow programmers to define NO_DEV_RANDOM and write their own GenerateSeed() function in /ctaocrypt/src/random.c. For more information about doing so, or questions, please contact us at facts@wolfssl.com.

“Some SecureRandom Thoughts”, Android Developers Blog: http://android-developers.blogspot.com/2013/08/some-securerandom-thoughts.html

Hi!  If you are interested in IoT and specifically security of IoT, then you’ll probably like this article on SEP 2.0.  SEP stands for Smart Energy Profile.  This note is just to let our users know that we’re following the evolution of the standard as it relates to SSL/TLS, and have provided our CyaSSL embedded TLS solution to a number of progressive companies that are building out the smart grid.  If you have questions about how CyaSSL fits into the smart grid and SEP 2.0, then contact us at facts@wolfssl.com.

If you need background information, there is an excellent article at EE Times that you can review here:  https://www.eetimes.com/document.asp?doc_id=1280846

CyaSSL now supports the Cavium NITROX processors, thus enabling CyaSSL users to take advantage of the incredible performance boosts provided by the NITROX family.  Cavium’s NITROX processors combine cryptographic acceleration with the latest security algorithms.

The NITROX PX family can deliver performance ranging from 500 Mbps to 2.5 Gbps for full SSL protocol offload, and anywhere from 4K to 17K RSA operations per second using 1024bit exponent RSA.  The NITROX III family can additionally boost SSL offload performance to anywhere from 5 Gbps to 40 Gbps, and can provide 35K to 200K RSA operations per second using 1024bit exponent RSA.

Are you interested in using CyaSSL with a Cavium NITROX processor?  If so, let us know at facts@wolfssl.com.

NITROX Security Processors:  https://www.cavium.com/processor_security.html

Hi!  wolfSSL`s Secure Embedded Web Server is now available for FreeRTOS.  Let us know if you`re interested at facts@wolfssl.com.

Here at wolfSSL, we’re always excited to see fan art! Today we’d like to thank Steve Barker (https://plus.google.com/103515628980768116177/posts) for the rendition of our logo and tagline!

One of the consistent themes at Black Hat is attacks on industrial control systems; which includes water plants, power plants, and oil refineries.  One of the presentations was centered around using honeypots to determine the level of attack activity.  An excellent article on the presentation and related material can be found here:  http://gcn.com/Articles/2013/08/07/ics-honeypots.aspx?s=security_080813&admgarea=TC_SecCybersSec&Page=1

Some of the attacks can be mitigated with wolfSSL, by using our embedded SSL to secure firmware updates and eliminate MITM attacks.  We`ve seen a number of progressive companies adopt our products to do exactly that.  

Qualys put out an excellent SSL deployment best practices paper a few months ago.  If you have not seen it, then check it out here:  https://www.ssllabs.com/projects/best-practices/