verify in example.c fails (always!)

Line 33 in 622d28c

salty_sign(&seed, data, 6, &signature);

Line 34 in 622d28c

salty_verify(&public_key, data, sizeof(data), &signature);

The verification call in the example fails, as it uses sizeof(data) for the message length, while sign used '6'. Because the message "salty!" is written as string literal, its length is '7' including the zero terminator.
Is this intended behavior in the example?
If I change sizeof(data) to '6' in the verification call, everything is fine. I would suggest to either

use sizeof() in both places. If you want to avoid the terminating zero being part of the message, you can initialize it using a somewhat ugly character array literal like {'s', 'a', 'l', 't', 'y', '!'}, or
stay with the string literal and use strlen() in both places.

Further, the error value returned from the verification call might be checked and even printed.

As soon as I'll get the semihosted qemu to work and can enjoy printf() output, I might also open a PR :-)

Yes, strlen sounds good.

This is just me being really bad at C :))
I couldn't get either the assertions to work (as in fail visibly) nor the semihosting.
My goal here was not to have the instructions start with "and now download this huge vendor-supplied thing", but keep it minimal to just showcase how to call the API (and also add a test in CI that everything works in C land). It seemed to me since there's no actual standardization on build systems and linker scripts, it would be opportune to lean on libopencm3.

Regarding QEMU: Salty fundamentally uses the DSP instructions (e.g. UMAAL), which are in Cortex-M4 but not in Cortex-M3. Now vanilla QEMU has no Cortex-M4s, but it does have this musca-b1, which is a test chip by Arm, which is Cortex-M33 (= Cortex-M4 + TrustZone, from our perspective).

I think might also make sense to use https://xpack.github.io/qemu-arm/#supported-boards-and-mcus, which is a rebrand of the project formerly known as "GNU MCU Eclipse" and has some Cortex-M4s to choose from. Maybe something like the STM32F4-Discovery even has a GUI mode where you can press buttons, not sure.

JFTR: regarding semihosting, I found that just printf() and it's stdio relatives are not working well, most probably due to buffering issues and maybe linker map stuff or whatever, as the build time config and qemu seem not to match 100%. Sometimes I see even garbage on the screen.
What does actually work are syscalls like write() and even _exit(). And by chance I found a printf() variant that I wasn't aware of before: dprintf(fd, fmt, ...). It's like printf(), but writes directly to an fd. And it WORKS! dprintf(2, "Hello, %s\n", "World") should be visible when run under qemu.
This should already be good enough to write integration tests for the C API. The result can be returned to the host using _exit() (note the underscore, regular exit() does not link (and does not make much sense, either)). qemu will exit and forward the _exit() argument.

Finally, I had a chance to investigate the printf() issue again.
The root cause is that the manually tweaked linker script (link.x) keeps the ccm memory area, at an 'arbitrary' location, which puzzles the calculation of the end symbol. However, the end symbol is crucial for libc to work correctly.
Now I know what I have to do next. Expect a PR soon.

I think might also make sense to use https://xpack.github.io/qemu-arm/#supported-boards-and-mcus, which is a rebrand of the project formerly known as "GNU MCU Eclipse" and has some Cortex-M4s to choose from. Maybe something like the STM32F4-Discovery even has a GUI mode where you can press buttons, not sure.

I also checked that, but it does not seem to support hard float:

$ ~/opt/xpack-qemu-arm-2.8.0-10/bin/qemu-system-gnuarmeclipse -nographic -board STM32F4-Discovery -mcu STM32F407VG -semihosting-config enable=on,target=native -image example.elf 
QEMU 2.8.0-10 monitor - type 'help' for more information
(qemu) qemu-system-gnuarmeclipse: Attempt to set CP10/11 in SCB->CPACR, but FP is not supported yet.

No need to use hard float, constant-time crypto should be integer only.

That said, I'm fine with sticking with vanilla QEMU and musca-b1 (cf. also https://github.com/nickray/muscab1-pac if you are into Rust).

The thing that's really sad about QEMU is that the DWT cycle counter isn't implemented. Would be so awesome to empirically fuzz constant-timeness of the code.

No need to use hard float, constant-time crypto should be integer only.

I thought so, but wasn't patient enough to rebuild everything with soft-float to try it.

That said, I'm fine with sticking with vanilla QEMU and musca-b1 (cf. also https://github.com/nickray/muscab1-pac if you are into Rust).

I'm just beginning with Rust and this project seems a good opportunity doing so. Meanwhile, I managed to run the stuff in qemu-tests.

The thing that's really sad about QEMU is that the DWT cycle counter isn't implemented. Would be so awesome to empirically fuzz constant-timeness of the code.

Yes, it would be cool to have that counter. But I don't think that is a project for a sunny Sunday afternoon...