The microblog: 2020.06.28 00:56:55

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


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 mentioned that setting high bit "avoids infinity and avoids timing attacks". This was six years before extracted keys from exactly this timing leak in OpenSSL. See also and

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., and

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.