Hi,

Can you send me the output of your wolfSSL debug log for the case you think is odd/incorrect?  wolfSSL debugging can be enabled by compiling wolfSSL with DEBUG_WOLFSSL, then calling wolfSSL_Debugging_ON() as the first wolfSSL function call in your application code.

Thanks,
Chris

To answer your question about fastmath as the default, we do enable it as the default on Unix/Linux 64-bit platforms.

On some 32-bit platforms users will get an error about a missing register being available because of PIC.  We have a few workarounds for this issue listed in the README, but for out-of-the-box compilation we have opted not to enable it by default on 32-bit platforms.

In general, fastmath is more commonly used over the normal big integer library - both on embedded platforms and desktop/enterprise ones.  It is quite a bit faster on most platforms.

Best Regards,
Chris

Hi StrToLower,

The main source and header directories of the wolfSSL package are:

./wolfssl - All wolfSSL and wolfCrypt headers, this directory structure needs to remain intact (ie: ./wolfssl, ./wolfssl/wolfcrypt, etc.).

./wolfcrypt - This directory holds the sources files for the underlying wolfCrypt crypto module.  Normally you can include all source files from this directory.  Features are excluded through the use of preprocessor defines (ex: NO_DES3)

./src - This directory holds the source files for the wolfSSL SSL/TLS layer.  All files in this directory should be compiled as well.

Best Regards,
Chris

Hi,

Have you compiled your application using the same preprocessor defines that were used when compiling wolfSSL?

When using the Autoconf system (./configure), the easiest way to make sure this happens is to include the <wolfssl/options.h> header as the first wolfSSL include in your application:

#include <wolfssl/options.h>
#include <wolfssl/ssl.h>
...

Best Regards,
Chris

Hi,

Are you interested in using Diffie-Hellman standalone, or in the context of SSL/TLS?  If using DH in SSL/TLS, the TLS protocol takes care of transporting the DH parameters and public keys.

If using DH in a standalone use case, your application will need a way to transfer the DH parameters and public keys to the other party.  Using the dh_test() function in test.c as an example, both the client and server will load the DH parameters into a DhKey structure using one of the two functions:

wc_DhSetKey() - used with individual "p" and "g" parameters
wc_DhKeyDecode() - used with a DH "key" that contains the "p" and "g" parameters

Each side (client and server) will generate their own private and public keys using:

wc_DhGenerateKeyPair()

The public keys from the wc_DhGenerateKeyPair() operations will need to be transferred to the other peer.  The final shared secret will then be derived by each side using:

wc_DhAgree()

Best Regards,
Chris

Hi,

The OCSP callback (registered with wolfSSL_CTX_SetOCSP_Cb()) is meant to allow your application to have control over connecting to the OCSP Responder and parsing/verifying the response.  wolfSSL uses an internal OCSP callback (EmbedOcspLookup() in ./src/io.c) to do this by default, but when you override our internal callback with wolSSL_CTX_SetOCSP_Cb(), your application needs to handle this yourself within your callback.  Your callback should return 0 on success or -1 on error.

One option that would allow you to inspect the OCSP response would be to:

1.  Write and register your own OCSP callback with wolSSL_CTX_SetOCSP_Cb()
2.  Have your callback just call our default callback (EmbedOcspLookup()).  This is a public API function exposed through <wolfssl/ssl.h>
3.  After our internal callback returns, you should be able to look at the response data inside the "unsigned char** resp" output variable.

Best Regards,
Chris

Hi Henry,

The examples under the ./mqx directory of wolfSSL were written for CodeWarrior + wolfSSL + MQX.  Although this doesn't include an HTTPS example, it does include a library project, wolfCrypt test and benchmark projects, and wolfSSL client example.  Can you elaborate on how they were failing?

We don't currently have an HTTPS example for MQX/K64.  The closest one I can think of is the httpsrv_wolfssl_frdmk64f example project that ships with the Kinetis SDK (KSDK) 1.3.0.  This is available direct from the NXP website.

Best Regards,
Chris

Hi hstr,

If you are using the wolfSSL example client and server, you can use the "-a" option to use the anonymous cipher.  This option will cause both client and server to call the above two functions.  It sounds like your server didn't have the anonymous cipher enabled and thus couldn't find a common cipher suite.

$ cd wolfssl-3.9.6
$ ./configure --enable-anon
$ make
$ ./examples/server/server -a

$ ./examples/client/client -a

Best Regards,
Chris

Hi,

I have attached a PDF which should help explain wolfSSL's OCSP Stapling functionality.  Are you able to share any details of the project you are working on?

Thanks,
Chris

Hi,

RsaSSL_Sign() does not do a hash operation on the input data before signing.  Your application will need to hash the input data before passing it in for signing.

wolfCrypt's hash functions are prototyped by the respective header file, ie:

<wolfssl/wolfcrypt/sha.h>
<wolfssl/wolfcrypt/sha256.h>
<wolfssl/wolfcrypt/sha512.h>

The heap usage doesn't look out of the expected range.  By default, wolfSSL and wolfCrypt use the normal big integer library for public key calculations and operations.  Alternatively, you can use the "fastmath" library instead.  The fastmath library puts more on the stack and less on the heap, whereas the big integer library uses more heap and less stack.  If you wanted to use less heap, you could enable the fastmath library by defining:

USE_FAST_MATH
TFM_TIMING_RESISTANT

Best Regards,
Chris

Hi hstr,

Typically when we do benchmarking, we benchmark the cryptography algorithms versus benchmarking a send or recv that would include I/O operations.  The underlying cryptography is going to be the most performance intensive operations of the SSL/TLS connection, where sending or receiving data over a network or transport medium is going to have many more factors in play than the SSL/TLS library.

We ship a crypto benchmark application with wolfSSL, located in the <wolfssl_root>/wolfcrypt/benchmark/benchmark.c file.  If you are compiling this on an embedded platform, you can define NO_MAIN_DRIVER to compile out the main() from benchmark.c if you have your own driver/main().  You can also define BENCH_EMBEDDED when compiling the library/benchmark.c to use less memory.  benchmark.c contains individual crypto benchmark functions (ex: bench_aes(), bench_rsa(), etc.) which can be called individually, or you can call benchmark_test() which will call all of the enabled crypto benchmarks.

Going back to your mentioned benchmark, do you know if both connections were using the same cipher suite, key length, and application code?

Thanks,
Chris