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.

wolfSSL adds support for ARM`s Keil MDK-ARM and RTX

In an effort to ensure that the wolfSSL lightweight SSL library operates seamlessly with the Keil tools, we have recently added MDK-ARM 4 project files to our package.  Additionally, we have added support for Keil RTX.  Information on MDK-ARM 4 can be found here:  Information on RTX can be found here:  Support is currently in beta.  Let us know if you would like to check it out by contacting us at

We will also be adding support for Keil MDK-ARM 5, when it comes out of beta.

wolfSSL will be Exhibiting at Interop 2013

wolfSSL will be exhibiting at the 2013 Interop conference in Las Vegas next week. Interop brings together over ten thousand IT professionals for five days to provide training and education as well as providing an excellent networking opportunity. The Interop Expo consists of over 350 exhibitors covering a wide range of products and solutions. Interop has a 26 year history in the US and has expanded beyond its beginnings in network infrastructure to encompass a broad range of technologies including Cloud, Virtualization, Data Centers, Wireless & Mobility, and Information Security.

wolfSSL will be exhibiting in booth #460, talking about the CyaSSL Embedded SSL Library, wolfCrypt Embedded Crypto Engine, yaSSL Embedded Web Server, and SSL Inspection. If you have questions, are curious about our products, or would just like to chat about open source software, feel free to stop by!

Interop will be held at the Mandalay Bay Convention Center in Las Vegas, NV – from May 7th through the 9th. For more information about the conference, please visit the official site:

To schedule a meeting with wolfSSL during Interop, please contact us at

Looking for an IPv6 Compatible SSL Stack?

Many developers are now starting to think about IPv6 and what implications this will have on existing and future projects. IPv6 is becoming increasingly widespread and adoption will further continue to increase into the future.

As a developer, project manager, or curious individual, you may be faced with finding an SSL library which is compatible with IPv6. If so, rest assured! The wolfSSL embedded SSL library is compatible with both IPv4 and IPv6! The library itself has been designed to be IP neutral and work with either protocol version. In addition, we provide an easy-to-use build option to IPv6-enable our example applications for testing purposes.

To turn on IPv6 support when compiling wolfSSL and our example applications, use the “–enable-ipv6” build option:

./configure –enable-ipv6

Addresses beginning with fe80:: are link-local only. These addresses require an interface or scopeid suffix. For example, if ifconfig shows something similar to this:

inet6 fe80::62c5:47ff:fe97:ac2c%en1 prefixlen 64 scopeid 0x6

You could ping this address by doing either:

ping6 -I en1 fe80::62c5:47ff:fe97:ac2c


ping6 fe80::62c5:47ff:fe97:ac2c%en1

To start the wolfSSL example server using IPv6, remember to use the “-b” option to bind the server to any interface (unless localhost only is desired):

./examples/server/server -b

If an example wolfSSL example server was running on another link-local host (started with the “-b” option), a wolfSSL client could connect to it by doing something similar to:

./examples/client/client -h fe80::20c:29ff:fedc:e701%en1

Curious about how widespread IPv6 currently is? Google currently tracks IPv6 adoption here:, and you can see how many IPv6 hits/second Akamai is getting here:

If you have any questions about how to use wolfSSL with IPv6, or general questions about using wolfSSL embedded SSL or CTaoCrypt in areas such as the Internet of Things, smart energy, home automation, M2M communication, or cloud services, please get in touch with us at

Tax Day Release of wolfSSL 2.6.0

Sick of all the tax day giveaways that you don`t really need, or worse, have to wait in line for?  How about a no wait release of CyaSSL 2.6.0 instead?  New features include:

– DTLS 1.2 featuring AEAD ciphers.  We`re excited about this feature and welcome any feedback.

-SHA-3 finalist Blake is now supported.  Blake2b is extremely fast and uses very little resources, so we like it a lot.

– Support for SHA-384 cipher suites including ECC ones is included as well.  And if you ever need to do HMAC with SHA-512 that`s now supported as well.

– The example client/server can now track memory and stack use with -t and –enable-stacksize respectively.

– IPv6 examples/tests now allow link-local with scopeid resolution and full ipv6 addresses instead of defaulting to localhost.  As before, use –enable-ipv6 to turn on IPv6 in the examples and don`t forget -b on the server to bind to any interface.

– CYASSL_GENERAL_ALIGNMENT manipulates the SSL input/output buffers to align crypto access for easier integration with hardware support.  SSL itself isn`t very friendly to alignment with 5 byte TLS headers and 13 byte DTLS buffers, but we think we have a good solution for this.

– Many new ./configure options including disable/enable for rsa, dh, dsa, md5, sha, arc4, null (ciphers), oldtls, and asn (no certs or public keys allowed).  ./configure options are all lowercase now for better consistency.  A cyassl/options.h header is also now generated during the ./configure process that allows a user to easily use the same settings/flags that cyassl itself was built with.

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

Happy Tax Day,
Team wolfSSL

Is TLS False Start going to take off?

TLS requires both end points to have received and processed their peer`s Change Cipher Spec and Finished messages before starting to transfer their bulk encrypted data. It needs the Finished message to validate its peer`s identify. To save one round-trip time, an endpoint after having sent its Finished message could start sending its encrypted data using that cipher specification.

wolfSSL currently does not directly support TLS False Start, but it is tolerant of a peer sending its data immediately after sending its Finished message. It just will not send encrypted data to its peer until it has completed its handshake.

Do you need wolfSSL to handle TLS False Start? Contact us at

CTaoCrypt will be changing to wolfCrypt

We would like to give our users an early heads up that our cryptography library, CTaoCrypt will soon be changing names to wolfCrypt. With the name change, there may be some changes to the existing crypto API. You’ll also begin to see changes in our documentation and website.

If you have any questions about the conversion, please feel free to contact us at

– Team wolfSSL

wolfSSL adds support for SHA-3 finalist BLAKE

wolfSSL now supports BLAKE2b hashes at the cryptographic level.  Support for digest sizes from 256bits – 512 bits is included.  BLAKE was one of 5 finalists for the NIST hash competition to pick SHA-3.  BLAKE2 is an improved version that simplifies software implementations and has great speed while consuming little resources, a perfect fit for our philosophy.  BLAKE2b is the version that supports 256bit-512bit digests and is actually faster in software than MD5.  We`ve seen over 4 Gbps per core in our testing!  To try it out grab our latest branch at github and –enable-blake2 on the ./configure line.  It will be included in our next major release as well.

wolfSSL GitHub Repo:
BLAKE2 Website:

wolfSSL, provider of CyaSSL Embedded SSL, releases first embedded TLS and DTLS protocol fix for Lucky Thirteen Attack

Researchers have found a new a new attack vector for TLS 1.1 and 1.2 protocol implementations, which wolfSSL has promptly fixed in its leading embedded TLS product.

In the paper “Lucky Thirteen: Breaking the TLS and DTLS Record Protocols” authors Nadhem AlFardan and Kenneth Paterson present a family of attacks that apply to CBC-mode for TLS (1.1 and 1.2) and DTLS (1.0 and 1.2). All of the attacks are based on a delicate timing analysis of the decryption processing needed in block mode. The various attacks are distinguishing, partial plaintext recovery, and full plaintext recovery in nature. All the attacks exploit the protocol when badly formatted padding is handled during processing. A MAC verification must still be performed on something to prevent existing timing attacks. The RFCs suggest using a zero-length pad which was thought to be safe, but these attacks show that it can be exploited.

There are a few ways to avoid the attack. Using stream ciphers is the simplest. Stream ciphers like ARC4, HC- 128, and RABBIT are not vulnerable because they don`t use block mode and padding. HC-128 and RABBIT are unique to wolfSSL and also have the benefit of being extremely fast. Another way is to use Authenticated Encryption like AES-GCM and AES-CCM instead of block mode with CBC. wolfSSL includes several cipher suites utilizing Authenticated Encryption algorithms. Lastly, wolfSSL implemented the countermeasures suggested in the paper in version 2.5.0 to avoid timing attacks.

Founded in 2004, wolfSSL offers open-source, embedded security solutions that are fast, small, portable and standard compliant including CyaSSL, the C-language SSL library for embedded and RTOS environments; yaSSL, the embedded C++ SSL library; and yaSSL Embedded Web Server, a fast, embeddable, secure web server. Dual licensed, wolfSSL caters to the security applications in industrial automation, smart energy, surveillance, medical, military, telecommunications markets and the open-source community. Distributed worldwide, wolfSSL is headquartered in Bozeman, Montana.

Posts navigation

1 2 3 154 155 156 157 158 159 160 183 184 185

Weekly updates