2019.10.04 19:01:00 (1180165935732273155) from Daniel J. Bernstein, replying to "Paul Crowley (@ciphergoth)" (1179959883589771265):
Looking at the (horrifying) libgcrypt code, I would say that they tried hard to write a vulnerable implementation, and succeeded for ECDSA, but _didn't_ succeed for EdDSA. The double-size Ed25519 hash means that they would have needed an extra reduction step to enable the attack.
2019.10.04 19:25:30 (1180172103049457664) from Daniel J. Bernstein:
There have been many other timing-attack vulnerabilities in libgcrypt, and clearly there will be more. We have to throw away variable-time crypto code _without_ waiting for attacks to be demonstrated. But this particular libgcrypt EdDSA attack is stopped by the double-size hash.
2019.10.04 20:17:40 (1180185232550572034) from Daniel J. Bernstein:
Here's a CFRG message five years ago describing exactly this scenario, where the double-size EdDSA/Ed25519 nonces prevent damage from a "timing attack revealing the nonce length" if the implementor hasn't done extra work to reduce modulo the group order: https://mailarchive.ietf.org/arch/msg/cfrg/8z3ZcujGRxFSGEBI-uE7C1tjw4c
2019.10.04 05:22:13 (1179959883589771265) from "Paul Crowley (@ciphergoth)":
This is really not good. A huge part of the point of EdDSA is that you can just pick up and drop in a timing side-channel free implementation. It must have taken real work to write a vulnerable implementation from scratch instead.