Andy Polyakov

BTW, how did you compile it exactly? Do you use say Rust bindings or make raw C calls?

> I just added server.c to a Keil project. Question is what was the optimization level. A possible pitfall is that assembler-assisted ECDSA won't be that dependent on optimization level,...

> `./build.sh CROSS_COMPILE=arm-none-eabi- -ffreestanding` Hmm, gcc leaves reference to memset (**without** us calling it) and __aeabi_uidivmod. `./build.sh CC=clang --target=arm-none-eabi -ffreestanding` is another option. This still leaves reference to __aeabi_uidivmod, which...

Oh! And of course you'd need to throw in `-mcpu=cortex-m4` option.

> Oh! And of course you'd need to throw in `-mcpu=cortex-m4` option. BTW, clang even issues umaal instructions, so that assembly won't give you an edge is respect to hardware...

> Easier said than done. Keil does not like the library format, so will have to dig around on what is required there. Giving it server.o might work better... >...

> BLS is just significantly computationally heavier than ECDSA. For an embedded system the correct answer is likely to be an integrated co-processor. One wishes OpenTitan was an accessible option,...

> But, then I got a bunch of link errors about relocating objects, mostly related to stdio. As already mentioned, server.c has ~to~ **no** dependencies on C run-time, i.e. no...

To summarize. It's the ability to keep whole vectors in the register bank that translates to performance "leaps". Most notably one can barely accommodate a 256-bit vector in ARM32 registers(*),...

> don't consider the [Kinetis K82] mention as "this one will actually solve the problem." Just in case. One has to recognize that the co-processor is still power-constrained, which in...