Re: avr-crypto-lib

W dniu 29.05.2021 o 20:37, David Brown pisze:
> 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.
>
>
  To OP:

there was (is?) a project for AVR named "OpenCryptoToken", using 
Elliptic Curve cryptography.

Size and execution time "acceptable" on AVR.

Maybe this would fit better than RSA?


Laurent