In constrained memory systems, it can be very handy to ed25519 sign messages that are readily available and complete, however not available in one contiguous memory. With the current sign() signature, such messages need to be copied into contiguous memory.
An example for this situation is my solokey eddsa support POC solokeys/solo1#478.
For illustration, I added a sign2() function in https://github.com/enrikb/salty/tree/feature/scatter-gather-message (just copy and paste of the regular sign()).
Of course, this can also be done for verify(), and also more sophisticated versions like working on a vector of message fragments are possible, following the POSIX readv()/writev() pattern (but maybe not needed that much?).
What do you think about such an API enhancement?

Even though QEMU does not implement the cortex M4 DWT cycle counter, real hardware often does.
I have successfully tested the commented out cycle counter code from qemu-test on a real STM32F411 board. Of course, the cycle count for sign() is not constant, as the message length varies.
So, now it would be nice to have a feature in salty to enable cycle counting in 'the right places'.
As a starting point, dedicated tests for low level calls would be fine, too.

** Programming Finished **
** Verify Started **
** Verified OK **
** Resetting Target **
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
enabled cycle counter
keypair.sign took 5539346 cycles
keypair.sign took 5539196 cycles
keypair.sign took 5539230 cycles
keypair.sign took 5539254 cycles
keypair.sign took 5873812 cycles
keypair.sign took 5564848 cycles
All tests passed, including RFC 8032 test vectors!

(As a quick test, I wrapped all regular sign() calls with the counting code.)

Figure out what rust-lang/stdarch#437 was doing.
See if it can be done as a separate crate.
Implement umaal.
See if it's possible to rewrite Haase's assembly using this.

I have added everything I think should be needed (some documents would help)
I get a shed of errors starting with:
dave@dave-TUXEDO-Aura-15-Gen1:~/git/solokeys/solo1/crypto/salty/c-api$ make build
cargo build --release --target thumbv7em-none-eabihf
Compiling subtle v2.4.1
Compiling panic-halt v0.2.0
Compiling salty v0.1.0-alpha.1 (/home/dave/git/solokeys/solo1/crypto/salty)
error[E0463]: can't find crate for core
|
= note: the thumbv7em-none-eabihf target may not be installed
= help: consider downloading the target with rustup target add thumbv7em-none-eabihf

error[E0463]: can't find crate for compiler_builtins

error[E0433]: failed to resolve: use of undeclared crate or module atomic
--> /home/dave/.cargo/registry/src/github.com-1ecc6299db9ec823/panic-halt-0.2.0/src/lib.rs:33:9

I am willing to believe this is my fault but some pointers in the readme towards what is needed to be installed where and how for this to work would make life (especially mine) far far easier, then we would all be able to benefit from the hardwork that has obviously been put in.
I am trying to compile the solokey solo1 project, that at last compiles but apparently it needs the salty library

ed25519-dalek and other implementations make use of the generic types defined in the signature crate to be able to do a generic implementation over multiple potential signing algorithms.
Is there a specific reason this crate does not implement these traits? Or am I missing something?

I understand that the Signature type from ed25519 is not used due to the optimized in-memory storage done in this library, but maybe providing From<> impls for those types could make a nice API?

I'm considering doing a PR for this but want to hear your opinion first.

Hi @nickray ,

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 :-)

Bumps MSRV to Rust 1.59.

It's a bit of a hassle for downstream C consumers to have the embedded target installed (distro rust/cargo packages often don't include rustup). Since c-api/libsalty.a is 3MB, adding it to git is probably a bad idea.

It seems that &scalar * &MontgomeryPoint::basepoint() is not the same as (&scalar * &EdwardsPoint::basepoint()).to_montgomery(). Check if this is an implementation error or expected.

We already talk about this, but opening here to stay organized. Signatures seem to be invalid deterministically about 1% of the time. One of the vectors that causes a bad signature is the following.

ed25519  Secret / seed = 5C 8A 90 83 8D 10 55 24 FE 8D F6 5A 9D AF D9 9C C4 08 53 7B 6C A3 1B 39 91 0B 71 75 35 55 74 15 
ed25519  public key = E7 0E 8F C5 4B 8E 9E 35 67 ED 82 D9 CE 98 A8 DA 06 BD 06 C4 A3 83 F4 36 C3 BA 05 5D C8 48 A8 04

signing data = BF AB C3 74 32 95 8B 06 33 60 D3 AD 64 61 C9 C4 73 5A E7 F8 ED D4 65 92 A5 E0 F0 14 52 B2 E4 B5 01 00 00 0B 0E 31 32 33 34 35 36 37 38 39 61 62 63 64 65 66 30 31 32 33 34 35 36 37 38 39 61 62 63 64 65 66 30

(incorrect) signature = 45 13 8A 44 1F B8 D0 C5 6B 1F F7 E5 7E 75 99 38 49 12 17 99 F1 58 E0 DE 56 F7 29 29 70 EA 93 9C FA 56 EF EE 50 AD DF 2A 80 4F AA 46 41 9D 37 D8 4C C4 7B 93 AE 96 9E F0 39 2C B7 F2 00 E5 36 10

https://github.com/FiloSottile/mostly-harmless/tree/main/ed25519vectors

Currently agreement::PublicKey only implements TryFrom<[u8;32]> instead of From

This prevents using non-canonical curve elements. However, the standardised x25519 function has a signature of x25519(k: [u8; 32], u: [u8; 32]) -> [u8; 32] which doesn't fail and silently canonicalize the public type.

For example x25519-dalek implements From.

I've been trying to track the v0.2 release from crates.io back to a git commit in this repo but there doesn't appear to be a tag for it. There doesn't seem to be a tag for the v0.1 release either. Any chance you all are willing to tag these releases explicitly? Manually comparing the source tree that cargo pulls down isn't too much work (it looks like v0.2 is the current head of the main branch), but having an explicit tag would be ideal.

https://github.com/google/wycheproof/blob/master/testvectors/eddsa_test.json

like RustCrypto/elliptic-curves#232