Follow up #844

[tcharding]

Original post: #844 (comment)

• Go through all the newly one-liner functions and consider deprecating/removing them
• Delete existing Secp256k1 object and replace with a dummy object that reimplements the existing API (to the extent possible) by passing through to global functions
• Then I think we can cut a release.
• Then we can fix the API tests by doing deprecate-and-rename on a bunch of methods, and do another major release.

(I have not thought through the last two points.)

[apoelstra]

Adding here so I don't forget, though these are long-term goals that will be quite difficult and annoying to implement:

• Somehow share randomness between threads in the std case, and especially somehow avoid starting every thread with the same seed
• (With upstream help) rerandomize only a couple bits at a time, since 256 bits is slow and waay overkill
• (With upstream help) allow feeding data from non-secret calls (e.g. verification) into the rerandomization RNG without doing the slow process of actually rerandomizing
• Attempt to detect forks and rerandomize?

I remind readers of this issue that this whole rerandomization project is a defense-in-depth measure against sidechannel attacks, none of which we believe to exist with current compilers and the current codebase, and for which we have extensive analysis and testing upstream. Just because I write something here that has a clear theoretical benefit does not mean that it will ever have any practical benefit, and certainly does not mean that we are obiglated to bend over backward to implement any of these things.

[apoelstra]

Also we may want to recreate this whole issue #346 (comment) since the issue is ultimately pretty simple and we have a good idea of the solution, but there are 75+ comments on it and lots of distraction about wasm when the issue is really about any nostd system.

[tcharding]

And from 844, not necessarily actionable just so we don't forget:

Arguably in the signing methods we should xor in the message, and in ElligatorSwift::from_seckey we should xor in the auxliary randomness if it's available. The idea here is that if the user signs with multiple messages, we won't rerandomize with the same seed. This might provide additional protection in some multi-threaded scenarios. (But it would still not help in the case of a user who is doing many signatures and spawning a new thread for each one. I guess we ought to discourage that in the docs somewhere.)

Posted by Andrew: #855 (comment)