126 Reply by chrisc

(3 replies, posted in wolfSSL)

Hi,

wolfSSL only supports one anonymous cipher suite (one without authentication).  That is "TLS_DH_anon_WITH_AES_128_CBC_SHA", and can be enabled by compiling wolfSSL with "--enable-anon" or defining HAVE_ANON.  After compiling, your application can enable the anonymous cipher suite by using the following function calls, like our example client and server do:

wolfSSL_CTX_allow_anon_cipher(ctx);
wolfSSL_CTX_set_cipher_list(ctx,"ADH-AES128-SHA");

Note that this cipher suite still supports encryption.

Best Regards,
Chris

Go to forum: wolfSSL

127 Reply by chrisc

(3 replies, posted in wolfSSL)

Hi,

Thanks for the additional info on your project, and glad to help out.

Going back to the library size, you were compiling the static wolfSSL library (.lib), which most likely was also pulling in some OS-level stuff when linking.  If you were to switch and compile the wolfSSL DLL instead of the static library, you would see a footprint size more closely aligned with your 200-300kB number.

Best Regards,
Chris

Go to forum: wolfSSL

128 Reply by chrisc

(1 replies, posted in wolfSSL)

Hi,

Thanks for looking at and working with wolfSSL!

By default, wolfSSL uses dynamic Input/Output buffers that start at 5 bytes each then grow and shrink as necessary to accommodate SSL/TLS/DTLS records.  Shrinking the buffer back down after use is done in order to minimize dynamic resource use.  On many embedded systems, that same heap memory could potentially need to be used by other tasks/areas of the app.

Now, moving past our default configuration, we have several ways that I/O memory usage can be customized by the user which may be helpful if trying to optimize for minimum resource use, performance, or to align to design/project requirements.  Some of those include:

1.  Custom Memory Handlers - wolfSSL includes a memory abstraction layer that allows users to write and register their own malloc, realloc, and free functions.  You can define XMALLOC, XFREE, and XREALLOC to your own custom functions.  Using this, you could write your own memory functions that watch for the DYNAMIC_TYPE_IN_BUFFER and DYNAMIC_TYPE_OUT_BUFFER heap hints.  This would let you allocate one memory block for each and hand the same buffer back if the allocator requests it.  In your case, if you wanted to skip shrinking the buffer, your custom realloc() function could opt to not free that buffer.

2.  Defining LARGE_STATIC_BUFFERS when compiling wolfSSL dynamically allocates a fixed size 17K Input buffer and a fixed size 17K output buffer, increasing the size of the WOLFSSL object by about 34K. The maximum TLS record size is 16K plus some overhead, so LARGE_STATIC_BUFFERS allows someone to get all possible memory upfront and not have to worry about a low memory situation during the handshake for example.

Best Regards,
Chris

Go to forum: wolfSSL

129 Reply by chrisc

(3 replies, posted in wolfSSL)

Hi,

The default wolfSSL configuration used in the Visual Studio project files has not been optimized for footprint size.  For example, the user_settings.h file used by the VS projects to compile wolfSSL is located at:

<wolfssl_root>/IDE/WIN/user_settings.h

This settings file enables the OpenSSL Compatibility Layer (OPENSSL_EXTRA), RIPEMD (WOLFSSL_RIPEMD), SHA-512 (WOLFSSL_SHA512), and sniffer support (WOLFSSL_SNIFFER).  You can try disabling unneeded features to reduce the library size as needed.

The Visual Studio project files are meant to be a starting place for getting wolfSSL compiled with Visual Studio, where users can then optimize for performance, size, or features from there.

Do you mind if I ask what kind of project you are working on?

Thanks,
Chris

Go to forum: wolfSSL

130 Reply by chrisc

(1 replies, posted in wolfSSL)

Hi,

If you don't need to do client authentication, your server does not need to load a list of CA certificates using the wolfSSL_CTX_load_verify_locations() function.  You will just need to load a server private key and certificate.

Best Regards,
Chris

Go to forum: wolfSSL

131 Topic by chrisc

(0 replies, posted in Announcements)

wolfSSL has added support for embOS in the wolfCrypt embedded cryptography library. We have example projects in the “<wolfssl_root>/IDE/IAR-EWARM/embOS/” directory which include a library to link against, a benchmark, and wolfcrypt_test that are preconfigured for Atmel’s SAMV71 Xplained Ultra when using IAR Embedded Workbench for ARM (EWARM). These examples are set up to build and run with no user modifications by default (After you download the documented software and have on hand the necessary hardware).

The examples will be available in the next stable release of the wolfSSL embedded SSL/TLS library and are currently available in the wolfSSL development branch at: https://github.com/wolfssl/wolfssl

There is a README_custom_port that will assist in creating a project that targets a different MPU as well. As always we are more than willing to help anyone get setup and going so please feel free to contact us support@wolfssl.com if you ever have any questions!

Go to forum: Announcements

132 Topic by chrisc

(0 replies, posted in Announcements)

When using wolfSSL with MySQL (https://www.mysql.com/) the portability and robustness refined in the IoT realm meets databases. The patch has been updated to MYSQL version 5.6.30 and allows for easy replacement of the bundled TLS/SSL library to a recent version of wolfSSL. Using the patch leverages the progressive, lightweight wolfSSL embedded SSL/TLS library when securing database connections. The patch, along with instructions on how to apply it, can be found on github at this repository https://github.com/wolfSSL/mysql-patch.

For more information contact wolfSSL at info@wolfssl.com

Go to forum: Announcements

133 Topic by chrisc

(0 replies, posted in Announcements)

Are you interested in seeding wolfSSL with quantum entropy?  wolfSSL has recently partnered with Whitewood Encryption Systems to bring support for the Whitewood netRandom client library to wolfSSL.

Whitewood netRandom is a client/server solution for delivery true random numbers.  The netRandom server includes the Whitewood Entropy Engine - a hardware-based high-performance, quantum random number generator.  A netRandom client securely connects to this server to retrieve quantum entropy.  This is beneficial in environments where it is tough or impossible to locally generate good random numbers.  Since the security of a cryptosystem is dependent on true random numbers, this is very important for users of wolfSSL and wolfCrypt.

When wolfSSL is compiled with support for the netRandom client library API, wolfSSL’s PRNG will be seeded with quantum random numbers from the netRandom server.  Users can compile wolfSSL with netRandom support by using the following ./configure option or by defining HAVE_WNR when compiling wolfSSL:

--with-wnr=PATH      Path to Whitewood netRandom install (default /usr/local)

netRandom support adds the following two functions to the wolfSSL API, through the <wolfssl/wolfcrypt/random.h> header:

int wc_InitNetRandom(const char* configFile, wnr_hmac_key hmac_cb, int timeout);
int wc_FreeNetRandom(void);

An application should call wc_InitNetRandom() once during startup, passing it the netRandom configuration file, optional HMAC callback, and entropy timeout.  wc_FreeNetRandom() should be called upon application shutdown to free the netRandom context.

Usage examples can be found in the wolfSSL example applications, located in under the “./examples” directory of the wolfSSL download.  netRandom support is currently available in the development branch of wolfSSL (https://github.com/wolfssl/wolfssl) and will be incorporated into the next stable release as well.

For more information about using the wolfSSL embedded SSL/TLS library with the Whitewood netRandom client library, contact us at info@wolfssl.com.

References:
Whitewood Encryption Systems: http://www.whitewoodencryption.com/
Whitewood netRandom: http://www.whitewoodencryption.com/prod … eneration/

Go to forum: Announcements

134 Topic by chrisc

(0 replies, posted in Announcements)

OpenSSL released a security advisory on May 3rd 2016: https://www.openssl.org/news/secadv/20160503.txt.  Some wolfSSL embedded SSL/TLS users are probably wondering if similar security fixes are needed in wolfSSL.  The answer to that is no.  Specifically, CVE-2016-2107 and CVE-2016-2108 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.

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

Go to forum: Announcements

135 Topic by chrisc

(0 replies, posted in Announcements)

wolfSSL is happy to announce that the wolfSSL embedded SSL/TLS and wolfCrypt cryptography libraries have been ported to the uTasker operating system!

uTasker[1] is an operating system, stack, and collection of services designed for embedded devices.  It includes an OS, filesystem, device drivers, and TCP/IP stack among other features.  The uTasker package includes a device simulator, allowing developers to test and debug code faster than would be possible on physical hardware itself.  Complete details on the uTasker stack can be found on the project website: http://www.utasker.com/.

wolfSSL has added a new preprocessor define to enable the uTasker port layer called WOLFSSL_UTASKER.  The port currently includes example client and server uTasker tasks which make use of the wolfSSL I/O abstraction layer to send and receive data over a secure SSL/TLS connection using uTasker RAW sockets.  The example tasks have been tested using the uTasker device simulator contained in the “uTasker_M522XX_V1.4-6” distribution.

What this means for projects using uTasker is that network connections can now communicate securely over SSL/TLS, using the progressive and lightweight wolfSSL SSL/TLS library.  Applications can also take advantage of the underlying wolfCrypt cryptography library to access crypto operations directly (block ciphers, stream ciphers, AEAD ciphers, hash functions, public key algorithms, and certificate verification routines).

The wolfSSL uTasker example client and server task are located in the ‘wolfssl-examples’ GitHub repository, linked below.  Documentation for these examples and on using wolfSSL with uTasker can be found on the wolfSSL website:

Using wolfSSL with uTasker: https://wolfssl.com/wolfSSL/Docs-wolfssl-utasker.html
wolfSSL uTasker Examples: https://github.com/wolfSSL/wolfssl-exam … er/utasker

If you are interested in using wolfSSL on a uTasker-based project, feel free to reach out to us at info@wolfssl.com with any questions.

[1] http://www.utasker.com/index.html

Go to forum: Announcements

136 Reply by chrisc

(1 replies, posted in wolfSSL)

Hi hanshuang,

We ported wolfSSL to mongoose a while back using the wolfSSL OpenSSL Compatibility Layer (./configure --enable-opensslextra), but haven't tried compiling wolfSSL against current mongoose releases yet.

Can you share more about your desired use case of mongoose and wolfSSL?

Thanks,
Chris

Go to forum: wolfSSL

137 Reply by chrisc

(3 replies, posted in wolfSSL)

Hi Jack,

Great, thanks for following up and letting me know what helped.

Best Regards,
Chris

Go to forum: wolfSSL

138 Reply by chrisc

(1 replies, posted in wolfSSL)

[This was also answered through the wolfSSL support channel, but copying info here for user reference.]

wolfSSL's stack and heap usage will vary between 1-36kB depending on public key algorithm, key size, and math library being used.  wolfSSL has a Resource Use document available that details stack and heap usage, which can be obtained by emailing support@wolfssl.com.

As mentioned in this related post [1], wolfSSL contains a memory abstraction layer that allows applications to write and register their own memory handling functions (ie: malloc, realloc, free) with wolfSSL.  These are mapped by defining XMALLOC, XREALLOC, and XFREE at compile time.

[1] http://www.yassl.com/forums/topic795-us … xfree.html

Go to forum: wolfSSL

139 Reply by chrisc

(1 replies, posted in wolfSSL)

[This was also answered through the wolfSSL support channel, but copying here for user reference.]

Since wolfSSL allows you to map XMALLOC and XFREE to a custom function, you could have your own memory handling "malloc" and "free" functions that handle memory as you desire. This could be managing memory from a single block or block(s) of static memory or pre-allocated buffers. We don't have a set of example custom memory functions out of the box for this, but provide the abstraction.

The heap hint gives the memory handlers an idea of what kind of memory the pointer is for. In some cases, this allows the memory handlers to reuse or manage memory more efficiently, keeping track of what types of memory they have allocated and freed. We don't currently have documentation about the different kinds of heap hint types, but this has been added to our documentation request list.

Best Regards,
Chris

Go to forum: wolfSSL

140 Reply by chrisc

(3 replies, posted in wolfSSL)

Hi Jack,

When using TLS 1.2, if the client doesn't send a client certificate, the server can choose what to continue or error out.  From RFC5246[1]:

If the client does not send any certificates, the
server MAY at its discretion either continue the handshake without
client authentication, or respond with a fatal handshake_failure
alert.

From the node.js documentation, it looks like you might need to add the rejectUnauthorized option to your server config, ie "rejectUnauthorized: true".  Can you give that a try?

Thanks,
Chris

[1] https://tools.ietf.org/html/rfc5246#section-7.4.6

Go to forum: wolfSSL

141 Reply by chrisc

(4 replies, posted in wolfCrypt)

Hi hdan,

Can you tell me where the above was failing for you, and how you are calling that function?  Are you initializing/importing the ecc_point's somewhere else?

Do you mind if I ask what your end goal is for adding ECC points?  I just want to verify we don't already have the functionality you are looking for elsewhere.

Thanks,
Chris

Go to forum: wolfCrypt

142 Reply by chrisc

(1 replies, posted in wolfSSL)

Hi cfarrin,

Can you try calling setFd() after you create the wolfSSL session with WolfSSLSession()?

Thanks,
Chris

Go to forum: wolfSSL

143 Reply by chrisc

(4 replies, posted in wolfCrypt)

Hi,

wolfCrypt's ECC implementation has the functionality to add two points internally, but doesn't currently expose it as part of the public API.  The internal implementation is located in the ecc_projective_add_point() function of ./wolfcrypt/src/ecc.c.

Can you elaborate on your desired use case of ECC point addition?

Thanks,
Chris

Go to forum: wolfCrypt

144 Reply by chrisc

(3 replies, posted in wolfSSL)

Thanks for letting me know you got this resolved.  Let us know if anything else comes up.

Thanks,
Chris

Go to forum: wolfSSL

145 Reply by chrisc

(3 replies, posted in wolfSSL)

Hi,

Do you know what error is returned from wolfSSL_get_error() in your above code?  This will let us know the specific error code from wolfSSL.  A Wireshark trace (.pcap) may also be helpful to debug.

Thanks!
Chris

Go to forum: wolfSSL

146 Reply by chrisc

(5 replies, posted in wolfSSL)

Hi,

If you have wolfSSL compiled with ECC, PSK, CCM-8, and static PSK support:

./configure --enable-ecc --enable-psk --enable-aesccm C_EXTRA_FLAGS="-DWOLFSSL_STATIC_PSK"

You should be able to make a connection between the wolfSSL example client and server using ECDHE-ECDSA-AES128-CCM-8 using:

./examples/server/server -l ECDHE-ECDSA-AES128-CCM-8 -c ./certs/server-ecc.pem -k ./certs/ecc-key.pem
./examples/client/client -l ECDHE-ECDSA-AES128-CCM-8 -A ./certs/server-ecc.pem

And a connection using PSK-AES128-CCM-8 using:

./examples/server/server -s -l PSK-AES128-CCM-8
./examples/client/client -s -l PSK-AES128-CCM-8

Can you try those?

Thanks,
Chris

Go to forum: wolfSSL

147 Reply by chrisc

(5 replies, posted in wolfSSL)

Hi,

The TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 cipher suite is enabled in your above configuration (ECDHE-ECDSA-AES128-CCM-8).

As you found in our README, we did disable static key cipher suites for security reasons.  You can re-enable them by defining one or more of WOLFSSL_STATIC_RSA, WOLFSSL_STATIC_DH, and WOLFSSL_STATIC_PSK.  To gain access to the "TLS_PSK_WITH_AES_128_CCM_8" cipher suite, you will need to define WOLFSSL_STATIC_PSK when compiling wolfSSL.  You can do that like so through C_EXTRA_FLAGS:

./configure <options> C_EXTRA_FLAGS="-DWOLFSSL_STATIC_PSK"

Are you doing research in conjunction with a university?

Best Regards,
Chris

Go to forum: wolfSSL

148 Reply by chrisc

(3 replies, posted in wolfSSL)

Glad to hear we found the missing piece of the puzzle.  Thanks for looping back and letting us know.

Go to forum: wolfSSL

149 Reply by chrisc

(1 replies, posted in wolfSSL)

Hi,

wolfSSL contains an OpenSSL compatibility layer.  This layer currently contains roughly the 400 most commonly used OpenSSL functions, which are then mapped down to wolfSSL's native API internally.  As OpenSSL contains over 4,000 functions, this layer is not complete and meant to act as a starting place.  This layer slowly grows as we do more ports into applications that had previously used OpenSSL.  Some recent examples of these have been OpenSSH, stunnel, and lighttpd.

You can enable the OpenSSL compatibility layer when compiling wolfSSL by using the "--enable-opensslextra" ./configure option, or by defining OPENSSL_EXTRA.  To compile an existing OpenSSL-based application against the wolfSSL compatibility layer, you will need to switch the <openssl/ssl.h> header to <wolfssl/openssl/ssl.h> and link against "-lwolfssl" instead of "-lssl -lcrypto".

We haven't tried compiling wolfSSL with Qt yet, so I don't know at the moment what (if any) gaps there would be between our compatibility layer and Qt's usage of the OpenSSL API.  You could try the compilation yourself, or we could explore porting wolfSSL into Qt on a consulting basis if desired.

Let us know what you think and we can go from there.  You can reach us directly at info (at) wolfssl (dot) com.

Best Regards,
Chris

Go to forum: wolfSSL

150 Reply by chrisc

(3 replies, posted in wolfSSL)

A possible disadvantage would be slightly higher stack use per thread, since you now have an ECC fixed point cache per thread, instead of one global cache.  The upside is that it may be more performant as you no longer have to lock/unlock mutexes on the cache.

Go to forum: wolfSSL