Intro to PKCS #5: Password-Based Cryptography Specification

Our third post in our PKCS series, we will be looking at PKCS  #5. PKCS #5 is the Password-Based Cryptography Specification and is currently defined by version 2.0 of the specification. It is defined in RFC 2898 http://tools.ietf.org/html/rfc2898. It applies a pseudorandom function, such as a cryptographic hash, cipher, or HMAC to the input password or passphrase along with a salt value and repeats the process many times to produce a derived key, which can then be used as a cryptographic key in subsequent operations. The added computational work makes password cracking much more difficult, and is known as key stretching.

A. Key Derivation Functions

A key derivation function produces a derived key from a based key and other parameters. In a password-based key derivation function, the base key is a password and the other parameters are a salt value and an iteration count.

Two functions are specified below: PBKDF1 and PBKDF2. PBKDF2 is recommended for new applications; PBKDF1 is included only for compatibility with existing applications, and is not recommended for new applications.

B. PBKDF1

PBKDF1 applies a hash function, which shall be MD2, MD5 or SHA-1, to derive keys. The lengths of the derived keying bounded by the length of the hash function output, which is 16 octets from MD2 and MD5 and 20 octets from SHA-1.

Steps:

1. If dkLen > 16 for MD2 and MD5, or dkLen > 20 for SHA-1, output “derived key too long” and stop.

2. Apply the underlying hash function Hash for c iterations to the concatenation of the password P and

    the salt S, then extract the first dkLen octets to produce a derived key DK:

T_1 = Hash (P || S) ,

T_2 = Hash (T_1) ,

T_c = Hash (T_{c-1}) ,

DK = Tc<0..dkLen-1>

3. Output the derived key DK.

C. PBKDF2

PBKDF2 applies a pseudorandom function to derive keys. The length of the derived key is essentially unbounded. However, the maximum effective search space for the derived key may be limited by the structure of the underlying pseudorandom function.

Steps:

1. If dkLen > (2^32 – 1) * hLen, output “derived key too long” and stop.

2. Let l be the number of hLen-octet blocks in the derived key, rounding up, and let r be the number of octets

    in the last block:

l = CEIL (dkLen / hLen) ,

r = dkLen – (l – 1) * hLen .

Here, CEIL (x) is the “ceiling” function, i.e. the smallest integer greater than, or equal to, x.

3. For each block of the derived key apply the function F defined below to the password P, the salt S, the

    iteration count c, and the block index to compute the block:

T_1 = F (P, S, c, 1) ,

T_2 = F (P, S, c, 2) ,

T_l = F (P, S, c, l) ,

where the function F is defined as the exclusive-or sum of the first c iterates of the underlying pseudorandom  function PRF applied to the password P and the concatenation of the salt S and the block index i:

F (P, S, c, i) = U_1 \xor U_2 \xor … \xor U_c

where

U_1 = PRF (P, S || INT (i)) ,

U_2 = PRF (P, U_1) ,

U_c = PRF (P, U_{c-1}) .

Here, INT (i) is a four-octet encoding of the integer i, most significant octet first.

4. Concatenate the blocks and extract the first dkLen octets to produce a derived key DK:

DK = T_1 || T_2 ||  …  || T_l<0..r-1>

5. Output the derived key DK.

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

http://tools.ietf.org/html/rfc2898

D. CyaSSL Support

CyaSSL supports both PBKDF1 and PBKDF2. The header file can be found in <cyassl_root>/cyassl/ctaocrypt/pwdbased.h and the source file can be found in <cyassl_root>/ctaocrypt/src/pwdbased.c of the CyaSSL library. When using these functions, they must be enabled when CyaSSL is configured. This is done by:

./configure –enable-pwdbased

The functions:

int PBKDF1(byte* output, const byte* passwd, int pLen,

                      const byte* salt, int sLen, int iterations, int kLen,

                      int hashType);

int PBKDF2(byte* output, const byte* passwd, int pLen,

                      const byte* salt, int sLen, int iterations, int kLen,

                      int hashType);

CyaSSL also supports PKCS12

int PKCS12_PBKDF(byte* output, const byte* passwd, int pLen,

                            const byte* salt, int sLen, int iterations,

                            int kLen, int hashType, int purpose);

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

Video Tutorial: Basic Compilation and Installation of CyaSSL

If you are looking for a quick and easy guide on compiling, installing and using CyaSSL, then we have some good news: In order to make it even easier to understand and install CyaSSL, we recently created a video tutorial to help get you started.

The video will walk you through the downloading and installing process, as well as provided a basic demonstration of a few of CyaSSL’s example client and server programs. The video is on our YouTube channel, which can be found here: https://www.youtube.com/channel/UCxcGPWzOnhdocvKmxqhfvPg

With a direct link to the video here:

https://www.youtube.com/watch?v=zXRLwW0DIPA

CyaSSL is a C-based embedded SSL/TLS library which is lightweight, portable, and works with a wide range of systems.  It offers a simple, easy to use, API with several abstraction layers for ease of access in a wide range of product types.

If you have any questions feel free to contact us at facts@wolfssl.com or support@wolfssl.com. For more information, you may visit us at http://www.wolfssl.com/.

Integrating ChaCha20 and Poly1305 Into wolfSSL

We`ve implemented ChaCha20 allowing for the use of both 128 bit and 256 bit keys and are in the process of implementing Poly1305 into wolfSSL. Both crypt tools and a suite using the two are on schedule to be released by the end of the summer.

The ChaCha20 and Poly1305 algorithms, originally developed by Bernstein, have been shown to be very secure. Further reading about these algorithms can be found in the link below.

http://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-04

We`re excited about this addition to our code.  If you have comments, questions, or need it in our code sooner than the end of this summer, let us know!  We can be reached at facts@wolfssl.com or by phone at +1 425 245 8247.

Using wolfSSL on Raspberry Pi

Did you know that the wolfSSL lightweight SSL library builds and runs out of the box on the Raspberry Pi? We recently ran tests on a Raspberry Pi model B with wolfSSL 3.0.0. You can check out the results below:

1. Downloading

For the test, we downloaded cyassl-3.0.0.zip file from our download page.

2. Building

Instead of cross compiling wolfSSL to armv6, we compiled wolfSSL directly on our Raspberry Pi to get an average time of the building process. Following the process described in the README file to configure and build wolfSSL, the results were as follows:

$ time ./configure

real 1m33.504s
user 0m50.270s
sys 0m16.550s

$ time make

real 3m20.676s
user 2m50.290s
sys 0m6.940s

3. Benchmarking

To decide which math library to use we compared the results of the default build (./configure) with a modified one (./configure –enable-fastmath):

wolfSSL Benchmark, Normal Big Integer Math Library

pi@raspberrypi ~/cyassl-3.0.0 $ ./ctaocrypt/benchmark/benchmark
AES 5 megs took 0.880 seconds, 5.681 MB/s
ARC4 5 megs took 0.230 seconds, 21.734 MB/s
3DES 5 megs took 3.064 seconds, 1.632 MB/s

MD5 5 megs took 0.104 seconds, 48.112 MB/s
SHA 5 megs took 0.217 seconds, 23.072 MB/s
SHA-256 5 megs took 0.498 seconds, 10.032 MB/s

RSA 2048 encryption took 17.453 milliseconds, avg over 100 iterations
RSA 2048 decryption took 147.625 milliseconds, avg over 100 iterations
DH 2048 key generation 48.942 milliseconds, avg over 100 iterations
DH 2048 key agreement 61.991 milliseconds, avg over 100 iterations

wolfSSL Benchmark, Fast Big Integer Math Library

pi@raspberrypi ~/cyassl-3.0.0 $ ./ctaocrypt/benchmark/benchmark
AES 5 megs took 0.889 seconds, 5.624 MB/s
ARC4 5 megs took 0.200 seconds, 24.943 MB/s
3DES 5 megs took 2.479 seconds, 2.017 MB/s

MD5 5 megs took 0.101 seconds, 49.303 MB/s
SHA 5 megs took 0.217 seconds, 23.004 MB/s
SHA-256 5 megs took 0.561 seconds, 8.914 MB/s

RSA 2048 encryption took 4.622 milliseconds, avg over 100 iterations
RSA 2048 decryption took 131.030 milliseconds, avg over 100 iterations
DH 2048 key generation 57.496 milliseconds, avg over 100 iterations
DH 2048 key agreement 57.325 milliseconds, avg over 100 iterations

As expected, the fastmath provided more performant RSA operations – thus we used this build for the example test.

4. Running

After testing the crypto layer, it was time to test the protocol layer running our client example against our server example running or a remote Ubuntu server:

$ time ./examples/client/client -h external_server
SSL version is TLSv1.2
SSL cipher suite is TLS_RSA_WITH_AES_256_CBC_SHA256
Server response: I hear you fa shizzle!

real 0m0.885s
user 0m0.520s
sys 0m0.080s

5. Conclusion

wolfSSL 3.0.0 works out of the box on Raspberry Pi. While building wolfSSL on Raspberry Pi is OK, it does take some time to do so. Users should consider using cross compilation during the development cycle if building wolfSSL for the Pi on a regular basis needed.

6. Extra

If you like to stay synchronized with the latest commits of our github repository, don`t like to wait for stable releases, love git repositories, or just want to checkout a specific version, you can do so by following these steps before compiling wolfSSL:

* Check if you have libtool, autoconf and automake installed on your Pi:
$ sudo apt-get install libtool autoconf automake
* Clone wolfSSL repository from GitHub:
$ git clone https://github.com/cyassl/cyassl.git
* Run the autogen script:
$ cd cyassl
$ ./autogen.sh

wolfSSL and Oculus Rift

Hi everyone, we’re curious if anyone is interested in using wolfSSL with the Oculus Rift? If you don’t know what an Oculus Rift is, it is a Next Generation Virtual Reality Technology for video games or any Virtual Reality Applications. You can learn more at the following URL:

http://www.oculusvr.com/

If you have any questions, or would like to see wolfSSL working with the Oculus Rift, please email us at facts@wolfssl.com

wolfSSL and CyaSSL Users SAFE from Recent OpenSSL Security Advisories

OpenSSL released several security advisories yesterday: http://www.openssl.org/news/secadv_20140605.txt. None of these are attacks on the SSL/TLS protocols themselves.  They are all implementation bugs.  Most are critical bug fixes to DTLS (TLS over UDP).  As a clean room implementation of SSL, wolfSSL does not use any OpenSSL code and is free from these defects.  The most critical report seems to be the Man in the Middle vulnerability where an attacker can inject a Change Cipher Spec message to force a weak key stream (CVE-2014-0224).  wolfSSL does not create the keying material upon receipt of the Change Cipher Spec message as OpenSSL did/does and is free from this problem.

The purpose of this note is not to critique OpenSSL, but rather to inform our user base about how they may be affected.  For additional information or questions about CyaSSL please contact us at facts@wolfssl.com

Support for AES-NI in Visual Studio

Hi!  We`ve been supporting AES-NI for a few years now.  We`ve decided to extend that support to Visual Studio users.  If you would like to use AES-NI with Visual Studio, then let us know.  Beta code will be available shortly.  Contact us at facts@wolfssl.com if you have questions.

wolfSSL Releases IoT Demo of CyaSSL Working with Xively and mbed

For those of you interested in how CyaSSL fits into IoT, here is an example you should take a look at!

We have prepared a demo with CyaSSL, Xively, and mbed. It runs on various mbed platforms with Ethernet connections, including NXP LPC1768 whose RAM size is as small as 32k for applications + 32k for drivers.

In the demo configuration, mbed sends sensor data every 10 seconds through SSL to the Xively server, and you can see it through the browser on your pc.

 “mbed with Sensors” –[https]–> “Xively Server” <–[https]– “Browser on PC”

Xively is a cloud IoT service. It provides both HTTP and HTTPS APIs for IoT clients, in which they highly recommend HTTPS for obvious reasons, especially for commercial applications.

The demo includes the CyaSSL-based https client class. It is forked from the standard mbed http client class. So you can find out how it can be embedded into a socket-based program as well.

To use the project, please go to our mbed site and import the demo.

http://mbed.org/users/wolfSSL/

http://mbed.org/users/wolfSSL/code/CyaSSL-Xively/

For more information:

Xively: http://xively.com

mbed: http://mbed.org

mbed HTTPClient class:

    http://mbed.org/users/donatien/code/HTTPClient/

    http://mbed.org/handbook/TCP-IP-protocols-and-APIs

wolfSSL Enforces Stack Usage Reduction

Understanding the stack and the heap are fundamental steps for all software developers. The importance of such understanding is inversely proportional to the amount of memory available on the platform, as both compete for a piece of the total memory space available on a system.

In some cases the developer has the choice of when to use one (either the stack or heap) more than the other. In other cases, a scenario may force the developer to work with minimal use of the stack, the heap, or both.

With this in mind, wolfSSL is introducing a new build option in CyaSSL. Developers can now choose a CyaSSL build that best matches their needs of using more stack and less heap OR more heap and less stack. This process is being accomplished by the refactoring of the CyaSSL code. Currently 90% of the encryption layer has been refactored to use the new option.

Small stack usage is not enabled by default. To enable it users must use the option “–enable-small-stack” when configuring the CyaSSL build as in the following example:

./configure –enable-small-stack [other options]

For users who don`t use CyaSSL`s configure script for compilation, smaller stack usage is not enabled by default. In this case, users will need to add the compiler directive CYASSL_SMALL_STACK in config.h file or settings.h to enjoy its benefits as in the following example:

#define CYASSL_SMALL_STACK

or

#define CYASSL_SMALL_STACK 1

If you have any questions about stack usage with CyaSSL please let us know at facts@wolfssl.com.

wolfSSL with TLS 1.3

Hi!  Some of you know that the IETF working group on TLS is creating the specification for TLS 1.3.  We plan to upgrade wolfSSL to the TLS 1.3 specification as soon as the spec is finalized, or even close to finalized.  We are always aggressive with implementing the new TLS specifications, because we like to supply the community with a good test bed.  We did a great job getting TLS 1.2 out right away, as well as DTLS 1.2, and the community appreciated the effort.  We plan to continue our tradition of being quick with new protocol level changes.  

If you`re interested in what TLS 1.3 thinking is so far, then look here:  https://www.ietf.org/proceedings/87/slides/slides-87-tls-5.pdf.  If you have TLS 1.3 questions or comments, you are welcome to email us at facts@wolfssl.com or call us at +1 425 245 8247.

Posts navigation

1 2 3 160 161 162 163 164 165 166 194 195 196