RFC 8032 describes Edwards Curve Digital Signature Algorithms. The most well known version of which is ed25519 - which uses the PureEdDSA strategy with SHA512 and Curve25519.
I'm working on a project where it is desirable to depart from that for two reasons. The first is implementation size, an embedded/FPGA implementation is in the long term plan and the the primary hash algorithm other places in the project is Blake3. The second is that the PureEdDSA strategy requires two passes over the data being signed/verified, which is undesireable for similar runtime memory reasons.
This market resolves YES if:
I cannot get a signature scheme based EdDSA and Blake3 that signs and verifies in one pass working in a timely manner. (ruled out, I got it working just fine, and then transitioned to Schnorr signatures)
The implementation proves to be unreliable over the first year of use in some way.
There's any security flaw that comes up in the first year of use due to using ~HashEdDSA~ Schnorr signatures with Blake3 instead of PureEdDSA with SHA512.
Any sufficiently compelling unforseen reason that I should have stuck with ed25519 or blake3 and then ed25519 on top of it.
I have the code audited and the auditer finds major problems.
Explicitly excluded from those other reasons:
I am annoyed that I need to implement ~HashEdDSA~ Schnorr(Blake3,Curve25519) multiple times to port the library to multiple languages.
Curve25519 is broken (by quantum computers or otherwise).
Blake3 is broken in a way that also affects the other uses in the project (e.g. collisions can be generated).
The market resolves no if a year after both public release and production use, the market hasn't resolved yes.
I am not a cryptography researcher. I have implemented multiple hash functions and signature schemes (including more complicated group signature schemes), but pretty closely following existing work/papers. This initial version of the project is written in Rust, and will be using existing libraries to the extent possible.
1,000@Nightsquared I did end up transitioning primitives - from Curve25519 to Ristretto255. This means no subgroup problems. The rust repository contains a complete description, though I may not have pushed the latest code.
The closest I came to mucking it up (to my knowledge) was including the public key in the second hash without including it in the first hash to derive the secret scalar nonce. In the theretical event that someone signed the same thing for multiple public keys (like for a threshold signature) this could lead to nonce reuse. However, threshold signatures usually specify their own nonce generation, which would be domain separated from normal signatures.
Overall I'm pretty happy with it. It's faster, streamable (without prehashing), smaller, and has fewer footguns that Ed25519. Unless someone comes up with a compelling problem with it, I'd consider it a success.
@Imuli I'm working on a first release, which actually is not EdDSA, but much closer to a typical Schnorr signature.
Overall, I'm much happier with it than EdDSA (which has pretty half-baked domain separation). I have updated the market description accordingly, and feel that it's still in the spirit of the market.
@Imuli First two releases - second one to clean up keygen (and get an extra bit of key space) and regularize the hash function parameterization (always key with the domain instead of sometimes with the domain and sometimes with the secret key).
https://crates.io/crates/c255b3