Viem Breaks RFC 6979 Conformance, Risks Privacy and Protocol Compatibility

[szaglam]

Check existing issues

• I checked there isn't already an issue for the bug I encountered.

Viem Version

2.23.7

Current Behavior

Component: Signature Generation

Summary

The upcoming release of Viem will introduce non-deterministic "hedged signatures," deviating from the well-established RFC 6979 standard for deterministic ECDSA signatures. This change, driven by Paul Miller without apparent public discussion, research, testing, or cryptographic audits, poses significant privacy risks and breaks compatibility with protocols and applications relying on RFC 6979. I urge the Viem team to revert this change or make it opt-in until proper evaluation and community consensus are achieved.

Steps to Reproduce

1. Use latest Viem to generate an ECDSA signature with a fixed private key and message digest (e.g., via signMessage or signTypedData).
2. Repeat the signature generation with the same inputs.
3. Compare the resulting (r, s) values across runs.
4. Validate against an RFC 6979-compliant implementation (e.g., OpenSSL or a known-conforming library).

Expected behavior

Signatures generated with the same private key and digest should be identical, adhering to RFC 6979 determinism.

Actual Behavior

Signatures vary across runs due to the introduction of randomness in the nonce (hedged signatures), breaking RFC 6979 conformance.

Impact

This change has far-reaching consequences:

1. Privacy Nightmare from Non-Deterministic Signatures
   Non-deterministic signatures allow signers ~2^256 possible (r, s) pairs for a given input, enabling covert marking. For example:
   A hardware wallet manufacturer could embed a secret device ID into signatures. By regenerating (r, s) until hash("salt" || r)[0..16] == device_id, they could link on-chain activity to a user's identity (e.g., tied to a credit card purchase). This is undetectable to users without access to the secret salt.
   RFC 6979 prevents this by ensuring a single, deterministic (r, s) output, making signatures indistinguishable across conforming implementations.

2. Breaks Existing Protocols and Applications
   Several protocols rely on RFC 6979 determinism for security and functionality:
   Galxe Passport: Uses deterministic signatures for wallet-derived secrets.
   zkPass: Relies on consistent signature output for key derivation.
   KimlikDAO KPass: As a KimlikDAO contributor, I can confirm KPass derives symmetric encryption keys from deterministic signatures. Non-deterministic outputs in Viem will break this key derivation, rendering KPass unusable with affected wallets.

3. Unproven Security Benefits
   The rationale for hedged signatures—adding randomness to mitigate implementation flaws—lacks substantiation:
   RFC 6979 already provides fault tolerance by deterministically deriving the nonce from the private key and message, avoiding weak RNG issues.
   Determinism enables rigorous testing: identical outputs across implementations (e.g., Viem vs. OpenSSL) confirm correctness, reducing the risk of subtle bugs.
   No peer-reviewed research or public cryptographic analysis supports hedged signatures improving security over RFC 6979. Claims of resilience against side-channel attacks or fault injection remain speculative without evidence.

4. Lack of Transparency and Consensus
   Paul Miller has aggressively pushed hedged signatures across multiple projects, including:
   go-ethereum (Issue #30773)
   Ethers.js (Issue #4885)
   Ethereumjs (Issue #3801)
   This feature was implemented months ago with no visible public discussion, testing, or audits. Miller, not a cryptographer, appears to be forcing adoption without stakeholder input—a "hammer vs. nail" approach unfit for such a critical cryptographic change.

Request: Revert Viem to RFC 6979-compliant deterministic signatures.
Long-Term Consideration: If hedged signatures are deemed valuable, make them an opt-in feature (e.g., via a config flag like useHedgedSignatures: true) after:

• Public discussion on security mailing lists (e.g., CFRG).
• Independent cryptographic review and audits.
• Test vectors and cross-implementation validation.
• Community consensus among Ethereum developers and protocol maintainers.
• Additional Context

RFC 6979 has been battle-tested since 2013, offering a balance of security, testability, and interoperability. Deviating from it without justification risks fracturing the Ethereum ecosystem and exposing users to privacy violations.

Call to Action

I implore the Viem maintainers to prioritize user safety and ecosystem compatibility over unproven experimentation. Please address this in the next release and provide clarity on how this change was greenlit without broader input.

Expected Behavior

No response

Steps To Reproduce

No response

Link to Minimal Reproducible Example

No response

Anything else?

No response

[jxom]

Viem doesn’t use hedged signatures by default as this would be a breaking change in a non-major version. The consumer has to opt-in to it.

[paulmillr]

Unproven Security Benefits

Fault attacks / attacks against deterministic signatures have been discussed in SH16, BP16, RP17, ABFJLM17, SBBDS17, PSSLR17, SB18, WPB19, AOTZ19, FG19.

Notwitstanding these papers, hedging was described in following 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