wolfSSL at MSU Career Fair and Info Session

This year, wolfSSL will be hosting an info session introducing wolfSSL and its applications, and will also be exhibiting at the Montana State University (MSU) 2018 Fall Career Fair.

The info session takes place on Monday, October 1st from 5:00pm-6:00pm. The info session will be hosted in Roberts Hall, room 113. For directions, please refer to the MSU map here: http://calendar.msu.montana.edu/locations.php?building=1&ref=map. There will be free pizza and stickers as well for attendees!

The info session will cover topics such as what wolfSSL is, the company background, products, and work environment. There will also be a live demo of the wolfSSL library in action, complete with Wireshark analysis. Additionally, there will be a chance for attendees to ask questions about wolfSSL's paid Summer internship program.

To prepare for the info session, feel free to view our about page, product information pages, or try out our example applications.

In addition to the info session, wolfSSL will be attending MSU's 31st Annual Fall Career Fair on Thursday, October 4th, for the duration of the fair. Manning the booth will be various senior employees throughout the event, along with some of wolfSSL's current interns. Feel free to stop by to drop off a résumé, get firsthand feedback about wolfSSL internships, or to introduce yourself to wolfSSL's Bozeman team.

For more information, contact info@wolfssl.com, or download wolfSSL from our download page to test it out. We look forward to meeting you!

Certificate Signing Request (CSR) generation with wolfSSL

Over the past year we have had multiple inquiries regarding Certificate Signing Request (CSR) generation from users looking to programatically generate a CSR using wolfSSL. To better assist our users with this feature we have setup a ready-made example in our GitHub examples repository and we are adding a section about CSR functionality to the wolfSSL manual. The example mentioned can be found using the link below:

The new manual section will be in chapter 7: Section 7.9 “Certificate Signing Request (CSR) Generation” and is located on our website here: https://www.wolfssl.com/docs/wolfssl-manual/ch7/

Some notes on CSR’s and wolfSSL:

To configure wolfSSL for CSR generation please add these options:
./configure --enable-certreq --enable-certgen

wolfSSL can generate a CSR for a requesting party which is then be sent to a Certificate Authority for use in issuing a certificate for that party.

wolfSSL can either generate a certificate from scratch with all mandatory fields set or it can generate a CSR from scratch with optional fields excluded.



As some items are deemed “optional” in a CSR that are otherwise “mandatory” in a certificate, wolfSSL’s parsing engine does not yet support consuming a CSR for use in generating a certificate. The wolfSSL parsing engine strictly checks all features required in a certificate and considers them to be mandatory. Passing in a CSR that does not contain these features results in an error from the parsing engine at this time. wolfSSL does not yet have a timeline for adding the additional parsing rules to allow CSR consumption but if this is a feature you would like to see added please send the wolfSSL team a note at support@wolfssl.com so an upvote can be added on your behalf to that feature enhancement! Unique users requesting a specific feature escalates the priority of that feature so let the wolfSSL team know!

If you have any questions concerning CSR generation, feedback on the example provided, or anything else for that matter, please contact us anytime at support@wolfssl.com! Our support staff are ready, wiling, and eager to help our end users in any way they can!

wolfSSL support for Microsoft Azure Sphere (Pluton Security)

In early March 2018 we added support for the new Microsoft Azure Sphere microcontroller, which uses Pluton security for ECC P-256 key generation and sign/shared secret (ECDSA/ECDHE). This micro is targeting the embedded IoT space and supports Azure IoT cloud or any of your choosing. This chip uses wolfSSL and wolfCrypt for solving its TLS and Cryptographic security.



For more questions please email us at info@wolfssl.com.

wolfTPM support for STMicro ST33TP TPM 2.0 modules

We have added ST33TP support for the I2C and SPI version of the TPM 2.0 modules to the wolfTPM library.

STMicro ST33TP* TPM 2.0 Module Specifications:

  • Interfaces: SPI (33MHz) or I2C (400kHz)
  • Algorithms: RSA (1024/2048), ECC (224/256), AES (128/192/256), SHA1, SHA2, HMAC
  • Certifications: CC EAL4+ and FIPS 140-2 Level 2
  • NV Storage: 112KB

wolfTPM Library Features:

  • The design allows for easy portability to different platforms.
  • Native C code designed for embedded use.
  • Single IO callback for hardware interface.
  • No external library dependencies.
  • Compact code size and minimal memory use.
  • HAL IO callback examples for Raspberry Pi, STM32 CubeMX Hal and Atmel ASF.
  • Tested on ST ST33TP* SPI/I2C and Infineon Optiga SLB9670.

Wrappers to simplify:

  • Key Generation
  • RSA encrypt/decrypt
  • ECC sign/verify (ECDSA)
  • ECC shared secret (ECDH)
  • NV access (key and data storage)

Examples for:

  • All TPM2 native API’s
  • TPM wrappers
  • PKCS #7
  • Certificate Signing Request (CSR)
  • TLS Client/Server
  • Benchmarking

For the latest information and sources see GitHub here:

For more questions please email us at info@wolfssl.com.

wolfSSL now has lwIP support

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/

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 README.md and reference PK callbacks can be found here: https://github.com/wolfSSL/wolfssl/tree/master/wolfcrypt/src/port/st

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 info@wolfssl.com.

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 (https://github.com/wolfSSL/wolfssl/pull/1815). 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 README.md and reference PK callbacks can be found here: https://github.com/wolfSSL/wolfssl/tree/master/wolfcrypt/src/port/atmel

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 info@wolfssl.com.

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: http://www.mozilla.org/projects/security/pki/nss/ssl/draft302.txt
Comparison of SSLv2 and SSLv3: http://stason.org/TULARC/security/ssl-talk/4-11-What-is-the-difference-between-SSL-2-0-and-3-0.html

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: http://tools.ietf.org/html/rfc2246

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: http://tools.ietf.org/html/rfc4346#section-1.1

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: http://tools.ietf.org/html/rfc5246

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: https://tools.ietf.org/html/rfc8446

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)
Cisco – SSL: Foundation for Web Security (http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_1-1/ssl.html)

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

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: http://mynewt.apache.org/

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 README.md 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 README.md document in our “wolfssl-examples” repository on GitHub for information about build, test, and deployment methods.


Please contact us at info@wolfssl.com 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

Posts navigation

1 2