Category: Uncategorized

wolfSSL is happy to announce that the first release of the wolfSSL JNI wrapper is now available for download.

wolfSSL JNI provides Java applications with SSL/TLS support up to the current industry standards of TLS 1.2 and DTLS 1.2.  Current Java implementations have lacked DTLS support, causing Java developers to write their own custom JNI wrapper if they wanted or needed to use DTLS.  wolfSSL JNI solves this problem by giving developers a ready-to-use Java wrapper around the robust and mature CyaSSL lightweight SSL library.

In addition to providing DTLS support, wolfSSL JNI has been designed with flexibility in mind.  It allows Java applications to write custom callbacks for I/O, public key, MAC/encrypt, decrypt/verify, and logging, and allows developers to leverage all the flexibility and portability that has made CyaSSL popular with users around the globe.

Like CyaSSL, wolfSSL JNI is dual licensed under both the GPLv2 as well as a standard commercial license.  Detailed licensing and support options can be found on the wolfSSL Licensing page (linked below).

Download wolfSSL JNI and give it a try!  If you have any questions or comments, please feel free to reach out to us at facts@wolfssl.com.

Download:  https://www.wolfssl.com/download/
wolfSSL JNI Manual: http://www.yassl.com/yaSSL/Docs-wolfssl-jni-manual.html
wolfSSL JNI Product Page:  http://yassl.com/yaSSL/Products-wolfssljni.html
License Information:  http://yassl.com/yaSSL/License.html

Hi!  We are currently considering implementing Oauth for devices.  

OAuth, first defined by RFC 5849 (1.0), and revised with RFC 6749 (2.0) specifies an authorization framework to allow third party applications to obtain limited access to HTTP services.  From RFC 6749:

“In the traditional client-server authentication model, the client requests an access-restricted resource (protected resource) on the server by authenticating with the server using the resource owner`s credentials.  In order to provide third-party applications access to restricted resources, the resource owner shares its credentials with the third party.”

Under this traditional approach, third parties are given direct access to the resource owner`s credentials.  This brings with it several concerns, including passwords being stored in plaintext, third parties gaining overly-broad access to the resource owner`s resources, and the inability for resource owners to revoke third party privileges without having to change their password.

OAuth presents a way to solve these issues by having the third party application request access to resources controlled by a resource owner (which are hosted on a resource server).  The application is then issued a different set of credentials than those of the resource owner which it can then in turn use to access the desired resources.

Do you need an OAuth client on your device or for your embedded application?  If so, let us know at facts@wolfssl.com.

RFC 5849:  http://tools.ietf.org/html/rfc5849
RFC 6749:  http://tools.ietf.org/html/rfc6749
OAuth Community Site:  http://oauth.net/

Hi!  This is just a reminder.  We are still all about open source.  We believe that Open Source Software is the best way to conceive, share, deliver, support and build software.

We believe in open source for all of the right and well documented reasons.  If you can`t work with open source then tell us your story at facts@wolfssl.com.

Hi!  The CyaSSL Embedded SSL engine, wolfCrypt cryptography library, and the wolfSSL Embedded Web Server now support Freescale`s ColdFire hardware encryption.  Our initial benchmarks show that AES and 3DES cryptography operations are up to 10 times faster when done with ColdFire`s hardware acceleration.  If you would like to use one of our products with ColdFire, and leverage ColdFire`s hardware cryptography, then contact us at facts@wolfssl.com.

Are you just learning about SSL/TLS, or interested in learning how to layer it into an existing application? If so, we include an SSL tutorial in Chapter 11 of our wolfSSL Manual which provides a good introduction to integrating wolfSSL into a typical TCP socket-based application.

Our SSL/TLS Tutorial uses base examples found in the popular “Unix Network Programming” book by Richard Stevens, Bill Fenner, and Andrew Rudoff. It then walks the programmer through the integration of wolfSSL step by step, eventually giving them a working application with secure communication through SSL.

The tutorial can be found at the following URL:
wolfSSL SSL/TLS Tutorial

Please contact us at facts@wolfssl.com with any questions or comments regarding the tutorial or the wolfSSL lightweight SSL/TLS library.

Hi!  One of the alternative ciphers we`ve considered implementing in wolfSSL is the Serpent Cipher.  Not only does it have a cool sounding alliterative name, but it is theoretically more secure than Rijndael/AES.  In fact, it was a finalist for AES.  An overview of the Serpent Cipher can be found here:  http://en.wikipedia.org/wiki/Serpent_(cipher).

If you think it is productive for us to add Serpent to wolfSSL, then just let us know at facts@wolfssl.com.  

In unrelated news, We Are The Champions http://www.youtube.com/watch?v=04854XqcfCY  of National Cyber Security Awareness Month.  See:  https://staysafeonline.org/ncsam/ncsam-champions/, for the complete list of champions, and how to get involved.  

Hi!  It is rare for a cryptography algorithm to make the pages of the popular press, but Dual_EC_DRBG has done just that!  The best article we`ve seen to date is Kim Zetter`s lucid article in Wired: https://www.wired.com/2013/09/nsa-backdoor/.

For the record, we have never implemented the Dual_EC_DRBG algorithm, nor gone so far as to set it as a default.  See:  http://blog.cryptographyengineering.com/2013/09/rsa-warns-developers-against-its-own.html

We`re moths to the flame when it comes to alternative and new crypto, as witnessed by our implementations of NTRU, SHA-3, HC-128, and Rabbit.  We like trying new things and then benchmarking them in our test rigs, but on Dual_EC_DRBG, we passed.

All that said, we deliver our products in open source, and you and everyone else are welcome to inspect them.  Our position on our cryptography implementation follows:

1.  We can trace all of our code to a very limited set of developers in our company.  We are open source, but unlike some projects, we tightly control and inspect the code that goes into our mainline.

2.  Our code is vetted out not only by wolfSSL staff, but by a diverse and wide array of people in open source, cryptography, and commercial security companies.  

The above is not true for the OpenSSL project.  As Matthew Green says, OpenSSL is “a patchwork nightmare originally developed by a programmer who thought it would be a fun way to learn Bignum division.* Part of it is because crypto is unbelievably complicated. Either way, there are very few people who really understand the whole codebase.”  See:  http://blog.cryptographyengineering.com/2013/09/on-nsa.html.  Our thoughts on comparing CyaSSL to OpenSSL are here:  https://www.wolfssl.com/how-does-wolfssl-compare-to-openssl/, and here:  https://www.wolfssl.com/openssl-in-devices-gets-cracked-when-trying-to-enhance-randomness-2/

Finally, a comment from Bruce Schneier on staying Secure:  

“Closed-source software is easier for the NSA to backdoor than open-source software. “

http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surveillance

We are open source, and we believe in open source.  Open source is the best way to develop, deliver, and support cryptography.  Ipso Facto.  Over and out from team wolfSSL.

Do you have a processor and compiler which support Intel’s AES-NI? If so, you can take advantage of the increase in performance provided by AES-NI in CyaSSL and wolfCrypt.

wolfSSL has worked with Intel to publish a white paper describing how Intel’s AES-NI can be used with the CyaSSL embedded SSL library. This paper provides a brief overview of the Intel AES-NI instructions and demonstrates the performance gains realized when Intel AES-NI is used in place of a more traditional software-only based AES implementation. The CyaSSL embedded SSL library is used as a test bed in the white paper to perform the comparison as it can be built with either traditional software-based AES or hardware-based AES-NI support at compile time. As a secondary goal to demonstrating Intel AES-NI performance, this paper explains how to determine if a pre-built SSL library (static or shared) offers built-in support for the Intel Advanced Encryption Standard New Instructions.

The white paper can be downloaded directly from the wolfSSL website at the following location. If you have any questions about using CyaSSL on Intel hardware, please contact us at facts@wolfssl.com.

CyaSSL AES-NI White Paper: wolfSSL White Papers (http://yassl.com/yaSSL/cyassl-embedded-ssl-white-papers.html)

Did you know that the CyaSSL lightweight SSL library has support for hardware-based cryptography and random number generation offered by the STM32 processor? Supported cryptographic algorithms include AES (CBC, CTR), DES (ECB, CBC), 3DES, MD5, and SHA1. For details regarding the STM32 crypto and hash processors, please see the STM32F2xx Standard Peripheral Library document (linked below).

Devices using the STM32 with CyaSSL can see substantial speed improvements when using hardware crypto versus using CyaSSL’s software crypto implementation. The following benchmarks were gathered from the CTaoCrypt benchmark application (ctaocrypt/benchmark/benchmark.c) running on the STM3221G-EVAL board (STM32F2) using the STM32F2 Standard Peripheral Library and FreeRTOS.

CyaSSL Software Crypto, Normal Big Integer Math Library

AES 1024 kB took 0.822 seconds,   1.22 MB/s
ARC4 1024 KB took 0.219 seconds,   4.57 MB/s
DES       1024 KB took 1.513 seconds,   0.66 MB/s
3DES     1024 KB took 3.986 seconds,   0.25 MB/s

MD5         1024 KB took 0.119 seconds,   8.40 MB/s
SHA         1024 KB took 0.279 seconds,   3.58 MB/s
SHA-256  1024 KB took 0.690 seconds,   1.45 MB/s

RSA 2048 encryption took 111.17 milliseconds, avg over 100 iterations
RSA 2048 decryption took 1204.77 milliseconds, avg over 100 iterations
DH  2048 key generation   467.90 milliseconds, avg over 100 iterations
DH  2048 key agreement   538.94 milliseconds, avg over 100 iterations

STM32F2 Hardware Crypto, Normal Big Integer Math Library

AES        1024 kB took 0.105 seconds,   9.52 MB/s
ARC4     1024 KB took 0.219 seconds,   4.57 MB/s
DES       1024 KB took 0.125 seconds,   8.00 MB/s
3DES     1024 KB took 0.141 seconds,   7.09 MB/s

MD5           1024 KB took 0.045 seconds,  22.22 MB/s
SHA           1024 KB took 0.047 seconds,  21.28 MB/s
SHA-256  1024 KB took 0.690 seconds,   1.45 MB/s

RSA 2048 encryption took 111.09 milliseconds, avg over 100 iterations
RSA 2048 decryption took 1204.88 milliseconds, avg over 100 iterations
DH  2048 key generation  467.56 milliseconds, avg over 100 iterations
DH  2048 key agreement   542.11 milliseconds, avg over 100 iterations

To enable STM32 hardware crypto and RNG support, define STM32F2_CRYPTO and STM32F2_RNG when building CyaSSL. For a more complete list of defines which may be required, please see the CYASSL_STM32F2 define in /cyassl/ctaocrypt/settings.h.

If you would like to use CyaSSL with STM32 hardware-based cryptography or RNG, or have any questions, please contact us at facts@wolfssl.com for more information. The latest stable release of CyaSSL is available for download under the GPLv2 direct from the wolfSSL website.

CyaSSL embedded SSL library: http://wolfssl.com/yaSSL/Products-cyassl.html
STM32: http://www.st.com/internet/mcu/class/1734.jsp
STM32F2 Standard Peripheral Library documentation: http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/USER_MANUAL/DM00023896.pdf

The bi-monthly release of CyaSSL, 2.8.0, is now ready to download from our website.  New features include:

– AES-GCM and AES-CCM use AES-NI

– NetX default IO callback handlers

– IPv6 fixes for DTLS Hello Cookies

– The ability to unload Certs/Keys after the handshake, CyaSSL_UnloadCertsKeys()

– SEP certificate extensions

– Callback getters for easier resource freeing

– External CYASSL_MAX_ERROR_SZ for correct error buffer sizing

– MacEncrypt and DecryptVerify Callbacks for User Atomic Record Layer Processing

– Public Key Callbacks for ECC and RSA

– Client now sends blank cert upon request if doesn’t have one with TLS <= 1.2

Please see the README and our on-line documentation for more information or feel free to contact us.