So, what’s new at wolfSSL? Take a look below to check out the most recent news.

wolfSSL at XSWIG

wolfSSL recently presented at the XSWIG (Xilinx Security Working Group) in Longmont Colorado. Covering the topics of building wolfSSL for an Ultrazed EG starter kit and collecting benchmark values with hardware acceleration. If you would like more details of what we talked about, or are looking to add security to an FPGA embedded board contact us at!

wolfSSL at ARM TechCon 2017

Join wolfSSL at ARM TechCon, in booth #420, for the world’s largest ARM event! October 25th & 26th at the Santa Clara Convention Center in Santa Clara, CA. wolfSSL Engineer, David Garske and Business Director, Rich Kelm will be on hand to answer your Cryptography, SSL/TLS questions and talk about what’s new in the world of wolfSSL! Email if you would like to schedule an appointment!

Breaking Ed25519 paper using wolfSSL

A recent paper used wolfSSL as a test bed for proving out their attack on Ed25519 signatures.  You can read the paper here: .  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.

KRACK Attacks: Wi-Fi Security Has Been Breached

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.

Paper Title:

     “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).


Internship Info Session and MSU Fall Career Fair

In preparation for the 2018 Fall Career Fair at MSU Bozeman, wolfSSL will be holding an info session this upcoming Thursday at Montana State University in Bozeman, MT for students interested in learning more about wolfSSL and our upcoming 2018 Summer internship program.  The session will introduce wolfSSL as a company – including background information, product lineup, work environment, and more.

We encourage any students who are interested in Internet security, SSL/TLS, cryptography, embedded security, or software development to attend!  Pizza will be served.

wolfSSL Info Session
Thursday, September 28, 2017
Montana State University, Bozeman
5-6pm, Roberts Hall 321

We look forward to seeing you there! Feel free to contact with any questions or for more information. To learn more about the wolfSSL lightweight SSL/TLS library, visit our product page, or download the Open Source version today!

Sensors Midwest 2017

You are invited to join wolfSSL at the 2017 Sensors Midwest Expo. Sensors Midwest, the only event 100% dedicated to sensors and sensing technologies, is taking place October 3-4, 2017 at the Donald E. Stephens Convention Center in Rosemont, IL. Chris Conlon, Engineering Manager, will be on hand to answer any and all of your Cryptography and SSL/TLS questions.

If you are attending or planning on attending please stop by the wolfSSL booth (#1009) or schedule an appointment by contacting Christin either by phone at +1 206 459 7061 or by email at

wolfSSL Intel SGX Testing

wolfSSL has support for Intel SGX and we do continuous integration testing on that support. This means that every night a process starts up and runs unit tests on crypto operations in a secure Enclave. Here’s a peek at some of the on going tests in action

LINK => App
GEN => trusted/Wolfssl_Enclave_t.c
CC <= trusted/Wolfssl_Enclave_t.c
cc -Wno-implicit-function-declaration -std=c11 -m64 -O2 -nostdinc -fvisibility=hidden -fpie -fstack-protector -IInclude -Itrusted -I../..// -I../..//wolfcrypt/ -I/opt/intel/sgxsdk/include -I/opt/intel/sgxsdk/include/tlibc -I/opt/intel/sgxsdk/include/stlport-fno-builtin -fno-builtin-printf -I. -DWOLFSSL_SGX -DHAVE_WOLFSSL_TEST -c trusted/Wolfssl_Enclave.c -o trusted/Wolfssl_Enclave.o
CC <= trusted/Wolfssl_Enclave.c -m64 -O2 -Wl,--no-undefined -nostdlib -nodefaultlibs -nostartfiles -L/opt/intel/sgxsdk/lib64 -L../../IDE/LINUX-SGX/ -lwolfssl.sgx.static.lib -Wl,--whole-archive -lsgx_trts -Wl,--no-whole-archive -Wl,--start-group -lsgx_tstdc -lsgx_tstdcxx -lsgx_tcrypto -lsgx_tservice -Wl,--end-group -Wl,-Bstatic -Wl,-Bsymbolic -Wl,--no-undefined -Wl,-pie,-eenclave_entry -Wl,--export-dynamic -Wl,--defsym,__ImageBase=0 -Wl,--version-script=trusted/ LINK =>

+ ./App -t
Crypt Test:
error test passed!
base64 test passed!
base64 test passed!
MD5 test passed!
MD4 test passed!
SHA test passed!
SHA-256 test passed!
Hash test passed!
HMAC-MD5 test passed!
HMAC-SHA test passed!
HMAC-SHA256 test passed!
GMAC test passed!
ARC4 test passed!
HC-128 test passed!
Rabbit test passed!
DES test passed!
DES3 test passed!
AES test passed!
AES192 test passed!
AES256 test passed!
AES-GCM test passed!
RANDOM test passed!
RSA test passed!
DH test passed!
DSA test passed!
PWDBASED test passed!
ECC test passed!
ECC buffer test passed!
mutex test passed!
memcb test passed!
Crypt Test: Return code 0

Interested in using FIPS with SGX or questions about wolfSSL testing? Contact us at

IoT Oil and Gas 2017

Come join wolfSSL at the IoT in Oil and Gas Conference

Rod Weaver, of the wolfSSL Team, will be in Houston, Texas, this week, Wednesday September 13th through Friday September 15th for the IoT Oil and Gas Conference. This event will be held at the Marriott Westchase.

If you are attending or planning on attending please stop buy our Booth or schedule an appointment with Rod to talk Cryptography at the show. You can contact either Rod by phone at (425) 245-8247 or by email at

How to use the 0-RTT rope to climb, without hanging yourself!

One of the major new features of TLS v1.3 is the 0-RTT handshake protocol. This variation of the handshake, using Pre-Shared Keys (PSKs), allows the client to send encrypted data to the server in the first flight. This is particularly useful for TLS on embedded devices. Take the example of IoT. There may be thousands or even millions of devices reporting back regularly to the central servers with small updates.

Using 0-RTT, the IoT device can send a ClientHello plus all the update data, known as “early data”, in one flight. Then, the server responds with the ServerHello, EncryptedExtensions, and Finished messages plus acknowledgement of the early data all in one flight. Finally the device responds with EndOfEarlyData and Finished messages in a final flight to close the loop on the security.

We can see that the data is offloaded, without having to wait for the server. The device stores a little state and goes back to its job ready for the interrupt on response. If the response times out then the server can resend with an updated ClientHello. On response, the device processes the handshake messages and responds closing the connection and the update can be discarded.

This is all very efficient in terms of processing and overall round-trip time. But, there are potential security issues including: replay attacks and no forward security.

An attacker can replay messages from a device. The server decrypts the early data using a key directly derived from the PSK and no other authentication is performed. Without the second flight from the client, the server would not recognize the copy is invalid. The recommended defense is single-use tickets. Each ticket contains a fresh PSK. This has the downside of requiring a shared database of tickets across servers. Alternatively, unique values from the ClientHello used with each PSK can be stored instead.

The attacker may also intercept the client’s first flight and spam the server with copies. If the early data contains “state modifying” data as in the example above, processing a copy would be disastrous. If the PSK is single-use, the client will get out of sync with the server and a full handshake will be required. The server may well interpret the attack as the client attempting to retry and therefore this must be handled at the application level.

When the PSK is reused for a number of messages, forward secrecy is lost. This means that if a device is compromised all messages encrypted using keys derived from the current PSK are exposed. The recommended defense is to use a short timeout with tickets to limit the period of vulnerability.

Using 0-RTT does require more careful architecture on the server side, the benefits at the client side are worth it.

Posts navigation

1 2 3 4 73 74 75


Latest Tweets