RECENT BLOG NEWS

Are you just learning about SSL/TLS, or interested in learning how to layer it into an existing application? If so, we include an SSL tutorial in Chapter 11 of our wolfSSL Manual which provides a good introduction to integrating wolfSSL into a typical TCP socket-based application.

Our SSL/TLS Tutorial uses base examples found in the popular “Unix Network Programming” book by Richard Stevens, Bill Fenner, and Andrew Rudoff. It then walks the programmer through the integration of wolfSSL step by step, eventually giving them a working application with secure communication through SSL.

The tutorial can be found at the following URL:
wolfSSL SSL/TLS Tutorial

Please contact us at facts@wolfssl.com with any questions or comments regarding the tutorial or the wolfSSL lightweight SSL/TLS library.

Hi!  One of the alternative ciphers we`ve considered implementing in wolfSSL is the Serpent Cipher.  Not only does it have a cool sounding alliterative name, but it is theoretically more secure than Rijndael/AES.  In fact, it was a finalist for AES.  An overview of the Serpent Cipher can be found here:  http://en.wikipedia.org/wiki/Serpent_(cipher).

If you think it is productive for us to add Serpent to wolfSSL, then just let us know at facts@wolfssl.com.  

In unrelated news, We Are The Champions http://www.youtube.com/watch?v=04854XqcfCY  of National Cyber Security Awareness Month.  See:  https://staysafeonline.org/ncsam/ncsam-champions/, for the complete list of champions, and how to get involved.  

Hi!  It is rare for a cryptography algorithm to make the pages of the popular press, but Dual_EC_DRBG has done just that!  The best article we`ve seen to date is Kim Zetter`s lucid article in Wired: https://www.wired.com/2013/09/nsa-backdoor/.

For the record, we have never implemented the Dual_EC_DRBG algorithm, nor gone so far as to set it as a default.  See:  http://blog.cryptographyengineering.com/2013/09/rsa-warns-developers-against-its-own.html

We`re moths to the flame when it comes to alternative and new crypto, as witnessed by our implementations of NTRU, SHA-3, HC-128, and Rabbit.  We like trying new things and then benchmarking them in our test rigs, but on Dual_EC_DRBG, we passed.

All that said, we deliver our products in open source, and you and everyone else are welcome to inspect them.  Our position on our cryptography implementation follows:

1.  We can trace all of our code to a very limited set of developers in our company.  We are open source, but unlike some projects, we tightly control and inspect the code that goes into our mainline.

2.  Our code is vetted out not only by wolfSSL staff, but by a diverse and wide array of people in open source, cryptography, and commercial security companies.  

The above is not true for the OpenSSL project.  As Matthew Green says, OpenSSL is “a patchwork nightmare originally developed by a programmer who thought it would be a fun way to learn Bignum division.* Part of it is because crypto is unbelievably complicated. Either way, there are very few people who really understand the whole codebase.”  See:  http://blog.cryptographyengineering.com/2013/09/on-nsa.html.  Our thoughts on comparing CyaSSL to OpenSSL are here:  https://www.wolfssl.com/how-does-wolfssl-compare-to-openssl/, and here:  https://www.wolfssl.com/openssl-in-devices-gets-cracked-when-trying-to-enhance-randomness-2/

Finally, a comment from Bruce Schneier on staying Secure:  

“Closed-source software is easier for the NSA to backdoor than open-source software. “

http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surveillance

We are open source, and we believe in open source.  Open source is the best way to develop, deliver, and support cryptography.  Ipso Facto.  Over and out from team wolfSSL.

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.