RECENT BLOG NEWS

Recent releases of wolfSSL have included new assembly code targeted at the Intel x86_64 platform. Large performance gains have been made which are being discussed over a six blog post series. In this first blog, we will talk about the performance of AES-GCM.

The assembly code for AES-GCM has been rewritten to take best advantage of the AVX1 and AVX2 instructions. The performance of AES-GCM is now as good or better than OpenSSL.

The two charts below show the relative performance of AES-128-GCM encryption on an Intel AVX1 and AVX2 chipsets. They compare the performance of wolfSSL and OpenSSL with an older version of wolfSSL (before the assembly code changes).

Small block size performance is important when dealing with locally stored data like keys or data in a database. Meanwhile, large block size performance is important for large data transfers in TLS.

The performance of wolfSSL has significantly improved from small up to big block sizes. On AVX1, the smallest block size performance has increased by over 130% and at the top end, there is a 42% improvement. Similarly, on AVX2, the improvement is over 150% for small block sizes to 11% for large block sizes. The new wolfSSL assembly code is also significantly better than OpenSSL for small blocks and is about the same at the largest block size. Similar performance improvements have been achieved for AES-256-GCM as well.

If you have questions about using the wolfSSL embedded TLS library on your platform, or about performance optimization of the library, contact us at support@wolfssl.com.

References:

Introduction to Intel® Advanced Vector Extensions
Advanced Vector Extensions (Wikipedia)

Since version 3.6.6, wolfSSL has had continually improving support for stunnel, a lightweight TLS proxy, designed to add SSL/TLS encryption to unsecured applications without changes to the program`s source code. Licensed under GNU GPLv2 and with an alternative commercial option, stunnel can be utilized to secure a host of different applications, including: mail exchange (SMTP, IMAP, POP3), web hosting (HTTP), remote shell, and virtually any other unprotected protocol desired.

Porting stunnel to use wolfSSL`s embedded SSL/TLS library means taking advantage of wolfSSL`s minimal footprint and high speed crypto implementation to increase performance and decrease required resources when compared to the previous SSL library. Not only that, but using wolfSSL with stunnel combines these benefits with the peace of mind that your application is secured by a progressive, transparent and stable SSL/TLS library, known for its quality, integrity and efficiency.

To build wolfSSL for use with stunnel, simply configure wolfSSL with:

$ ./configure --enable-stunnel

from wolfSSL`s main directory, then make and make install.

For a version of stunnel that links to the wolfSSL library, or for more information, contact us at facts@wolfssl.com.

With the latest wolfMQTT v1.1 release you can easily connect your devices running wolfMQTT to IBM’s Watson IoT Platform. Trying out wolfMQTT is simple using the provided MQTT client example and your IBM Cloud account. The default example provides a link to the IBM Quickstart broker where you can view a graph generated by the data without an account.

As a side note, wolfMQTT uses the wolfSSL embedded SSL/TLS library for SSL/TLS support.  Since wolfSSL supports TLS 1.3, your wolfMQTT-based projects can now use MQTT with TLS 1.3 with a supported broker!

You can download the latest release from our website or clone on GitHub. For more information please email us at facts@wolfssl.com.

The wolfSSL (formerly CyaSSL) embedded SSL library supports lwIP, the light weight internet protocol implementation, out of the box.  The user merely needs to define WOLFSSL_LWIP or uncomment the line /* #define WOLFSSL_LWIP */ in os_settings.h to use wolfSSL with lwIP.  

The focus of lwIP is to reduce RAM usage while still providing a full TCP stack.  That focus makes lwIP great for use in embedded systems, the same area where wolfSSL is an ideal match for SSL/TLS needs.  An active community exists with contributor ports for many systems.  Give it a try and let us know if you have any suggestions or questions.

For the latest news and releases of lwIP, you can visit the project homepage, here: http://savannah.nongnu.org/projects/lwip/

Our third post in our PKCS series, we will be looking at PKCS  #5. PKCS #5 is the Password-Based Cryptography Specification and is currently defined by version 2.0 of the specification. It is defined in RFC 2898 http://tools.ietf.org/html/rfc2898. It applies a pseudorandom function, such as a cryptographic hash, cipher, or HMAC to the input password or passphrase along with a salt value and repeats the process many times to produce a derived key, which can then be used as a cryptographic key in subsequent operations. The added computational work makes password cracking much more difficult, and is known as key stretching.

A. Key Derivation Functions

A key derivation function produces a derived key from a based key and other parameters. In a password-based key derivation function, the base key is a password and the other parameters are a salt value and an iteration count.

Two functions are specified below: PBKDF1 and PBKDF2. PBKDF2 is recommended for new applications; PBKDF1 is included only for compatibility with existing applications, and is not recommended for new applications.

B. PBKDF1

PBKDF1 applies a hash function, which shall be MD2, MD5 or SHA-1, to derive keys. The lengths of the derived keying bounded by the length of the hash function output, which is 16 octets from MD2 and MD5 and 20 octets from SHA-1.

Steps:

1. If dkLen > 16 for MD2 and MD5, or dkLen > 20 for SHA-1, output “derived key too long” and stop.

2. Apply the underlying hash function Hash for c iterations to the concatenation of the password P and

    the salt S, then extract the first dkLen octets to produce a derived key DK:

T_1 = Hash (P || S) ,

T_2 = Hash (T_1) ,

…

T_c = Hash (T_{c-1}) ,

DK = Tc<0..dkLen-1>

3. Output the derived key DK.

C. PBKDF2

PBKDF2 applies a pseudorandom function to derive keys. The length of the derived key is essentially unbounded. However, the maximum effective search space for the derived key may be limited by the structure of the underlying pseudorandom function.

Steps:

1. If dkLen > (2^32 – 1) * hLen, output “derived key too long” and stop.

2. Let l be the number of hLen-octet blocks in the derived key, rounding up, and let r be the number of octets

    in the last block:

l = CEIL (dkLen / hLen) ,

r = dkLen – (l – 1) * hLen .

Here, CEIL (x) is the “ceiling” function, i.e. the smallest integer greater than, or equal to, x.

3. For each block of the derived key apply the function F defined below to the password P, the salt S, the

    iteration count c, and the block index to compute the block:

T_1 = F (P, S, c, 1) ,

T_2 = F (P, S, c, 2) ,

…

T_l = F (P, S, c, l) ,

where the function F is defined as the exclusive-or sum of the first c iterates of the underlying pseudorandom  function PRF applied to the password P and the concatenation of the salt S and the block index i:

F (P, S, c, i) = U_1 \xor U_2 \xor … \xor U_c

where

U_1 = PRF (P, S || INT (i)) ,

U_2 = PRF (P, U_1) ,

…

U_c = PRF (P, U_{c-1}) .

Here, INT (i) is a four-octet encoding of the integer i, most significant octet first.

4. Concatenate the blocks and extract the first dkLen octets to produce a derived key DK:

DK = T_1 || T_2 ||  …  || T_l<0..r-1>

5. Output the derived key DK.

To learn more about PKCS #5, you can look through the specification, here:

http://tools.ietf.org/html/rfc2898

D. CyaSSL Support

CyaSSL supports both PBKDF1 and PBKDF2. The header file can be found in <cyassl_root>/cyassl/ctaocrypt/pwdbased.h and the source file can be found in <cyassl_root>/ctaocrypt/src/pwdbased.c of the CyaSSL library. When using these functions, they must be enabled when CyaSSL is configured. This is done by:

./configure –enable-pwdbased

The functions:

int PBKDF1(byte* output, const byte* passwd, int pLen,
           const byte* salt, int sLen, int iterations, int kLen,
           int hashType);
int PBKDF2(byte* output, const byte* passwd, int pLen,
           const byte* salt, int sLen, int iterations, int kLen,
           int hashType);

CyaSSL also supports PKCS12

int PKCS12_PBKDF(byte* output, const byte* passwd, int pLen,
                 const byte* salt, int sLen, int iterations,
                 int kLen, int hashType, int purpose);

To learn more about the CyaSSL embedded SSL library, you can download a free GPLv2-licensed copy from the wolfSSL download page, http://wolfssl.com/yaSSL/download/downloadForm.php, or look through the CyaSSL Manual, https://www.wolfssl.com/docs/wolfssl-manual/.  If you have any additional questions, please contact us at facts@wolfssl.com.

PSK cipher suites are a superb choice in low resource environments where both ends of the connection can be controlled. With PSK, each side of the connection has an already agreed upon key to use rather than agreeing on one during the TLS handshake. This reduces resource consumption for each session using PSK.

For example, on one of wolfSSL’s test machines the cipher suite DHE-PSK-AES128-CBC-SHA256 has an average connection time of 3.498 milliseconds with a peak byte usage of 6,335. On the same machine a similar cipher suite DHE-RSA-AES128-SHA256, not using PSK, has an average connection time of 7.146 milliseconds and peak byte usage of 19,431. wolfSSL always recommends using ephemeral keys (DHE or ECDHE) to maintain forward secrecy but in an ultra limited resource environment, memory and speed can be further improved by using a static PSK cipher suite such as PSK-AES128-CBC-SHA.

In addition to RAM reduction, using PSK can reduce the library footprint size as well. One of the smallest wolfSSL builds to date has been the LeanPSK build, which comes in at around 21kB.  For comparison, a typical build on an embedded, optimized compiler will be 60-100kB.

For information regarding the use of PSK cipher suites or general inquiries about wolfSSL’s embedded SSL/TLS library contact us!

Wikipedia: https://en.wikipedia.org/wiki/TLS-PSK

With the release of TLS 1.3, there are promises of enhanced security and speed. But how exactly do the changes from TLS 1.2 to TLS 1.3 cause these improvements? The following is a list of differences between TLS 1.2 and 1.3 that shows how the improvements are achieved.

wolfSSL is among the first libraries to support TLS 1.3. Below are the major differences between TLS 1.2 and TLS 1.3

TLS 1.3

This protocol is defined in Draft 28. TLS 1.3 contains improved security and speed. The major differences include:

• The list of supported symmetric algorithms has been pruned of all legacy algorithms. The remaining algorithms all use Authenticated Encryption with Associated Data (AEAD) algorithms.

• A zero-RTT (0-RTT) mode was added, saving a round-trip at connection setup for some application data at the cost of certain security properties.

• Static RSA and Diffie-Hellman cipher suites have been removed; all public-key based key exchange mechanisms now provide forward secrecy.

• All handshake messages after the ServerHello are now encrypted.

• Key derivation functions have been re-designed, with the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) being used as a primitive.

• The handshake state machine has been restructured to be more consistent and remove superfluous messages.

• ECC is now in the base spec  and includes new signature algorithms. Point format negotiation has been removed in favor of single point format for each curve.

• Compression, custom DHE groups, and DSA have been removed, RSA padding now uses PSS.

• TLS 1.2 version negotiation verification mechanism was deprecated in favor of a version list in an extension.

• Session resumption with and without server-side state and the PSK-based ciphersuites of earlier versions of TLS have been replaced by a single new PSK exchange.

Internet Draft: https://tools.ietf.org/html/draft-ietf-tls-tls13-28

Resources:

If you would like to read more about SSL or TLS, here are several resources that might be helpful:

TLS – Wikipedia (http://en.wikipedia.org/wiki/Transport_Layer_Security)
SSL versus TLS – What`s the Difference? (http://luxsci.com/blog/ssl-versus-tls-whats-the-difference.html)
Differences Between SSL and TLS Protocol Versions (http://www.wolfssl.com/differences-between-ssl-and-tls-protocol-versions/)
Cisco – SSL: Foundation for Web Security (http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_1-1/ssl.html)