Re: avr-crypto-lib

[David Brown]

On 29/05/2021 18:45, BERTRAND Joël wrote:
> David Brown a écrit :
>> On 29/05/2021 14:37, BERTRAND Joël wrote:
>>> Nigel Winterbottom a écrit :
>>>> I took a quick look and attempted to compile your Crypto library in
>>>> Visual Studio.
>>>>
>>>> I got nowhere: Probably for good reasons; Microsoft C doesn't allow
>>>> dynamic array size like this:
>>>>
>>>>   bigint_word_t d_b[a->length_W + b->length_W];
>>>>
>>>> This is about as far as I'm going to get on this, there is just far too
>>>> much work to get it to compile to run on the Desktop.
>>>> Wouldn't it be funny if thiat line was the reason for your crash.
>>>
>>>     Do you think I have to replace these allocations by malloc()/free() or
>>> alloca() ? I haven't written theses routines, but I can try to fix them.
>>> But I would be sure my issue comes from this kind of allocation.
>>>
>>
>> A VLA like the one above is fine when using a decent C compiler - which
>> MSVC is not.  (It's an okay C++ compiler, but has traditionally failed
>> to support C99.  I gather it's a bit better with the most recent
>> versions, but it still has its own silly ideas about some features and
>> library functions.)
>>
>> You do have to be aware that a VLA like this gets allocated on the data
>> stack.  If you are using an RTOS and have limited stack size, that can
>> quickly be an issue.  (alloca also allocates on the stack.)
>>
>> If you can, you should try to allocate this array statically, using a
>> maximum size for the array.  That gives you a much clearer idea of the
>> sizes you need, and whether or not you have space for everything on the
>> device.  It avoids run-time complications or allocation failures, and
>> the risk of memory fragmentation (malloc/free should be avoided in
>> embedded systems whenever possible).  And it will be noticeably more
>> efficient on an AVR.
> 
>       OK. If I understand, in my case, this code should run as expected as
> gcc is C99 compliant.

AFAIK VLA's will work fine (though less efficiently than a statically
allocated array).

> 
>       If I check pointers, I see that high value returned by malloc() (I use
> malloc() to allocate private and public keys for some reasons) is 0xde6.
> Thus heap ends at 0xde6+0xff+0x2. Current stack is about 0x3f62.
> 

Try to avoid any kind of malloc() in all code on an AVR.

>       Only two solutions : avr-crypto-lib is broken or I have done a mistake
> in my code... And I think I have a bug in this code.
> 
>       RSA encoding computes (code word**65537)%modulus if I remember. Length
> of codeword is 256 bytes. I suppose (code word**65537) cannot be saved
> in available RAM. I will check next monday with exponent=3.
> 

The operation "(x ** y) % z" is done as a combined calculation, not by
calculating "(x ** y)" and then reducing it modulo "z".  Basically, you
do "x = code_word;" then "x = (x ** 2) % modulus;" 16 times, and finally
"x = (x * code_word) % modulus;".  Even then, it still takes a fair
amount of working ram for an AVR, and quite a bit of processing time.

Such encryption can work on an AVR that is big enough, but it is not a
good fit for a microcontroller of that kind.