Using wolfSSL in other Open Source Projects

Hi!  If you are a long time user of wolfSSL, then you probably know that we actively engage the open source community.  Our intention is to create more and better open source software for all to use and enjoy.  

What you may not know about is one of our key business policies, which is to provide free support to open source projects that consume our products.  So if you are building open source stuff, you are more than welcome to engage our support team for help.  The best way to do that is through our support forums.  However, if you have an issue that is sensitive, then you are welcome to email us at support@yassl.com.

Camellia Cipher Now Available in wolfSSL

We have added the Camellia-CBC cipher to CTaoCrypt and wolfSSL. The following cipher suites are available for TLS:

• TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
• TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
• TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256
• TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256
• TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
• TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
• TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256
• TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256

Camllia-CBC will be available in our next release. The latest sources are available in our GitHub repository. To enable Camellia-CBC in wolfSSL, configure the build with the option “–enable-camellia”. We are very excited to offer this new cipher. If you are interested in other Camellia cipher suites, including any ECC cipher suites, please contact us at info@yassl.com.

Using Pre-Shared Keys (PSK) with wolfSSL

Ever wondered how to use PSK with the embedded wolfSSL library?  PSK is useful in resource constrained devices where public key operations may not be viable.  It`s also helpful in closed networks where a Certificate Authority structure isn`t in place.  To enable PSK with wolfSSL you can simply do:

$ ./configure --enable-psk

Using PSK on the client side requires one additional function call:

wolfSSL_CTX_set_psk_client_callback()

There`s an example client callback in cyassl/test.h called my_psk_client_cb().  The example sets the client identity which is helpful for the server if there are multiple clients with unique keys and is limited to 128 bytes.  It could also examine the server identity hint in case the client is talking to multiple servers with unique keys.  Then the pre-shared key is returned to the caller, here that is simply 0x1a2b3c4d, but it could be any key up to 64 bytes in length (512 bits).

On the server side two additional calls are required:

wolfSSL_CTX_set_psk_server_callback()
wolfSSL_CTX_use_psk_identity_hint()

The server stores it`s identity hint to help the client with the 2nd call, in our server example that`s “cyassl server”.  An example server psk callback can also be found in my_psk_server_cb() in cyassl/test.h.  It verifies the client identity and then returns the key to the caller, which is again 0x1a2b3c4d, but could be any key up to 64 bytes in length.  If you have any questions about using PSK with TLS please let us know.

Updated API Documentation

We want to let our users and followers know that we recently updated the API documentation for the wolfSSL embedded SSL library. With this update, all functions in the standard wolfSSL build (98) are now documented plus an additional 19 related to various defines related to DTLS, Callbacks, DER-specific, NTRU or OpenSSL extra functions.

You can find the updated API documentation online in Chapter 17 of the wolfSSL Manual, here:

http://yassl.com/yaSSL/Docs-cyassl-manual-17-cyassl-api-reference.html

If you have any questions, please let us know at info@yassl.com.

Visit the Leading Lightweight SSL Provider at RSA

We will be exhibiting at RSA again this year.  Please visit us at booth 755.  We will be talking about our latest releases of wolfSSL embedded SSL, Suite B, Fips 140-2, and answering specific questions for our users.  We will be fully staffed with engineering resources at the show, so bring us your most challenging questions!

If you would like to set aside a specific time to chat, then please email us at info@yassl.com.

wolfSSL Now Supports AES with CCM-8

We have added the Counter with CBC-MAC Mode with 8?byte authentication (CCM-8) for AES to wolfSSL. The following cipher suites are available for TLS v1.2:

• TLS_RSA_WITH_AES_256_CCM_8_SHA384
• TLS_RSA_WITH_AES_128_CCM_8_SHA256

AES with CCM-8 will be available in our next release. The latest sources are available in our GitHub repository. To enable AES with CCM-8 in wolfSSL, configure the build with the option “??enable?aesccm”. We are very excited to offer this new cipher. If you are interested in other AES-CCM-8 cipher suites, including any ECC cipher suites, please contact us at info@yassl.com.

Getting started with wolfSSL`s ECC

Release 2.4.6 of wolfSSL is the first to include our ECC implementation publicly.  Let`s look at how to get started using the ECC features.  First, you`ll need to turn on ECC.  With the autoconf system this is simply a configure flag:

./configure –enable-ecc
make
make check

Note the 96 different TLS cipher suites that make check verifies.  You can easily use any of these tests individually, e.g., to try ECDH-ECDSA with AES256-SHA you can start our example server 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.  To have an OpenSSL client connect the wolfSSL server you could do:

openssl s_client -connect localhost:11111

since wolfSSL uses the port 11111 by default, though this can be changed with the port option -p.  To allow the server to bind to any interface instead of the default localhost use the -b option.  A full list of options can be seen with -?.

Intro to PKCS #3: Diffie-Hellman Key Agreement Standard

A while back, we started a series on the PKCS standards. Our first post was about PKCS #1, the RSA Cryptography Standard. This is the second post in the PKCS standards series, introducing PKCS #3 – the Diffie-Hellman Key Agreement Standard.

PKCS #3 is the Diffie-Hellman Key Agreement Standard and is currently defined by version 1.4 of the specification, located here: http://www.rsa.com/rsalabs/node.asp?id=2126. It defines a standard enabling two parties to agree on a secret key known only to them (without having prior arrangements). This is done in such a way that even if an eavesdropper is listening to the communication channel on which the key agreement took place, the eavesdropper will not be able to obtain the secret key. After the secret key has been agreed upon by the two involved parties, it may be used in a subsequent operation – such as encrypting further communications between the two parties.

The specification itself defines standards for parameter generation, Phase 1 and 2 of the key agreement, and the object identifier to be used.

A. Parameter Generation

As stated in the specification, “a central authority shall generate Diffie-Hellman parameters, and the two phases of key agreement shall be performed with these parameters.” This central authority will generate several parameters including an odd prime (p) and an integer (g), where the base satisfies 0 < g < p. It may also optionally select an integer (l) which is the private-value length in bits and which satisfies 2^(l-1) <= p. A. Phase 1

This section of the specification describes the first (of two) phases of the Diffie-Hellman key agreement and contains three steps, namely:

– private-value generation
– exponentiation
– integer-to-octet-string conversion

As stated by the specification, “the input to the first phase shall be the Diffie-Hellman parameters. The output from the first phase shall be an octet string PV, the public value; and an integer x, the private value.” Each party of the key agreement will perform Phase 1 independently of the other party.

I. Phase 2

This section of the specification describes the second phase of the Diffie-Hellman key agreement and contains three steps as well, namely:

– octet-string-to-integer conversion
– exponentiation
– integer-to-octet-string conversion

As stated by the specification, “the input to the second phase shall be the Diffie-Hellman parameters; an octet string PV’, the other entity’s public value; and the private value x. The output from the second phase shall be an octet string SK, the agreed-upon secret key.” As the first step, this step is performed by each party independently as well (but after they have exchanged public values from the Phase 1).

I. Object Identifier

The last item defined in PKCS #3 are two object identifiers to be used with Diffie-Hellman key agreement, pkcs-3 and dhKeyAgreement. The pkcs-3 OID identifies Diffie-Hellman key agreement and is specified as:

pkcs-3 OBJECT IDENTIFIER ::= { iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) 3 }

The second OID, dhKeyAgreement, identifies the PKCS #3 key agreement method.

To learn more about PKCS #3, you can look through the specification, here:

http://www.rsa.com/rsalabs/node.asp?id=2126

To learn more about the wolfSSL embedded SSL library, you can download a free GPLv2-licensed copy from the yaSSL download page, https://www.wolfssl.com/download/, or look through the wolfSSL Manual, http://www.yassl.com/yaSSL/Docs-cyassl-manual-toc.html. If you have any additional questions, please contact us at info@yassl.com.

Linux Journal – Elliptic Curve Cryptography

If you are a reader of Linux Journal (http://www.linuxjournal.com/), you may have seen the interesting article in this month’s issue about Elliptic Curve Cryptography written by Joe Hendrix:

http://www.linuxjournal.com/content/january-2013-issue-linux-journal-security

In the article, Joe explains how ECC works (with several descriptive charts), talks about how NIST makes recommendations on the actual security provided by different algorithms with varying bit strengths, and shows readers how to use ECC in the popular OpenSSH application. We enjoyed reading through it.

Beginning with the 2.4.6 release of the wolfSSL embedded SSL library, wolfSSL now has support for ECC cipher suites as well. We have had ECC support internally for quite some time, but have now made it available to our open source user base.

wolfSSL’s open source ECC implementation can be found in the /cyassl/ctaocrypt/ecc.h header file and the /ctaocrypt/src/ecc.c source file. Supported ECC cipher suites include:

/* ECDHE suites */
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_RC4_128_SHA
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA

/* ECDH suites */
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDH_RSA_WITH_RC4_128_SHA
TLS_ECDH_ECDSA_WITH_RC4_128_SHA
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA

/* AES-GCM suites */
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384

You can download a GPLv2-licensed copy of wolfSSL from our download page (https://www.wolfssl.com/download/). If you have any questions or would like more information about our ECC implementation or the wolfSSL lightweight SSL library, feel free to let us know at info@yassl.com. We always enjoy hearing from our users!