Hi Cxdinter,

If you define HAVE_ECC_BRAINPOOL then it will enable the Brainpool curves, however you must create the ECC key using wc_ecc_make_key_ex to tell the ECC layer you want to use that curve type:

ecc_key key;
ret = wc_ecc_init(&key);
ret = wc_ecc_make_key_ex(rng, 32, &key, ECC_BRAINPOOLP256R1);

Then you can call wc_SignatureGenerate.

The best way to add defines if not using ./configure is to globally define WOLFSSL_USER_SETTINGS (like in your CFLAGS) and add a new user_settings.h file somewhere in your include path.

There is a good user_settings.h example here:
https://github.com/wolfSSL/wolfssl/blob … settings.h

Also, if you haven't seen it there is a great signature/verify example here:
https://github.com/wolfSSL/wolfssl-exam … /signature
Although its missing the custom ECC curve example above, so I'm going to add that soon.

Thanks,
David Garske, wolfSSL

Hi cxdinter,

Thank you so much for the report.

It looks like that scenario could happen if your call to wc_RNG_GenerateBlock did not return 0 (in wc_ecc_make_key_ex at line 2507). In that case variable "a" would be un-initialized from the stack and the call to "mp_clear" could cause a seg fault due to invalid pointer.

Will you confirm your wc_RNG_GenerateBlock return code? It should be zero indicating success.

I've pushed a fix for that here:
https://github.com/wolfSSL/wolfssl/pull/626

Let me know if that helps.

Thanks,
David Garske, wolfSSL

Hi Jesussotofan,

All calls to wc_GenerateSeed are in wolfcrypt/src/random.c. There are multiple places where this function exists depending on the hardware platform. Those start at line 1133.

If you are defining CUSTOM_RAND_GENERATE_SEED then it will use the function used in that define. I'd also make sure you don't have NO_DEV_RANDOM defined.

The function wc_InitRng calls wc_GenerateSeed. Make sure the wolfcrypt/src/random.c is being included with the build. Make sure you have a wc_GenerateSeed function in your random.c or use the CUSTOM_RAND_GENERATE_SEED define to remap it to your own function.

Have you seen our Arduino example for wolfSSL?
https://github.com/wolfSSL/wolfssl/tree … DE/ARDUINO

Thanks,
David Garske, wolfSSL

Hi Jesussotofan,

Your platform must not have a random number seed function defined in random.c (starting at line 1133).

Either you can:
1. Locate a reference implementation in random.c and make sure you have the right define set for your hardware platform / OS.

2. Define CUSTOM_RAND_GENERATE_SEED and use your own implementation:

int rand_gen_seed(byte* output, word32 sz);
#define CUSTOM_RAND_GENERATE_SEED  rand_gen_seed

In your example above, I also recommend:
including:
#include <wolfssl/wolfcrypt/random.h>

Using WC_RNG for the rng global:
WC_RNG rng;

Let me know if you have anymore questions,

Thanks,
David Garske, wolfSSL

Hi Hagai,

That's great you are using wolfMQTT and wolfSSL with Amazon AWS! It would be excellent to get more info on your project by emailing us at info@wolfssl.com when you get a chance.

I've seen an issue like this before and it was due to timezone differences between local time and the time in the cert. The ValidateDate function tries to offset the local time by looking for +/- at the end of the cert begin/end dates.

If you are using the FREESCALE_MQX or FREESCALE_KSDK_MQX defines the asn.c XTIME gets mapped to mqx_time which ends up calling "_time_get". The mqx_time function should be getting the number of seconds since UTC.

You might consider implementing your own XTIME function and by defining "USER_TIME" and adding a new function in your code called XTIME: time_t XTIME(time_t * timer);. Then you can offset the XTIME your timezone diff.

Thanks, David Garske, wolfSSL

Hey Avenuti,

I am able to reproduce the error with normal math and ECC-521 on that board. I was then also able to reproduce on my Mac with 32-bit mode (-m32) and NO_64BIT defined. Happens with or without ECC_TIMING_RESISTANT.

This failure only happens on 32-bit systems with normal math. Until then please use fast math with ECC-521.

For reference the error is:
"ecc_test_curve_size 66 failed!: -1023
ECC      test failed!
error = -1023"

The error is happening inside the "ecc_check_pubkey_order" function, which returns -215 (ECC_INF_E).

We are investigating the cause and will let you know when we have a resolution. Thanks again for the report!

Thanks, David Garske, wolfSSL

Hey Avenuti,

I'll take a look at the TFM_ECC521 define. I personally testing that combination on a Cortex M4 without any issue, but its possible there is an problem with the FP_MAX_BITS_ECC calc on a 32-bit micro with TFM_ECC521. I'll let you know the results of my testing early tomorrow.

In the mean-time did you try it without "FP_MAX_BITS_ECC" defined? You could also try setting "FP_MAX_BITS_ECC" to a larger value like 1200 and see if that helps.

Thanks, David Garske, wolfSSL

Hi Will,

Please check out this webpage for a basic tutorial:
http://learn.perl.org/first_steps/

The script can be run directly and it will update certs_test.h.
./gencertbuf.pl

Thanks,
David Garske, wolfSSL

Hey Hstr,

That's great you figured it out. Thanks for the report and providing the details back for other users as well.

I'm going to make some corrections to the example, since the server and client should not both be using the server-ecc.pem. It works, but its not good practice for both to be using the same private key. I will also include DER versions of these. The server-ecc.pem is a CA and should be used on the client. The server needs to get a new cert signed by that CA. I'll let you know when this has been updated.

For reference the pem to der conversion using openssl is:
openssl x509  -inform pem -in ./certs/server-ecc.pem -outform der -out ./certs/server-ecc.der

In the wolfssl directory we have a script called ./gencertbuf.pl which does the byte array conversion and builds the wolfssl/certs_test.h file.

Thanks, David Garske, wolfSSL

Hi Hstr,

I've added the ECC keys/certs to the certs_test.h on a branch. Still some work to do so the test code uses them in a NO_FILESYSTEM scenario. However if you want to use those as static const byte arrays they are there for you.

https://github.com/dgarske/wolfssl/comm … ec3da4f289

David

Hi Hstr,

You'll also need to define HAVE_TLS_EXTENSIONS and HAVE_SUPPORTED_CURVES. Also you won't need to define "BUILD_TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256" as that is done automatically in internal.h when ECC, AES-GCM and SHA256 are enabled.

I see what you mean about the ecc-key and ecc-cert not being in the certs_test.h file. I'll see about getting that updated. Thanks for bringing that to our attention.

Thanks,
David Garske

Hey Jrandombob,

Its possible the compiler/libc you are using requires an aligned pointer, but that is not typical. A memcpy function is super simple and can sometimes be optimized for 32-bit CPU's to copy int by int, vs. byte by byte.

Which compiler and libc are you using? What are your hard fault registers values telling you? https://community.arm.com/thread/5414

If this memory you are writing to comes from an alloc have you verified its a valid, usable address? Is it just memcpy or is it affecting other libc functions?

David