2020.06.28 00:56:55 (1277013067876851713) from Daniel J. Bernstein, replying to "Ján Jančár (@j08ny)" (1276883296023175170):
The fact that nonces _can_ be reduced doesn't eliminate the protection: simple implementations won't spend extra code on the reduction. Example: libgcrypt rolled its own and was still protected by the long nonces, the scenario described years earlier in https://mailarchive.ietf.org/arch/msg/cfrg/8z3ZcujGRxFSGEBI-uE7C1tjw4c/.
2020.06.09 14:52:27 (1270337966746087430) from "Frank ⚡ (@jedisct1)", replying to "Steve (@Sc00bzT)" (1270333735897108482):
Requiring the high bit to be set was a terrible decision. It never protected any specialized implementation, yet is utterly confusing and breaks associativity. And clamping was also applied to EdDSA for no good reasons.
2020.06.27 15:06:38 (1276864517390036993) from Daniel J. Bernstein, replying to "Frank ⚡ (@jedisct1)" (1270337966746087430):
Page 31 of https://cr.yp.to/talks/2005.09.20/slides.pdf mentioned that setting high bit "avoids infinity and avoids timing attacks". This was six years before https://eprint.iacr.org/2011/232.pdf extracted keys from exactly this timing leak in OpenSSL. See also https://cr.yp.to/talks.html#2014.07.23 and https://mailarchive.ietf.org/arch/msg/cfrg/pt2bt3fGQbNF8qdEcorp-rJSJrc/.
2020.06.27 15:28:02 (1276869902813421569) from Daniel J. Bernstein:
The high bit is an example of a much broader success story: many security failures in cryptographic implementations can be predicted by cryptographic designers and proactively avoided through changes in designs. See, e.g., https://cr.yp.to/talks.html#2015.01.07 and https://blog.cr.yp.to/20191024-eddsa.html.
2020.06.27 16:21:15 (1276883296023175170) from "Ján Jančár (@j08ny)":
Regarding nonces used in EdDSA, you might want to update the "EdDSA for more curves" paper. It has a note which effectively negates the long nonces used in EdDSA. EdDSA in libraries is not vulnerable because most libraries do not roll their own, if they did they might be.