RECENT BLOG NEWS

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 with software only running at 160MHz here are our current wolfSSL benchmarks:

ESP-ROM:esp32c3-api1-20210207
Build:Feb  7 2021
rst:0x1 (POWERON),boot:0xf (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:DIO, clock div:1
I (30) boot: ESP-IDF v4.4.1-dirty 2nd stage bootloader
I (30) boot: compile time 10:13:40
I (30) boot: chip revision: 3
I (32) boot.esp32c3: SPI Speed      : 80MHz
I (37) boot.esp32c3: SPI Mode       : DIO
I (42) boot.esp32c3: SPI Flash Size : 4MB
I (47) boot: Enabling RNG early entropy source...
I (216) cpu_start: cpu freq: 160000000
I (216) cpu_start: Application information:
I (218) cpu_start: Project name:     wolfSSL_esp32_benchmark
I (225) cpu_start: App version:      v0.1-925-g935ebfd
I (231) cpu_start: Compile time:     Aug  3 2022 10:12:05
I (237) cpu_start: ELF file SHA256:  900d509ee08c8d01...
I (243) cpu_start: ESP-IDF:          v4.4.1-dirty
I (249) heap_init: Initializing. RAM available for dynamic allocation:
I (255) heap_init: At 3FC8DB60 len 000324A0 (201 KiB): DRAM
I (261) heap_init: At 3FCC0000 len 0001F060 (124 KiB): STACK/DRAM
I (268) heap_init: At 50000020 len 00001FE0 (7 KiB): RTCRAM
I (275) spi_flash: detected chip: generic
I (279) spi_flash: flash io: dio
AES-128-CBC-enc     10 MB took 1.000 seconds,   10.376 MB/s
AES-128-CBC-dec     11 MB took 1.001 seconds,   10.561 MB/s
AES-192-CBC-enc      9 MB took 1.000 seconds,    9.399 MB/s
AES-192-CBC-dec     10 MB took 1.000 seconds,    9.546 MB/s
AES-256-CBC-enc      9 MB took 1.000 seconds,    8.594 MB/s
AES-256-CBC-dec      9 MB took 1.002 seconds,    8.723 MB/s
AES-128-GCM-enc      3 MB took 1.007 seconds,    2.546 MB/s
AES-128-GCM-dec      3 MB took 1.007 seconds,    2.546 MB/s
AES-192-GCM-enc      2 MB took 1.004 seconds,    2.480 MB/s
AES-192-GCM-dec      2 MB took 1.004 seconds,    2.480 MB/s
AES-256-GCM-enc      2 MB took 1.008 seconds,    2.422 MB/s
AES-256-GCM-dec      2 MB took 1.009 seconds,    2.420 MB/s
GMAC Default         3 MB took 1.000 seconds,    3.397 MB/s
3DES                 3 MB took 1.003 seconds,    3.164 MB/s
MD5                102 MB took 1.000 seconds,  101.978 MB/s
SHA                 49 MB took 1.000 seconds,   48.730 MB/s
SHA-256             15 MB took 1.000 seconds,   14.941 MB/s
SHA-512             13 MB took 1.001 seconds,   12.731 MB/s
HMAC-MD5           101 MB took 1.000 seconds,  100.977 MB/s
HMAC-SHA            48 MB took 1.000 seconds,   48.291 MB/s
HMAC-SHA256         15 MB took 1.001 seconds,   14.805 MB/s
HMAC-SHA512         13 MB took 1.001 seconds,   12.536 MB/s
PBKDF2               2 KB took 1.008 seconds,    1.829 KB/s
RSA     2048 public        394 ops took 1.000 sec, avg 2.538 ms, 394.000 ops/sec
RSA     2048 private         8 ops took 1.293 sec, avg 161.625 ms, 6.187 ops/sec
ECC   [      SECP256R1]   256 key gen        50 ops took 1.039 sec, avg 20.780 m                                  s, 48.123 ops/sec
ECDHE [      SECP256R1]   256 agree          50 ops took 1.038 sec, avg 20.760 m                                  s, 48.170 ops/sec
ECDSA [      SECP256R1]   256 sign           48 ops took 1.010 sec, avg 21.042 m                                  s, 47.525 ops/sec
ECDSA [      SECP256R1]   256 verify         26 ops took 1.045 sec, avg 40.192 m                                  s, 24.880 ops/sec
CURVE  25519 key gen        20 ops took 1.003 sec, avg 50.150 ms, 19.940 ops/sec
CURVE  25519 agree          20 ops took 1.002 sec, avg 50.100 ms, 19.960 ops/sec
ED     25519 key gen       529 ops took 1.001 sec, avg 1.892 ms, 528.472 ops/sec
ED     25519 sign          470 ops took 1.000 sec, avg 2.128 ms, 470.000 ops/sec
ED     25519 verify        254 ops took 1.002 sec, avg 3.945 ms, 253.493 ops/sec
Benchmark complete
I (467072) wolfbenchmark: wolfssl_check: 0

See also:

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

For questions please email facts@wolfssl.com

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.

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/

For questions please email facts@wolfssl.com

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.

To take a look at the code and test it out contact us at fact@wolfssl.com.

The cURL Project and wolfSSL is happy to announce the annual cURL Developers Conference, cURL Up has been rescheduled for Thursday September 15, 2022! cURL Up will be held virtually this September giving allowing the world – wide cURL community to join.

cURL Up is the annual curl developers conference where we gather and talk Internet protocols, curl’s past, current situation and how to design its future.

This is an intimate and very friendly meetup where you will have the opportunity to talk to Daniel Stenberg, founder and maintainer of cURL, as well as other speakers and sponsors about cURL and related technologies.

The first 50 registrants get some awesome swag!

When: Sep 15, 2022 06:00 AM Pacific Time (US and Canada)

Register in advance for this webinar:
https://us02web.zoom.us/webinar/register/WN_YHLm4WXGSKC-D8O6sgIb6Q

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

If you have questions or comments contact us at facts@wolfssl.com

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, comments or suggestions, send us an email at facts@wolfssl.com.