Month: August 2022

wolfSSL version 5.5.0 is available now! Say hello to QUIC support. With this release of wolfSSL we have added in QUIC support and can be used with QUIC implementations such as ngtcp2 (https://github.com/ngtcp2/ngtcp2); which means wolfSSL can now be used for the TLS portion of HTTP/3 connections in cURL. Along with QUIC support this release saw additions for: RSA-PSS certificate support, Dilithium post quantum algorithm use with TLS, and some additional porting to even more embedded devices to name a few things. In addition to the new features added, there were enhancements to some of the existing ones, such as the expansion of ABI support, along with some fixes like with DTLS 1.3 asynchronous builds.

A full list of changes can be found in the ChangeLog.md or on the wolfssl website.
For questions about the release contact facts@wolfssl.com

wolfSSL release 5.5.0 contained 4 vulnerability fixes. Most are considered low severity and affect a very small subset of users. 3 of the listed issues were found by external researchers (thanks to their efforts! you can see them mentioned on each of the reports) The last one listed with a potential DTLS DoS attack was found thanks to our internal testing.

CVE ID	Severity	Description
CVE-2022-38153	Low	In wolfSSL version 5.3.0 if compiled with –enable-session-ticket and the client has non-empty session cache, with TLS 1.2 there is the possibility of a man in the middle passing a large session ticket to the client and causing a crash due to an invalid free. There is also the potential for a malicious TLS 1.3 server to crash a client in a similar manner except in TLS 1.3 it is not susceptible to a man in the middle attack. Users on the client side with –enable-session-ticket compiled in and using wolfSSL version 5.3.0 should update their version of wolfSSL.  Thanks to Max at Trail of Bits for the report and “LORIA, INRIA, France” for research on tlspuffin.
CVE-2022-38152	Low	If using wolfSSL_clear to reset a WOLFSSL object (vs the normal wolfSSL_free/wolfSSL_new) it can result in runtime issues. This exists with builds using the wolfSSL compatibility layer (–enable-opnesslextra) and only when the application is making use of wolfSSL_clear instead of SSL_free/SSL_new. In the case of a TLS 1.3 resumption, after continuing to use the WOLFSSH object after having called wolfSSL_clear, an application could crash. It is suggested that users calling wolfSSL_clear update the version of wolfSSL used.  Thanks to Max at Trail of Bits for the report and “LORIA, INRIA, France” for research on tlspuffin.
N/A	Low	Fault injection attack on RAM via Rowhammer leads to ECDSA key disclosure. Users doing operations with private ECC keys such as server side TLS connections and creating ECC signatures, who also have hardware that could be targeted with a sophisticated Rowhammer attack should update the version of wolfSSL and compile using the macro WOLFSSL_CHECK_SIG_FAULTS.  Thanks to Yarkin Doroz, Berk Sunar, Koksal Must, Caner Tol, and Kristi Rahman all affiliated with the Vernam Applied Cryptography and Cybersecurity Lab at Worcester Polytechnic Institute for the report.
N/A	Medium	Potential DoS attack on DTLS 1.2. In the case of receiving a malicious plaintext handshake message at epoch 0 the connection will enter an error state reporting a duplicate message. This affects both server and client side. Users that have DTLS enabled and in use should update their version of wolfSSL to mitigate the potential for a DoS attack.

Notes:

If not free’ing FP_ECC caches per thread by calling wc_ecc_fp_free there is a possible memory leak during TLS 1.3 handshakes which use ECC. Users are urged to confirm they are free’ing FP_ECC caches per thread if enabled to avoid this issue. 

 

For additional vulnerability information visit the vulnerability page at https://www.wolfssl.com/docs/security-vulnerabilities/. 

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

If you have a vulnerability to report or would like more information, contact us at facts@wolfssl.com, the wolfSSL development team takes vulnerabilities seriously.

wolfSSL’s GoLang wrapper, go-wolfssl, now includes a first round of wolfCrypt APIs. The wolfCrypt cryptography engine is a lightweight crypto library written in ANSI C and known for its small size, speed, and feature set, as well as its royalty-free pricing and excellent cross-platform support. Now with go-wolfssl, GO users can take advantage of this crypto engine and the many algorithms/ciphers it supports. The recently added features include ECC sign/verify, SHA hashing, and AES encryption.

Although it’s still in its early stages, factors like optimization, FIPS validation, and excellent customer support from our expert engineers make go-wolfssl the ideal TLS/crypto solution for GO projects in the long run.

Are you interested in a more complete Golang wrapper?

Contact us at facts@wolfssl.com with any questions, comments, or suggestions!

Here at wolfSSL we love TLS 1.3, but we also know there are other protocols out there such as: DTLS, QUIC, SSH, MQTT and Noise.  In this post we will compare and contrast TLS 1.3 against Noise and provide some notes about FIPS-140 and post-quantum cryptography.

Noise itself is NOT a protocol per se; it is a protocol framework (here lies the biggest difference between TLS 1.3 and Noise). When using TLS 1.3 the connection will be authenticated, confidential, and have integrity. It is quite simple and efficient to get these properties.  All of wolfSSL’s example server and client applications that do TLS 1.3 are just a few hundred lines of code and the simplest can easily be under 100 lines (found here:https://github.com/wolfSSL/wolfssl-examples/tree/master/tls). Contrast that with the requirement that you need to design your own Noise-based protocol depending on the security properties that you desire, and suddenly Noise looks a bit more challenging than TLS 1.3.  Expertise is required! See section 7.5 of https://noiseprotocol.org/noise.html to see the fundamental patterns that can be used.

The next biggest difference is authentication. TLS usually requires the server to have an X.509 certificate so the client can verify the identity of the server.  The server’s identity is bound to the public key via the certificate and is verified by proving possession of the private key to the client. The Noise Framework does not support identity verification; it leaves that to the application. However, it does allow for using static encryption keys which then ensures that each side is talking to the same party they were talking to in the past. And again, you must design or use the correct pattern to achieve this goal and then design identity verification into your application.

TLS 1.3 standardizes the cryptographic algorithms and NIST gives guidance on which algorithms to use in it. As a result, it is easy to stay in compliance with FIPS-140. For example, if you simply use wolfSSL’s defaults in our FIPS-certified product, you will be fine. On the other hand, for Noise, NIST has given no guidance so you are on your own when you design your protocol or pick your patterns.

Can you do post-quantum cryptography in TLS 1.3 today? Yes! There are private use code points for the Supported Groups Extension and Signature Algorithm Extension.  However, once post-quantum algorithms are standardized, standard codepoint and OIDs should quickly follow. The mechanics and cryptographic artifacts of post-quantum signature schemes and KEMs (key encapsulation mechanism) fit quite nicely into the TLS 1.3 handshake and X.509 certificate PKI. For more details, you can read our documentation about post-quantum TLS 1.3 in wolfSSL at https://www.wolfssl.com/documentation/manuals/wolfssl/appendix07.html.  What about the Noise Framework? The short answer is no. The protocol framework relies on the “non-interactiveness” of the Diffie-Hellman key exchange protocol and KEMs are interactive! There are no known post-quantum non-interactive key exchange algorithms as of the time of this writing.  However, research into different possibilities is ongoing and the Noise Protocol framework could eventually evolve into supporting post-quantum algorithms. For example, please see https://eprint.iacr.org/2022/539.pdf. 

Our conclusion is that if TLS 1.3 can get you what you need, then keep it simple and use TLS 1.3.

For any questions, or to get help using wolfSSL in your product or projects, contact us at facts@wolfssl.com.

Version 1.4.0 of the wolfCrypt JCE Provider and JNI wrapper is now available for download!

wolfCrypt JNI/JCE provide Java-based applications with an easy way to use the native wolfCrypt cryptography library. The thin JNI wrapper can be used for direct JNI calls into native wolfCrypt, or the JCE provider (wolfJCE) can be registered as a Java Security provider for seamless integration underneath the Java Security API. wolfCrypt JNI/JCE can work with wolfCrypt FIPS 140-2 (and upcoming 140-3) as well!

Release 1.4.0 of wolfCrypt JNI has bug fixes and new features including:

• Add example directory with one simple ProviderTest example (PR 32)
• Fix double free of ChaCha pointer (PR 34)
• Add test cases for ChaCha.java (PR 34)
• Skip WolfCryptMacTest for HMAC-MD5 when using wolfCrypt FIPS 140-3 (PR 35)
• Use new hash struct names (wc_Md5/wc_Sha/etc) in native code (PR 35)
• Fix potential build error with non-ASCII apostrophes in Fips.java (PR 36)

Version 1.4.0 can be downloaded from the wolfSSL download page, and an updated version of the wolfCrypt JNI/JCE User Manual can be found here. For any questions, or to get help using wolfSSL in your product or projects, contact us at facts@wolfssl.com.

Version 1.10.0 of the wolfSSL JSSE Provider and JNI wrapper is now available for download!

wolfSSL JNI/JSSE provide Java-based applications with an easy way to use the native wolfSSL SSL/TLS library. The thin JNI wrapper can be used for direct JNI calls into native wolfSSL, or the JSSE provider (wolfJSSE) can be registered as a Java Security provider for seamless integration underneath the Java Security API. wolfSSL JNI/JSSE provides TLS 1.3 support and also can work with wolfCrypt FIPS 140-2 (and upcoming 140-3).

Release 1.10.0 has bug fixes and new features including:

JNI and JSSE Changes:

• Add SSLEngine.getApplicationProtocol(), fixes Undertow compatibility (PR 84)
• Wrap wolfSSL_UseALPN() at JNI level (PR 84)
• Fix compile error for wolfSSL < 4.2.0 and wolfSSL_set_alpn_protos() (PR 84)
• Fix NullPointerException when no selected ALPN is available (PR 84)
• Fix JNI build when wolfSSL compiled with –disable-filesystem (PR 104)
• Fix SSLEngine compatibility with data larger than TLS record size (PR 105)
• Refactor SSLEngine handshake status to be more inline with SunJSSE (PR 105)
• Add verbose SSLEngine logging with “wolfsslengine.debug” property (PR 105)

Documentation Changes:

• Fix missing Javadoc warnings in ALPN code

Example Changes:

• Update Android Studio IDE project to use Android 11 (SDK 30)

Version 1.10 can be downloaded from the wolfSSL download page, and an updated version of the wolfSSL JNI/JSSE User Manual can be found here. For any questions, or to get help using wolfSSL in your product or projects, contact us at facts@wolfssl.com.

If you use Yocto and have a communications security need or maybe just crypto, perhaps meta-wolfssl has what you are looking for! wolfSSL offers the latest cutting edge solutions in cryptography and transport protocols.

wolfSSL Inc. has support for post-quantum crypto, API’s for use with a QUIC library, crypto with a certification (if needed) FIPS 140-2, FIPS 140-3, or DO-178C DAL A and much more including but not limited to: in-house embedded SSH client/server, MQTT client, secure bootloader (wolfBoot) etc! wolfSSL also offers support for many commonly used third-party open source implementations, just head on over to our products page or check out our OSP support repo on GitHub to find out more!

To get started with wolfSSL in Yocto, if you have 2 minutes to spare in your day, please checkout our two-part series YouTube-short videos at the following links:

wolfSSL + Yocto – how to (part 1)
wolfSSL + Yocto – how to (part 2)

This very quick, two-part series shows you all you would need to get started for building wolfSSL into your yocto image in just 2 minutes! wolfSSL has very experienced and knowledgeable engineers to answer any questions you might have once you are beyond the initial standup phase (IE how to configure wolfSSL with different settings etc), just reach out to us at support@wolfssl.com if you have any questions, we are always eager to help out!

P.S. If meta-wolfssl does not yet include a Yocto recipe for one of our products please let us know through our support channel which one you would be eager to see added next!

wolfSSL continues to follow recent development of the protocols driving today’s Internet. QUIC, by some regarded as the successor to TCP, is gaining momentum and is used in production by Google, Fastly, Cloudflare and others when you browse the net.

QUIC is built on top of TLSv1.3 – in a novel way – and now you may use wolfSSL inside your QUIC protocol stack to deliver HTTP/3. The wolfSSL team has contributed integrations to ngtcp2, the popular QUIC implementation. cURL will give you HTTP/3 with wolfSSL on the command line and in your libcurl integration soon.

HTTP/3 is only one (but dominant) use of QUIC. DNS queries are coming, adding the new triple ‘DoQ’ to the list of ‘Do*’ acronyms for name resolution protocols. And other QUIC applications are under active development in the IETF.

API++

The wolfSSL QUIC API is aligned with the corresponding APIs in other *SSL libraries, making integration with QUIC protocol stacks easier and protecting investments. This is a departure from past customs where OpenSSL used to drive the design of APIs. However OpenSSL declined to participate and offers no QUIC support for the foreseeable future.
The need for a new API arises from the improved security design of the QUIC protocol. QUIC protects not only application data, but also its own protocol information with strong encryption. Its packets are more opaque to middleboxes.

This means that en-/decryption needs to happen ‘outside’ of what a TLS library commonly handles. However, the designers of QUIC were well aware of the worth of TLSv1.3 in its design
and implementations.

This resulted in a protocol that makes full use of TLSv1.3 handshake negotiation, ciphers and sessions, but takes over the actual en-/decryption itself. Using secrets and keys from the TLS handshake. These are the facilities that the QUIC API adds.

wolfSSL + QUIC == wolfSSL

Building wolfSSL with QUIC support will give you wolfSSL. All features work as before. In addition you may enable QUIC on a WOLFSSL instance or context. And have a mix of (D)TLS and QUIC sessions in the same application.

For more details about the release of information in general contact facts@wolfssl.com.

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

For questions about using the sniffer with TLS please email facts@wolfssl.com.