Verify signatures after signing

[quad]

Description

Verify signatures after signing

As per BIP-340, footnote 14:

Verifying the signature before leaving the signer prevents random or
attacker provoked computation errors. This prevents publishing invalid
signatures which may leak information about the secret key. It is
recommended, but can be omitted if the computation cost is prohibitive.

Notes to the reviewers

How do we test this?

Checklists

All Submissions:

• I've signed all my commits
• I followed the contribution guidelines
• I ran cargo fmt and cargo clippy before committing

[danielabrozzoni]

Since the footnote says "prevents random or attacker provoked computation errors", maybe we should re-try if the verification fails, and after one retry, return an error instead of panicking?

[quad]

I wouldn’t retry. The effect of a random computation error likely isn’t limited to just the internals of the signature call. Either the CPU or more likely the RAM is in an invalid state. Failing fast is the correct behaviour as, regardless, the caller needs to be able to handle failure. See: https://docs.kernel.org/admin-guide/ras.html In the case of an attacker provoked error, re-running leaks more information in a tighter loop. Halting on detection of glitch attacks is the norm. And many classes of side channel attacks are specifically mitigated by slowing down the loop. See: https://www.blackhat.com/docs/eu-15/materials/eu-15-Giller-Implementing-Electrical-Glitching-Attacks.pdf

…

On Tue, Aug 16, 2022, at 23:51, Daniela Brozzoni wrote: Since the footnote says "prevents *random* or attacker provoked computation errors", maybe we should re-try if the verification fails, and after one retry, return an error instead of panicking? — Reply to this email directly, view it on GitHub <#718 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAF3WKXCLFVRVV3D2S2RSTVZOMEZANCNFSM56RDBPCA>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[jmecom]

IMO, if a fault occurs, the caller should be made aware and the library should not silently retry until success occurs. The correct response to a fault detection may vary from system-to-system, and so the library should be flexible. I'll quote the Hardware Hacking Handbook on some possible fault responses:

A fault response is what to do when a fault is detected. The goal here is to reduce the chances of a successful attack to the point where an attacker will give up. On the one end of the spectrum, you can implement a program exit, OS reboot, or chip reset. These actions will delay an attacker but in principle still allow them infinite tries. Somewhere in the middle of the spectrum is signaling a backend system to flag this device as suspicious and perhaps disable the account. On the other end of the spectrum, you can implement permanent measures like wiping keys, accounts, or even burning fuses that disallow the chip from booting up.

[danielabrozzoni]

Yeah, you're right, re-trying doesn't seem to be a good idea, sorry :)

[afilini]

ACK 31eed5f

[afilini]

Wait, I can't merge this unless the commits are signed: @quad you can either sign them yourself, or if you prefer I can sign them with my own key, let me know.

[quad]

Feel free to sign it with your key.

[quad]

@afilini I've signed the commit. Would you please re-approve running workflows?

[afilini]

re-ACK 7b1ad1b