426 Reply by dgarske

(1 replies, posted in wolfCrypt)

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

Go to forum: wolfCrypt

427 Reply by dgarske

(9 replies, posted in wolfCrypt)

Hey Avenuti,

A fix for this issue has been pushed to GitHub PR#535:
https://github.com/wolfSSL/wolfssl/pull/535

Thanks, David Garske, wolfSSL

Go to forum: wolfCrypt

428 Reply by dgarske

(9 replies, posted in wolfCrypt)

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

Go to forum: wolfCrypt

429 Reply by dgarske

(9 replies, posted in wolfCrypt)

Hey Avenuti,

Sorry about the confusion. I thought you meant it wasn't working with USE_FAST_MATH.

The most common reason for a failure with normal math is that it uses heap allocations for the big integers. If you want to get normal math working I'd recommend increasing your heap size and trying again.

With USE_FAST_MATH disabled none of the options listed above are used except "ECC_TIMING_RESISTANT". That's because TFM_ and FP_MAX_BITS_ECC are only used with fast math.

The fast math uses stack for its allocations while normal math uses heap. The fast math tends to be faster because there is no heap allocation/free overhead.

The "ALT_ECC_SIZE" will save memory if using RSA and ECC because it will use heap allocations of a reduced size for ECC points, but only works when used with USE_FAST_MATH.

I'll run some tests this week and see if I can locate any issues using normal math and ECC-521. I have an LPC1837 board here to test with and see if I can reproduce.

Thanks, David Garske, wolfSSL

Go to forum: wolfCrypt

430 Reply by dgarske

(9 replies, posted in wolfCrypt)

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

Go to forum: wolfCrypt

431 Reply by dgarske

(6 replies, posted in wolfSSL)

Hi Will,

You can see an example of how I added DER's for ECC certs/keys here:
https://github.com/dgarske/wolfssl/comm … ec3da4f289

If you are looking for a good tool to view/convert binary I like "Hex Fiend", but its for the Mac only.
Here is a good list of hex tools: https://en.wikipedia.org/wiki/Comparison_of_hex_editors

David

Go to forum: wolfSSL

432 Reply by dgarske

(6 replies, posted in 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

Go to forum: wolfSSL

433 Reply by dgarske

(6 replies, posted in wolfSSL)

Hi will,

I recently had a forum topic on this exact issue.
https://www.wolfssl.com/forums/topic836 … ha256.html

If you still have questions let me know and I'll provide additional details.

Thanks, David Garske, wolfSSL

Go to forum: wolfSSL

434 Reply by dgarske

(5 replies, posted in 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

Go to forum: wolfSSL

435 Reply by dgarske

(4 replies, posted in wolfCrypt)

Hi Hyunbum83,

It looks like we support encrypting an ECC private key using the API "wolfSSL_PEM_write_mem_ECPrivateKey". However this is an openssl compatibility API layer, so you'll have to setup a "WOLFSSL_EC_KEY" object using "wolfSSL_EC_KEY_new()" and load it using "wolfSSL_EC_KEY_LoadDer".

I'm going to add a feature request to expose this without opensslextra. Curious what you are working on that requires this? It will help us prioritize this feature if we have some background on what you are working on.

Note: Using "wolfSSL_PEM_write_mem_ECPrivateKey" requires having --enable-keygen --enable-opensslextra (or WOLFSSL_KEY_GEN and OPENSSL_EXTRA defined).

Thanks,
David Garske, wolfSSL

Go to forum: wolfCrypt

436 Reply by dgarske

(5 replies, posted in 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

Go to forum: wolfSSL

437 Reply by dgarske

(4 replies, posted in wolfCrypt)

Hi Hyunbum83,

Have a look at this article we posted a while back:
https://www.wolfssl.com/wolfSSL/Blog/En … ation.html

We support this using "wc_PKCS12_PBKDF". Enabled using ./configure --enable-pwdbased or making sure NO_PWDBASED is not defined.

Let me know if this doesn't answer your question.

Thanks, David Garske, wolfSSL

Go to forum: wolfCrypt

438 Reply by dgarske

(5 replies, posted in wolfSSL)

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

Go to forum: wolfSSL

439 Reply by dgarske

(9 replies, posted in wolfCrypt)

Hey Avenuti,

Updating to lastest wolfSSL will resolve this. There were numerous fixes with ECC math back on May 4th that resolve the ecc_is_point check for ECC 521. If you have ALT_ECC_SIZE defined you'll want to make sure FP_MAX_BITS_ECC is set high enough (like 1088). If you update to the latest you can not define FP_MAX_BITS_ECC and let the tfm.h header handle it.

David

Go to forum: wolfCrypt

440 Reply by dgarske

(2 replies, posted in wolfCrypt)

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

Go to forum: wolfCrypt

441 Reply by dgarske

(1 replies, posted in wolfCrypt)

Hey Comomind,

The smallest wolfCrypt only ECC and SHA256/SHA512 can get is about 15K flash and 1K ram. That's because of the math required for ECC.

Typically the library is configured two ways:
1. Using automake and ./configure
2. Defining WOLFSSL_USER_SETTINGS and adding your own user_settings.h file.

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

Things you'll need to change from that example are:
1. Add "WOLFCRYPT_ONLY" to disable the TLS/SSL code. (or use ./configure --enable-cryptonly).
2. Remove HAVE_ECC192, HAVE_ECC224, HAVE_ECC384 and HAVE_ECC521 (so you are left with only the 256-bit curves).
3. Remove TFM_ECC192, TFM_ECC224, TFM_ECC384 and TFM_ECC521
4. Turn off RSA change line 101 to #if 0 (./configure --disable-rsa)
5. Turn off AES change line 117 to #if 0 (./configure --disable-aes)
6. Turn off ChaCha/Poly (./configure --disable-chacha --disable-poly1305)
7. Turn off hashing for Sah1. (./configure --disable-sha)
8. Turn off MD5 (./configure --disable-md5)
9. To adjust size vs. performance play with ECC_SHAMIR, ECC_TIMING_RESISTANT and TFM_TIMING_RESISTANT.
10. If you are only doing an ECC verify you can define the following to disable portions of the ECC code: "NO_ECC_SIGN", "NO_ECC_DHE" and "NO_ECC_KEY_EXPORT".

David

Go to forum: wolfCrypt

442 Reply by dgarske

(9 replies, posted in wolfCrypt)

Hello Avenuti,

Thanks for the detailed question.

It looks like you are not using the latest v3.9.8 wolfSSL release. There have been a few fixes/changes in that area of ECC vector testing. I've seen this error and believe you can workaround it without an update by defining ECC_SHAMIR. I do recommend you update if you can.

For your NXP LPC1837 micro I would recommend the following settings:
#define USE_FAST_MATH
#define TFM_TIMING_RESISTANT
#define TFM_ARM (or TFM_ASM if that one fails)

#define HAVE_ECC
#define ECC_USER_CURVES
#define HAVE_ECC521
#define ECC_SHAMIR
#define ECC_TIMING_RESISTANT

#define ALT_ECC_SIZE
#define TFM_ECC521

For additional details on these and a good example of a user_settings.h configuration file see here:
https://github.com/wolfSSL/wolfssl/blob … settings.h

Thanks and let me know if that resolves your failure.

David Garske

Go to forum: wolfCrypt