Re: avr-crypto-lib
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 bg a écrit : > >>> 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. > > 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 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 additions of C99 to avoid issues with heap > allocation, but they bring some problems of their own. > > 5) You may find https://munacl.cryptojedi.org/atmega.shtml > helpful. > > I hope to find some spare time to get some stuff better documented > and improved (or remove what can't be fixed). > > For short: I doubt that RSA on an AVR could be brought to a > productive use (maybe except for some cases where you are willing > to wait minutes). My application only uses encryption the first time firmware is booted. After this first encryption, it only call decrypt functions. I have obtained the same results with uECC and AES. Best regards, JKB -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEq4YCoAJMwLElZVYXOAfo0lKQ8+cFAmC2Xv0ACgkQOAfo0lKQ 8+cwvw//dCMp09LO+euPjdj2qzzUCrAqwGOLtsHCIXTr/alDToUZlyhSsrs0/qxH 0COXBtu+GEB/mYbhGRR5p37IOjUtw9nMlPcZ+rnYum7mTIQBPHHRFrWHQBLlv4zD iO5ZfIWQF+u6d4miR0DniSUGA30wQTVlEi+d6YSgT5JKwRFlBo0PGvOk6ZcAg6Yo /UCb1Rn37Ga6MuSdNG2oRF9B1xXPoDulv29DyK5/RYhWXqnz2JJ2pe6RK+NmN6Ky /dP0b0dfTDRb2FdgMdEAgGDcssxd3j/E4kPDEDqcF4XBOMDQ65UF2RbkOZ4JxV3A SDffrgmheA6ckiUnbRxmXaq1mnT7KfD5B5TdbKYqeH+AU7gaAHoRvLvXuIbQoLxZ Xhr6LRnXsQVQwhWMhfkVdsy70d6HHGYhDTGF3cMVDTKozS3vv4r9jDv2RK9TIYGW k8afjuoM8O55wGr98j4dx3XbQD+ypcOStNiESq70fTUXzTQtxZWK/LgFxErpbcll ciw7horFt/mY9/USeIpD6xoI4PVXYq3XiIkBUvVAdkgabkQuHPpieKshSm7du8Ue 8jMF41GZAAiGhJrnfpClIfFMpFc+p3omjHlmMLRDQ0Vzo66IKuKUpE+GXIDO5z2r 5+PayqreQ6m8KCOmNWFFpzfg+a7O+iLPcO2z+jFbd/mDFBW+9I8= =9n8c -END PGP SIGNATURE-
Re: avr-crypto-lib
>> 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. 1) Sorry for 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 additions of C99 to avoid issues with heap allocation, but they bring some problems of their own. 5) You may find https://munacl.cryptojedi.org/atmega.shtml helpful. I hope to find some spare time to get some stuff better documented and improved (or remove what can't be fixed). For short: I doubt that RSA on an AVR could be brought to a productive use (maybe except for some cases where you are willing to wait minutes). Best regards, ~ bg -- bg nerilex Daniel Otte E-Mail: b...@nerilex.org XMPP/Jabber: b...@nerilex.org Matrix: @bg:nerilex.org Mastodon: https://chaos.social/@bg Phone: +49-152-03012876 Fingerprint: CB4E 915F ACAD EEC2 0D34 D266 2978 788D 0DB2 E18E OpenPGP_signature Description: OpenPGP digital signature
Re: avr-crypto-lib
wt., 1 cze 2021 o 08:37 BERTRAND Joël napisał(a): > 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. > try to replace in the example above: /* add your fix here */ with: bigint_adjust(); bigint_adjust(>exponent); bigint_adjust(>modulus); The computation takes 4 seconds on my laptop. Note that the "I" value changes (from I=0.. to): BIGINT: 0x40f5.. 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 found a uECC library but I don't understand how use this library > to encrypt data (I think I have understand how I can sign data). > > Best regards, > > JB >
Re: avr-crypto-lib
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 understand how use this library to encrypt data (I think I have understand how I can sign data). Best regards, JB
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
Re: avr-crypto-lib
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 causes a memory corruption.
>
If you know where you bug is, try to reduce your code to the bare minimum,
example:
#include "rsa_basic.h"
extern rsa_publickey_t *public;
#define BIGGER_THEN_RSA_KEY_MODULUS 300
int main() {
char str[BIGGER_THEN_RSA_KEY_MODULUS] = "This is a test";
stty_print("Hi!\n");
rsa_clef_publique(); //even this is too much, you should set "public"
directly
bigint_t data = { .length_W = strlen(str),
.info = 0, //?? make sure you know how to set this!!! (for all bigint_t)
.wordv = str};
/* add your fix here */
stty_print("data:\n");
stty_print_bigint();
stty_print_public(public);
rsa_enc(, public);
stty_print("encrypted:\n");
stty_print_bigint();
stty_print("Done\n");
}
> buffer overflow somewhere without success. Is there a tool like electric
> fence to find memory corruption on avr ?
That's a good question, unfortunately I don't know the answer,
but in your case you could use "simavr" (avr simulator) for
testing/debugging,
simavr output should look like this (for the code above, after fixing your
bug):
firmware-antivol$ simavr -t -vv --mcu atmega1284 --freq 800
firmware.elf
Loaded 113450 .text at address 0x0
Loaded 2316 .data
Loaded 3200 .eeprom
Hi!.
data:.
BIGINT: 0x40f5..
L=14..
I=6..
54 68 69 73 20 69 73 20 61 20 74 65 73 74 ..
..
RSA public key: 0xe89..
BIGINT: 0xe89..
L=3..
I=0..
01 00 01 ..
..
BIGINT: 0xe8e..
L=256..
I=7..
89 39 71 6D 12 88 0F DF 7F 7E 30 B2 97 B4 64 36..
F6 6A 97 58 F7 97 9C 6B BC CD 76 01 4F 7D 4B AF..
74 3C 76 4A B8 88 A3 BE 64 56 11 51 36 A4 EE 0C..
ED B3 34 FA EE 5E D8 28 0B 60 F3 E1 F8 29 C1 C5..
52 6E 97 73 B8 71 BF 0C F4 D8 E9 73 DC E1 3A 10..
1B 27 24 8A 19 53 FB 41 31 FA 08 3E DE 3E 52 B6..
7A ED CF DE A2 38 BF 04 C8 F1 71 C0 B4 9E CC 19..
2D E4 39 36 E3 FB 81 CC 6B 19 7D F2 2E 23 87 10..
6D 91 74 9B AD D6 FF 23 AF DB B7 8F 18 E3 AC 9F..
38 4B 34 26 7D 1A B5 74 BC 6E 15 2A 98 E5 F1 D3..
20 A0 3B C0 90 A4 56 AC 10 26 2F EC B8 6A B6 DB..
F9 56 56 49 21 13 1D 22 3A 1D 09 7C 54 7E 86 F3..
0A EC 5A B4 ED A3 01 8A FD 8D AB 5B E6 9F D1 24..
38 FD 3B 92 DB 3C 93 60 70 D9 9B 7D 37 70 40 60..
22 75 3C 53 F3 55 F5 C1 D5 8A DC DB 00 DD 70 5A..
3B 2A 3E AA 52 0E C2 B8 69 AF EE 22 B1 23 E9 D3..
encrypted:.
BIGINT: 0x40f5..
L=256..
I=7..
37 B2 E9 51 35 58 4E DA A4 D6 B2 B8 B3 6A F6 38..
CE C6 23 54 5B 6C 95 D9 59 78 1E A4 0B 1A C8 2F..
96 93 18 95 11 88 9D 98 03 E6 32 6D 79 7B AE 0C..
E8 0F 3A 9E 3F DF B7 72 C8 AC E2 38 D7 42 63 E1..
32 57 2A 1A 06 C7 39 36 AF FE 47 C7 D5 A6 B5 E8..
E1 CB 04 B8 9C C3 1F B4 13 65 26 6C 8F 4A A5 F6..
70 45 B9 96 A7 7E C5 17 A7 70 BE 58 B0 D3 55 A8..
AD 56 5B 8B DE A0 8A 24 EB 3D F2 EF B8 B5 59 05..
F8 1D 3F FE C1 E5 96 EE 69 54 D4 7B 6C 38 EE 60..
81 74 34 A4 12 93 94 66 47 48 DE D0 5B 74 B4 5E..
1D B5 88 F6 7A FE CE 78 CB C7 42 97 D2 06 43 FF..
67 97 BB 92 3B 4B 77 12 D8 1E DA DD F2 8C D4 1C..
DE 25 38 CD 35 60 A9 25 12 1C B0 67 95 DF 38 B6..
4D 00 14 FD EB 1C 06 14 20 70 70 8E 08 42 13 94..
72 FA AE 3B 3A 82 B8 7D FA 21 F2 69 82 C9 AB D2..
46 34 F8 21 50 0B 29 EB E6 6E B6 53 38 09 9D 87..
Done.
Note 1. I didn't initialize the serial, simavr doesn't care
Note 2. I had to fix firmware.h:322:
- unsigned char reserve[0x0200 - 34];
+ unsigned char reserve[0x0200 - 36];
Note 3. ".eeprom" section is in firmware.elf (where it probably should be)
Note 4. you can also debug the simavr simulation with avr-gdb:
firmware-antivol$ simavr -t -vv --mcu atmega1284 --freq
800 firmware.elf -g
(in second terminal)
firmware-antivol$ avr-gdb firmware.elf -ex 'target remote
:1234'
good luck with debugging!
--
some afterthoughts after seeing your code:
* for debugging it's a good practice to compile your code with '-g -O0'
flags, your makefiles should have one place where I could set/change this
(consider using CFLAGS)
* consider replacing: (*it).luminosite with: it->luminosite (it's much
easier to read, at least for me)
* should you use malloc? the best answer to this is: google "avr malloc"
* should you use VLA's (variable length arrays, this: "bigint_word_t
d_b[a->length_W + b->length_W]") normally I would say definitely yes,
but you probably will use your multitasking library at some point (I'm
not sure if multitasking on avr is a good idea, but I'm old ;) ) so bear in
mind that you will have to fine tune stack sizes for each thread.
* should you use static allocated memory: definitely yes, whenever it's
possible (on small CPUs)
* consider adding to your makefile (it's sometimes helpful): avr-size
--format=avr --mcu=atmega1284 firmware.elf
* don't do this: eeprom_read_byte((const uint8_t *) (0x0200 + i));
do this instead: eeprom_read_byte((uint8_t
Re: avr-crypto-lib
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.
Re: avr-crypto-lib
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
Re: avr-crypto-lib
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. David
Re: avr-crypto-lib
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. Best regards, JKB
Re: avr-crypto-lib
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. -- Nigel On Fri, 28 May 2021 at 18:24, BERTRAND Joël wrote: > 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 (2048) on > a workstation with openssl and I write this key in EEPROM. > > My code reads public key from EEPROM and converts inernal > pointers. It > sends this key on serial console after it has converted EEPROM data into > rsa_publickey_t struct: > > RSA public key: 0xde1 <- address of exponent > BIGINT: 0xde1 > L=3 > I=0 > 01 00 01 > > BIGINT: 0xde6 <- address of modulus > L=256 > I=0 > FD 90 D5 83 32 44 55 07 5E AE F1 EF D5 64 4C EB > EC F1 51 C9 39 BC 78 AE 07 4F 34 95 FA 9D 04 64 > FF 7D 2F 5A CD 43 33 BE FD 69 29 0B 2B 3C 92 34 > 0D B2 E0 A0 E6 46 B6 B0 B0 58 95 2C D8 00 9F 8A > D3 C5 07 83 91 83 2B 04 71 AA 01 15 D2 C4 CF 7C > 9A 17 46 20 7B 17 EE 4E 79 5B 9D C0 35 6E B7 89 > F8 39 7C 06 95 DA 15 5A AB 2C 0F FD 4F 56 01 EE > EB 47 90 DA 7A 7F BE A3 05 20 AF 5B B4 4D 92 BA > BB B2 8D EB 1B 0C 18 5E 1D 78 3D AC 8F EB 0E 91 > 2A 89 B3 40 EF D8 13 A7 DA 3B 9C C4 F7 19 A5 BE > E5 9B C7 D2 A1 D0 16 9E A6 8D B6 A2 A1 B0 BC CD > 9B CE E0 6A 63 9E B0 C4 81 1A D4 3A EA 0E B7 50 > CC 49 8A F2 1C 60 A2 01 75 27 DE 20 FA 91 B4 FA > 41 0D 0F 66 21 E8 33 22 28 E9 F8 9F DA A9 D8 58 > BB 10 98 A3 6E CF B6 41 15 72 1B 10 0A D4 E1 D4 > 9C FA 8E 52 75 D2 2C 9B C9 2C CA 7F 3C C7 4A 9B > > Value written on serial console is expected value (I have the same > value in eeprom.hex file). > > Now, I want to use rsa_enc() function. This function waits for a > bigint_t. No problem, I create a bigint_t with my message: > > BIGINT: 0x3f62 <- address on stack > L=16 > I=0 > E6 4C E7 31 3D 1C 48 D0 5F 5C 2B 73 8A 5D 64 3E > > But when rsa_enc() is called, firmware crashes. I have searched a > buffer overflow somewhere without success. Is there a tool like electric > fence to find memory corruption on avr ? > > My firmware is downlodable at > https://hilbert.systella.fr/public/firmware-antivol.tar.gz > > Best regards, > > JB > >
