RECENT BLOG NEWS

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: https://github.com/cyassl/cyassl
BLAKE2 Website: https://blake2.net/

We have added DTLSv1.2 to wolfSSL. The latest sources are available in our GitHub repository. To enable DTLSv1.2 in wolfSSL, configure the build with the option “–enable-dtls”. We are very excited to offer this new protocol. If you are interested in discussing the cipher suites available for DTLSv1.2, please contact us at facts@wolfssl.com.

Here`s another good article on the Lucky Thirteen breach quoting SSL researcher Ivan Ristic:  http://www.computerworlduk.com/news/security/3424689/new-attack-techniques-against-ssl-revealed/

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.

Release 2.5.0 of the wolfSSL lightweight SSL/TLS library has been released and is now available for download. This release has bug fixes and new features including:

– Fix for TLS CBC padding timing attack identified by Nadhem Alfardan and Kenny Paterson: http://www.isg.rhul.ac.uk/tls/
– Microchip PIC32 (MIPS16, MIPS32) support
– Microchip MPLAB X example projects for PIC32 Ethernet Starter Kit
– Updated CTaoCrypt benchmark app for embedded systems
– 1024-bit test certs/keys and cert/key buffers
– AES-CCM-8 crypto and cipher suites
– Camellia crypto and cipher suites
– Bumped minimum autoconf version to 2.65, automake version to 1.12
– Addition of OCSP callbacks
– STM32F2 support with hardware crypto and RNG
– Cavium NITROX support

CTaoCrypt now has support for the Microchip PIC32 and has been tested with the Microchip PIC32 Ethernet Starter Kit, the XC32 compiler and MPLAB X IDE in both MIPS16 and MIPS32 instruction set modes. See the README located under the /mplabx directory for more details.

To add Cavium NITROX support do:

./configure –with-cavium=/home/user/cavium/software

pointing to your licensed cavium/software directory. Since Cavium doesn`t build a library we pull in the cavium_common.o file which gives a libtool warning about the portability of this. Also, if you`re using the github source tree you`ll need to remove the -Wredundant-decls warning from the generated Makefile because the cavium headers don`t conform to this warning. Currently wolfSSL supports Cavium RNG, AES, 3DES, RC4, HMAC, and RSA directly at the crypto layer. Support at the SSL level is parital and currently just does AES, 3DES, and RC4. RSA and HMAC are slower until the Cavium calls can be utilized in non blocking mode. The example client turns on cavium support as does the crypto test and benchmark. Please see the HAVE_CAVIUM define.

wolfSSL is able to use the STM32F2 or STM32F4 hardware-based cryptography and random number generator through the STM32F2 Standard Peripheral Library. For necessary defines, see the CYASSL_STM32F2 define in settings.h. Documentation for the STM32F2 Standard Peripheral Library can be found in the following document:
http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/USER_MANUAL/DM00023896.pdf

The wolfSSL manual is available online or in PDF format. For build instructions and comments about the new features please check the manual. If you have any question, please contact us at info@yassl.com.

Hi!  If you are a long time user of wolfSSL, then you probably know that we actively engage the open source community.  Our intention is to create more and better open source software for all to use and enjoy.  

What you may not know about is one of our key business policies, which is to provide free support to open source projects that consume our products.  So if you are building open source stuff, you are more than welcome to engage our support team for help.  The best way to do that is through our support forums.  However, if you have an issue that is sensitive, then you are welcome to email us at support@yassl.com.

We have added the Camellia-CBC cipher to CTaoCrypt and wolfSSL. The following cipher suites are available for TLS:

• TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
• TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
• TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256
• TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256
• TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
• TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
• TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256
• TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256

Camllia-CBC will be available in our next release. The latest sources are available in our GitHub repository. To enable Camellia-CBC in wolfSSL, configure the build with the option “–enable-camellia”. We are very excited to offer this new cipher. If you are interested in other Camellia cipher suites, including any ECC cipher suites, please contact us at info@yassl.com.

Ever wondered how to use PSK with the embedded wolfSSL library?  PSK is useful in resource constrained devices where public key operations may not be viable.  It`s also helpful in closed networks where a Certificate Authority structure isn`t in place.  To enable PSK with wolfSSL you can simply do:

$ ./configure --enable-psk

Using PSK on the client side requires one additional function call:

wolfSSL_CTX_set_psk_client_callback()

There`s an example client callback in cyassl/test.h called my_psk_client_cb().  The example sets the client identity which is helpful for the server if there are multiple clients with unique keys and is limited to 128 bytes.  It could also examine the server identity hint in case the client is talking to multiple servers with unique keys.  Then the pre-shared key is returned to the caller, here that is simply 0x1a2b3c4d, but it could be any key up to 64 bytes in length (512 bits).

On the server side two additional calls are required:

wolfSSL_CTX_set_psk_server_callback()
wolfSSL_CTX_use_psk_identity_hint()

The server stores it`s identity hint to help the client with the 2nd call, in our server example that`s “cyassl server”.  An example server psk callback can also be found in my_psk_server_cb() in cyassl/test.h.  It verifies the client identity and then returns the key to the caller, which is again 0x1a2b3c4d, but could be any key up to 64 bytes in length.  If you have any questions about using PSK with TLS please let us know.

We want to let our users and followers know that we recently updated the API documentation for the wolfSSL embedded SSL library. With this update, all functions in the standard wolfSSL build (98) are now documented plus an additional 19 related to various defines related to DTLS, Callbacks, DER-specific, NTRU or OpenSSL extra functions.

You can find the updated API documentation online in Chapter 17 of the wolfSSL Manual, here:

http://yassl.com/yaSSL/Docs-cyassl-manual-17-cyassl-api-reference.html

If you have any questions, please let us know at info@yassl.com.

We have added the Counter with CBC-MAC Mode with 8?byte authentication (CCM-8) for AES to wolfSSL. The following cipher suites are available for TLS v1.2:

• TLS_RSA_WITH_AES_256_CCM_8_SHA384
• TLS_RSA_WITH_AES_128_CCM_8_SHA256

AES with CCM-8 will be available in our next release. The latest sources are available in our GitHub repository. To enable AES with CCM-8 in wolfSSL, configure the build with the option “??enable?aesccm”. We are very excited to offer this new cipher. If you are interested in other AES-CCM-8 cipher suites, including any ECC cipher suites, please contact us at info@yassl.com.