Category: Uncategorized

Some of you may be familiar with the TLS 1.2 signature_algorithm extension, and might be curious if wolfSSL supports it. The signature_algorithm extension is found in section 7.4.1.4.1 RFC5246 (http://tools.ietf.org/html/rfc5246#section-7.4.1.4.1), and is a hello extension of type supported_signature_algorithms. The purpose of this extension is to allow clients to indicate to the server which signature/hash algorithm pairs may be used in digital signatures. If the client supports the default algorithms, the client is not required to send this extension.

wolfSSL supports the default algorithms, and as such, the wolfSSL client does not support this extension. The wolfSSL server will accept this extension if received from a client, but currently doesn’t do anything with the response it receives. This is something that will most likely be added to wolfSSL in the future when more clients and servers start using non-default extension algorithms.

If you have any questions about wolfSSL, or would like more information, please let us know at info@yassl.com.

Thanks,
Team yaSSL

Are you currently using wolfSSL in your open source, community, or hobby project? If so, we’d love to hear about what you’ve done so far and what your plans are for the future. yaSSL is dedicated to helping community-based projects who are using the wolfSSL embedded SSL library or the yaSSL Embedded Web Server. Let us know about your project at info@yassl.com and we’ll put you up on our Community page.

Technical support for community-based open source projects is free and available either through our support forums, or by emailing us directly at support@yassl.com.

To access and download our most recent wolfSSL source code, please visit our project page on GitHub, here. As always, please feel free to contact us with any questions you might have regarding our products.

Thanks!
Team yaSSL

You may have not realized it, but wolfSSL is very popular for game development, and is in use in millions of games.  

Here`s why:  

1. Experienced:  The yaSSL team has been supplying game developers with an efficient, portable SSL Stack for years.

2. Small:  Our code size is small.  We won`t bog down your game.

3. Portable:  We run on all the major gaming consoles/platforms and some of the minor ones.

4. Scalable:  Building a MMPORG and require security?  We have experience helping with that too.  wolfSSL won`t consume all of your server`s memory.

5. Streaming media:  wolfSSL was built with securing streaming media in mind.

Let us know if you have questions.  If you are a game developer and would like to speak with our references in the gaming industry, just email us at info@yassl.com.

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.