* Recommend a byte length for aux random data
* Clarify that with signature verification by default at the end of the signing algorithm, using public keys from untrusted sources is not an issue.
* A few editorial nits
- Separate nonce generation into getting a random byte string and converting it to a suitable scalar ...
- ... to make clear that the byte string can be generated differently.
- Make the warning a little bit more prominent and improve writing
This is supposed to supersede https://github.com/sipa/bips/pull/158.
I tried to say this carefully. I don't think that multiparty signing is in general broken with short hashes. For example the attack in #158 could be avoided by letting everybody not only commit to the nonce but also to the message. It's just that using a collision-resistant hash just eliminates the problem entirely...
- Separate nonce generation into getting a random byte string and converting it to a suitable scalar ...
- ... to make clear that the byte string can be generated differently.
- Make the warning a little bit more prominent and improve writing
This is supposed to supersede https://github.com/sipa/bips/pull/158.
I tried to say this carefully. I don't think that multiparty signing is in general broken with short hashes. For example the attack in #158 could be avoided by letting everybody not only commit to the nonce but also to the message. It's just that using a collision-resistant hash just eliminates the problem entirely...
Tim Ruffing