Improve security of signature generation

[paulmillr]

Recent Elliptic.js CVE highlightened a danger of fault attacks.

Check out blog post: Deterministic signatures are not your friends and ethresear.ch post. Deterministic RFC6979 signatures are good, however, if an error happens during sig generation, then the error is propagated to the very end. In worst cases it will mean k reuse and private key leak.

Solution

Use hedged signatures. RFC6979 3.6: already specifies additional k' extraEntropy to mix-in 32 byte of random data on every signature. It is standard way of doing this.

Switch is from k = hash_6979(private_key, message) to k = hash_6979(private_key, message, extraEntropy)

Pros

Increased security against private key leakage. Even when passed-through randomness is bad, the security would be just like today, not worse.

• Fault attacks / attacks against deterministic signatures have been discussed in SH16, BP16, RP17, ABFJLM17, SBBDS17, PSSLR17, SB18, WPB19, AOTZ19, FG19.
• Hedging was described in specs BIP340 in 2018-2020 ("Using unpredictable randomness additionally increases protection against other side-channel attacks, and is recommended whenever available."), CFRG draft in 2022 and of course RFC6979 section 3.6.
• Bitcoin has been using extra entropy for low-r grinding since 2018 and hedged schnorr BIP340 since 2021
• Apple iOS, Safari browser and Signal all specifically use hedged ed25519 even though RFC8032 ed25519 is not hedged

Cons

• Signatures (r, s) would become non-deterministic and "new" after every signature.
  • Some protocols use deterministic sigs as keys.
  • These protocols can ask for deterministic sigs, for example, by specifying static extraEntropy
• Slightly increased chance of fingerprinting
  • Injecting caf3 as first 2 bytes will take 65K+ generations on average - totally infeasible for hardware wallets (ledger uses 48MHz STM32F042)
  • To be reliable, fingerprinting needs to inject 10+ bytes, which means billions of signatures

[paulmillr]

Viem is on board and implemented the changes today.

[ricmoo]

This is something I would prefer being opt-in, as many applications already in use depend on deterministic signatures.

Is there a way to specify the random source? I would prefer to supply the random source, as some platforms do not have a global source (or the existing source) is not cryptographically secure.

[ricmoo]

(I otherwise fully endorse adding additional entropy to the signing k)

[paulmillr]

secp256k1.sign(msgHash, privateKey, { extraEntropy: extraEntropy }) where extraEntropy could be false, true, or Uint8Array that you pass.

[paulmillr]

This is something I would prefer being opt-in, as many applications already in use depend on deterministic signatures.

• Which applications depend on deterministic signatures besides tests?
• It makes sense to have it opt-in because it's breaking, however, we should strongly consider making it default in ethers v7. Opt-ins will not really increase security of the whole ecosystem (users don't care and don't know), while opt-out will.

[ricmoo]

I know CLR uses it when computing their semi-ephemeral voting keys.

I also use it for many of my CLI scripts and simple web interfaces. For example, when computing a salt for registering ENS names. The salt only needs to remain “secret” for about 4 blocks, at which time it is revealed. In general, for blinding operations it is a useful technique since the salt can be recovered (by signing a specific message), without the need for a database or any other complex system on the event of a website refresh or a CLI which has no storage in the first place.

I have also seen it used before with generating short-lived shared secrets.

I am absolutely game for making it opt-out after a major version change, but would also prefer to follow suit with whatever Geth/Clef is doing. Have you tried convincing them yet?

[paulmillr]

The cases seem useful! However, you’re advanced user. Most users aren’t. Advanced users can disable it. If we’ll manage to improve security for all non advanced users that would be a huge jump.

I will ask their thoughts on it soon.

[ricmoo]

Oh, I am in no way disagreeing that it is a good idea to add additional entropy.

I just want to make sure we behave like the existing ecosystem (as best as possible) and don’t want to introduce breaking changes in a non-major version.

[paulmillr]

don’t want to introduce breaking changes in a non-major version

agree 100%

ethereum/go-ethereum#30773

[paulmillr]

Vulnerability is now public: GHSA-vjh7-7g9h-fjfh

My blog post on the issue: https://paulmillr.com/posts/deterministic-signatures/