So, what’s new at wolfSSL? Take a look below to check out the most recent news, or sign up to receive weekly email notifications containing the latest news from wolfSSL. wolfSSL also has a support-specific blog page dedicated to answering some of the more commonly received support questions.

About Open Source

Hi!  This is just a reminder.  We are still all about open source.  We believe that Open Source Software is the best way to conceive, share, deliver, support and build software.

We believe in open source for all of the right and well documented reasons.  If you can`t work with open source then tell us your story at

wolfSSL Embedded SSL on ColdFire 547X/548X with Hardware Encryption Acceleration

Hi!  The CyaSSL Embedded SSL engine, wolfCrypt cryptography library, and the wolfSSL Embedded Web Server now support Freescale`s ColdFire hardware encryption.  Our initial benchmarks show that AES and 3DES cryptography operations are up to 10 times faster when done with ColdFire`s hardware acceleration.  If you would like to use one of our products with ColdFire, and leverage ColdFire`s hardware cryptography, then contact us at

SSL/TLS Programming Tutorial

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 with any questions or comments regarding the tutorial or the wolfSSL lightweight SSL/TLS library.

Serpent Cipher in wolfSSL Embedded SSL

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:

If you think it is productive for us to add Serpent to wolfSSL, then just let us know at  

In unrelated news, We Are The Champions  of National Cyber Security Awareness Month.  See:, for the complete list of champions, and how to get involved.  

wolfSSL does _not_ implement Dual_EC_DRBG

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:

For the record, we have never implemented the Dual_EC_DRBG algorithm, nor gone so far as to set it as a default.  See:

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:  Our thoughts on comparing CyaSSL to OpenSSL are here:, and here:

Finally, a comment from Bruce Schneier on staying Secure:  

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

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.

Implementation and Performance of AES-NI in wolfSSL Lightweight SSL

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

CyaSSL AES-NI White Paper: wolfSSL White Papers (

wolfSSL STM32 Hardware Crypto and RNG Support

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 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:
STM32F2 Standard Peripheral Library documentation:

CyaSSL Release 2.8.0 Now Available

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


– 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.

Recent Security Compromise in Android Apps using Java Cryptography Architecture (JCA)

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 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

“Some SecureRandom Thoughts”, Android Developers Blog:

CyaSSL and SEP 2.0

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

If you need background information, there is an excellent article at EE Times that you can review here:

Posts navigation

1 2 3 158 159 160 161 162 163 164 190 191 192

Weekly updates