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.