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

Thanks, David Garske, wolfSSL

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

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

I also tested various permutations of enabling/disabling the following:
FP_MAX_BITS_ECC (disabled or enabled with a few different sizes, as you suggested)
TFM_ASM
TFM_TIMING_RESISTANT
TFM_ECC521
ECC_TIMING_RESISTANT

None seemed to have an effect on success or failure, it always came down to: failure with USE_FAST_MATH disabled, success with it enabled.

Also, another question: what are any advantages/disadvantages/tradeoffs in using ALT_ECC_SIZE? Enabling/disabling this didn't seem to affect either code size or performance times.

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

However, while testing performance/optimization, I rebuilt after disabling TFM. Running the test once again gives a -1023 error.

After I first pulled 3.9.8 I thought I successfully ran it with and without TFM. Since then I've updated the chip library from LPCopen 2.12 to 2.18, so maybe this is causing some issue? (I could go back and double check on 2.12 but downgrading would be a pain)

Edit: I tried disabling just TFM_ECC521 (as opposed to disabling USE_FAST_MATH, ALT_ECC_SIZE, and every TFM_ entry), and the test worked. Maybe I just missed one of the related #defines?

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

ECC_SHAMIR was already enabled by default in the IDE/LPCXPRESSO user_settings file.
ECC_TIMING_RESSISTANT was not defined; adding this in had no effect (default curve success, P-521 curve failure).
TFM_ECC521 was also not defined; adding this in caused a different failure, even with the default curve:

From inside test_ecc, the failure occurred here, with output -1024:

    ret = wc_ecc_check_key(&userA);
    if (ret != 0)
        return -1024;

Here is where the failure occurs inside wc_ecc_check_key (err returns -1):

    /* make sure point is actually on curve */
    if (err == MP_OKAY)
        err = ecc_is_point(key->dp, &key->pubkey, &prime);

I'll look into trying out 3.9.8.

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

I'm able to build and run the wolf_example project in the IDE/LPCXPRESSO directory. Running the test with default settings is a success, but if I attempt to add in support for the P-521 curve (#define HAVE_ECC521 in user_settings.h) the test fails, with error code -1023.

Separate from the wolf_example project, I've also tested wolfCrypt within my own project by including just the necessary .c and .h files for the functions I need. I've done a bit of digging to figure out exactly where the error occurs:

Hash verification fails at line 2469 of ecc.c

2467   /* does v == r */
2468   if (err == MP_OKAY) {
2469       if (mp_cmp(&v, r) == MP_EQ)
2470           *stat = 1;
2471   }

This happens within line 6261 of test.c, causing the return at 6266

6261    ret = wc_ecc_verify_hash(sig, x, (byte*)vector->msg, (word32)vector->msgLen, &verify, userA);
6262    if (ret != 0)
6263        return -1021;
6264
6265    if (verify != 1)
6266        return -1023;

which is called within line 6598 of test.c

6597        ecc521.curveName = "nistp521";
6598        ret = ecc_test_raw_vector(&ecc521, &userA, sig, sizeof(sig));
6599        if (ret < 0) {
6600            return ret;
6601        }

To utilize the P-521 curve, are the additional steps needed besides defining HAVE_ECC521?
If not, what else might be causing this issue?