Dichotomy between verification equations for EdDSA

[armfazh]

The Section 5.1.7 of RFC-8032 specifies:

5.1.7 Verify 

 3.  Check the group equation [8][S]B = [8]R + [8][k]A'.  It's
     sufficient, but not required, to instead check [S]B = R + [k]A'.

which equation will be used?
🚀 : [h][S]B = [h]R + [h][k]A'
❤️ : [S]B = R + [k]A'

[twiss]

The current draft doesn't specify which one should be used (which I guess you probably know, but just to be explicit) - is your opinion that we should pick one or the other?

I'm not sure if implementations will be able to pick very easily, they might be stuck with whatever their crypto library does. But it might be worth looking into what those commonly do, if every library does one of them, perhaps we can standardize on that.

[kayabaNerve]

Due to the above mentioned issue, I explicitly support this being locked down. Otherwise, browsers may disagree on signature validity.

I personally vote for the cheaper, non-cofactor clearing equation. Implementations, as a matter of policy, shouldn't generate torsioned keys in practice.

---

The prior comment mentions reviewing what libraries do. Almost all libraries for Ed25519 have differing behavior and can be forced into incompatibility with each other.

https://hdevalence.ca/blog/2020-10-04-its-25519am

Unfortunately, in practice, the best you'd get is a set of rules closest to most libraries making it easiest to fork said libraries/add additional rules to achieve spec-compliance.

[kayabaNerve]

OpenSSL and BoringSSL both implement the non-cofactor clearing check.