HEDGED SIGNATURES
Why deterministic ECDSA and EdDSA can still benefit from fresh randomness.
ECDSA requires a secret nonce for every signature. A biased or repeated nonce can expose the private key. Deterministic nonce generation addressed this operational hazard by deriving the nonce from the private key and message rather than relying only on fresh randomness.
Determinism is a major improvement. It also causes the same key and message to follow the same internal computation every time. Under physical observation or fault injection, that repeatability can become an advantage to an attacker.
Hedged signatures mix fresh randomness into deterministic derivation while preserving security when that additional randomness is weak. The goal is not to choose between determinism and randomness, but to avoid depending entirely on either failure model.
The ECDSA nonce is part of the private computation
For each ECDSA signature, a scalar nonce determines an ephemeral curve point and enters the equation containing the private key. Two signatures using the same nonce under different message hashes reveal enough information to solve for that key.
Partial bias can also be exploitable across many signatures. Historical failures have come from weak generators, insufficient entropy and accidental state reuse.
The nonce never appears directly in the signature, but its security is inseparable from the long-lived key.
Deterministic generation removes one source of catastrophe
RFC 6979 defines deterministic nonce generation for DSA and ECDSA using HMAC-based derivation from the private key and message hash. A correct implementation no longer needs fresh environmental entropy for each signature.
Ed25519 is deterministic by design. It derives a per-message scalar from secret key material and the message.
This makes signatures reproducible and protects against a random-number generator that fails after key generation. It does not make nonce derivation or scalar arithmetic public information; those operations still process secrets.
Repeatability can amplify physical attacks
If a device signs the same message repeatedly, deterministic generation produces the same internal scalar and often the same execution path. An attacker can align power or electromagnetic traces and average noise across observations.
Fault injection can also target a repeatable intermediate computation. A deterministic retry after a fault may recreate conditions that make differential analysis easier.
Constant-time and fault-resistant implementation remain the first line of defense. Additional randomness can make repeated executions less identical when those defenses are imperfect.
A hedge combines independent failure assumptions
A hedged construction begins from deterministic secret and message material, then incorporates fresh random input through a defined derivation. If the random input is unpredictable, it varies the nonce across equivalent signatures. If it is fixed, biased or attacker-known, the deterministic secret contribution should still protect the nonce.
This requirement rules out casual combinations. Replacing a deterministic nonce with random bytes reintroduces total dependence on the generator. XORing values without analysis can create bias or cancellation.
The construction needs a specified pseudorandom function, domain separation and exact input encoding.
Additional randomness is not public salt
The extra input should be generated for the signing operation and handled as sensitive intermediate state. Publishing it can remove some of the intended protection against side-channel correlation.
It is not a signature field that verifiers need. The output remains an ordinary ECDSA or EdDSA signature.
Implementations should zeroize the random contribution and derived nonce with the same care as other ephemeral secret values.
Retries need a defined policy
A signing API may repeat an operation after a transport timeout or device error. Should the retry use new random input or reproduce the original signature?
New randomness reduces trace alignment but produces a different signature. That can complicate idempotency when the first result may already have been committed elsewhere. Reusing captured randomness requires preserving sensitive operation state.
The application should distinguish retrying one logical operation from initiating another. Cryptographic randomness and transaction identity need coordinated semantics.
Randomness inside a secure element
A secure element may expose a standard ECDSA operation without accepting caller-supplied additional randomness. Its internal implementation may use deterministic, randomized or hedged nonces without revealing which.
For applications exposed to physical attack, this is a capability worth documenting. Compliance with the external signature format says nothing about internal nonce generation or countermeasures.
A programmable applet can implement a hedge only if it has access to the private key operation, a suitable random source and the required derivation primitive inside the protected boundary.
Message prehashing affects derivation
Deterministic schemes derive the nonce from a representation of the message. If one layer passes a prehash and another expects raw message bytes, implementations can produce incompatible results or bind the nonce to less context than expected.
Protocol variants, context strings and domain separation must follow the signature specification. Additional randomness does not repair ambiguity in the signed bytes.
The lesson remains that signatures are over bytes, not meaning.
Testing needs controlled failures
A hedged implementation should be tested with high-quality random input, all-zero input, repeated input and failures in the random source. Signatures must remain valid in every permitted case.
Tests should confirm that fresh input changes internal nonce derivation and normally changes the signature, while a deterministic fallback remains compatible with the specification.
Fault and side-channel evaluation require physical measurements. Functional test vectors cannot establish resistance to those attacks.
Hedging does not excuse a bad RNG
A design that remains secure when additional randomness is poor still benefits from a strong generator. The fresh input provides diversity against repeated execution and may protect against flaws in deterministic derivation.
The generator needs health checks, reseeding and lifecycle analysis. Hedging changes the consequence of failure; it does not make failure desirable.
Determinism is one defense, not the complete boundary
Deterministic signatures solved a serious class of nonce-generation failures. They did not remove secret-dependent computation from signing devices.
Fresh randomness can add defense against repeated traces and faults, provided it is combined through a construction that remains secure when the random input fails.
Determinism is not a substitute for entropy because the strongest implementation can use each to hedge the other’s weakness.
