Category: Uncategorized

The wolfSSL team continues to embrace the open source community for the ever expanding product line of Espressif chips with support for the RISC-V architecture of the ESP32-C3.

Do you want to use world-class encryption software on your next ESP32 project? Check out the fully open-source wolfSSL codebase. The code continues to be free to use for makers under the terms of GPLv2. Commercial users for any size project are encouraged to contact us for licensing, professional support, and engineering development services.

Try out the wolfSSL encryption libraries today! Wondering which board to use? Check out our friends creating the ICE-V Wireless RISC-V ESP32-C3 and ice40 FPGA board. There’s a community example using this board for the wolfSSL SSH to UART Server.

We are currently working on adding RISC-V cryptographic hardware acceleration and support for the Espressif ESP-IDF Version 5.0.

For the RISC-V ESP32-C3-MINI with software only running at 160MHz here are our current wolfSSL benchmarks, using a user_settings.h file from GitHub, but hardware acceleration disabled:

ESP-ROM:esp32c3-api1-20210207
Build:Feb  7 2021
rst:0x1 (POWERON),boot:0xc (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fcd5820,len:0x16dc
load:0x403cc710,len:0x96c
load:0x403ce710,len:0x2e2c
entry 0x403cc710
I (30) boot: ESP-IDF v5.0-dirty 2nd stage bootloader
I (30) boot: compile time 15:02:47
I (30) boot: chip revision: v0.3
I (32) boot.esp32c3: SPI Speed      : 80MHz
I (37) boot.esp32c3: SPI Mode       : DIO
I (42) boot.esp32c3: SPI Flash Size : 2MB
I (47) boot: Enabling RNG early entropy source...
I (52) boot: Partition Table:
I (56) boot: ## Label            Usage          Type ST Offset   Length
I (63) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (70) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (78) boot:  2 factory          factory app      00 00 00010000 00177000
I (85) boot: End of partition table
I (90) esp_image: segment 0: paddr=00010020 vaddr=3c050020 size=149b8h ( 84408) map
I (111) esp_image: segment 1: paddr=000249e0 vaddr=3fc8a400 size=01508h (  5384) load
I (112) esp_image: segment 2: paddr=00025ef0 vaddr=40380000 size=0a128h ( 41256) load
I (125) esp_image: segment 3: paddr=00030020 vaddr=42000020 size=409b4h (264628) map
I (167) esp_image: segment 4: paddr=000709dc vaddr=4038a128 size=001b8h (   440) load
I (167) esp_image: segment 5: paddr=00070b9c vaddr=50000010 size=00014h (    20) load
I (175) boot: Loaded app from partition at offset 0x10000
I (179) boot: Disabling RNG early entropy source...
I (195) cpu_start: Pro cpu up.
I (204) cpu_start: Pro cpu start user code
I (204) cpu_start: cpu freq: 160000000 Hz
I (204) cpu_start: Application information:
I (207) cpu_start: Project name:     wolfssl_benchmark
I (213) cpu_start: App version:      v5.6.4-stable-328-gb7b20eded-di
I (220) cpu_start: Compile time:     Dec 13 2023 15:02:38
I (226) cpu_start: ELF file SHA256:  310a92e2d70d3422...
I (232) cpu_start: ESP-IDF:          v5.0-dirty
I (237) heap_init: Initializing. RAM available for dynamic allocation:
I (244) heap_init: At 3FC8C890 len 0004FE80 (319 KiB): DRAM
I (251) heap_init: At 3FCDC710 len 00002950 (10 KiB): STACK/DRAM
I (257) heap_init: At 50000024 len 00001FDC (7 KiB): RTCRAM
I (264) spi_flash: detected chip: generic
I (268) spi_flash: flash io: dio
W (272) spi_flash: Detected size(4096k) larger than the size in the binary image header(2048k). Using the size in the binary image header.
I (286) cpu_start: Starting scheduler.
I (290) wolfssl_benchmark: ---------------- wolfSSL Benchmark Example ------------
I (298) wolfssl_benchmark: --------------------------------------------------------
I (306) wolfssl_benchmark: --------------------------------------------------------
I (314) wolfssl_benchmark: ---------------------- BEGIN MAIN ----------------------
I (323) wolfssl_benchmark: --------------------------------------------------------
I (331) wolfssl_benchmark: --------------------------------------------------------
I (339) esp32_util: Extended Version and Platform Information.
I (346) esp32_util: Chip revision: v0.3
I (350) esp32_util: SSID and plain text WiFi password not displayed in startup logs.
I (359) esp32_util:   Define SHOW_SSID_AND_PASSWORD to enable display.
I (366) esp32_util: Using wolfSSL user_settings.h in C:/workspace/wolfssl-master/IDE/Espressif/ESP-IDF/examples/wolfssl_benchmark/components/wolfssl/include/user_settings.h
I (382) esp32_util: LIBWOLFSSL_VERSION_STRING = 5.6.4
I (388) esp32_util: LIBWOLFSSL_VERSION_HEX = 5006004
I (393) esp32_util: CONFIG_ESP_DEFAULT_CPU_FREQ_MHZ = 160 MHz
I (400) esp32_util: Stack HWM: 54312
I (404) esp32_util:
I (407) esp32_util: Macro Name                 Defined   Not Defined
I (414) esp32_util: ------------------------- --------- -------------
I (421) esp32_util: NO_ESPIDF_DEFAULT........                 X
I (428) esp32_util: HW_MATH_ENABLED..........     X
I (433) esp32_util: WOLFSSL_SHA224...........     X
I (439) esp32_util: WOLFSSL_SHA384...........     X
I (444) esp32_util: WOLFSSL_SHA512...........     X
I (450) esp32_util: WOLFSSL_SHA3.............     X
I (455) esp32_util: HAVE_ED25519.............     X
I (461) esp32_util: HAVE_AES_ECB.............                 X
I (468) esp32_util: HAVE_AES_DIRECT..........                 X
I (474) esp32_util: USE_FAST_MATH............     X
I (480) esp32_util: WOLFSSL_SP_MATH_ALL......                 X
I (486) esp32_util: SP_MATH..................                 X
I (493) esp32_util: WOLFSSL_HW_METRICS.......     X
I (499) esp32_util: RSA_LOW_MEM..............     X
I (504) esp32_util: WC_NO_HARDEN.............                 X
I (511) esp32_util: TFM_TIMING_RESISTANT.....     X
I (516) esp32_util: ECC_TIMING_RESISTANT.....     X
I (522) esp32_util: WC_NO_CACHE_RESISTANT....     X
I (527) esp32_util: WC_AES_BITSLICED.........                 X
I (534) esp32_util: WOLFSSL_AES_NO_UNROLL....                 X
I (541) esp32_util: TFM_TIMING_RESISTANT.....     X
I (546) esp32_util: ECC_TIMING_RESISTANT.....     X
I (552) esp32_util: WC_RSA_BLINDING..........     X
I (557) esp32_util: NO_WRITEV................     X
I (563) esp32_util: FREERTOS.................     X
I (568) esp32_util: NO_WOLFSSL_DIR...........     X
I (574) esp32_util: WOLFSSL_NO_CURRDIR.......     X
I (579) esp32_util: WOLFSSL_LWIP.............     X
I (585) esp32_util:
I (588) esp32_util: Compiler Optimization: Performance
I (594) esp32_util:
I (596) esp32_util: LIBWOLFSSL_VERSION_GIT_ORIGIN = https://github.com/gojimmypi/wolfssl.git
I (606) esp32_util: LIBWOLFSSL_VERSION_GIT_BRANCH = master
I (612) esp32_util: LIBWOLFSSL_VERSION_GIT_HASH = b7b20ededda4cea208fb7745629904fda64c7524
I (621) esp32_util: LIBWOLFSSL_VERSION_GIT_SHORT_HASH = b7b20eded
I (628) esp32_util: LIBWOLFSSL_VERSION_GIT_HASH_DATE = 'Wed Dec 13 14:36:23 2023 +1000'
I (636) esp32_util: CONFIG_IDF_TARGET = esp32c3
I (641) esp32_util: NO_ESP32_CRYPT defined! HW acceleration DISABLED.
I (649) esp32_util: NOT SINGLE_THREADED
I (653) esp32_util: Boot count: 1
I (657) wolfssl_benchmark: app_main CONFIG_BENCH_ARGV = -lng 0
I (666) wolfssl_benchmark: Stack HWM: 54112

I (669) wolfssl_benchmark: construct_argv arg:-lng 0

------------------------------------------------------------------------------
 wolfSSL version 5.6.4
------------------------------------------------------------------------------
wolfCrypt Benchmark (block bytes 1024, min 1.0 sec each)
RNG                        575 KiB took 1.014 seconds,  567.061 KiB/s
AES-128-CBC-enc           1725 KiB took 1.011 seconds, 1706.231 KiB/s
AES-128-CBC-dec           1675 KiB took 1.006 seconds, 1665.010 KiB/s
AES-192-CBC-enc           1475 KiB took 1.004 seconds, 1469.124 KiB/s
AES-192-CBC-dec           1450 KiB took 1.006 seconds, 1441.352 KiB/s
AES-256-CBC-enc           1300 KiB took 1.007 seconds, 1290.963 KiB/s
AES-256-CBC-dec           1275 KiB took 1.002 seconds, 1272.455 KiB/s
AES-128-GCM-enc            450 KiB took 1.058 seconds,  425.331 KiB/s
AES-128-GCM-dec            450 KiB took 1.058 seconds,  425.331 KiB/s
AES-192-GCM-enc            425 KiB took 1.039 seconds,  409.047 KiB/s
AES-192-GCM-dec            425 KiB took 1.040 seconds,  408.654 KiB/s
AES-256-GCM-enc            400 KiB took 1.016 seconds,  393.701 KiB/s
AES-256-GCM-dec            400 KiB took 1.016 seconds,  393.701 KiB/s
GMAC Default               567 KiB took 1.000 seconds,  567.000 KiB/s
3DES                       400 KiB took 1.061 seconds,  377.003 KiB/s
MD5                      10650 KiB took 1.001 seconds, 10639.361 KiB/
SHA                       5425 KiB took 1.004 seconds, 5403.386 KiB/s
SHA-224                   1450 KiB took 1.008 seconds, 1438.492 KiB/s
SHA-256                   1450 KiB took 1.008 seconds, 1438.492 KiB/s
SHA-384                   1300 KiB took 1.011 seconds, 1285.856 KiB/s
SHA-512                   1300 KiB took 1.011 seconds, 1285.856 KiB/s
SHA-512/224               1300 KiB took 1.011 seconds, 1285.856 KiB/s
SHA-512/256               1300 KiB took 1.011 seconds, 1285.856 KiB/s
SHA3-224                   950 KiB took 1.019 seconds,  932.287 KiB/s
SHA3-256                   900 KiB took 1.022 seconds,  880.626 KiB/s
SHA3-384                   700 KiB took 1.034 seconds,  676.983 KiB/s
SHA3-512                   475 KiB took 1.004 seconds,  473.108 KiB/s
SHAKE128                  1100 KiB took 1.018 seconds, 1080.550 KiB/s
SHAKE256                   900 KiB took 1.023 seconds,  879.765 KiB/s
RIPEMD                    4325 KiB took 1.004 seconds, 4307.769 KiB/s
HMAC-MD5                 10525 KiB took 1.000 seconds, 10525.000 KiB/
HMAC-SHA                  5375 KiB took 1.004 seconds, 5353.586 KiB/s
HMAC-SHA224               1450 KiB took 1.016 seconds, 1427.165 KiB/s
HMAC-SHA256               1450 KiB took 1.016 seconds, 1427.165 KiB/s
HMAC-SHA384               1275 KiB took 1.007 seconds, 1266.137 KiB/s
HMAC-SHA512               1275 KiB took 1.007 seconds, 1266.137 KiB/s
PBKDF2                       0 KiB took 1.084 seconds,    0.173 KiB/s
RSA     1024  key gen         1 ops took 5.502 sec, avg 5502.000 ms
RSA     2048  key gen         1 ops took 34.705 sec, avg 34705.000 ms
RSA     2048   public        46 ops took 1.016 sec, avg 22.087 ms
RSA     2048  private         2 ops took 8.848 sec, avg 4424.000 ms
ECC   [      SECP256R1]   256  key gen         4 ops took 1.165 sec, avg 291.250 ms
ECDHE [      SECP256R1]   256    agree         4 ops took 1.159 sec, avg 289.750 ms
ECDSA [      SECP256R1]   256     sign         4 ops took 1.178 sec, avg 294.500 ms
ECDSA [      SECP256R1]   256   verify         2 ops took 1.120 sec, avg 560.000 ms
CURVE  25519  key gen         3 ops took 1.144 sec, avg 381.333 ms
CURVE  25519    agree         4 ops took 1.524 sec, avg 381.000 ms
ED     25519  key gen        73 ops took 1.005 sec, avg 13.767 ms
ED     25519     sign        62 ops took 1.005 sec, avg 16.210 ms
ED     25519   verify        40 ops took 1.042 sec, avg 26.050 ms
Benchmark complete

ESP-32-C3 Benchmark Metrics updated December 2023 with the latest version of wolfSSL.

See also:

• wolfSSH Espressif Home Page
• wolfSSH to UART example for ESP32
• Espressif ESP32-C3

If you have questions about any of the above, please contact us at facts@wolfSSL.com or cacll us at +1 425 245 8247.

Download wolfSSL Now

The sniffer support for processing multiple streams concurrently using our asynchronous version of the library. Support has been added for offloading to Intel QuickAssist or Cavium Nitrox V type hardware. Additionally we support offloading to worker threads. This allows a large increase in sniffer throughput for handling the asymmetric operations.

Our sniffer tool is built into wolfSSL and allows decryption of TLS traffic where the static RSA/ECC key is know or the ephemeral key used on one side is known. We support TLS v1.2 and TLS v1.3. The sniffer tool can process pcap files previously recorded or live.

We also support using a Key Manager for protected generation and storage of ephemeral keys with TLS v1.3. This is based on the ETSI TS 103 523-3 Middlebox Security Protocol; Part 3: Enterprise Transport Security. If interested see our full library and demo here: https://github.com/wolfSSL/wolfKeyMgr

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

We offer two CMSIS packs for wolfSSL to assist with quick adoption of our library into your projects.

Our STM Cube Pack

For STM32 users we offer a CMSIS pack. This is available inside the STM32CubeIDE as we are a “MadeForSTM32” project. We work closely with STM to provide a seamless integration. The integration provides a simple GUI interface to configure the library for your hardware with out of the box support for most STM32 flavors.

The pack includes an example console application for running wolfCrypt test/benchmarks and a TLS client/server.

Official ST Page: https://www.st.com/en/partner-products-and-services/i-cube-wolfssl.html

Our documentation: https://github.com/wolfSSL/wolfssl/tree/master/IDE/STM32Cube

Our Keil CMSIS Pack

For Keil MDK and uVision users we provide a CMSIS pack for wolfSSL, which includes wolfCrypt and TLS examples. This allows for quick adoption of our library into your embedded target.

Guide: https://www.wolfssl.com/docs/keil-mdk-arm/

Pack Download: https://www2.keil.com/mdk5/partnerpacks/

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

CAAM support with wolfSSL on QNX was expanded. Previously the port included i.MX6 devices now it can run on i.MX8 devices and handle AES-CTR operations in addition to the previously supported ECC, CMAC, and BLOB operations.This enhancement included some additional refactoring and robustness of the QNX resource manager in wolfSSL.

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

wolfBoot v1.12 has been released. This version introduces the support for a new signature verification algorithm, RSA3072, new test cases, a new simulated architecture to speed up the validation, and some new features to support more use cases. Here is a brief description of some of the new features in this version.

Support for encrypted incremental updates

Our delta firmware update support is designed to reduce transfer times for firmware updates. By applying a binary patch on the existing version, wolfBoot is able to update the current firmware with a special update image, a “delta” update package, which maps the difference between the current and the new version. This feature can now be combined with our symmetric, pre-shared key encryption mechanism, allowing for encrypted delta updates.

Signed binaries and numeric identifiers

It is now possible to assign an identifier to each signed image. Our sign tool accepts a new command line argument (–id N) to set a custom id for a signed payload.

Id ‘1’ is the default, and is usually the image of the application, or the OS kernel, staged by wolfBoot after verification.

Id ‘0’ is reserved for wolfBoot self-updates.

Ids 2 to 15 can be used to design custom read-only partitions, extra images and binary extensions, each one living in a different flash memory partition, or mapped to a different zone in memory.

Support for multiple public keys

wolfBoot v1.12 now supports multiple public keys that can be stored together in the designed trust anchor, into a new data structure called `keystore`.

A keystore can contain keys that are either generated, using the keygen tool like in the previous versions, or imported from a third-party provisioning mechanism.

Each key can carry different permissions, i.e. can be allowed to authenticate binary images only associated with one or more specific identifiers.

wolfBoot is our secure bootloader that relies on wolfCrypt to provide secure boot and firmware updates. It can be used to secure the boot process on any embedded system, from very resource-restricted microcontrollers up to more powerful, microprocessor-based platforms, and even on x86_64 PC-based architectures. Safe-by-design, it’s the ideal choice in safety-critical systems that need to integrate a secure bootloader.

Find out more about wolfBoot! Download the source code and documentation from our download page, or clone the repository from GitHub. If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

Join our live wolfEngine  webinar, where we introduce one of our newest products wolfEngine, a separate standalone library which links against wolfSSL (libwolfssl) and OpenSSL. wolfEngine implements and exposes an OpenSSL engine implementation which wraps the wolfCrypt native API internally. Algorithm support matches that as listed on the wolfCrypt FIPS 140-2 certificate #3389.

Learn about about what wolfEngine is, why you should care, and why wolfEngine could be the solution to all of your problems. As always bring your questions for the Q&A following the presentation.

Watch the webinar here: wolfEngine : wolfCrypt as an Engine for OpenSSL

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

The summer release of wolfMQTT, v1.14.0, is now available! This release has several bug fixes and optimizations including:

• Support post-quantum KYBER_LEVEL1 and P256_KYBER_LEVEL1 with FALCON_LEVEL1 in wolfMQTT. by @anhu #300
• Add WOLFMQTT_USE_CB_ON_DISCONNECT for CB on client disconnect by @embhorn in #302
• Fix to release connect ack props by @embhorn in #301

Check out the changelog from the download for a full list of features and fixes, or contact us at facts@wolfssl.com with any questions:

https://github.com/wolfSSL/wolfMQTT/blob/master/ChangeLog.md

While you’re there, show us some love and give the wolfMQTT project a Star!

You can download the latest release here: https://www.wolfssl.com/download/

Or clone directly from our GitHub repository: https://github.com/wolfSSL/wolfMQTT

If you are working on MQTT, or if you just have questions, don’t hesitate to contact us at facts@wolfssl.com. We’re more than happy to hear from you!

Want to talk to us face to face about wolfMQTT at Black Hat?  Come by Booth 1084!

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

DTLS 1.3 is here! wolfSSL release 5.4.0 was recently sent out and one of the exciting new features in the release was initial support for DTLS 1.3. This new protocol implementation gives improvements over the previous 1.2/1.0 versions of DTLS and compliments the TLS 1.3 implementation in wolfSSL quite nicely.

wolfSSL prides itself on our many firsts. As a Cybersecurity company we have to make sure all of our products are state of the art. As such we make sure to be proactive, so that our products are always the best they can be. Being an open source company, we like to keep our users, customers, and followers up to date on our successes.  

wolfSSL Current Firsts:

• First Open Source Dual Licensed TLS (GPLv2/Commercial)
• First TLS to adopt fuzz testing; now sporting 7 internal nightly fuzz testers and 2 external fuzz testers
• First TLS 1.2 implementation
• First DTLS 1.2 implementation
• First TLS to support quantum resistant encryption (PQC) …in 2010!  We used NTRU.
• First TLS 1.3 implementation
• First MQTT SN implementation
• First MQTT 5.0 implementation
• First IETF SUIT Secure Boot implementation 
• First TLS 1.3 Sniffer
• First DO 178 DAL A certified crypto library
• First TPM 2.0 stack designed for baremetal and embedded systems – wolfTPM

Now wolfSSL is the first to have DTLS 1.3 implementation. wolfSSL’s DTLS 1.3 implementation is not ready for commercial use, but it’s fully functional and ready for being beta-tested! As usual, you can find the code at our GitHub repo or you can download the latest beta version here.

Since its first version, DTLS aims to bring the same security guarantees as TLS, but without requiring a reliable and order-preserving underlying protocol. This means that it’s much more suitable for latency-sensitive applications that can suffer from the overhead of TCP or similar protocols. The specifications of DTLSv1.3 were published just last April (RFC 9147) and DTLSv1.3 brings all the improvements of TLS v1.3 to DTLS: faster and more secure handshake, 0-RTT resumption, modern crypto algorithms, better downgrade protection and so on. We are the first to release a working implementation. 

If you are working on DTLS, or if you just have questions, don’t hesitate to contact us at facts@wolfssl.com. We’re more than happy to hear from you!

Want to talk to us face to face about DTLS 1.3 at Black Hat?  Come by Booth 1084!

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

DTLS 1.3 is here! wolfSSL release 5.4.0 was recently sent out and one of the exciting new features in the release was initial support for DTLS 1.3. This new protocol implementation gives improvements over the previous 1.2/1.0 versions of DTLS and compliments the TLS 1.3 implementation in wolfSSL quite nicely.

Another big change to make note of in this release is that the SP math implementation was switched to be the default one. Now when running a basic configuration and not specifying a specific math implementation SP math is used. Many hardware ports and RTOS ports were also updated, one such case was that the support of NXP’s CAAM when using QNX was expanded on.

In release 5.4.0 there were 3 vulnerabilities listed as fixed in wolfSSL. Two relatively new reports, one dealing with a DTLS 1.0/1.2 denial of service attack and the other a ciphertext attack on ECC/DH operations. The last vulnerability listed was a public disclosure of a previous attack on AMD devices fixed since wolfSSL version 5.1.0. Coordination of the disclosure of the attack was done responsibly, in cooperation with the researchers, waiting for the public release of the attack details since it affects multiple security libraries.

A full list of what was changed can be found in the wolfSSL ChangeLog (https://www.wolfssl.com/docs/wolfssl-changelog/).

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

Well, the internet has been abuzz with the announcement of the four post-quantum algorithms that will move on from the NIST Post-Quantum Competition to standardization. They are:

• KYBER Key Encapsulation Mechanism
• DILITHIUM Signature Scheme
• FALCON Signature Scheme
• SPHINCS+ Signature Scheme

NIST has a very detailed report about the algorithms and some explanations which can be found here:https://nvlpubs.nist.gov/nistpubs/ir/2022/NIST.IR.8413.pdf

Its great to see that both KYBER and FALCON are among the algorithms moving on as wolfSSL has already built in support for both of them with our integration with liboqs. So what is next for wolfSSL?

Our plan is to take a 2 pronged approach.

In the near term, we will continue to leverage our integration with liboqs to quickly bring support for DILITHIUM and SPHINCS+ into wolfSSL.

While that is happening, we will also be writing our own implementations of the new algorithms that will be standardized. For our own implementations, the “harvest now, decrypt later” threat model is top of mind and so we will begin with KYBER. We will then move onto DILITHIUM, FALCON and then SPHINCS+.

Do you want to learn more about these algorithms? Do you think we should implement the algorithms in a different order? Let us know! If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.