37

Using the terminology of the ECDSA Wikipedia page, ECDSA (and DSA) signatures require a random k value for each signature which ensures that the signature is different each time even if the message and key are the same. For some applications, a "constant" signature may be desirable.

It seems to me that there would be no harm in implementing "constant" ECDSA by setting the "random" k value to be the x-coordinate of the message hash z (converted to a curve point in some arbitrary fashion) multiplied by the private key. Obviously the method translates back to DSA.

This scheme might be useful for implementations that do not have access to a source of random numbers.

Are there any problems with this? Is there a faster way of generating a suitable k than a point multiplication?

kelalaka
  • 49,797
  • 12
  • 123
  • 211
ByteCoin
  • 747
  • 1
  • 6
  • 7

4 Answers4

34

There is a draft RFC which describes a way to implement deterministic (EC)DSA (with test vectors). In this draft, both $h(m)$ (the hash of the message) and $x$ are used as input to a deterministic PRNG which uses HMAC (that's HMAC-DRBG as specified by NIST); the PRNG output is used to yield $k$. I am not sure your simple multiplication with $x$ would be enough to guarantee security; ideally, a random oracle should be used, and HMAC-DRBG is the closest to a practical random oracle that I could find.

Note that $k$ must be generated uniformly in the $[1, q-1]$ range (where $q$ is the subgroup order). Any information on $k$, even partial (such as: values between $1$ and $2^{160}-q$ are twice as probable than values between $2^{160}-q$ and $q$), can be exploited by the attacker.

(There will be a new draft version with a few text changes in the draft -- but the same test vectors -- as soon as I find the time to do it.)

Edit: the RFC is now published as RFC 6979.

Thomas Pornin
  • 88,324
  • 16
  • 246
  • 315
13

In their 1998 SAC paper, M'Raihi et al showed how to use hash functions to turn Schnorr signatures (quite similar to (EC)DSA) deterministic, and proved that if the original signature scheme (with randomness) is secure, so is the deterministic one.

Bernstein et al's recent EdDSA signature scheme uses the same technique to avoid randomness.

Samuel Neves
  • 12,960
  • 46
  • 54
1

It seems to me that there would be no harm in implementing "constant" ECDSA by setting the "random" k value to be the x-coordinate of the message hash z (converted to a curve point in some arbitrary fashion) multiplied by the private key. Obviously the method translates back to DSA.

The private key can be calculated when there are any two different legitimate signatures.

  • msg_hash: $z_i$
  • signature: $(r_i, s_i)$
  • private key: $sk$
  • deterministic k: $k_i = [z_i \cdot P].x \cdot sk$, and point $P$ is on the same curve. and $P$ is public. let $px_i = [z_i \cdot P].x$, so $k_i = px_i \cdot sk$

$$ \begin{align*} s_1 &= \frac{m_1 + r_1 \cdot sk}{px_1 \cdot sk} \\ s_2 &= \frac{m_2 + r_2 \cdot sk}{px_2 \cdot sk} \\ \Rightarrow s_1 \cdot px_1 \cdot (m_2 + r_2 \cdot sk) &= s_2 \cdot px_2 \cdot (m_1 + r_1\cdot sk) \end{align*} $$

So the private key $sk$ can be calculated as the $px_i$ is public.

How about the $k_i = [z_i \cdot P_1].x + [sk \cdot P_2].x$, and point $P_1, P_2$ is on the same curve. You can still calculate the private key by referring to here

liquan.eth
  • 111
  • 2
-3

This certainly creates the opportunity to mount a birthday attack. Oscar creates two Messages hashing to the same value - certainly doable at least with sha1 or MD5 and succeeds in making you sign both of them. He can then reconstruct your private key from the signatures.

I would certainly avoid deterministic ECDSA Signatures and regard the very act of securely creating the random number for signing as a core security feature.

In an ECDSA setting the (P)RNG is a prime target for attack. Tampering with this part is dangerous in my opinion, regardless whether it may mathematically be sound in principle.