1 Reply by den2k

(4 replies, posted in wolfCrypt)

embhorn wrote:

Hi den2k,

I think this level of effort will need a proper feature request. I can help you get started if you can send an email to support@wolfssl.com

Thanks,
Eric

I will see if I can manage to stay in the boundaries first, I am quite in a rush and new features + a new version will definitely push me over my deadline.

Thanks a lot for the support!

Go to forum: wolfCrypt

2 Reply by den2k

(4 replies, posted in wolfCrypt)

Hi, thanks for the welcome!

The project is a firmware updater, it has to reside in the code area dedicated to the bootlloader (currently 32k, I could get to 36 but I will try not to because it would break compatibility with our older application binaries). Due to customer request we have to implement SHA256 and RSA3072 to sign the application binary and AES-CMAC128 for escalating security levels.

The compiler is Armcc5 - can't move to ArmClang for compatibility and validation reasons.

Here are all the compilation options:

#define WOLFSSL_SP_SMALL
#define WOLFSSL_SP_LOW_MEM
#define WOLFSSL_SP_NO_2048
#define NO_AES_192
#define NO_AES_256   
#define RSA_LOW_MEM
#define USE_SLOW_SHA256
#define WOLFSSL_RSA_PUBLIC_ONLY
#define WOLFSSL_RSA_VERIFY_ONLY
#define WOLFSSL_RSA_VERIFY_INLINE
#define WC_NO_HARDEN
#define TFM_TIMING_RESISTANT
#define ECC_TIMING_RESISTANT
#define NO_AES_DECRYPT

#define NO_HASHDRBG
#define WOLFSSL_CMAC
#define WOLFSSL_AES_DIRECT
#define WOLFSSL_AES_SMALL_TABLES

#define WOLFCRYPT_ONLY
#define WOLFSSL_NO_SOCK
#define NO_ASN_TIME
#define NO_SESSION_CACHE
#define NO_STDIO_FILESYSTEM
#define WOLFSSL_NO_FENCE
#define NO_MAIN_DRIVER
#define SIZEOF_LONG_LONG 8
#define NO_WRITEV
#define NO_DEV_RANDOM
#define WOLFSSL_IGNORE_FILE_WARN
#define USE_WOLFSSL_MEMORY
#define WOLFSSL_TRACK_MEMORY

I initially wished to use only static memory for safety and MISRA reasons but the stack usage would have exceeded the total available RAM on the chip!!! It went ot 0x84-- bytes, 33kB only for the stack.

The MCU specs are:
- 128 kB flash + 12 kB data flash
- 32 kB RAM
- ARM Cortex M4F @ 100 Mhz

Consider it is by far the most powerful MCU we have available, we usually range from 3 to 8 kB of RAM, 32 to 72 kB of flash and 40 Mhz M3 CPU.

Now I manage to have the preexisting comms and update features in 14kB of Flash, the required WolfCrypt features + 2 hardcoded public keys in another 15 kB, leaving me with about 3.6 kB for the additional code I will need (shouldn't be a problem).

As for RAM, I have the following reservations
* 20 kB HEAP
*** 7 kB is the tracked max usage for RSA functions
*** 12 kB are needed for shadowing
*** 1 kB is there for the various sovrastructures
* 2 kB stack (tracked max usage is 0x600 bytes, aka 1.5kB
* 6 kB used by previous code
* 1 kB reserved as UNINIT

Now if I can cut the RAM space used by the RsaKey by ~700 bytes it would give me a lot more breathing room.

Go to forum: wolfCrypt

3 Topic by den2k

(4 replies, posted in wolfCrypt)

Hello everyone, I am using WolfCrypt on a very limited bare metal microcontroller and I need to use RSA3072 due to customer request.

Using the sp math library I get the smallest flash footprint but the RsaKey structure weighs 1572 bytes (as per sizeof()). I checked the struct and saw that the exponent is defined as mp_int, which becomes an sp_int, which is always an array of 193 32-bit words. That's 772 bytes when e->used is always 1.

struct RsaKey {
    mp_int n, e;
    //...

Is it necessary to have so much space dedicated to the exponent?

Just to add a bit of context, I am working on  a system with 32 kB of RAM, which is already huge (normally we use 3 or 6 kB chips) and with the other requirements of the piece of software I am writing I am down to only 3624 bytes of available RAM.

Go to forum: wolfCrypt