[CFRG] Re: RFC 8032bis: resources on resolving some Ed25519 issues

[Jack Grigg <[e-mail]>]

At C2SP we maintain a set of Ed25519 test vectors:

https://github.com/C2SP/CCTV/tree/main/ed25519

These exercise a complete set of edge cases for the elliptic curve point
inputs (the public key A and the first half R of the signature) to Ed25519
signature verification. We also document the behaviours of some known
ecosystem specifications and implementations (which test vectors they
accept, reject, or are silent on). If you maintain an implementation of
Ed25519, we encourage you to run these test vectors; if you see a different
pattern of test vector results than any listed therein, or notice any bugs,
we'd welcome an update to the list!

On Fri, Nov 8, 2024 at 10:54 PM Ilari Liusvaara <[e-mail]>
wrote:

> It seems that some of the divergences are baked into exact specification
> requirements so there is no satisfying everyone with one specification
> without optional steps.
>
> There are at least the following axes:
>
> - No point check vs. order check vs. subgroup check.
> - Check point canonicity or not.
> - Check scalar canonicity or not.
> - Clear cofactor or not.
>
> (With some degeneracies: If doing subgroup check on R and A, clearing
> cofactor does not matter.)
>

And this is just the set of axes that are apparent within the
specifications. Implementation behaviour varies much more broadly beyond
these axes, and rarely conforms to any specification (as described in the
aforementioned blog post, and encoded in the C2SP test vectors).


> E.g., ZIP215 has no point check, no point canonicity check, scalar
> canonicity check, and cofactor clear. And it mandates doing exactly
> this.
>

(With my Zcash developer hat on:)

The reason we took this approach is that, by being a strict broadening of
the valid set of signatures, it entirely removed the need for the signer to
be aware of ZIP 215 rules and made migrating to them possible. Our pre-ZIP
215 validator implementation enforced scalar canonicity of S (as specified
in RFC 8032) which meant we could be certain that all signature producers
were also producing canonical scalars (which are significantly easier for
implementations to handle than non-prime-order elliptic curve points, as
evidenced by the wide variety of documented incompatible behaviour in the
latter). Under ZIP 215, signers required no changes in order for their
signatures to be valid, and crucially, the set of previously-created
signatures remained valid under ZIP 215 rules. Attempting to craft tighter
validation criteria for the elliptic curve point inputs, while navigating
around the numerous validation compatibility pitfalls, would have massively
complicated the protocol.

Cheers,
Jack