Hello Nikos,

First of all, I think you should use the function wc_ecc_verify_hash_ex() https://www.wolfssl.com/documentation/m … fy_hash_ex. This would eliminate the need for converting the signature from raw (R,S) format to signature, and also make the code smaller. signature.c and asn.c should not be needed in your build if you stick to the APIs in ecc.h instead.

To create the "mp_int" object to import the R,S components in the format expected by this call, you could do the following:

            mp_int mp_r, mp_s;
            mp_init(&mp_r);
            mp_init(&mp_s);
            mp_read_unsigned_bin(&mp_r, r, sizeof(r));
            mp_read_unsigned_bin(&mp_s, s,  sizeof(s));

Very important: before using your ecc_pubkey structure to import the key, you must initialize it:

    eccret = wc_ecc_init(&ecc_pubkey);

Your import call then looks fine as is:

// Import the key buffer to the ecc_key structure format
    eccret = wc_ecc_import_unsigned(&ecc_pubkey, pubkeyX, pubkeyY, NULL, ECC_SECP256R1);

Then finally you can call the correct verify function as:

          eccret = wc_ecc_verify_hash_ex(&mp_r, &mp_s, hash_data, hash_len, &result, &eccpubkey);

If all goes as expected, eccret should be zero and result should be 1, indicating successful verification.

Another thing I have noticed in your configuration: the SP assembly optimizations don't match your current MCU. Cortex-M0 is ARMv6-M and we do provide thumb instructions optimization for it. I suggest you remove the option WOLFSSL_SP_ARM_CORTEX_M_ASM and use WOLFSSL_SP_ARM_THUMB_ASM instead. Also the correct assembly file for Cortex-M0 is sp_armthumb.c if you are compiling with options "-mcortex-m0 -mthumb" as expected for this MCU. The sp_cortexm.c source file contains assembly optimizations for Cortex-M3 and later (up to newer ARMv8-M).

I would also recommend to add the option WOLFSSL_HAVE_SP_ECC to ensure ecc is using those optimizations.

Furthermore, since you are defining WOLFSSL_NO_MALLOC, I expect that you don't have/don't want to use dynamic allocation. In this case, in combination with SP_MATH, I would also suggest the following:

#define WOLFSSL_SP_NO_MALLOC
#define WOLFSSL_SP_NO_DYN_STACK

I hope this helps. Please let us know if you are still experiencing issues after the suggested fixes.

Thanks,
Daniele @wolfSSL Support

Hello again,

I managed to increase the heap needed so the verification runs correctly!
Now I am trying to optimize for code size. Thank you again for your quick and detailed support!
Do you have any tips on further optimizing for code size?
Thank you again and have a nice weekend!
Kind Regards,
Nikos

P.S my latest configuration

#define HAVE_ECC
#define HAVE_ECC_VERIFY
#define ECC_USER_CURVES

#define NO_RSA
#define SINGLE_THREADED
#define NO_MD5
#define NO_OLD_TLS
#define WOLFSSL_NO_PEM
#define WC_NO_RNG
#define NO_ECC_SIGN
#define NO_DSA
#define NO_ASN_TIME
#define NO_PWDBASED
#define NO_ASN
#define NO_ECC_KEY_EXPORT
#define WOLFCRYPT_ONLY
#define WC_NO_HARDEN
#define SIZEOF_LONG 4
#define SIZEOF_LONG_LONG 8
#define NO_FILESYSTEM

#define WOLFSSL_SMALL_STACK
#include "stdlib.h"
#define XMALLOC_OVERRIDE
#define XMALLOC(n, h, t)        malloc(n)
#define XREALLOC(p, n, h, t)    realloc(p, n)
#define XFREE(p, h, t)          free(p)

// SP_MATH_CONFIG
#define WOLFSSL_SP_MATH
#define WOLFSSL_HAVE_SP_DH
#define WOLFSSL_SP_SMALL
#define WOLFSSL_HAVE_SP_ECC
#define WOLFSSL_SP_ARM_THUMB_ASM

> FYI what I am actually trying to do is checking if I can implement a secure bootloader with wolfssl.

We already have that! Check out wolfBoot:

https://github.com/wolfSSL/wolfBoot

It's fully featured and highly portable, you can see we already support some M0's like the STM32L073, the Atmel/Microchip SAM-R21 and Cypress PSOC6.

For your reference about the code size, wolfBoot ECC256+SHA256 on STM32L0 is ~ 18KB in size including crypto, down to ~16KB without assembly optimizations, ~14KB if using ED25519 and SHA384, and even a little smaller if using LMS (post quantum crypto algorithms).

Thanks,

--
Daniele @wolfSSL Support