There are no special requirements or prerequisites for using wolfSSL in a RISC-V project. As noted in our prior blog, wolfSSL has been developed in a Clean Room environment and has no external dependencies. Unlike other options, wolfSSL is still maintained with oversight from the original developers. If your current project compiles, you can add wolfSSL.
git clone https://github.com/wolfSSL/wolfssl.git
cd wolfssl
Set Up the Build Environment: Ensure the RISC-V GNU toolchain is installed and configured.
Compile wolfSSL:
There’s not much difference between compiling for RISC-V or any other platform, unless perhaps you need to cross-compile. See additional information in the INSTALL file.
./autogen # optional, depending on source. (see docs)
./configure --host=riscv64-unknown-elf
make
make install
Configuring wolfSSL
Custom Build Options: Modify the configure command with options specific to your use case. For example, enabling TLS 1.3:
make install
./configure --host=riscv64-unknown-elf --enable-tls13
By following these steps, you’ll have wolfSSL downloaded, built, and configured on your RISC-V platform, ready for development.
Beyond the basic compilation of wolfSSL, there are a variety of enhancements and optimization options available for the RISC-V CPU. See our upcoming blog: “Customization and Advanced wolfSSL Features on RISC-V”
One of the key benefits of using wolfSSL in a RISC-V project is that the library has been developed in a “clean room” environment. In part, this means there’s no inherited code baggage and more importantly: no external dependencies. If there’s an existing RISC-V project, wolfSSL can be easily added. Just plug in the library and it is ready to go.
Reduced Footprint: wolfSSL’s small memory footprint and minimal code size are ideal for resource-constrained RISC-V environments.
Low Power Consumption: Efficient design leads to lower power consumption, perfect for embedded systems and IoT devices.
Performance Optimization:
Hardware Acceleration: Leverage RISC-V’s custom instructions for accelerated cryptographic operations with wolfSSL.
Scalability: Tailor wolfSSL’s modular design for optimized performance in various RISC-V applications.
Security:
Robust Features: Comprehensive support for modern cryptographic algorithms and TLS 1.3 ensures secure communication.
Compliance: FIPS 140-3 validation meets stringent security standards for various industries.
Flexibility and Customization:
Open Source: Modify and tailor wolfSSL to specific needs with its open-source nature.
Rich Feature Set: Access a wide range of cryptographic algorithms and protocols without additional libraries.
Community and Support:
Active Community: Benefit from a wealth of resources and community support for both wolfSSL and RISC-V. Visit our forums or browse our repositories on GitHub.
Professional Support: Commercial support from wolfSSL ensures quick resolution of critical issues.
Future-Proofing:
Evolving Standards: Stay compatible with the latest RISC-V advancements and features.
Longevity: Invest in sustainable and forward-compatible technologies with wolfSSL and RISC-V.
Combining wolfSSL with RISC-V allows for the creation of secure, efficient, and scalable applications across various computing environments.
Are you interested in RISC-V or FIPS Certification? We want to hear about your project!
The wolfSSL team has expanded our Open Source Projects repository with a port for Mosquitto, an open source MQTT broker. Mosquitto users can benefit from wolfSSL’s lightweight SSL/TLS library.
Why should you use wolfSSL with Mosquitto?
Portability across platforms and OS/RTOS environments
To use the Mosquitto port, follow the instructions in the patch file.
Set up wolfSSL
git clone https://github.com/wolfSSL/wolfssl.git
cd wolfssl
./autogen.sh
./configure --enable-mosquitto
make
make install
Set up Eclipse Mosquitto
git clone https://github.com/eclipse/mosquitto.git
cd mosquitto
git checkout v2.0.18
patch -p1 <
make WITH_TLS=wolfssl
make WITH_TLS=wolfssl test
Let us know what you think! We plan to add support for CMake builds. If you are interested or have questions about any of the above, please contact us at facts@wolfssl.com or +1 425 245 8247.
In the 5.7.2 release, a new macro WOLFSSL_MAX_ALT_NAMES was introduced to limit the maximum number of allowed subject alternative names to a default value of 128 to prevent a possible denial of service attack. Unfortunately, after the release, some commonly used certificates were brought to our attention that have more than 128 subject alternative names. If you started using 5.7.2 and hit error -161 on certificate handling this may be your problem. This issue can be immediately mitigated by building with WOLFSSL_MAX_ALT_NAMES at a number larger, say 512 or 1024. The wolfSSL master branch already has an increased default of 1024 which should be sufficient for all real world certificates and will be included in the 5.7.3 release.
wolfSSL release 5.7.2 is now available! This release includes an implementation of Dilithium, optimizations for RISC-V use, AES-XTS streaming capabilities, and quantum safe algorithm support with the Linux kernel module, to name a few of the recent additions. There have also been other enhancements, such as STM32 AES hardware support for STM32H5 and SHA-3 ARM thumb assembly implementations. Along with these amazing features and enhancements, some great fixes and additional sanity checks were added. One of the additional sanity checks limits the maximum number of alternate names parsed with certificates. This defaults to 128 but can be changed by defining the macro WOLFSSL_MAX_ALT_NAMES to any desired value. A full list of vulnerability fixes, feature additions, and general changes can be found in the ChangeLog.md bundled with wolfSSL or in the main README.md.
The lwIP project is a great, lightweight TCP/IP stack implementation, with widespread use in the embedded world. Users of lwIP and wolfSSL know that we have long supported an lwIP integration, which allows wolfSSL to handle the TLS layer while lwIP handles network input/output.
But what if you wanted to combine lwIP with IPSec? Furthermore, what if you wanted wolfCrypt to handle the IPSec cryptographic operations in such a combination?
If you’re curious about lwIP, wolfCrypt, and IPSec, or have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.
The wolfSSL embedded TLS library and its crypto engine wolfCrypt are both highly configurable to give users the best cryptographic performance. Our users appreciate that they’re able to customize their builds to suit their specific needs. If your needs are a crypto or SSL/TLS solution optimized for performance, we’ve compiled a list of the top 5 wolfSSL build options that you should consider.
Intel Assembly
For use with Intel/AMD processors, enabling the intelasm option for wolfSSL will utilize enhanced assembly instructions of the processor that can dramatically enhance cryptographic performance for most algorithms. The instruction sets leveraged when the configure option is enabled include AVX1, AVX2, BMI2, RDRAND, RDSEED, AESNI, and ADX. This option also automatically enables our Intel AES-NI support, which on its own can lead to direct AES encryption that’s over 3.3 times faster than using software-based AES. Performance increases in total can be as large as 5,800% when intelasm is used.
Enabled with: ./configure –enable-intelasm
Macro: WOLFSSL_ARMASM
ARM Assembly
Whether you’re doing cryptography on an ARMv8, ARMv7 or even an ARM64, armasm is the quickest way to speedup your cryptographic operations, and by doing so speedup your TLS that makes use of these algorithms. By using the cryptographic instructions built into the chips, we get a significant boost in performance over straight C. We recently did another round of tuning on our ARM64 code and got the crypto running up to 9.5 times faster than it already was.
Enabled with: ./configure –enable-armasm
Macro: WOLFSSL_ARMASM
RISC-V Assembly
The newest addition on this list, wolfSSL now has support for RISC-V hardware acceleration. The RISC-V assembly implementation of AES includes standard/scalar cryptography/vector cryptographic instructions for ECB/CBC/CTR/GCM/CCM and can be up to 50 times faster than the software implementation.
Enabled with: ./configure –enable-riscv-asm
Macro: WOLFSSL_RISCV_ASM
Single Precision Math Assembly
Unlike some of the other build options on this list, SP ASM is hardware agnostic. SP is Single Precision Math and it is a wolfSSL developed math library that is extremely well optimized for cryptographic math calculations. SP ASM is the assembly component of the SP math library. Enabling this option leads to faster RSA, ECC and DH operations.
Enabled with: ./configure –enable-sp –enable-sp-asm
Macros: WOLFSSL_SP_ASM (along with WOLFSSL_SP_HAVE_RSA/ECC/DH)
AES GCM (4-bit Table)
A hardware agnostic feature for AES GCM (authenticated cipher) to improve the symmetric performance of the GHASH authentication calculation. The performance gain is about a 3x speedup.
Enabled with: ./configure –enable-asmgcm=4bit
Macros: WOLFSSL_SP_ASM (along with WOLFSSL_SP_HAVE_RSA/ECC/DH)
We are excited to share the latest benchmark results of wolfSSL v5.7.0 running on the HiFive Unleashed at 1.4GHz. We implemented AES for ECB, CBC, CTR, GCM, and CCM using assembly for RISC-V. This benchmark demonstrates the performance capabilities of wolfSSL on RISC-V architecture, highlighting our commitment to providing high-performance, lightweight, and secure SSL/TLS solutions across diverse platforms.
The benchmark results prove that the new assembly optimizations are much faster.
With RISC-V assembly optimizations:
./configure --enable-riscv-asm && make
root@HiFiveU:~/wolfssl-riscv# ./wolfcrypt/benchmark/benchmark -aes-cbc -aes-gcm------------------------------------------------------------------------------
wolfSSL version 5.7.0
------------------------------------------------------------------------------
Math: Multi-Precision: Wolf(SP) word-size=64 bits=3072 sp_int.c
wolfCrypt Benchmark (block bytes 1048576, min 1.0 sec each)
AES-128-CBC-enc 20 MiB took 1.076 seconds, 18.588 MiB/s
AES-128-CBC-dec 20 MiB took 1.083 seconds, 18.473 MiB/s
AES-192-CBC-enc 20 MiB took 1.245 seconds, 16.062 MiB/s
AES-192-CBC-dec 20 MiB took 1.246 seconds, 16.047 MiB/s
AES-256-CBC-enc 15 MiB took 1.057 seconds, 14.189 MiB/s
AES-256-CBC-dec 15 MiB took 1.055 seconds, 14.212 MiB/s
AES-128-GCM-enc 15 MiB took 1.300 seconds, 11.543 MiB/s
AES-128-GCM-dec 15 MiB took 1.300 seconds, 11.535 MiB/s
AES-192-GCM-enc 15 MiB took 1.425 seconds, 10.526 MiB/s
AES-192-GCM-dec 15 MiB took 1.425 seconds, 10.523 MiB/s
AES-256-GCM-enc 10 MiB took 1.032 seconds, 9.687 MiB/s
AES-256-GCM-dec 10 MiB took 1.032 seconds, 9.691 MiB/s
GMAC Table 4-bit 31 MiB took 1.025 seconds, 30.251 MiB/s
Benchmark complete
Without RISC-V assembly optimizations:
./configure —enable-all && make
root@HiFiveU:~/wolfssl# ./wolfcrypt/benchmark/benchmark -aes-cbc -aes-gcm
------------------------------------------------------------------------------
wolfSSL version 5.7.0
------------------------------------------------------------------------------
Math: Multi-Precision: Wolf(SP) word-size=64 bits=4096 sp_int.c
wolfCrypt Benchmark (block bytes 1048576, min 1.0 sec each)
AES-128-CBC-enc 5 MiB took 12.798 seconds, 0.391 MiB/s
AES-128-CBC-dec 5 MiB took 12.672 seconds, 0.395 MiB/s
AES-192-CBC-enc 5 MiB took 15.301 seconds, 0.327 MiB/s
AES-192-CBC-dec 5 MiB took 15.181 seconds, 0.329 MiB/s
AES-256-CBC-enc 5 MiB took 17.820 seconds, 0.281 MiB/s
AES-256-CBC-dec 5 MiB took 17.669 seconds, 0.283 MiB/s
AES-128-GCM-enc 5 MiB took 12.870 seconds, 0.388 MiB/s
AES-128-GCM-dec 5 MiB took 12.870 seconds, 0.388 MiB/s
AES-192-GCM-enc 5 MiB took 15.375 seconds, 0.325 MiB/s
AES-192-GCM-dec 5 MiB took 15.376 seconds, 0.325 MiB/s
AES-256-GCM-enc 5 MiB took 17.878 seconds, 0.280 MiB/s
AES-256-GCM-dec 5 MiB took 17.896 seconds, 0.279 MiB/s
AES-128-GCM-STREAM-enc 5 MiB took 12.878 seconds, 0.388 MiB/s
AES-128-GCM-STREAM-dec 5 MiB took 12.878 seconds, 0.388 MiB/s
AES-192-GCM-STREAM-enc 5 MiB took 15.379 seconds, 0.325 MiB/s
AES-192-GCM-STREAM-dec 5 MiB took 15.385 seconds, 0.325 MiB/s
AES-256-GCM-STREAM-enc 5 MiB took 17.881 seconds, 0.280 MiB/s
AES-256-GCM-STREAM-dec 5 MiB took 17.888 seconds, 0.280 MiB/s
GMAC Table 4-bit 30 MiB took 1.006 seconds, 29.831 MiB/s
Benchmark complete
At wolfSSL we’re excited about stateful hash-based signature schemes and the CNSA 2.0, and we just had a webinar on this subject. If you recall, previously we added initial support for LMS/HSS and XMSS/XMSS^MT, through external integration with the hash-sigs and xmss-reference implementations.
Recently however we have completed our own wolfCrypt implementations of these algorithms, and would like to share benchmarking results and some of the build options available. Generally the wolfCrypt implementations of these signature methods are faster, with more options available to tune build size and performance.
With that said, we’ll review some of the more relevant build options and benchmarking data for LMS/HSS, and XMSS/XMSS^MT. These benchmarks were obtained on a Fedora 38 workstation with an Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz. Only a single core was used. wolfSSL was built with –enable-intelasm to utilize assembly speedups for all tests. Note: LMS/HSS and XMSS/XMSS^MT support a very wide range of parameters. For the sake of conciseness only a targeted range is benchmarked here.
LMS build options and benchmarking
The five main defines that customize the wolfCrypt LMS/HSS build are the following:
WOLFSSL_LMS_LARGE_CACHES
WOLFSSL_WC_LMS_SMALL
WOLFSSL_LMS_MAX_LEVELS=N
WOLFSSL_LMS_MAX_HEIGHT=H
WOLFSSL_LMS_VERIFY_ONLY
The define WOLFSSL_LMS_LARGE_CACHES will cache more of the authentication path into memory, speeding up signing operations for larger height trees.
The define WOLFSSL_WC_LMS_SMALL reduces code size and memory use overall, with the tradeoff of much slower signing operations. However the performance impact for verification is negligible.
The defines WOLFSSL_LMS_MAX_LEVELS, and WOLFSSL_LMS_MAX_HEIGHT set compile time limits on the size of the LMS/HSS hypertree, and mainly reduce code footprint without impacting performance. These can be used to slim the build size if you are only interested in a specific parameter set range. More specifically, WOLFSSL_LMS_MAX_LEVELS sets the max allowed levels in HSS (the number of trees in the hypertree), while WOLFSSL_LMS_MAX_HEIGHT sets the max allowed height per tree for both LMS and HSS.
The define WOLFSSL_LMS_VERIFY_ONLY restricts the build to a smaller verify-only subset (LMS API and data structures needed for keygen/signing are omitted). This does not impact verify performance, and is intended for embedded targets that need verify-only functionality (e.g. wolfBoot). WOLFSSL_LMS_VERIFY_ONLY can be combined with WOLFSSL_WC_LMS_SMALL, WOLFSSL_LMS_MAX_LEVELS, and WOLFSSL_LMS_MAX_HEIGHT for further footprint reduction.
In Table 1 we show benchmarking results (obtained with ./wolfcrypt/benchmark/benchmark -lms_hss) for these different build options, with the external LMS/HSS implementation provided for comparison.
In general we see the default wolfCrypt LMS/HSS performance (wc_lms) is much faster than the external integration (ext_lms) for all categories of operation (keygen, signing, verifying). The WOLFSSL_LMS_LARGE_CACHES (wc_lms large) option speeds up signing operations for larger height trees, but otherwise does not impact performance. The small variations in verify speed across wc_lms, wc_lms large, and wc_lms small are likely just system noise and do not represent a systematic trend. The WOLFSSL_WC_LMS_SMALL option (wc_lms small) significantly reduces signing speed, but leaves verification speed basically unchanged, making this option attractive for verify-only applications in embedded systems.
Table 1: Comparison of wolfCrypt LMS/HSS (wc_lms), wolfCrypt LMS/HSS with WOLFSSL_LMS_LARGE_CACHES (wc_lms large), wolfCrypt LMS/HSS with WOLFSSL_WC_LMS_SMALL (wc_lms small), and the external integration implementation (ext_lms). All values in units of ops/sec.
wc_lms
wc_lms large
wc_lms small
ext_lms
L2_H10_W2 keygen
6.482
6.494
12.828
1.330
L2_H10_W2 sign
4437.469
5521.796
6.526
786.083
L2_H10_W2 verify
13954.450
14087.794
13874.450
4789.383
L2_H10_W4 keygen
3.567
3.592
6.954
0.764
L2_H10_W4 sign
2452.361
3052.326
3.562
443.225
L2_H10_W4 verify
6482.891
6707.271
6962.215
2281.440
L3_H5_W4 keygen
70.926
73.673
227.376
17.467
L3_H5_W4 sign
4660.370
4669.019
74.653
820.640
L3_H5_W4 verify
4632.118
4670.963
4790.742
1756.355
L3_H5_W8 keygen
9.395
9.413
29.041
2.265
L3_H5_W8 sign
609.408
605.199
9.542
106.059
L3_H5_W8 verify
561.759
554.635
573.341
214.093
L3_H10_W4 keygen
2.384
2.368
7.128
0.569
L3_H10_W4 sign
2459.698
3067.848
2.376
444.601
L3_H10_W4 verify
4895.203
4345.130
4793.853
1618.676
L4_H5_W8 keygen
7.045
7.017
29.258
1.770
L4_H5_W8 sign
608.915
607.318
7.168
106.881
L4_H5_W8 verify
446.384
443.804
438.542
145.672
Graph 1: Signing speeds for wolfCrypt LMS/HSS (wc_lms), wolfCrypt LMS/HSS with WOLFSSL_LMS_LARGE_CACHES (wc_lms large), and the external integration implementation (ext_lms). All values in units of ops/sec.
XMSS build options and benchmarking
Three important defines that customize the wc_xmss build are:
WOLFSSL_WC_XMSS_SMALL
WOLFSSL_XMSS_MAX_HEIGHT=N
WOLFSSL_XMSS_VERIFY_ONLY
The define WOLFSSL_WC_XMSS_SMALL reduces code size and memory use overall, with the tradeoff of much slower signing operations, and 20-30% slower verification.
The define WOLFSSL_XMSS_MAX_HEIGHT=N sets compile time limits on the max height of the hypertree, and mainly reduces code size without impacting performance.
The define WOLFSSL_XMSS_VERIFY_ONLY restricts the build to a smaller verify-only subset, and can be combined with WOLFSSL_WC_XMSS_SMALL, and WOLFSSL_XMSS_MAX_HEIGHT for further size reduction. It does not impact verify performance.
In Table 2 we show benchmarking results for XMSS/XMSS^MT for these options (obtained with ./wolfcrypt/benchmark/benchmark -xmss_xmssmt_sha256), with the external XMSS/XMSS^MT implementation for comparison. The default wolfCrypt XMSS/XMSS^MT (wc_xmss) is in general better than the external integration (ext_xmss), for all operations. There is a smaller difference between wc_xmss and ext_xmss as compared to wc_lms and ext_lms though, because ext_xmss can benefit from assembly speedups whereas ext_lms cannot. Similar to LMS, the WOLFSSL_WC_XMSS_SMALL option (wc_xmss small) significantly reduces signing performance, but verify speeds remain fast, making this a good option for embedded verify-only targets.
Table 2: Comparison of wolfCrypt XMSS/XMSS^MT (wc_xmss), wolfCrypt XMSS/XMSS^MT with WOLFSSL_WC_XMSS_SMALL (wc_xmss small), and the external integration implementation (ext_xmss). All values in units of ops/sec.
wc_xmss
wc_xmss small
ext_xmss
XMSS-SHA2_10_256 keygen
1.587
1.079
0.943
XMSS-SHA2_10_256 sign
363.693
1.106
226.782
XMSS-SHA2_10_256 verify
3050.276
2044.995
1892.234
XMSSMT-SHA2_20/2_256 keygen
0.808
1.100
0.472
XMSSMT-SHA2_20/2_256 sign
298.138
0.551
191.214
XMSSMT-SHA2_20/2_256 verify
1307.295
982.836
852.348
XMSSMT-SHA2_20/4_256 keygen
9.880
35.274
7.309
XMSSMT-SHA2_20/4_256 sign
390.942
8.681
290.516
XMSSMT-SHA2_20/4_256 verify
729.433
517.298
443.444
XMSSMT-SHA2_40/4_256 keygen
0.406
1.107
0.237
XMSSMT-SHA2_40/4_256 sign
294.738
0.276
161.656
XMSSMT-SHA2_40/4_256 verify
750.591
487.257
424.986
XMSSMT-SHA2_40/8_256 keygen
5.604
35.318
3.755
XMSSMT-SHA2_40/8_256 sign
469.764
4.374
293.184
XMSSMT-SHA2_40/8_256 verify
361.289
262.160
225.254
XMSSMT-SHA2_60/6_256 keygen
0.266
1.099
0.159
XMSSMT-SHA2_60/6_256 sign
280.160
0.185
144.637
XMSSMT-SHA2_60/6_256 verify
521.610
352.718
295.882
XMSSMT-SHA2_60/12_256 keygen
4.143
35.280
2.505
XMSSMT-SHA2_60/12_256 sign
514.658
2.910
292.371
XMSSMT-SHA2_60/12_256 verify
247.682
170.459
152.471
Graph 2: Verify speeds for wolfCrypt XMSS/XMSS^MT (wc_xmss), wolfCrypt XMSS/XMSS^MT with WOLFSSL_WC_XMSS_SMALL (wc_xmss small), and the external integration implementation (ext_xmss). All values in units of ops/sec.
Conclusions
In general our wolfCrypt implementations for LMS/HSS and XMSS/XMSS^MT are significantly faster than the external reference implementations, with speedups of 20-30% to even 3x-4x possible depending on the combination of operation, algorithm, and parameters.
The small footprint build shows fast verification speeds for all parameters, making it an attractive choice for embedded verify-only applications (e.g. wolfBoot).
Overall our LMS/HSS implementation is faster than XMSS/XMSS^MT (at least on x86), which is consistent with what is known about these two methods. However which of the two is more appropriate for your use case will ultimately depend on other factors as well, such as signature size, target environment, and parameters used.
If you’re interested in learning more about our post-quantum work, or want to learn more about stateful hash-based signature schemes, contact us at wolfSSL by emailing facts@wolfSSL.com or calling us at +1 425 245 8247 to reach out to your regional wolfSSL business director.
It may not be as glamorous as the new ESP32 RISC-V chipsets with all the various hardware acceleration capabilities, but the ESP8266 is a well established device which has a large codebase available with an even larger user community.
Due to high customer demand, we’ve enhanced the wolfSSL libraries for the ESP8266. The recent changes have improved both the ESP-IDF CMake and traditional Makefile builds. This new capability allows for specification of the wolfSSL component source code as an alternative to using the setup script to copy everything locally.
For make, set the WOLFSSL_ROOT value in components/wolfssl/component.mk
For cmake, there are more options:
Set the WOLFSSL_ROOT value in components/wolfssl/CMakeLists.txt
Set the WOLFSSL_ROOT environment variable.
Have the components/wolfssl/CMakeLists.txt as a subdirectory in wolfSSL.
When a project is in a subdirectory of wolfSSL, the cmake file will search parent directories, up to the root, looking for wolfSSL.
The ability to specify the wolfSSL component source code ensures consistent versioning across projects and facilitates easy updates via GitHub.
You may have seen our recent announcement regarding wolfCrypt hardware acceleration for the ESP32 series. There’s no such capability on the ESP8266. However, there’s still a noticeable difference between debug and release optimizations, as shown at the end of this blog.
Once the Espressif ESP8266 RTOS SDK is installed, it is easy to get the wolfSSL examples working (see the README for more details):
# Set your path to RTOS SDK,
# shown here for default from WSL with VisualGDB
WRK_IDF_PATH=/mnt/c/SysGCC/esp8266/rtos-sdk/v3.4
# or
WRK_IDF_PATH=~/esp/ESP8266_RTOS_SDK
# Setup the environment
. $WRK_IDF_PATH/export.sh
# Optional: install as needed / prompted
# /mnt/c/SysGCC/esp8266/rtos-sdk/v3.4/install.sh
# Fetch wolfssl from GitHub if needed:
cd /workspace
git clone https://github.com/wolfSSL/wolfssl.git
# change directory to wolfssl client example.
cd wolfssl/IDE/Espressif/ESP-IDF/examples/wolfssl_client
# Adjust settings as desired
# Set IP address and wifi SSID name & password
idf.py menuconfig
# Build, flash and monitor
idf.py build flash -p /dev/ttyS70 -b 115200
idf.py monitor -p /dev/ttyS70 -b 74880
Are you interested in using the ESP8266 or ESP32 in your next project? Let us know! We love to hear about how wolfSSL is being used, and can optionally help promote your project on social media, with your approval.
