RECENT BLOG NEWS

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.

Currently MySQL comes bundled with yaSSL to provide an option for SSL/TLS connections when using a database. An update for MySQL to use the most recent wolfSSL library (formerly CyaSSL) instead of yaSSL is under way.

Along with an increased level of security comes the potential to use progressive features offered by wolfSSL – such as ChaCha20 / Poly1305 AEAD cipher suites (ex: ECDHE-RSA-CHACHA20-POLY1305). wolfSSL will fit nicely into both Open Source and commercial applications as it is dual licensed under both GPLv2 and standard commercial license terms.

For more information about the status of this port contact us at facts@wolfssl.com

This attack is based on the weak keys that the outdated stream cipher RC4 can sometimes generate.  Simply put, stop using RC4 in TLS connections.  In fact, wolfSSL (formerly CyaSSL) recently turned off the RC4 algorithm at build time.  This will be the default starting with the upcoming 3.4.6 release.  There has certainly been a pattern in the attacks that we’ve seen on TLS in the last few years; older Protocol versions, older modes, and older key sizes.  We suggest using TLS 1.2 with AEAD ciphers and forward secrecy.  Some people can’t get away with that in the interest of interoperability but it’s certainly the safest way forward that we can think of.  Please contact us with any questions.

Feel free to visit our website at wolfssl.com or email us at facts@wolfssl.com.

wolfSSL is adding crypto level use of Ed25519 to wolfCrypt and plans to add TLS use of Ed25519 in the future. Benchmarks of our Ed25519 implementation have shown that the sign time can be reduced by up to 90% and verify time by up to 65% compared with the common ECC-DSA!

The following are some initial benchmarks:

CPU: 2.5 GHz Intel Core i7

ECC 256 key generation 0.775 milliseconds, avg over 100 iterations
EC-DSA sign time 0.739 milliseconds, avg over 100 iterations
EC-DSA verify time 0.528 milliseconds, avg over 100 iterations

ED25519 key generation 0.055 milliseconds, avg over 100 iterations
ED25519 sign time 0.053 milliseconds, avg over 100 iterations
ED25519 verify time 0.184 milliseconds, avg over 100 iterations

Raspberry Pi (ARM 700MHz)

ECC 256 key generation 82.494 milliseconds, avg over 100 iterations
EC-DSA sign time 84.862 milliseconds, avg over 100 iterations
EC-DSA verify time 52.444 milliseconds, avg over 100 iterations

ED25519 key generation 1.543 milliseconds, avg over 100 iterations
ED25519 sign time 1.821 milliseconds, avg over 100 iterations
ED25519 verify time 3.832 milliseconds, avg over 100 iterations

For questions about wolfSSL contact us at facts@wolfssl.com

Hi!  As of June 30, 2015, we will no longer support CyaSSL 3.0 and older versions.  If you are using these older versions and need support to upgrade them, please contact us.  We can help you with the upgrade.

TwistM2M has released their multitalented, Verizon Wireless certified M2M device that allows cloud connectivity through Exosite’s secure cloud-based platform. This provides developers with a wide variety of widgets that can be used with the numerous sensors on the TwistM2M board including accelerometers, GPS, temperature and light sensors. The TwistM2M device is ideal for any developer wanting an Internet of Things (IoT) solution that can significantly shorten setup time and allow for many customizable applications.

wolfSSL was chosen as the SSL/TLS library for TwistM2M due to its extensive PIC32 support and lightweight capacity. wolfSSL also provides an I/O abstraction layer that helped TwistM2M tailor the SSL I/O functionality to use both cellular and Ethernet connections, a requirement for their M2M device.

If you would like more information on the TwistM2M platform, feel free to visit their website at www.twisthink.com. The TwistM2M/wolfSSL case study can be viewed on the wolfSSL case studies page.

For questions regarding the use of wolfSSL products in your embedded or IoT devices, contact us at facts@wolfssl.com.

Curious about new features and additions to wolfSSL technologies including the lightweight wolfSSL SSL/TLS library (formerly CyaSSL)?  Some items on our current roadmap include early TLS 1.3 adoption, curve25519 / ed25519 integration at the crypto and TLS level, more resource reduction options, and OCSP stapling support.  In terms of new environments we’ll soon have more FIPS platforms, additional hardware acceleration options, easier integration with event programming, Data plane development support, SRP integration, better Intel assembly crypto speedups, and more Open Source project plugins.  New product offerings will include wolfSSH and wolfCrypt as a separate library.  We also anticipate offering our testing and security audit programs as services.  Keep an eye out for connected home white papers and case studies.  Something we missed, or something you would like to see on our roadmap?  Please let us know.

Feel free to visit our website at wolfssl.com or email us at facts@wolfssl.com .