Re: avr-crypto-lib

[BERTRAND Joël]

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.

        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.

        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.

        Regards,

        JB