RECENT BLOG NEWS

OpenSSL released a security advisory on June 11th 2015: https://www.openssl.org/news/secadv_20150611.txt.  Some wolfSSL embedded TLS users are probably wondering if similar security fixes are needed in wolfSSL.  The answer to that is no.  Specifically, CVE-2015-1788 – 1792 and CVE-2014-8176 are OpenSSL implementation bugs.  Since wolfSSL and CyaSSL embedded SSL libraries have a completely different code base from OpenSSL we do not share these defects.  The other advisory is about Logjam and export grade crypto, wolfSSL is not vulnerable to that either.  Please see this blog post for more details: http://wolfssl.com/wolfSSL/Blog/Entries/2015/5/20_wolfSSL_and_CyaSSL_are_Not_Vulnerable_to_the_Recent_Logjam_Attack.html

Please contact wolfSSL by email at info@wolfssl.com, or call us at 425 245 8247 if you have any security related questions.

To support our customers pursuing FIPS 140-2 validations or Common Criteria evaluations, wolfSSL is adding FIPS 186-4 KeyGen to our next FIPS 140-2 validation. 

We are scheduled to complete CAVP algorithm testing in June and testing with our FIPS Laboratory in July.

Please contact wolfSSL at fips@wolfssl.com if you need a tested implementation of FIPS 186-4 KeyGen.

Version 1.2.0 of wolfSSL JNI is now available for download. wolfSSL JNI provides Java applications with a convenient Java API to the widely-used wolfSSL embedded SSL/TLS library, including support for TLS 1.2 and DTLS 1.2.

This release contains bug fixes and features including:

– Updated support for wolfSSL 3.4.6 and CyaSSL to wolfSSL name change
– Benchmark functionality in example client
– Updated example certificates
– Better detection of Java home on Mac and Linux

wolfSSL JNI 1.2.0 can be downloaded from the wolfSSL download page and the wolfSSL JNI Manual can be found here.

Effective immediately, FIPS Testing Laboratories must verify that cryptographic modules implement the health testing described in SP 800-90A (Section 11.3).

The wolfCrypt FIPS 140-2 Cryptographic Module (currently in “Coordination” at the CMVP) implements the health testing for the SP 800-90A Hash_DRBG.  

Cryptographic modules that do not include health testing will be placed on “HOLD” by the CMVP. The status on the NIST Modules in Process list will return to “IUT” (Implementation Under Test) until the health testing is implemented and retesting is completed.

See the recent blog post from InfoGard Laboratories for additional details: http://fips140.blogspot.com/2015/05/urgent-cmvp-guidance-effective.html

Please contact wolfSSL by email at fips@wolfssl.com, or call us at 425 245 8247 if you have any FIPS 140-2 questions.

The Logjam Attack exploits legacy SSL cipher suites from the 1990s that use DH and DHE export keys.  By definition a server in export mode has to use a low bit strength DH key (512 bits or less), which can now be cracked swiftly.  Even if a client supports export cipher suites but doesn’t broadcast support for them a man in the middle attacker can force the server to use the low grade key.  Fortunately for wolfSSL embedded SSL users we do not support export cipher suites.  No versions of wolfSSL or CyaSSL are vulnerable to the Logjam attack.  Our next version will allow build-time or run-time setting of minimum ephemeral key strengths for embedded TLS.

For more information check out https://weakdh.org.

“wolfSSL uses Intel`s extended instructions to accelerate crypto algorithms for IoT.

wolfSSL, an open source SSL/TLS security company has optimized the wolfSSL Transport Layer Security (TLS) library on 5th generation Intel® Core™ processors. With the inclusion of Intel’s extended instructions developers can use the wolfSSL libraries for applications on many devices, including embedded technologies. The resulting improvements mean end users will see enhanced speed and security with reduced power consumption across a wide range of devices including Internet of Things.

While cryptography arithmetic is often larger than many systems can support, even for 64-bit systems, by using Intel`s AVX1/2 SIMD instructions, developers can make use of the new optimizations to whittle down the compute needed, thereby reducing complexity and increasing performance. wolfSSL benchmarks show the wolfSSL secure hash algorithms are now significantly faster. The Advanced Vector Extensions perform multiple word operations with a single instruction (in parallel) to provide this boost in speed. wolfSSL also integrated Intel® Secure Key Technology (https://software.intel.com/en-us/blogs/2012/05/14/what-is-intelr-secure-key-technology ) to provide a high-quality, high-performance entropy source and random number generator.

Larry Stefonic, CEO of wolfSSL, adds “Handcrafting the world`s best crypto is our nature, so it is great to leverage Intel`s fantastic engineering support for the primitives to enhance our product. Our wolfSSL customers will enjoy better performance as a result of these software optimizations on 5th generation Intel Core processors.”
More detail on the performance can be found on the wolfSSL blog (https://www.wolfssl.com/intels-extended-instructions-accelerates-hash-algorithms/) while developers can download the latest release of wolfSSL on their website https://www.wolfssl.com/download/.

About wolfSSL:

Founded in 2004, wolfSSL is a dual licensed, open source and commercial company. wolfSSL provides high-end security, while also having a small enough footprint to be perfect for embedded systems.
For more information, please visit https://www.wolfSSL.com.”

Reference: http://www.prweb.com/releases/2015/04/prweb12660791.htm

Hi! A few years ago we collaborated with the MIT Kerberos team to port Kerberos to Android with wolfCrypt as the crypto engine. We have recently worked to get our wolfCrypt product FIPS 140-2 certified, and as such, can make a FIPS 140-2 version of Kerberos available to the market on Android and other platforms. Let us know if you’re interested and need any support. Contact us at facts@wolfssl.com, or call +1 425 245 8247.

Curious about how new machine instructions can accelerate crypto algorithms?  Most recently we added Intel’s Advanced Vector Extensions (AVX1 and 2) to wolfSSL’s secure hash algorithms.  Benchmarks show it improves the performance of SHA-256, 384 and 512 up to 75% (See: figure below). 

Intel`s AVX1/2 allows 128bit/256bit registers to perform multiple word operations with a single instruction in parallel.
The hashes take advantage of the AVX register parallelism and functional stitching between AVX and conventional registers as well.

How can you get it? Simply specify –enable-intelasm during ./configure with our latest version. It checks the instruction availability at run time, and you get the maximum performance improvement on your machine.

For further detail visit our “wolfSSL / wolfCrypt Benchmarks” page (http://wolfssl.com/yaSSL/benchmarks-cyassl.html).

—
AVX1:1.8GHz, Intel Core i5
AVX2: Intel Broadwell
—
AVX2:    SHA-256  50 megs took 0.320 seconds, 156.118 MB/s Cycles per byte =  9.75  = 47%
AVX1:   SHA-256  50 megs took 0.272 seconds, 184.068 MB/s Cycles per byte = 11.89  = 39%
Normal: SHA-256  50 megs took 0.376 seconds, 132.985 MB/s Cycles per byte = 16.46

AVX2:    SHA-384  50 megs took 0.226 seconds, 221.318 MB/s Cycles per byte =  6.88  = 42%
AVX1:   SHA-384  50 megs took 0.192 seconds, 260.975 MB/s Cycles per byte =  8.39  = 9%
Normal: SHA-384  50 megs took 0.209 seconds, 239.743 MB/s Cycles per byte =  9.13

AVX2:    SHA-512  50 megs took 0.224 seconds, 223.120 MB/s Cycles per byte =  6.82  = 75%
AVX1:   SHA-512  50 megs took 0.188 seconds, 266.126 MB/s Cycles per byte =  8.22  = 50%
Normal: SHA-512  50 megs took 0.281 seconds, 177.997 MB/s Cycles per byte = 12.29
===

A stream cipher encrypts plaintext messages by applying an encryption algorithm with a pseudorandom cipher digit stream (keystream). Each bit of the message is encrypted one by one with the corresponding keystream digit. Stream ciphers are typically used in cases where speed and simplicity are both requirements. If a 128 bit block cipher such as AES were to be used in place of a stream cipher where it was encrypting messages of 32 bit blocks, 96 bits of padding would remain. This is an inefficient approach and one reason why a stream cipher would be preferred, since they operate on the smallest possible unit.

Some common stream ciphers include RC4 (which has been shown to be vulnerable to attacks), Salsa20, ChaCha (a seemingly better variant of Salsa20), Rabbit, and HC-256, among others. Block ciphers can be used in stream mode to act as a stream cipher. If a block cipher is run in CFB, OFB, or CTR mode, it does not require additional measures to handle messages that aren’t equivalent to the length of multiples of the block size and eliminates the padding effect.

For information on the stream ciphers that can be implemented with wolfSSL or to learn more about the wolfSSL embedded SSL/TLS library, please view our wolfSSL product page or contact us at facts@wolfssl.com.

References

[1] Stream cipher. (2014, November 19). In Wikipedia, The Free Encyclopedia. Retrieved 16:19,
December
19, 2014, from http://en.wikipedia.org/w/index.php?title=Stream_cipher&oldid=634494612.

[2] Margaret Rouse. Stream Cipher. (2005). Available URL:
http://searchsecurity.techtarget.com/definition/stream-cipher.

[3] Block cipher mode of operation. (2014, December 12). In Wikipedia, The Free
Encyclopedia. Retrieved 17:13, December 19, 2014, from
http://en.wikipedia.org/w/index.php?title=Block_cipher_mode_of_operation&oldid=637837298.

Release 3.4.6 (March 30, 2015) of the wolfSSL lightweight embedded SSL library has bug fixes and new features including:

• Intel Assembly Speedups using instructions rdrand, rdseed, aesni, avx1/2, rorx, mulx, adox, adcx . They can be enabled with “–enable-intelasm”. These speedup the use of RNG, SHA2, and public key algorithms.
• Ed25519 support at the crypto level. Turn on with –enable-ed25519. Examples in “wolcrypt/test/test.c”, ed25519_test().
• Post Handshake Memory reductions. wolfSSL can now hold less than 1,000 bytes of memory per secure connection including cipher state.
• wolfSSL API and wolfCrypt API fixes, you can still include the cyassl and ctaocrypt headers which will enable the compatibility APIs for the foreseeable future
• INSTALL file to help direct users to build instructions for their environment
• For ECC users with the normal math library a fix that prevents a crash when verify signature fails. Users of 3.4.0 with ECC and the normal math library must update
• RC4 is now disabled by default in autoconf mode
• AES-GCM and ChaCha20/Poly1305 are now enabled by default to make AEAD ciphers available without a switch
• External ChaCha-Poly AEAD API, thanks to Andrew Burks for the contribution
• DHE-PSK cipher suites can now be built without ASN or Cert support
• Fix some NO MD5 build issues with optional features
• Freescale CodeWarrior project updates
• ECC curves can be individually turned on/off at build time.
• Sniffer handles Cert Status message and other minor fixes
• SetMinVersion() at the wolfSSL Context level instead of just SSL session level to allow minimum protocol version allowed at runtime
• RNG failure resource cleanup fix

• No high level security fixes that requires an update though we always recommend updating to the latest (except note 6, use case of ecc/normal math)

See the INSTALL file included with the wolfSSL download for build instructions.

More info about the wolfSSL embedded SSL library can be found on-line at http://wolfssl.com/yaSSL/Docs.html. Please contact wolfSSL at facts@wolfssl.com with any questions.