wolfSSL is about to make its alpha test debut as a Java based SSL provider on Android. This project took longer than planned, but we now have a version working internally. Alpha releases are available on a request basis. We’ll post more here as we make it available early next week.
In the meantime, for your listening and viewing pleasure: http://www.youtube.com/watch?v=7_IKcMl_a9A.
We’re often asked what differentiates wolfSSL and OpenSSL. Here’s our list:
a. wolfSSL builds are 20-40 times smaller than OpenSSL. Hence it is much more useful in embedded ssl implementations.
b. Standards support: wolfSSL supports TLS 1.1 and 1.2. OpenSSL does not support TLS 1.1 or 1.2.
c. wolfSSL was built with securing streaming media in mind. OpenSSL was built before streaming media was popular on the internet. As such, wolfSSL supports the latest streaming ciphers like Rabbit and HC-128 where OpenSSL does not.
d. License: wolfSSL is GPLv2 or commercial, with a company behind the commercial license. OpenSSL does not have a clear license.
e. We have tried to apply Occam’s razor as the guiding philosophy to our implementation of SSL. As such, our API focuses on the most critical and necessary functionality in order to simplify the problem. wolfSSL has 20 or so function calls, and an additional 230 for our OpenSSL compatibility layer. OpenSSL has over 3,500.
f. Really old code versus relatively new code: wolfSSL was written starting in 2004. OpenSSL started in 1995. Coding standards and requirements are a lot different now. OpenSSL has a longer legacy to support and maintain.
g. The OpenSSL legacy code comes from supporting usage profiles and operating systems that are no longer mainstream. The legacy code makes OpenSSL a easier to break and harder to fix.
h. OpenSSL was written as the SSL/TLS standards were being defined. Their code went down a number of blind alleys. We had the luxury of writing our code once the standards were well settled.
Please contact us at email@example.com if you have comments! We’ll be happy to re-factor this list with your input!
Hi! wolfSSL is ported to both the Cuda http://en.wikipedia.org/wiki/CUDA and OpenCL http://en.wikipedia.org/wiki/OpenCL frameworks. These frameworks are for writing programs that execute on GPU’s, or Graphical Processing Units. Generally, GPU’s are used for graphics processing, but due to their high production volumes and low cost, they can be useful for math intensive computing. Early adopters are building super computers based on GPU’s for various purposes. For example: http://hardware.slashdot.org/story/09/12/16/2255259/FASTRA-II-Puts-13-GPUs-In-a-Desktop-Supercomputer. Search Slashdot for GPU for more examples.
wolfSSL is ported to GPU’s because it is a low cost way to leverage GPU compute power for SSL offload, and can be much more cost effective for building SSL appliances.
Let us know at firstname.lastname@example.org if you are interested in running SSL on a GPU. We’ll be happy to support you!
Ivan Ristic from Qualys has a new study out which presents his results from an exhaustive survey of SSL servers. Some of the results are pretty interesting for those of us that create embedded ssl libraries. These points really caught our attention:
1. Too many SSL implementations still support insecure SSLv2.
2. Very few SSL implementations support TLS 1.1 and 1.2.
3. There is still wide support for weak ciphers.
As CyaSSL users know, CyaSSL does not support SSLv2 because it is insecure. Also, as a technology leader, CyaSSL has put TLS 1.1 in production for over three years and has had TLS 1.2 available for a year.
Ivan’s blog post: http://blog.ivanristic.com/2010/07/internet-ssl-survey-2010-is-here.html
Ivan’s BlackHat presentation: http://blog.ivanristic.com/Qualys_SSL_Labs-State_of_SSL_2010-v1.6.pdf
We have released an Alpha of our SSL Provider for Java. Currently supporting Mac and Linux operating systems, this provider enables Java developers to use wolfSSL through the javax.net.ssl package. By using this, Java developers can use familiar syntax and API calls to gain the speed and size advantages that the wolfSSL embedded SSL library provides.
Being in the Alpha stage, this provider currently only offers client functionality. If you want to give our provider a try, please download it from our additional downloads page here. Instructions for installation can be found in the README file included with the download.
We look forward to your feedback!
We`re thinking about implementing the security layer under Java to enable HealthVault applications for iphone and Android using our wolfSSL embedded ssl. This means we`ll support the proper certificate generation for HealthVault applications that want to allow their users to securely access HealthVault information from iphone and Android devices. As such, we`re interested in finding HealthVault application providers interested in iphone or Android. Are you interested in device based HealthVault? If yes, then please contact us at email@example.com.
The wolfSSL library for Android is almost ready for alpha testing. The project has taken us longer than anticipated! The key benefits to the new technology include:
1. Better performance than Android’s native SSL support through OpenSSL.
2. Smaller footprint.
3. Tight, seamless integration with Java as an SSL Provider.
The follow through of the project will also drive release of wolfSSL as a Java based SSL provider on other platforms. The initial targets are Mac and Linux. If you are interested in using wolfSSL hosted in Java, then contact us at firstname.lastname@example.org.
Here’s some pictures of Todd’s talk at OSCON about Secure Memcache. For those who have not been following, Secure Memcache is a Memcache branch that includes the wolfSSL embedded SSL for encryption between Memcache servers and clients.
Hi! One of our users recently requested that wolfSSL become compatible with Mongoose. As such, we have recently made changes to the wolfSSL 1.5.4 embedded ssl library to make it build seamlessly with the Mongoose embedded web server. Essentially this meant that we made minor enhancements to wolfSSL’s openssl compatibility layer to accomplish a clean build. Everything should build cleanly at this point, but let us know if you face any issues. If you build with wolfSSL instead of OpenSSL, you will get a smaller resulting build. You can contact us with any support issues you face at email@example.com.
Hi! Most of our readers will already know that AES is a key encryption standard used by governments worldwide, and that wolfSSL has always supported AES.
Intel has released a new set of instructions that is a faster way to implement AES, and wolfSSL is currently the first ssl library to fully support the new instruction set for production environments.
Essentially, Intel has added AES instructions at the chip level that perform the compute intensive parts of the AES algorithm, boosting performance.
What we’ve done is add the functionality to wolfSSL to allow it to call the instructions directly from the chip, instead of running the algorithm in software. This means that when you’re running wolfSSL on a chipset that supports AES-NI, you can run your AES crypto 5-10 times faster!
If you’re doing some benchmarking for your environment, let us know at firstname.lastname@example.org we’ll be happy to support you with the effort. Our current benchmarks are in the lab, and we’d like to work with users that can help us further define real world expectations for speed improvements from AES-NI.
References and further reading, ordered from general to specific:
Wikipedia entry on AES: http://en.wikipedia.org/wiki/Advanced_Encryption_Standard
Wikipedia entry on AES-NI: http://en.wikipedia.org/wiki/AES_instruction_set
Intel Software Network page on AES-NI: http://software.intel.com/en-us/articles/intel-advanced-encryption-standard-instructions-aes-ni/
See the readme of wolfSSL 1.5.4 for instructions on building with AES-NI.