Category: Uncategorized

One predominant question we get asked frequently is what are the build size and runtime memory usage of the wolfSSL embedded SSL library.  Hopefully this post will help clear things up.

Firstly, wolfSSL was built from the ground up to be optimized for embedded and resource-constrained devices and environments.  As such, we have kept a close eye on keeping our SSL library small while still providing the features our users want and need.

Build sizes (compiled binary size) for wolfSSL range between 30-100kB depending on build options and the compiler being used.  Typically on an embedded system, build sizes will be around 60kB.  This size will include a full-featured TLS 1.2-compliant client and server.  For details on build options, please see Chapter 2 of the wolfSSL Manual.

Looking at runtime memory usage, wolfSSL will generally consume somewhere between 5-50kB (average is around 3kB).  The runtime RAM usage per connection will vary depending the size of the input/output buffers being used.  For example, with standard 16kB buffers, the total runtime memory usage of wolfSSL with a single connection would be 3kB + 16kB + 16kB = 35kB.

If you have any further questions about wolfSSL code sizes, please contact us at info@yassl.com.  For a full list of wolfSSL features, please visit the wolfSSL Product Page.

Do you want to install a HTTPS-capable web server on your Apple TV? If so, continue reading below to find out how the open source yaSSL Embedded Web Server can easily be installed on the second generation Apple TV.

Following our port of wolfSSL to the second generation Apple TV, our next step was to get the yaSSL Embedded Web Server running on the Apple TV. Having a web server running on the Apple TV brings with it many benefits including the ability to host a website from a very small, energy-efficient, discreet, and quiet device.

If you missed our post on porting wolfSSL to the Apple TV, you can read it here: Running wolfSSL on the Apple TV 2. If you would like to install the yaSSL Embedded Web Server on your Apple TV with HTTPS support, follow the instructions in our previous post prior to installing yasslEWS. Note that you will need to build wolfSSL with either the –enable-opensslExtra or –enable-webServer build option.

Requirements:

1. Jailbroken second generation Apple TV (we leave this step for you to do)
2. wolfSSL installed on Apple TV for HTTPS support (see link above)

1. Compiling the Web Server

In order to easily compile the yaSSL Embedded Web Server for iOS (specifically the Apple TV), we added a new target to the makefile. You can download our updated yasslEWS makefile, here: Updated yasslEWS iOS Makefile.

After placing the new Makefile in your yasslEWS directory, simply run the following command. This will build yasslEWS for iOS and the ARM architecture.

make ios

1. Web Server Installation

After compiling the web server, move the application and configuration file to the Apple TV using your favorite FTP client. We chose to place the yaSSL Embedded Web Server in the following location on the Apple TV.

/private/var/mobile/Applications/yasslews

1. Running the Web Server

If you followed our previous instructions on installing wolfSSL on the Apple TV, the wolfSSL libraries should be located at “/usr/local/cyassl_atv2”. To make sure the loader can find them, you’ll need to set the path:

export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:/usr/local/cyassl_atv2/lib

Then, to start the web server with both insecure (HTTP) and secure (HTTPS) ports, issue the following command. Keep in mind that you can set runtime options either on the command line during startup or in the configuration file (yasslEWS.conf). The yaSSL Embedded Web Server will automatically load the configuration file name “yasslEWS.conf” if present in the same directory as the executable. For a list of config options, use the “./yasslEWS -h” command.

./yasslEWS -s server.pem -p 8080,8081s -e error.txt

1. Build Sizes

One of the great things about using wolfSSL and the yaSSL Embedded Web Server is that they have been designed and optimized to run on embedded devices – thus giving them an extremely small footprint. Below you can see the sizes on disk of the compiled wolfSSL library and yaSSL Embedded Web Server using the above methods for the Apple TV – a total disk footprint of 181 kB for both SSL and a web server!

wolfSSL
122 kB Footprint
Full Feature Set
Standards up to the current TLS 1.2

yaSSL Embedded Web Server
59kB Footprint
Full Feature Set

For more information about the wolfSSL embedded SSL library or the yaSSL Embedded Web Server, please visit their respective product pages (wolfSSL, yaSSLEWS). yaSSL products are open source and dual licensed under both the GPLv2 as well as standard commercial licensing.

If you have any questions or comments, please let us know at info@yassl.com. We’re interested in hearing what you think!

The Apple TV brought with it a long list of desirable and useful features for the home – including high usability, a small form factor, easy setup, and low cost. We here at yaSSL are users and fans of the second generation Apple TV, and as such, recently ported the wolfSSL embedded SSL library to the Apple TV 2. We were quite surprised by how easy it was to get wolfSSL up and running.

The Apple TV 2 runs iOS with the Apple A4 (ARM Cortex-A8) processor and is equipped with 256 Mb of RAM and a 8GB flash drive, giving it more than enough space and speed to effectively run wolfSSL.

Installation

1. Jailbreak your Apple TV
Installation of wolfSSL onto the Apple TV requires that the TV be jailbroken first. There are any number of readily-accessible posts around the internet explaining this process, therefore, we will leave this step up to you.

1. Cross compile wolfSSL for iOS and ARM
For this step, we used a modified version of a script written by Michael Aaron Safyan to cross compile libraries for iOS. You can find our modified version of the script for iOS 4.3 and the armv7 architecture, here: Cross Compile Script. This script uses the ARM toolchain from the iOS Developer tools that come with the iPhone SDK. It sets environment variables, then runs wolfSSL’s normal ./configure script.

If you want to change the location where wolfSSL is installed, you can edit the script to adjust for your desired directory location. To build wolfSSL, place the cross compile script (iOS4.3-configure.sh) in the root directory of the wolfSSL download and run the following commands. This builds wolfSSL with the –enable-fastmath option.

./iOS4.3-configure.sh
make
sudo make install

If unaltered, this will install the cross-compiled wolfSSL library into /usr/local/cyassl_atv2.

1. Copy wolfSSL to the Apple TV
Use your favorite FTP client to upload the contents of the /usr/local/cyassl_atv2 directory to the same location on your second generation Apple TV. If desired, you can also copy additional wolfSSL elements to the Apple TV such as the CTaoCrypt benchmark utility, the wolfSSL testsuite, or examples. We chose to place these on the Apple TV under the /var/mobile/Applications/cyassl directory.

1. Benchmark Results
Our results of running the CTaoCrypt benchmark application are below:

AES 5 megs took 0.500 seconds, 9.99 MB/s
ARC4 5 megs took 0.174 seconds, 28.66 MB/s
RABBIT 5 megs took 0.126 seconds, 39.56 MB/s
3DES 5 megs took 2.196 seconds, 2.28 MB/s

MD5 5 megs took 0.163 seconds, 30.73 MB/s
SHA 5 megs took 0.137 seconds, 36.61 MB/s
SHA-256 5 megs took 0.309 seconds, 16.20 MB/s

RSA 1024 encryption took 1.12 milliseconds, avg over 100 iterations
RSA 1024 decryption took 17.81 milliseconds, avg over 100 iterations
DH 1024 key generation 11.90 milliseconds, avg over 100 iterations
DH 1024 key agreement 11.22 milliseconds, avg over 100 iterations

If you have any questions or comments about our port to the Apple TV, please let us know at info@yassl.com. We’d be happy to hear what you think!

Most of the focus of wolfSSL has been towards the embedded world, emphasizing small size, speed, and low memory use.  Ironically, these attributes also make wolfSSL ideal for scaling on a huge magnitude.   Other libraries often run into problems when trying to scale to hundreds of thousands of connections for applications like load balancing or cloud services.  We have users doing just that.  

If you`d like to try wolfSSL in a highly scaled environment, drop us a line, we`re eager to help and explore performance options with you.

With release candidate 2, the full 2.0 version of wolfSSL is drawing near. We have chosen to put out several release candidates for wolfSSL 2.0 because of the volume of new features that were added combined with the number of bugs that are fixed in this release.

We would like to invite any interested developers and users to download and test wolfSSL 2.0 RC2 and let us know what you find. This will help speed up the release process, and hopefully turn up some bugs that we can fix before the final release. For testing, you can download the most recent version of wolfSSL 2.0 RC2 from our GitHub page, here:

https://github.com/cyassl/cyassl

Instructions for building wolfSSL can be found in the wolfSSL Manual, Chapter 2, titled “Building wolfSSL”. With RC2, we have also updated our documentation. If you find any documentation mistakes, or have suggestions in how we can improve, please let us know. Updated documentation can be found on our Docs page.

Please send any feedback, questions, or comments to info@yassl.com, or post to our support forums .

Thanks for your help!

Team yaSSL

Recently we’ve been working on enhancing and expanding our documentation and focusing on making it more useful for our users. One of the things that we recently released is an API Reference for the wolfSSL embedded SSL library. The wolfSSL API reference is available both online and in the wolfSSL Manual PDF. You can find it online, here:

wolfSSL API Reference (Chapter 17, wolfSSL Manual)

Please let us know what you think, and if you have any suggestions for further improvement in the wolfSSL documentation. You can email us at info@yassl.com with any questions or suggestions.

Thanks,
Team yaSSL

Cipher suites come in a variety of strengths.  Because they are made up of several different types of algorithms (authentication, encryption, and message authentication code (MAC)), the strength of each varies with the chosen key sizes.  There can be many methods of grading the strength of a cipher suite – the specific method used seems to vary between different projects and companies an can include things such as symmetric and public key algorithm key sizes, type of algorithm, performance, and known weaknesses.

NIST (National Institute of Standards and Technology) makes recommendations on choosing an acceptable cipher suite by providing comparable algorithm strengths for varying key sizes of each.  The strength of a cryptographic algorithm depends on the algorithm and the key size used.  The NIST Special Publication, SP800-57, states that two algorithms are considered to be of comparable strength as follows:

“… two algorithms are considered  to be of comparable strength for the given key sizes (X and Y) if the amount of work needed to “break the algorithms” or determine the keys (with the given key sizes) is approximately the same using a given resource. The security strength of an algorithm for a given key size is traditionally described in terms of the amount of work it takes to try all keys for a symmetric algorithm with a key size of “X” that has no short cut attacks (i.e., the most efficient attack is to try all possible keys).”

The two tables in section 4.3 of the wolfSSL Manual (Table 2, Table 3). are based off of both Table 2 (pg. 64) and Table 4 (pg. 66) from NIST SP800-57, and show comparable security strength between algorithms as well as a strength measurement (based off of NIST’s suggested algorithm security lifetimes using bits of security).

Using these tables as guides to begin to classify a cipher suite, we categorize it based on the strength of the symmetric encryption algorithm.  In doing this, a rough grade classification can be devised to classify each cipher suite based on bits of security (only taking into account symmetric key size):

LOW = bits of security smaller than 128 bits
MEDIUM = bits of security equal to 128 bits
HIGH = bits of security larger than 128 bits

Outside of the symmetric encryption algorithm strength, the strength of a cipher suite will depend greatly on the key sizes of the key exchange and authentication algorithm keys.  The strength is only as good as the cipher suite’s weakest link.

Following the above grading methodology (and only basing it on symmetric encryption algorithm strength), wolfSSL 2.0.0 currently supports a total of 0 LOW strength cipher suites, 12 MEDIUM strength cipher suites, and 8 HIGH strength cipher suites – as listed in section 4.3.2 of the wolfSSL Manual.  The following strength classification could change depending on the chosen key sizes of the other algorithms involved. For a reference on hash function security strength, see Table 3 (pg. 64) of NIST SP800-57.

In some cases, you will see ciphers referenced as “EXPORT” ciphers.  These ciphers originated from the time period in US history (as late as 1992) when it was illegal to export software with strong encryption from the United States.  Strong encryption was classified as “Munitions” by the US Government (under the same category as Nuclear Weapons, Tanks, and Ballistic Missiles). Because of this restriction, software being exported included “weakened” ciphers (mostly in smaller key sizes).  In the current day, this restriction has been lifted, and as such, EXPORT ciphers are no longer a mandated necessity.

As you may have noticed we have made a few changes to our website – mainly in color schemes, layouts, and enhanced documentation. One of the largest additions to our site is the HTML version of the updated wolfSSL embedded SSL library Manual, which can be found at the following link. It can also be downloaded in PDF form if you prefer that.

wolfSSL Manual (HTML)

Our RSS feed link has changed due to our terminology change from “News” to “Blog”. Our new RSS feed link is as follows: http://www.wolfssl.com/feed

If you have any website feature requests, or think that there’s something that we need to add, please contact us at info@yassl.com.

Thanks,
Team yaSSL

Hi!

We`ve been making several changes to our website lately which we plan to roll out in the near future. One of the things we`re doing is changing the name of our “News” feed to a “Blog” feed. We thought that we better keep up with the times and start using the correct terminology.

As a result of this change, our RSS feed link will be changing. If you are following our RSS feed, please use the following link from now on:

https://www.wolfssl.com/feed/

Stay tuned for site and documentation updates soon!

Thanks,
Team yaSSL

Here`s the fourth part in a four part series giving a more detailed report on some of the new features present in the recent wolfSSL release.

• Shared build only by default.  wolfSSL used to build in shared mode and static mode by default, somewhat handy, but twice as time consuming.  Now, wolfSSL will only build in shared mode by default, seemingly speeding up the build by a factor of two.  Of course either mode can still be explicitly disabled or enabled.

• Compiler visibility additions.  wolfSSL now uses compiler visibility, if the compiler supports it, to explicitly expose or hide non static functions.  This decreases wolfSSL`s pollution of the global namespace and also decreases the chance of collisions.

• Single Makefile.  wolfSSL used to use Makefiles recursively, one for each directory.  While initially easy to setup, there are several drawbacks to this configuration including slow build times and increasingly complex interactions between the files.  The new single makefile is simpler and faster.  Thanks to Brian Aker for suggesting the last two items.

• Kitchen sink warnings.  wolfSSL now has a configure option (–enable-gcc-lots-o-warnings) that turns on many additional warnings that shouldn`t fire in a release.  wolfSSL has removed the ones that do, though not all systems, versions, compiler versions have been tested so we`re still fine-tuning these.

Please email us at info@yassl.com or support@yassl.com with any questions regarding the above feature additions, or wolfSSL / embedded SSL in general.