(Table 4: CyaSSL Cipher Suites)
4.3.3 Block and Stream Ciphers
CyaSSL supports the AES, DES, 3DES, and Camellia block ciphers and the RC4, RABBIT and HC-128 stream ciphers. AES, DES, 3DES, RC4 and RABBIT are enabled by default. Camellia and HC-128 can be enabled when building CyaSSL (with the --enable-hc128 and --enable-camellia build options, respectively). The default mode of AES is CBC mode. To enable GCM or CCM mode with AES, use the --enable-aesgcm and --enable-aesccm build options. Please see the examples for usage and the CTaoCrypt Usage Reference (Chapter 10) for specific usage information.
SSL uses RC4 as the default stream cipher. It's a good one, though it's getting a little old. CyaSSL has added two ciphers from the eStream project into the code base, RABBIT and HC-128. RABBIT is nearly twice as fast as RC4 and HC-128 is about 5 times as fast! So if you've ever decided not to use SSL because of speed concerns, using CyaSSL's stream ciphers should lessen or eliminate that performance doubt.
To see a comparison of cipher performance, visit the CyaSSL Benchmark web page, located here: http://yassl.com/yaSSL/benchmarks-cyassl.html.
4.3.3.1 What’s the Difference?
Have you ever wondered what the difference was between a block cipher and a stream cipher?
A block cipher has to be encrypted in chunks that are the block size for the cipher. For example, AES has block size of 16 bytes. So if you're encrypting a bunch of small, 2 or 3 byte, chucks back and forth, over 80% of the data is useless padding, decreasing the speed of the encryption/decryption process and needlessly wasting network bandwidth to boot. Basically block ciphers are designed for large chucks of data, have block sizes requiring padding, and use a fixed, unvarying transformation.
Stream ciphers work well for large or small chucks of data. They are suitable for smaller data sizes because no block size is required. If speed is a concern, stream ciphers are your answer, because they use a simpler transformation that typically involves an xor'd keystream. So if you need to stream media, encrypt various data sizes including small ones, or have a need for a fast cipher then stream ciphers are your best bet.
4.3.4 Hashing Functions
CyaSSL supports several different hashing functions, including MD2, MD4, MD5, SHA-1, SHA-2 (SHA-256, SHA-384, SHA-512), and RIPEMD-160. Detailed usage of these functions can be found in the CTaoCrypt Usage Reference, Section 10.1.
4.3.5 Public Key Options
CyaSSL supports the RSA, DSA/DSS, DH, and NTRU public key options, with support for EDH (Ephemeral Diffie-Hellman) on the CyaSSL server. Detailed usage of these functions can be found in the CTaoCrypt Usage Reference, section 10.5.
CyaSSL has support for four cipher suites utilizing NTRU:
-
TLS_NTRU_RSA_WITH_3DES_EDE_CBC_SHA
-
TLS_NTRU_RSA_WITH_RC4_128_SHA
-
TLS_NTRU_RSA_WITH_AES_128_CBC_SHA
-
TLS_NTRU_RSA_WITH_AES_256_CBC_SHA
The strongest one, AES-256, is the default. If CyaSSL is enabled with NTRU and the NTRU package is available, these cipher suites are built into the CyaSSL library. A CyaSSL client will have these cipher suites available without any interaction needed by the user. On the other hand, a CyaSSL server application will need to load an NTRU private key and NTRU x509 certificate in order for those cipher suites to be available for use.
The example servers echoserver and server both use the define HAVE_NTRU (which is turned on by enabling NTRU) to specify whether or not to load NTRU keys and certificates. The CyaSSL package comes with test keys and certificates in the <cyassl_root>/certs directory. ntru-cert.pem is the certificate and ntru-key.raw is the private key blob.
The CyaSSL NTRU cipher suites are given the highest preference order when the protocol picks a suite. Their exact preference order is the reverse of the above listed suites, i.e., AES-256 will be picked first and 3DES last before moving onto the “standard” cipher suites. Basically, if a user builds NTRU into CyaSSL and both sides of the connection support NTRU then an NTRU cipher suite will be picked unless a user on one side has explicitly excluded them by stating to only use different cipher suites.
Using NTRU over RSA can provide a 20 - 200X speed improvement. The improvement increases as the size of keys increases, meaning a much larger speed benefit when using large keys (8192-bit) versus smaller keys (1024-bit).
4.3.6 ECC Support
CyaSSL has support for Elliptic Curve Cryptography (ECC) including ECDH-ECDSA, ECDHE-ECDSA, ECDH-RSA, and ECDHE-RSA.
CyaSSL’s ECC implementation can be found in the <cyassl_root>/cyassl/ctaocrypt/ecc.h header file and the <cyassl_root>/ctaocrypt/src/ecc.c source file.
Supported cipher suites are shown in Table 4, above. ECC is disabled by default, but can be turned on when building CyaSSL with the HAVE_ECC define or by using the autoconf system:
./configure --enable-ecc
make
make check
When “make check” runs, note the numerous cipher suites that CyaSSL checks. Any of these cipher suites can be tested individually, e.g., to try ECDH-ECDSA with AES256-SHA, the example CyaSSL server can be started like this:
./examples/server/server -d -l ECDH-ECDSA-AES256-SHA -c ./certs/server-ecc.pem -k ./certs/ecc-key.pem
-d disables client cert check while -l specifies the cipher suite list. -c is the certificate to use and -k is the corresponding private key to use. To have the client connect try:
./examples/client/client -A ./certs/server-ecc.pem
where -A is the CA certificate to use to verify the server.
4.3.7 PKCS Support
PKCS (Public Key Cryptography Standards) refers to a group of standards created and published by RSA Security, Inc. CyaSSL has support for PKCS #5, PKCS #8, and PBKD from PKCS #12.
4.3.7.1 PKCS #5, PBKDF1, PBKDF2, PKCS #12
PKCS #5 is a password based key derivation method which combines a password, a salt, and an iteration count to generate a password-based key. CyaSSL supports both PBKDF1 and PBKDF2 key derivation functions. A key derivation function produces a derived key from a base key and other parameters (such as the salt and iteration count as explained above). PBKDF1 applies a hash function (MD5, SHA1, etc) to derive keys, where the derived key length is bounded by the length of the hash function output. With PBKDF2, a psudorandom function is applied (such as HMAC-SHA-1) to derive the keys. In the case of PBKDF2, the derived key length is unbounded.
CyaSSL also supports the PBKDF function from PKCS #12 in addition to PBKDF1 and PBKDF2. The function prototypes look like this:
int PBKDF2(byte* output, const byte* passwd, int pLen, const byte* salt, int sLen,
int iterations, int kLen, int hashType);
int PKCS12_PBKDF(byte* output, const byte* passwd, int pLen, const byte* salt, int sLen,
int iterations, int kLen, int hashType, int purpose);
output contains the derived key, passwd holds the user password of length pLen, salt holds the salt input of length sLen, iterations is the number of iterations to perform, kLen is the desired derived key length, and hashType is the hash to use (which can be MD5, SHA1, or SHA2).
A full example can be found in ctaocrypt/src/test.c. More information can be found on PKCS #5, PBKDF1, and PBKDF2 from the following specifications:
PKCS#5, PBKDF1, PBKDF2: http://tools.ietf.org/html/rfc2898
4.3.7.2 PKCS #8
PKCS #8 is designed as the Private-Key Information Syntax Standard, which is used to store private key information - including a private key for some public-key algorithm and set of attributes.
The PKCS #8 standard has two versions which describe the syntax to store both encrypted private keys and non-encrypted keys. CyaSSL supports both non-encrypted and encrypted PKCS #8. Supported formats include PKCS #5 version 1 - version 2, and PKCS#12. Types of encryption available include DES, 3DES, RC4, and AES.
PKCS#8: http://tools.ietf.org/html/rfc5208
4.3.8 Forcing the Use of a Specific Cipher
By default, CyaSSL will pick the “best” (highest security) cipher suite that both sides of the connection can support. To force a specific cipher, such as 128 bit AES, add something similar to:
SSL_CTX_set_cipher_list(ctx, “AES128-SHA”);
after the call to SSL_CTX_new(); so that you have:
ctx = SSL_CTX_new(method);
SSL_CTX_set_cipher_list(ctx, “AES128-SHA”);
4.4 Hardware Accelerated Crypto
CyaSSL is able to take advantage of several hardware accelerated (or “assisted”) crypto functionalities in various processors and chips. The following sections explain which technologies CyaSSL supports out-of-the-box.
4.4.1 Intel AES-NI
AES is a key encryption standard used by governments worldwide, which CyaSSL has always supported. Intel has released a new set of instructions that is a faster way to implement AES. CyaSSL is 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 computational-intensive parts of the AES algorithm, boosting performance. For a list of Intel’s chips that currently have support for AES-NI, you can look here:
http://ark.intel.com/search/advanced/?s=t&AESTech=true
We have added the functionality to CyaSSL 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 CyaSSL on a chipset that supports AES-NI, you can run your AES crypto 5-10 times faster!
If you are running on an AES-NI supported chipset, enable AES-NI with the --enable-aesni build option. To build CyaSSL with AES-NI, GCC 4.4.3 or later is required to make use of the assembly code.
References and further reading on AES-NI, ordered from general to specific, are listed below. For information about performance gains with AES-NI, please see the third link to the Intel Software Network page.
AES (Wikipedia): http://en.wikipedia.org/wiki/Advanced_Encryption_Standard
AES-NI (Wikipedia): http://en.wikipedia.org/wiki/AES_instruction_set
AES-NI (Intel Software Network page): http://software.intel.com/en-us/articles/intel-advanced-encryption-standard-instructions-aes-ni/
4.4.2 STM32F2
CyaSSL is able to use the STM32F2 hardware-based cryptography and random number generator through the STM32F2 Standard Peripheral Library.
For necessary defines, see the CYASSL_STM32F2 define in settings.h. The CYASSL_STM32F2 define enables STM32F2 hardware crypto and RNG support by default. The defines for enabling these individually are STM32F2_CRYPTO (for hardware crypto support) and STM32F2_RNG (for hardware RNG support).
Documentation for the STM32F2 Standard Peripheral Library can be found in the following document:
http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/USER_MANUAL/DM00023896.pdf
4.4.3 Cavium NITROX
CyaSSL has support for Cavium NITROX (http://www.cavium.com/processor_security.html). To enable Cavium NITROX support when building CyaSSL use the following configure option:
./configure --with-cavium=/home/user/cavium/software
Where the “--with-cavium=” option is pointing to your licensed cavium/software directory. Since Cavium doesn't build a library CyaSSL pulls in the cavium_common.o file which gives a libtool warning about the portability of this. Also, if you're using the github source tree you'll need to remove the -Wredundant-decls warning from the generated Makefile because the cavium headers don't conform to this warning.
Currently CyaSSL supports Cavium RNG, AES, 3DES, RC4, HMAC, and RSA directly at the crypto layer. Support at the SSL level is partial and currently just does AES, 3DES, and RC4. RSA and HMAC are slower until the Cavium calls can be utilized in non-blocking mode. The example client turns on cavium support as does the crypto test and benchmark. Please see the HAVE_CAVIUM define.
4.5 SSL Inspection (Sniffer)
Beginning with the CyaSSL 1.5.0 release, CyaSSL has included a build option allowing it to be built with SSL Sniffer (SSL Inspection) functionality. This means that you can collect SSL traffic packets and with the correct key file, are able to decrypt them as well. The ability to “inspect” SSL traffic can be useful for several reasons, some of which include:
-
•Analyzing Network Problems
-
•Detecting network misuse by internal and external users
-
•Monitoring network usage and data in motion
-
•Debugging client/server communications
To enable sniffer support, build CyaSSL with the --enable-sniffer option on *nix or use the vcproj files on Windows. You will need to have pcap installed on *nix or WinPcap on Windows. There are five main sniffer functions which can be found in sniffer.h. They are listed below with a short description of each:
ssl_SetPrivateKey - Sets the private key for a specific server and port.
ssl_DecodePacket - Passes in a TCP/IP packet for decoding.
ssl_Trace - Enables / Disables debug tracing to the traceFile.
ssl_InitSniffer - Initialize the overall sniffer.
ssl_FreeSniffer - Free the overall sniffer.
To look at CyaSSL's sniffer support and see a complete example, please see the "snifftest" app in the "ssSniffer/sslSnifferTest" folder from the CyaSSL download.
Keep in mind that because the encryption keys are setup in the SSL Handshake, the handshake needs to be decoded by the sniffer in order for future application data to be decoded. For example, if you are using "snifftest" with the CyaSSL example echoserver and echoclient, the snifftest application must be started before the handshake begins between the server and client.
4.6 Compression
CyaSSL supports data compression with the zlib library. The ./configure build system detects the presence of this library, but if you're building in some other way define the constant HAVE_LIBZ and include the path to zlib.h for your includes.
Compression is off by default for a given cipher. To turn it on, use the function CyaSSL_set_compression() before SSL connecting or accepting. Both the client and server must have compression turned on in order for compression to be used.
Keep in mind that while compressing data before sending decreases the actual size of the messages being sent and received, the amount of data saved by compression usually takes longer in time to analyze than it does to send it raw on all but the slowest of networks.
4.7 Pre-Shared Keys
CyaSSL has support for two ciphers with pre shared keys:
TLS_PSK_WITH_AES_256_CBC_SHA
TLS_PSK_WITH_AES_128_CBC_SHA
These suites are automatically built into CyaSSL, though they can be turned off at build time with the constant NO_PSK. To only use these ciphers at runtime use the function CyaSSL_CTX_set_cipher_list() with the desired ciphersuite.
On the client, use the function CyaSSL_CTX_set_psk_client_callback() to setup the callback. The client example in <CyaSSL_Home>/examples/client/client.c gives example usage for setting up the client identity and key, though the actual callback is implemented in cyassl/test.h.
CyaSSL supports identities and hints up to 128 octets and pre shared keys up to 64 octets.
4.8 Client Authentication
Client authentication is a feature which enables the server to authenticate clients by requesting that the clients send a certificate to the server for authentication when they connect. Client authentication requires an X.509 client certificate from a CA (or self-signed if generated by you or someone other than a CA).
By default, CyaSSL validates all certificates that it receives - this includes both client and server. To set up client authentication, the server must load the list of trusted CA certificates to be used to verify the client certificate against:
CyaSSL_CTX_load_verify_locations(ctx, caCert, 0);
To turn on client verification and control its behavior, the CyaSSL_CTX_set_verify() function is used. In the following example, SSL_VERIFY_PEER turns on a certificate request from the server to the client. SSL_VERIFY_FAIL_IF_NO_PEER_CERT instructs the server to fail if the client does not present a certificate to validate on the server side. Other options to CyaSSL_CTX_set_verify() include SSL_VERIFY_NONE and SSL_VERIFY_CLIENT_ONCE.
CyaSSL_CTX_set_verify(ctx,SSL_VERIFY_PEER |
SSL_VERIFY_FAIL_IF_NO_PEER_CERT,0);
An example of client authentication can be found in the example server (server.c) included in the CyaSSL download (/examples/server/server.c).
4.9 Handshake Modifications
CyaSSL has the ability to group handshake messages if the user desires. This can be done at the context level with:
CyaSSL_CTX_set_group_messages(ctx);
or at the SSL object level with:
CyaSSL_set_group_messages(ssl);
