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.
In addition, wolfSSL now has a support-specific blog page dedicated to answering some of the more commonly received support questions.

wolfSSL 3.15.3 Now Available

wolfSSL is proud to announce release version 3.15.3 of the wolfSSL embedded TLS library.  This release contains bug fixes and new features, which include:

  • ECDSA blinding added for hardening against side channel attacks
  • Fix for OpenSSL compatibility layer build with no server (NO_WOLFSSL_SERVER) and no client (NO_WOLFSSL_CLIENT) defined
  • Intel assembly instructions support for compatible AMD processors
  • wolfCrypt port for Mentor Graphics Nucleus RTOS
  • Fix added for MatchDomainName() with additional tests added
  • Fixes for building with ‘WOLFSSL_ATECC508A’ defined
  • Fix for verifying a PKCS7 files in BER format with indefinite size

This release of wolfSSL fixes 2 security vulnerability fixes:

Medium level fix for PRIME + PROBE attack combined with a variant of Lucky 13.  Constant time hardening was done to avoid potential cache-based side channel attacks when verifying the MAC on a TLS packet. CBC cipher suites are susceptible on systems where an attacker could gain access and run a parallel program for inspecting caching. Only wolfSSL users that are using TLS/DTLS CBC cipher suites need to update. Users that have only AEAD and stream cipher suites set, or have built with WOLFSSL_MAX_STRENGTH (--enable-maxstrength), are not vulnerable. Thanks to Eyal Ronen, Kenny Paterson, and Adi Shamir for the report.

Medium level fix for a ECDSA side channel attack. wolfSSL is one of over a dozen vendors mentioned in the recent Technical Advisory “ROHNP” by author Ryan Keegan. Only wolfSSL users with long term ECDSA private keys using our fastmath or normal math libraries on systems where attackers can get access to the machine using the ECDSA key need to update. An attacker gaining access to the system could mount a memory cache side channel attack that could recover the key within a few thousand signatures. wolfSSL users that are not using ECDSA private keys, that are using the single precision math library, or that are using ECDSA offloading do not need to update. (blog with more information:

For more information, please contact You can see the full change log in the source archive from our website at or at our GitHub repository.

wolfSSL support for STSAFE-A100 crypto coprocessor

wolfSSL supports the STMicro STSAFE-A100 I2C cryptographic coprocessor. It's capable of ECC sign/verify (ECDSA) and shared secret (ECDH) operations for 256-bit and 384-bit (NIST Prime and Brainpool) curves. It has 2 key slots and 6KB of non-volatile memory for certificate or data storage.


  • Requires the STSAFE-A Device Library from ST
  • Requires wolfSSL interface and crypto configuration code (available by request and approval from ST)


  • wolfSSL uses PK callbacks for the TLS crypto operations
  • wolfCrypt uses the WOLFSSL_STSAFEA100 macro to enable native `wc_ecc_*` API support

The and reference PK callbacks can be found here:

Preprocessor Macros:


PK Callbacks:

wolfSSL TLS layer PK callbacks expose API’s to set ECC callbacks.Enabled with: #define HAVE_PK_CALLBACKS or ./configure --enable-pkcallbacks.

Reference API’s:

  • SSL_STSAFE_CreateKeyCb
  • SSL_STSAFE_SignCertificateCb
  • SSL_STSAFE_VerifyPeerCertCb
  • SSL_STSAFE_SharedSecretCb

Reference API for loading device certificate:

  • SSL_STSAFE_LoadDeviceCertificate

For more questions please email us at

wolfSSL support for the ATECC508A/ATECC608A crypto coprocessor

wolfSSL embedded SSL/TLS support the latest Microchip ATECC508A and ATECC608A I2C cryptographic coprocessors. The latest round of fixes to support the most recent CryptoAuthLib are in a pull request here ( We have not yet tested with the ATECC608A due to lack of hardware, but wolfSSL is compatible with the latest CryptoAuthLib. We plan on adding support for the new 608A PRF and HKDF for TLS 1.2 and TLS 1.3 speed improvements.



  • wolfSSL uses PK (Public Key) callbacks for the TLS crypto operations
  • wolfCrypt uses the WOLFSSL_ATECC508A macro to enable native `wc_ecc_*` API support

The and reference PK callbacks can be found here:

Additional demos for wolfSSL TLS Client/Server and wolfCrypt test/benchmarks can be found:

Preprocessor Macros:


PK Callbacks:

wolfSSL’s TLS layer PK callbacks expose API’s to set ECC callbacks. These are enabled with: #define HAVE_PK_CALLBACKS or ./configure --enable-pkcallbacks.

Reference API’s:

  • atcatls_create_key_cb
  • atcatls_verify_signature_cb
  • atcatls_sign_certificate_cb
  • atcatls_create_pms_cb

For more questions please email us at

Differences between SSL and TLS Protocol Versions (#TLS13)

Have you heard talk about SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2, and TLS 1.3 but never really knew the differences between the different versions? Secure Socket Layer (SSL) and Transport Security Layer (TLS) are both cryptographic protocols which provide secure communication over networks. These different versions are all in widespread use today in applications such as web browsing, e-mail, instant messaging and VoIP, and each is slightly different from the others.wolfSSL supports all three of these ciphers to best suit your needs and requirements. Below you will find the major differences between the different protocol versions.

SSL 3.0
This protocol was released in 1996, but first began with the creation of SSL 1.0 developed by Netscape. Version 1.0 wasn`t released, and version 2.0 had a number of security flaws, thus leading to the release of SSL 3.0. Some major improvements of SSL 3.0 over SSL 2.0 are:
– Separation of the transport of data from the message layer
– Use of a full 128 bits of keying material even when using the Export cipher
– Ability of the client and server to send chains of certificates, thus allowing organizations to use certificate hierarchy which is more than two certificates deep.
– Implementing a generalized key exchange protocol, allowing Diffie-Hellman and Fortezza key exchanges as well as non-RSA certificates.
– Allowing for record compression and decompression
– Ability to fall back to SSL 2.0 when a 2.0 client is encountered

Netscape`s Original SSL 3.0 Draft:
Comparison of SSLv2 and SSLv3:

TLS 1.0
This protocol was first defined in RFC 2246 in January of 1999. This was an upgrade from SSL 3.0 and the differences were not dramatic, but they are significant enough that SSL 3.0 and TLS 1.0 don`t interoperate. Some of the major differences between SSL 3.0 and TLS 1.0 are:
– Key derivation functions are different
– MACs are different – SSL 3.0 uses a modification of an early HMAC while TLS 1.0 uses HMAC.
– The Finished messages are different
– TLS has more alerts
– TLS requires DSS/DH support

RFC 2246:

TLS 1.1
This protocol was defined in RFC 4346 in April of 2006, and is an update to TLS 1.0. The major changes are:
– The Implicit Initialization Vector (IV) is replaced with an explicit IV to protect against Cipher block chaining (CBC) attacks.
– Handling of padded errors is changed to use the bad_record_mac alert rather than the decryption_failed alert to protect against CBC attacks.
– IANA registries are defined for protocol parameters
– Premature closes no longer cause a session to be non-resumable.

RFC 4346:

TLS 1.2
This protocol was defined in RFC 5246 in August of 2008. Based on TLS 1.1, TLS 1.2 contains improved flexibility. The major differences include:
– The MD5/SHA-1 combination in the pseudorandom function (PRF) was replaced with cipher-suite-specified PRFs.
– The MD5/SHA-1 combination in the digitally-signed element was replaced with a single hash. Signed elements include a field explicitly specifying the hash algorithm used.
– There was substantial cleanup to the client`s and server`s ability to specify which hash and signature algorithms they will accept.
– Addition of support for authenticated encryption with additional data modes.
– TLS Extensions definition and AES Cipher Suites were merged in.
– Tighter checking of EncryptedPreMasterSecret version numbers.
– Many of the requirements were tightened
– Verify_data length depends on the cipher suite
– Description of Bleichenbacher/Dlima attack defenses cleaned up.

RFC 5246:

TLS 1.3
This protocol is currently being revised, and is in its 28th draft. The major differences from TLS 1.2 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.

RFC 8446:

If you would like to read more about SSL or TLS, here are several resources that might be helpful:
TLS – Wikipedia (
SSL versus TLS – What`s the Difference? (
Cisco – SSL: Foundation for Web Security (

As always, if you have any questions or would like to talk to the wolfSSL team about more information, please contact

wolfSSL Support for Apache Mynewt

Apache Mynewt

Apache Mynewt is a operating system which is Open Source, modular and realtime (RTOS). It is designed for IoT devices that have limited memory and storage and need to run for a long time with minimal power consumption. More details of Apache Mynewt can be found on the project’s website:

wolfSSL is happy to announce support for Apache Mynewt! We have added a new preprocessor define to enable the mynewt port layer in wolfSSL, called WOLFSSL_APACHE_MYNEWT. This port uses Mynewt’s raw socket interface, “mnsocket”, to send and receive data over the SSL/TLS connection.

In order to use wolfSSL in your mynewt project, You need to deploy wolfSSL source code to the project. Please see the document included with wolfSSL for information about deployment and build methods.  Our Mynewt port and project documentation is located in the “IDE/mynewt” directory of the wolfSSL package:

We also created an example wolfSSL client for Mynewt.  To use the wolfSSL client sample in your mynewt project, you first need to first deploy the “wolfssl-example” source code to the project.  Please see the document in our “wolfssl-examples” repository on GitHub for information about build, test, and deployment methods.

Please contact us at if you would like more information about our Apache Mynewt support or about the wolfSSL SSL/TLS library in general. wolfSSL also now supports TLS 1.3 and FIPS 140-2, both of which could now be used in conjunction with Apache Mynewt!

wolfSSL Xilinx Support

wolfSSL now supports Xilinx SoCs and FPGAs. The wolfSSL embedded SSL/TLS library can be used with FPGAs which use the MicroBlaze CPU and/or Zynq and Zynq UltraScale+ SoCs. Improved performance speeds with using the hardware crpyto can be seen. Increasing AES-GCM, RSA, and SHA3 operations performance. In addition to the performance gained a user also gets the additional security the hardware provides while executing the algorithms.

For more information contact

How to speed up handshake times when using ECDHE (and/or ECDSA)

We have had some reports of low-end embedded systems taking 10-20 seconds to establish a TLS connection when generating a shared secret using the ECDH algorithm.

We wanted to remind our users of the fixed-point caching mechanism provided by wolfSSL. Users can enable fixed point caching with the configure option --enable-fpecc or by defining FP_ECC in their settings. Users will also need to configure which look up table (FP_LUT) to use and the number of entries (FP_ENTRIES).

FP_LUT: General rule is the larger the table, the more memory is needed but the faster subsequent lookup operations will be.

FP_ENTRIES: The number of entries allowed in the cache.

By default if users are not using the autoconf system (IE ./configure --enable-fpecc) users can start by adding these to either wolfssl/wolfcrypt/settings.h or their own user_settings.h when defining WOLFSSL_USER_SETTINGS globally:

/* Fixed point cache (speeds repeated operations against same private key) */
#undef  FP_ECC
#define FP_ECC
#ifdef FP_ECC
    /* Bits / Entries */
    #undef  FP_ENTRIES
    #define FP_ENTRIES  2
    #undef  FP_LUT
    #define FP_LUT      4  /* NOTE: FP_LUT must be between 2 and 12 inclusively */

Users can pre-cache fixed points on a curve related to a specific private key prior to establishing a connection to speed up shared secret computation times. Below we have provided some sample code users might use to accomplish this “pre-caching”. Ideally this would be a function you would run on system start-up or initialization of your embedded device prior to establishing a connection:

#include <stdio.h>
#include <string.h>

/* NOTE: ALWAYS include options.h or settings.h before any other wolf headers */
#include <wolfssl/options.h>
#include <wolfssl/wolfcrypt/settings.h>
#include <wolfssl/wolfcrypt/ecc.h>
#include <wolfssl/wolfcrypt/asn.h>

/* Build wolfSSL using ./configure --enable-fpecc or by adding #define FP_ECC to your user_settings.h. */

/* Fixed client ECC key */
static const unsigned char ecc_clikey_der_256[] =
    0x30, 0x77, 0x02, 0x01, 0x01, 0x04, 0x20, 0xF8, 0xCF, 0x92,
    0x6B, 0xBD, 0x1E, 0x28, 0xF1, 0xA8, 0xAB, 0xA1, 0x23, 0x4F,
    0x32, 0x74, 0x18, 0x88, 0x50, 0xAD, 0x7E, 0xC7, 0xEC, 0x92,
    0xF8, 0x8F, 0x97, 0x4D, 0xAF, 0x56, 0x89, 0x65, 0xC7, 0xA0,
    0x0A, 0x06, 0x08, 0x2A, 0x86, 0x48, 0xCE, 0x3D, 0x03, 0x01,
    0x07, 0xA1, 0x44, 0x03, 0x42, 0x00, 0x04, 0x55, 0xBF, 0xF4,
    0x0F, 0x44, 0x50, 0x9A, 0x3D, 0xCE, 0x9B, 0xB7, 0xF0, 0xC5,
    0x4D, 0xF5, 0x70, 0x7B, 0xD4, 0xEC, 0x24, 0x8E, 0x19, 0x80,
    0xEC, 0x5A, 0x4C, 0xA2, 0x24, 0x03, 0x62, 0x2C, 0x9B, 0xDA,
    0xEF, 0xA2, 0x35, 0x12, 0x43, 0x84, 0x76, 0x16, 0xC6, 0x56,
    0x95, 0x06, 0xCC, 0x01, 0xA9, 0xBD, 0xF6, 0x75, 0x1A, 0x42,
    0xF7, 0xBD, 0xA9, 0xB2, 0x36, 0x22, 0x5F, 0xC7, 0x5D, 0x7F,
static const int sizeof_ecc_clikey_der_256 = sizeof(ecc_clikey_der_256);

int pre_cache_my_priv_key(void)
    int ret;
/* If we plan on caching fixed points for ECC operations... */
#ifdef FP_ECC
    word32 idx = 0;
    WC_RNG rng;
    ecc_key dummyPubKey;
    ecc_key myPrivKey;
    word32 x = 32; /* large enough for 256-bit */
    unsigned char exportBuf[x];


    ret = wc_ecc_make_key(&rng, 32, &dummyPubKey);
    if (ret != 0) {
        printf("Failed to make the public key\n");
        return -1;

    ret = wc_EccPrivateKeyDecode(ecc_clikey_der_256, &idx,
                                 &myPrivKey, sizeof_ecc_clikey_der_256);
    if (ret != 0) {
        printf("Failed to import private key, ret = %d\n", ret);
        return -1;

    ret = wc_ecc_shared_secret(&myPrivKey, &dummyPubKey, exportBuf, &x);
    if (ret != 0) {
        printf("Failed to generate a shared secret\n");
        return -1;

    printf("Successfully pre-cached curve points!\n");
    ret = 0;

    return ret;

int main(void)
    int ret;

    ret = pre_cache_my_priv_key();

   /* Do other interesting things, establish a TLS connection, etc. */

   wolfSSL_Cleanup(); /* Calls the wc_ecc_fp_free() function to free cache resources */

   return 0;

If you have any questions on the above solution please contact us anytime at! If you have feedback or comments please send a note to we would love to hear from you!

TLS 1.3 combined with FIPS (#FIPS #TLS13)

wolfSSL is a lightweight TLS/SSL library that is targeted for embedded devices and systems. It has support for the TLS 1.3 protocol, which is a secure protocol for transporting data between devices and across the Internet. In addition, wolfSSL uses the wolfCrypt encryption library to handle its data encryption.

Because there is a FIPS 140-2 validated version of wolfCrypt, this means that wolfSSL not only has support for the most current version of TLS, but it also has the encryption backbone to support your FIPS 140-2 needs if required.

Some key benefits of combining TLS 1.3 with FIPS validated software include:

  1. Software becomes marketable to federal agencies - without FIPS, a federal agency is not able to use cryptographic-based software
  2. Single round trip
  3. 0-RTT (a mode that enable zero round trip time)
  4. After Server Hello, all handshake messages are encrypted.

And much more! For more information regarding the benefits of using TLS 1.3 or using the FIPS validated version of wolfCrypt, check out wolfSSL's TLS 1.3 Protocol Support and our wolfCrypt FIPS page.

FIPS 140-2 is a government validation that certifies that an encryption module has successfully passed rigorous testing and meets high encryption standards as specified by NIST. For more information or details on FIPS 140-2, it may be helpful to view this Wikipedia article:

For more details about wolfSSL, TLS 1.3, or if you have any other general inquiries please contact

To find out more about FIPS, check out the NIST FIPS publications or contact

Using cURL with wolfSSL and TLS 1.3

cURL is an open-source project that provides the command line tool, curl, for transferring data between client and server with URLs, powered by cURL’s library, libcurl. curl and libcurl both provide support for building SSL/TLS libraries, including wolfSSL! The latest version of cURL can be downloaded from

To build curl with wolfSSL, simply configure and install curl with:

$ ./configure --with-wolfssl --without-ssl
$ make && make install

Starting with version 7.52.0, curl provides TLS 1.3 support when built with a TLS library. TLS 1.3 protocol support is also currently available in the wolfSSL library. Since both curl and wolfSSL support TLS 1.3, curl can be compiled with the addition of wolfSSL to select the TLS 1.3 protocol.

Configuring wolfSSL and curl to implement TLS 1.3 is simple. To build curl and libcurl with wolfSSL, wolfSSL must first be configured with TLS 1.3 support.

To enable TLS 1.3 support in wolfSSL, compile and install wolfSSL with the “–enable-tls13” option:

$ ./configure --enable-tls13
$ make && make install

Then, build curl with TLS 1.3-enabled wolfSSL:

$ ./configure --with-wolfssl --without-ssl
$ make && make install

To test a TLS 1.3 connection with curl + wolfSSL, invoke curl with the –tlsv1.3 option on a server that supports TLS 1.3. For example:

$ curl --tlsv1.3

A successful connection will return the HTML page downloaded from


For more information on the cURL project, visit

If you would like more information about wolfSSL’s support for TLS 1.3 or help on using it in your application, contact us at

wolfSSL at RIOT Summit

wolfSSL will be attending and exhibiting at RIOT Summit 2018, in Amsterdam, Netherlands. wolfSSL engineer Daniele Lacamera will be giving a talk titled "TLS v1.3 and RIOT OS", on Thursday, September 13th during the IoT Security Session (1:30pm - 3:30pm). Additionally, wolfSSL expert and Business Director, Rod Weaver will be attending the event on Thursday, September 13th.

RIOT Summit 2018 will be held on September 13th and 14th, at the Science Park Congress Center (directions).

Stop by to hear Daniele's presentation, to have questions about wolfSSL/licensing wolfSSL answered in person, or email us at for more details.

wolfSSL also supports TLS 1.3, and will have TLS 1.3 stickers on hand. We look forward to seeing you there!

Live Webinar – Build wolfSSL Into Secure Enclaves

Please join wolfSSL Senior Engineer David Garske for the live webinar, "Build wolfSSL into secure enclaves / ST, Infineon, Microchip". Explore wolfSSL's support of external crypto hardware (I.E. secure enclaves). Specifically the Infineon SLB 9670 and ST33 TPM 2.0, Microchip ATECC508A and the ST ST-SAFE100A chips we support.

Please register for one of the following times:

When: Sep 12, 2018 3:00 PM Central European Time
Register in advance for this webinar:

When: Sep 12, 2018 10:00 AM Pacific Time (US and Canada)
Register in advance for this webinar:

When: Sep 14, 2018 10:00 AM Singapore
Register in advance for this webinar:

After registering, you will receive a confirmation email containing information about joining the webinar.

We look forward to seeing you there!

For more information regarding the webinar or wolfSSL, please contact

Posts navigation

1 2 3 4 76 77 78

Weekly updates


Latest Tweets