The microblog: 2021.06.15 22:01:30

2021.06.15 22:01:30 (1404891836645208066) from Daniel J. Bernstein, replying to "Steven Galbraith (@EllipticKiwi)" (1404377032725651464):

Yes, the suggestion in Section 5.3 of ends up setting bit 255 instead. The hashing is under very different constraints: doubling the output size simplifies parts of the design, helps protect implementations (as we saw with Minerva), and doesn't cost much.

2021.06.15 22:11:57 (1404894466469625856) from Daniel J. Bernstein:

Part of the design process is predicting software incentives and turning those into helping, rather than hurting, security. Look at, e.g., explaining in 2014 how 512-bit nonces protect simple non-reducing implementations against nonce timing attacks.


2021.06.14 01:22:02 (1404217529363402759) from "Steven Galbraith (@EllipticKiwi)":

I dont mind the leading 1. It's the zero LSB that seems unnecessary

2021.06.14 01:46:07 (1404223588123648004) from Daniel J. Bernstein, replying to "Steven Galbraith (@EllipticKiwi)" (1404217529363402759):

Pohlig-Hellman immediately reveals the bottom 3 bits, so setting them to be nonzero wouldn't gain security, while zero gives slight simplifications+speedups in optimized software. The multi-user security questions you mention are tied to the top bits, not the bottom bits.

2021.06.14 11:50:48 (1404375760874270723) from "Steven Galbraith (@EllipticKiwi)":

I could have been more precise in my comments. Fixing a leading bit is ok. But want distribution to be close to uniform. Since p \approx 2^{255} and #E \approx p this is easy. But your choice in EdDSA to use bit 2^{254} and 3 MSB=0, means only 2^{251} possible.

2021.06.14 11:55:51 (1404377032725651464) from "Steven Galbraith (@EllipticKiwi)", replying to "Steven Galbraith (@EllipticKiwi)" (1404375760874270723):

If you'd set bit 255 instead, or not zeroed the last 3 bits, then all would be good. It's interesting that you took a much more conservative approach to the hashing/de-randomization (I would not have gone as far as 512 bit hashing).