>> doesn't return to main routine. Something is probably broken
>>> somewhere.
>
> 1) Sorry for the delayed reply.
You're welcome.
> 2) I'm somewhat lacking the time to improve and document
> avr-crypto-lib (this also caused item 1)
>
> 3) RSA was newer re
or the delayed reply.
2) I'm somewhat lacking the time to improve and document avr-crypto-lib (this
also caused item 1)
3) RSA was newer really stable, or of useable speed (even with 1024 bit keys).
Also the current implementation is lacking some important optimizations.
4) I used the VLA a
40f5..
L=14..
I=6..
I've tried to find a "HOWTO use avr-crypto-lib" documentation,
but I couldn't find any, which is a little worrying (maybe I didn't try
hard enough).
If there is no documentation reading the source code and test code is an
option.
>
> I have foun
RSA doesn't run as expected. With expopent=3 and length=512, program
doesn't crash but after four hours (@ 16 MHz on simavr), gdb shows that
program stays in RSA subroutines and doesn't return to main routine.
Something is probably broken somewhere.
I have found a uECC library but I don't
c 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 en
pt., 28 maj 2021 o 19:23 BERTRAND Joël
napisał(a):
> Hello,
>
> I beg your pardon as my question is not related to gcc itself.
>
> I have added to my firmware a subset of avr-crypto-lib (AES and
> RSA).
> If AES128/192/256 run as expected, RSA cause
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
k 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
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
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
.
>
> I have added to my firmware a subset of avr-crypto-lib (AES and
> RSA).
> If AES128/192/256 run as expected, RSA causes a memory corruption.
> Of course, I don't generate RSA key on AVR. I create this key (2048) on
> a workstation with openssl and I write this key in
Hello,
I beg your pardon as my question is not related to gcc itself.
I have added to my firmware a subset of avr-crypto-lib (AES and RSA).
If AES128/192/256 run as expected, RSA causes a memory corruption.
Of course, I don't generate RSA key on AVR. I create this key
12 matches
Mail list logo
