Re: [CFRG] RFC 8032 Erratum: EdDSA test vectors

[Hubert Kario <[e-mail]>]

On Thursday, 24 November 2022 17:58:19 CET, François Garillot wrote:
> Hi Mike,
>
>> Perhaps we should then change the RFC to indicate that 
>> implementations SHOULD use the weaker, cofactored verification 
>> equation?
>
> If Ed25519 was a greenfield or niche project, that would 
> perhaps be ideal. Other changes (e.g. strongly-binding 
> signatures), detailed in the paper as well as in other 
> publications ([1]) may also deserve consideration. In fact, some 
> library maintainers working in a consensus context have already 
> adopted some of these changes (see [2] for some detailed 
> rationale).
>
> Yet considering there is a plethora of load-bearing libraries 
> that use cofactorless verification exclusively in a wide range 
> of contexts today, their maintainers might favour compatibility 
> with historical verification decisions. A good middle ground 
> then seems to be mandating the documentation of their 
> implementation's behaviour on -at least- the cofactored / 
> cofactorless edge case, which is where the test vectors may 
> help.
>
> [1]: https://eprint.iacr.org/2020/823 
> [2]: https://hdevalence.ca/blog/2020-10-04-its-25519am

And the RFC can also allow for the behaviour to change with a configuration
option...

> -- 
> FG
>
>
> On Thu, Nov 24, 2022 at 11:06 AM Mike Hamburg <[e-mail]> wrote:
> Hi François,
>
> That makes sense: it’s entirely reasonable to include these 
> test vectors with a note that they aren’t technically required 
> by the RFC.
>
> Perhaps we should then change the RFC to indicate that 
> implementations SHOULD use the weaker, cofactored verification 
> equation?
>
> Cheers,
> — Mike
>
> On Nov 24, 2022, at 3:16 PM, François Garillot 
> <[e-mail]> wrote:
>
> Hi Mike,
>
> I would caution against excluding the test vectors for 
> cofactored/cofactorless verification: Table 3 of the paper 
> explains that, unless a library uses a cofactored verification 
> equation, batch verification and iterated single-signature 
> verification will not agree on all signature sets. Such a 
> disagreement is consequential in some contexts: for instance, it 
> could make a library using a cofactorless verification equation 
> delicate to use in a BFT consensus protocol. Those test vectors 
> seem important to include, so as to encourage libraries to 
> document this implementation choice.
>
> Table 5 of the paper documents the FIPS186-5 recommendations, 
> to the best of the authors' knowledge.
>

-- 
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic