176

(5 replies, posted in wolfSSL)

Hi,

Thanks for letting us know that upgrading to 14.04.3 fixed the issue.

Best Regards,
Chris

177

(5 replies, posted in wolfSSL)

Hi,

I can confirm that wolfSSL 3.7.0 downloaded from the wolfssl.com download page compiles correctly on an Ubuntu 14.04 64-bit virtual machine.

I have the following aclocal version:

$ aclocal --version
aclocal (GNU automake) 1.14.1

What version of aclocal do you have installed?

Thanks,
Chris

178

(1 replies, posted in wolfSSL)

Hi byron,

We don't currently have a way to serialize all information in a wolfSSL context or session.  The closest we have to that the feature to save the certificate cache and session cache:

--enable-savesession - enabling this option will allow an application to persist (save) and restore the wolfSSL session cache to/from memory buffers.

--enable-savecert - enabling this option will allow an application to persist (save) and restore the wolfSSL certificate cache to/from memory buffers.

Best Regards,
Chris

179

(5 replies, posted in wolfSSL)

Hi,

How and where did you download wolfSSL from?  Can you confirm what steps you are using to compile the library?  A normal build would be similar to:

unzip wolfssl-3.7.0.zip
cd wolfssl-3.7.0
./configure
make

Thanks,
Chris

Hi Olga,

Glad to hear that fixed your problem!

Best Regards,
Chris

The wolfMQTT v0.3 release adds a new example for secure firmware update. This example uses the wolfSSL embedded SSL/TLS library to hash/sign the binary image and send it over MQTT. The example has two applications. One is called fwpush, which hashes, signs and publishes the firmware image over TLS to an MQTT broker. The second is called fwclient, which subscribes to the example firmware update topic, receives the firmware image and validates the signature of it. This example is located in examples/firmware.

The latest wolfMQTT releases can be downloaded at:
https://wolfssl.com/wolfSSL/download/downloadForm.php

Documentation for wolfMQTT can be found here:
https://wolfssl.com/wolfSSL/Docs-wolfmqtt-manual.html

The latest source code can be found on our GitHub repo at:
https://github.com/wolfSSL/wolfMQTT

For questions please contact support at support@wolfssl.com.

Hi,

Have you enabled PSK support when compiling wolfSSL?  This can be done with the "--enable-psk" ./configure option:

./configure --enable-psk

Thanks,
Chris

Hi alex_b,

If you would like wolfSSL to hang on to the peer certificate after the SSL/TLS handshake, you can define KEEP_PEER_CERT when compiling wolfSSL.

With wolfSSL, by default the verify callback is only called upon verification failure.  wolfSSL handles certificate verification internally, which is unlike OpenSSL that forces the user to do the verification.  This means that on all failure cases, the preverify parameter will be zero. 

Optionally, you can force wolfSSL to call the verify callback on every verification - regardless if it is successful or a failure - by defining WOLFSSL_ALWAYS_VERIFY_CB.  In this case, if preverify is equal to "1", wolfSSL has already successfully verified the peer certificate.  We provide this option for those users who wish to do custom inspection of certificate elements past normal certificate verification measures.

Does this help clear things up?

Best Regards,
Chris

Hi Olga,

How are you using RSA in your application?  Is this during an SSL/TLS connection or standalone?  Do you know where the segmentation fault is happening?

One thing to check, if you are compiling wolfSSL using the ./configure system, are you including <wolfssl/options.h> in your application before any other wolfSSL headers?  This will ensure that you application uses the same settings as how wolfSSL was compiled.

Thanks,
Chris

Hi cfarrin,

Great, thanks for the update.  Glad to hear you have it working!

Best Regards,
Chris

Hi windsp,

Yes, ecc_sign_hash() checks to make sure the value of 'k' is within the required range.  You can see this in ./wolfcrypt/src/ecc.c, around line #1738:

   /* quick sanity check to make sure we're not dealing with a 0 key */
   if (err == MP_OKAY) {
       if (MP_YES == mp_iszero(&key->k))
           err = MP_ZERO_E;
   }

   /* the key should be smaller than the order of base point */
   if (err == MP_OKAY) {
       if (mp_cmp(&key->k, &order) != MP_LT)
           err = mp_mod(&key->k, &order, &key->k);
   }

Best Regards,
Chris

Hi jurkovi,

What Cortex-M4 processor are you using for your benchmarks?  And what public key size are you using (1024, 2048, 4096, ...)?

Are you using the wolfCrypt benchmark application to run the benchmarks?

Thanks,
Chris

188

(2 replies, posted in wolfCrypt)

Hi gawiz,

XMALLOC/XFREE/XREALLOC are part of the wolfSSL memory abstraction layer.  By default, these just map down to malloc/free/realloc, but depending on if you are using one of our OS ports, these are mapped instead to that OS's memory functions.  Whenever wolfSSL needs to allocate, reallocate, of free memory internally, we call XMALLOC/XFREE/XREALLOC.

Users can also define XMALLOC/XFREE/XREALLOC in their settings.h or user_settings.h (if HAVE_USER_SETTINGS is defined), mapping them to their own custom memory handlers.

Since these are used internally by wolfSSL, at your own application level, you are still free to use your own memory functions directly (ie: malloc, etc.).

Best Regards,
Chris

189

(1 replies, posted in General Inquiries)

Hi vittico,

wolfSSL proper has had ECC support for roughly three years now.  If you're starting off a new project with wolfSSL, I would recommend downloading the latest stable version (3.7.0) from our download page:

https://wolfssl.com/wolfSSL/download/downloadForm.php

We have a JNI wrapper for wolfSSL called "wolfSSL JNI".  We bundle this as a separate product, which also wraps the DTLS 1.2 support of wolfSSL.  You can find more info about this product at the below URL, and download it from the same download page as above.  FYI, we have a new version of wolfSSL JNI that will be compatible with the 3.7.0 release coming out this week.

https://www.wolfssl.com/wolfSSL/Product … sljni.html

Best Regards,
Chris

190

(3 replies, posted in wolfCrypt)

Hi gawiz,

Can you share what your end goal is?  We may be able to suggest an approach based on that?

Thanks,
Chris

Hi cfarrin,

We just recently added the wolfSSL_get_jobject() function to better handle some of the internal callbacks in JNI.  You'll need to update the "wolfssl" git submodule to the current HEAD.

I'll work on updating our wolfssl-examples repository with this change as well.

Best Regards,
Chris

192

(5 replies, posted in wolfCrypt)

Hi Olga,

Just checking in to see if you got your ECC key import working.  I wanted to point out that we have several other ECC key import functions as well:

int wc_ecc_import_x963(const byte* in, word32 inLen, ecc_key* key);
int wc_ecc_import_private_key(const byte* priv, word32 privSz, const byte* pub, word32 pubSz, ecc_key* key);

Our API docs for ECC functions are located here:

https://wolfssl.com/wolfSSL/Docs-wolfss … i-ecc.html

Best Regards,

Hi gawiz,

As a follow-up, we have examples of using SHA-256 in our wolfCrypt test application.  This can be found in the wolfSSL package at the following location:

<wolfssl_root>/wolfcrypt/test/test.c

Specifically, inside of the sha256_test() function.  Do you mind if I ask what you are working on?

Thanks,
Chris

Hi gawiz,

Yes, that's correct.  wc_Sha256Final() just takes a pointer to a memory location from the user.  This means that your application is responsible for managing that memory - whether it be on the stack as above, or dynamically if you allocated it with malloc().

Best Regards,
Chris

Hi Gareth,

The wolfSSL_SHA256_Init(), wolfSSL_SHA256_Update(), and wolfSSL_SHA256_Final() functions are part of the wolfSSL OpenSSL Compatibility layer.  Are you enabling that layer at compile time when you are building wolfSSL?  You can do that when using ./configure with "--enable-opensslextra", or if using preprocessor flags by defining OPENSSL_EXTRA.

If you don't want to use the OpenSSL Compatibility Layer, you can use our wolfCrypt SHA-256 functionality directly through the following header file:

<wolfssl/wolfcrypt/sha256.h>

Specifically the following functions:

int wc_InitSha256(Sha256* sha);
int wc_Sha256Update(Sha256* sha, const byte* data, word32 len);
int wc_Sha256Final(Sha256* sha, byte* out);

Best Regards,
Chris

196

(11 replies, posted in wolfSSL)

Hi,

In general, you should be able to follow the steps listed in Section 2.4 of the wolfSSL Manual:

https://wolfssl.com/wolfSSL/Docs-wolfss … lfssl.html

This will walk you through adding the source files and header files to your project.  We recently added a define to ./wolfssl/wolfcrypt/settings.h for KSDK + FreeRTOS, FREESCALE_FREE_RTOS.

With the most current KSDK release, you are also able to download wolfSSL from the Freescale website, as a add-on for the KSDK.  This comes with a few example KDS and IAR project files.

Best Regards,
Chris

197

(1 replies, posted in General Inquiries)

Hi naftaliz,

We just finished integration and testing with the current VxWorks release (7).  This includes support for AES-256.

Best Regards,
Chris

Hi cfarrin,

It looks like our Android example needs to be updated to include the following wolfSSL source file:

wolfcrypt/src/wc_encrypt.c

We'll work on getting this updated.

Thanks,
Chris

Hi Kannan,

Do you need to install wolfSSL as an SSL provider at the OS-level in Android, or can you use it at the application level?  Most of our current development regarding using wolfSSL with Android is now being done on our "wolfSSL JNI" product/wrapper.  This allows your application to use wolfSSL from Java.  You can find the wolfSSL JNI manual here:

https://www.wolfssl.com/documentation/w … Manual.pdf

And download it from our website here:

https://wolfssl.com/wolfSSL/Products-wolfssljni.html

Best Regards,
Chris

Glad things are working now  smile