wolfSSL 3.12.2 is now available for download! This release includes many performance improvements with Intel ASM (AVX/AVX2) and AES-NI. wolfSSL has implemented a new single precision math option to speed up RSA, DH and ECC in this release. Embedded hardware support has been expanded for STM32, PIC32MZ and ATECC508A, and AES-XTS mode support has been added for use with disk encryption.
There have been improvements to some of our certificate API’s that allow for setting the serial number, key usage and extended key usage. A refactor of the `SSL_` API’s and hash types has been performed to allow OpenSSL coexistence. There have been improvements made for TLS 1.3 support in this release. A fix was implemented for OCSP stapling to prevent sending the extension unexpectedly, WOLFSSL specific user contexts were added for callbacks, and there were fixes for some OpenSSL and MySQL compatibility functions. The wolfSSL Micrium port was updated for Micrium uC/OS-III, and there were fixes implemented for asynchronous modes as well.
Continue reading below for a summary of the features and fixes included in this release!
- Speedups for SHA2, ChaCha20/Poly1035 using AVX/AVX2
- Speedups for AES GCM with AES-NI (–enable-aesni)
- New Single Precision math option for RSA, DH and ECC (See –enable-sp) (all off by default).
- Math updates and added TFM_MIPS speedup
- Fixes for HAVE_INTEL_MULX
- Added AES XTS mode (–enable-xts)
- Rename the file io.h/io.c to wolfio.h/wolfio.c
- Cleanup the wolfIO_Send function
- Improvements to Visual Studio DLL project/solution
- Added function to generate public ECC key from private key
- Added async blocking support for sniffer tool
- Updated Micrium uC/OS-III Port
- Fixes for various TLS 1.3 disable options (RSA, ECC and ED/Curve 25519)
- Fix to disallow upgrading to TLS v1.3
- Fixes for wolfSSL_EVP_CipherFinal() when message size is a round multiple of a block size
- Add HMAC benchmark and expanded AES key size benchmarks
- Added simple GCC ARM Makefile example (see IDE/GCC-ARM)
- Add tests for 3072-bit RSA and DH
- Fixed DRAFT_18 define and fixed downgrading with TLS v1.3
- Alternate certificate chain support with WOLFSSL_ALT_CERT_CHAINS defined enables checking a cert against multiple CA’s
- Fixes to allow custom serial number during certificate generation
- Added method to get WOLFSSL_CTX certificate manager
- Improvement to wolfSSL_SetOCSP_Cb to allow a context per WOLFSSL object
- Updated root certs for OCSP scripts
- Added ASN Extended Key Usage Support. (See wc_SetExtKeyUsage)
- Fix for creation of the KeyUsage BitString
- Added TLS extension for Supported Point Formats (ec_point_formats)
- Fix to not send OCSP stapling extensions in client_hello when not enabled
- Added new API’s for disabling OCSP stapling
- Add check for SIZEOF_LONG with Sun and LP64
- Added new –disable-oldnames option to allow for using openssl alongside wolfssl headers (without OPENSSL_EXTRA)
- Refactor SSL_ and hashing types to use wolf specific prefix (WOLFSSL and WC_) to allow OpenSSL coexistence
- Added configure option for building library for wolfSSH (–enable-wolfssh)
- Added ability to use wolf implementation of strtok using USE_WOLF_STRTOK
- Cleanup include paths for MySQL cmake build
- Fix for 8k keys with MySQL compatibility
- OpenSSL compatibility layer improvements, additions, and fixes
- Expanded API unit tests
- Update HASH_DRBG Reseed mechanism and add test case
- Added wolfCrypt hash tests for empty string and large data
- Fixes for STM32 crypto hardware acceleration
- Fixes for ATECC508A
- Fixes for PIC32MZ hashing
- Fixes and improvements to asynchronous modes for Intel QuickAssist and Cavium Nitrox V
Team wolfSSL is preparing for Halloween with a pumpkin carving! Our embedded security products are continually evolving. We encourage you to check our our wolfSSL embedded SSL/TLS library here, wolfMQTT, wolfSSH, or visit our product page for a complete list of lightweight Open Source security products.
As always if you have any questions, or would like more information about our products, please contact us at email@example.com.
It recently came to our attention that the preprocessor macro ALT_ECC_SIZE was missing in our documentation. As a result we decided to post a blog about this to help inform customers of the value for using this in space constrained devices using the fastmath math library with RSA/DH and ECC in wolfSSL.
The fastmath code uses an array of a fixed size to store the big integers. By default, the array is big enough for RSA 2048-keys. The FP_MAX_BITS option can be used to make the array smaller if just using ECC. If using both RSA/DH and ECC, the define ALT_ECC_SIZE provides an alternate smaller size for the ecc_point structure. The size can be manually adjusted using FP_MAX_BITS_ECC, otherwise it will be calculated automatically based on the enabled curves.
Without ALT_ECC_SIZE, the ecc_point has three single item arrays of mp_ints for the components of the point. With ALT_ECC_SIZE, the components of the point are pointers that are set to each of a three item array of alt_fp_ints. While an mp_int will have 4096 bits of digit inside the structure, the alt_fp_int will only have 528 bits. A size value was added in the ALT case, as well, and is set by mp_init() and alt_fp_init(). The functions fp_zero() and fp_copy() use the size parameter. An int needs to be initialized before using it instead of just fp_zeroing it, the init will call zero. FP_MAX_BITS_ECC defaults to 528, but can be set to change the number of bits used in the alternate FP_INT.
The ALT_ECC_SIZE option can only be enabled with USE_FAST_MATH.
More details can be found in the wolfssl/wolfcrypt/ecc.h file.
If you have any questions, concerns, comments or feedback please contact us anytime at firstname.lastname@example.org or email@example.com.
We at wolfSSL are pleased to announce that now you can use wolfSSL directly from Docker!
In a few words, Docker is a tool designed to make it easier to create, deploy, and run applications by using containers. Containers are like virtual machines, but way more lighter as the container shares some resources with the hosting machine.
We created a collection of wolfSSL containers targeting the following OSs: Debian, Ubuntu, Alpine Linux, CentOS
There are 3 different flavors of containers we have created based on each OS, they are: lib, test and examples
wolfssl/wolfssl ubuntu-examples 9198e6d82596 127MB
wolfssl/wolfssl ubuntu-test ba5ca8ca4359 351MB
wolfssl/wolfssl ubuntu-lib 125125eea7ab 126MB
ubuntu latest 2d696327ab2e 122MB
wolfssl/wolfssl debian-examples cd066ee3b5db 106MB
wolfssl/wolfssl debian-test 5a3edb3a2a20 356MB
wolfssl/wolfssl debian-lib 3086ef0f07b6 105MB
debian latest 72ef1cf971d1 100MB
wolfssl/wolfssl centos-examples 37687e96d5b9 222MB
wolfssl/wolfssl centos-test 359d4195ca53 392MB
wolfssl/wolfssl centos-lib a8c6cafd6205 221MB
centos latest 196e0ce0c9fb 197MB
wolfssl/wolfssl alpine-examples 490120f86d61 8.74MB
wolfssl/wolfssl alpine-test 52b698631bec 228MB
wolfssl/wolfssl alpine-lib 692a0c26cda6 7.97MB
alpine latest 76da55c8019d 3.97MB
The -lib images contains only the wolfSSL binaries, while -examples also contains the test examples and -test also contains wolfSSL’s source code.
You can find further information on how to run wolfSSL examples on a docker container in our docker hub page: https://hub.docker.com/u/wolfssl/
And here is a quick example, server in the left tab and the client in the right tab:
A recent paper used wolfSSL as a test bed for proving out their attack on Ed25519 signatures. You can read the paper here: https://eprint.iacr.org/2017/985.pdf . This was not an attack on wolfSSL itself or its implementation, but rather a differential power attack that involves SHA-512 and Ed25519. The recommended countermeasure is to change Ed25519 and remove its deterministic signature properties. If you are interested in this countermeasure please let us know as we can make this available as a build option.
According to a recent article, researchers have announced that Wi-Fi security has a protocol level exploit that can render all Wi-Fi traffic vulnerable to sniffing or manipulation. The good news is that if you are already using an independent form of end-to-end encryption such as SSL/TLS then the stolen packets are of little use as they are encrypted independent of the WEP/WPA1/WPA2 protocols.
These vulnerabilities are scheduled to be presented on November 1st at the 24th annual “ACM Conference on Computer and Communications Security” to be held in Dallas, TX.
“Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2”
Mathy Vanhoef (KU Leuven, imec-DistriNet)
Frank Piessens (KU Leuven, imec-DistriNet)
Securing your Wi-Fi traffic with SSL/TLS, offered by @wolfSSL, can keep your data secure in a wireless world by providing independent end-to-end security for your Wi-Fi traffic rendering any stolen Wi-Fi traffic useless to attackers. Users MUST BE AWARE and look for the green lock to ensure the SSL/TLS was not stripped while using Wi-Fi (See video below for explanation!)
PLEASE WATCH THIS VIDEO so you know how to detect if SSL/TLS has been STRIPPED and your traffic is vulnerable to sniffing and/or modification!
An addendum to the report notes that all WPA Supplicant users using v2.6 are vulnerable to this attack (All android 6.0+ users).