Month: June 2015

If working on a memory constrained device we now have memory optimized Ed25519 and Curve25519 options. This can be enabled with using the configure setting “./configure –enable-ed25519=small –enable-curve25519=small –enable-sha512”.

The new feature allows for a trade off in memory usage versus speed. All of the operations in the memory optimized build, except for SHA-512, use types that are equal to or less than 32 bits in size. On a Raspberry Pi the size of Ed25519 and Curve25519 is just under 18k for the memory optimized build versus 83k for the standard. The trade off for less memory does come at a hit to run time but for use cases that don`t generate many keys and have very little memory to work with this is a great option.

For more info please contact us at facts@wolfssl.com.

Larry Stefonic, our CEO, was recently interviewed by TechnologyAdvice on the future of wearables: an important space for embedded SSL/TLS and cryptography.

With the advent of the Internet of Things we are increasingly using connected devices throughout our day.  Unsecured, these devices leave us vulnerable in ways not even imaginable 20 years ago.  Larry talks about wolfSSL’s role in meeting customer demand for securing these varied devices from diverse and dedicated attackers.

With medical devices in particular becoming connected, he positions us as having exciting challenges securing new attack surfaces that have never before existed.  As doctors and medical companies push the boundaries of what devices can be built, we work on ensuring that those devices and their patients are secure. Read more below.

“wolfSSL enables Freescale`s hardware encryption for embedded tls, embedded cryptography, and the IoT”

wolfSSL Inc, the most popular embedded SSL, cryptography, and FIPS 140-2 provider for the IoT, has partnered with Freescale to deliver high performance, hardware enabled cryptography for Freescale`s MQX RTOS on the Kinetis platform. The hardware cryptography is enabled through wolfSSL`s well integrated and deeply tested support for the Kinetis platform`s MMCAU, which supports AES, SHA, and 3DES.

Larry Stefonic, wolfSSL Inc CEO noted that “Our support for the latest hardware cryptography from Freescale affords IoT developers a world of security and performance advantages. By combining forces with Freescale to leverage the Kinetis based crypto, we support the IoT community by providing smaller footprint, dramatically increased performance, and faster time to market. Securing a new IoT device can be daunting, but our joint effort with Freescale makes it much easier.”
More details and benchmarks for wolfSSL running on Kinetis can be found here:

https://www.wolfssl.com/docs/nxp/

About wolfSSL:
Founded in 2004, wolfSSL Inc provides high-end security, while also having a small enough footprint to be perfect for the IoT.

Reference: http://www.prweb.com/releases/2015/06/prweb12795767.htm

The new release of the wolfSSL embedded SSL library has bug fixes and new features including:

– Max Strength build that only allows TLSv1.2, AEAD ciphers, and PFS (Perfect
   Forward Secrecy).  With –enable-maxstrength.
– Server side session ticket support, the example server and echoserver use the
   example callback myTicketEncCb(), see wolfSSL_CTX_set_TicketEncCb().
– FIPS version submitted for iOS.
– TI Crypto Hardware Acceleration.
– DTLS fragmentation fixes.
– ECC key check validation with wc_ecc_check_key().
– 32bit code options to reduce memory for Curve25519 and Ed25519.
– wolfSSL JNI build switch with –enable-jni.
– PicoTCP support improvements.
– DH min ephemeral key size enforcement with wolfSSL_CTX_SetMinDhKey_Sz().
– KEEP_PEER_CERT and AltNames can now be used together.
– ChaCha20 big endian fix, big endian users should update.
– SHA-512 signature algorithm support for key exchange and verify messages.
– ECC make key crash fix on RNG failure, ECC users must update.
– Improvements to usage of time code.
– Improvements to VS solution files.
– GNU Binutils 2.24 ld has problems with some debug builds, to fix an ld error
  add -fdebug-types-section to C_EXTRA_FLAGS

– No high level security fixes that requires an update though we always
  recommend updating to the latest (except note 14, ecc RNG failure)

See INSTALL file for build instructions.
More info can be found on-line at http://wolfssl.com/yaSSL/Docs.html

Have you heard about the recent ChaCha20-Poly1305 AEAD and are wondering about how secure it is? It`s comprised of two ciphers, ChaCha20 and Poly1305, that are designed to be constant time, making it naturally resistant to timing attacks. The AEAD is being used by many notable companies that also trust it for their security – such as Google Chrome and Apple’s HomeKit. ChaCha20-Poly1305 has gone through security analysis and is considered secure.

To view a formal security analysis done on Adam Langley`s IETF protocol using ChaCha20-Poly1305 see https://eprint.iacr.org/2014/613.pdf

For added analysis done on Salsa (what ChaCha is based from) see section 5 from http://cr.yp.to/snuffle/salsafamily-20071225.pdf

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

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.