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.
