Open djc opened 3 years ago
We have tested ring's signature verification algorithm here (as a proxy to BoringSSL) : https://eprint.iacr.org/2020/1244 The code we used for testing is available here: https://github.com/novifinancial/ed25519-speccheck
The TL;DR: Ring, like BoringSSL, uses cofactorless verification (vectors 4-5), correctly rejects non-canonical scalars (vectors 6-7), but admits small components in the key and signature (vectors 0-3), and other more minor details (see paper).
Coda: One of the outcomes of this analysis has been that block chains at large crucially rely on several implementations agreeing perfectly on the set of valid signatures among an externally-controlled set. The main source of discrepancy is the topic of cofactored ( 8SB ≟ 8R + 8H(R|A|m)A, recommended by the standards) vs. cofactorless multiplication ( SB ≟ R + H(R|A|m) A, used by most libraries). To make sure anyone can apply the verification equation they need, it would be useful to have an (opt-in) cofactored verification in BoringSSL, and transitively, in Ring.
See https://hdevalence.ca/blog/2020-10-04-its-25519am. Would be good to detail what approach ring choose in the documentation and/or offer multiple options that make it clear what's going on.