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

[Benson Muite <[e-mail]>]

On 11/25/22 16:04, Hubert Kario wrote:
> 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 

The reference [2] is interesting, as a hardware implementation of EdDSA 
does not allow edge cases.  It is unclear how many other hardware 
implementations there are, since these are more difficult to change 
compared to software implementations.
[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...
Maybe adding some context is helpful, in particular to aid use in new 
applications which seem to be growing and to ensure upgrade in legacy 
applications where it is necessary.  The number of library 
implementations are not so large, and at least for the openly available 
and widely deployed ones, making required changes seems feasible.
> 
>> -- 
>> 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.
>>
>