2
$\begingroup$

For an implementation of ECDSA, I'm considering the risks of publishing public keys together with multiple signatures.

From what Google tells me, a common pitfall is the use of the same random value K for multiple signatures.

My question is; are there any other known risks, or common mistakes, regarding the publishing of multiple signatures from one keypair?

$\endgroup$
4
  • 1
    $\begingroup$ Depending on how long the private key is in use, quantum computers may become a risk, they would be able to deduce the private key from the public key (obviously) or from a signature given that you know the data that is signed. $\endgroup$ – VincBreaker Aug 7 '18 at 8:52
  • $\begingroup$ @VincBreaker: Thanks for your answer. By deduction, I assume you mean brute force methods? $\endgroup$ – Kees Aug 7 '18 at 9:20
  • $\begingroup$ I would not call an attack that uses Shor's algorithm and a quantum computer brute force. Then again, it will still iterate over the possible values (even if it does this for many values at the same time, so in that sense it is brute force. But splitting hairs over terminology is commonly not that productive. $\endgroup$ – Maarten Bodewes Aug 7 '18 at 12:08
  • 1
    $\begingroup$ Just publishing public keys doesn't do anything by the way; the parties that want to verify the signature by a trusted public key. That has nothing to do with ECDSA though; that's a standard requirement for any signature scheme. The parties may also want to have a clue which public key needs to be for verification; trying all keys is not a good idea. You may want to use a key size of a particular size, and you may want to make sure that the hash algorithm is secure, i.e. SHA-2 or -3, not MD5 or SHA-1. $\endgroup$ – Maarten Bodewes Aug 7 '18 at 12:10
2
$\begingroup$

ECDSA is advertised to prevent existential forgery even in the face of an adaptive chosen-message attack. That is: even if the adversary can control the messages you sign, not just see a few signatures, they still can't find a single message/signature pair for a message they didn't ask you to sign.

As part of your obligations of the ECDSA security contract, of course, you must choose the per-signature secret $k$ independently and uniformly at random; if you fail to do this—if you repeat the per-signature secret, or if your choice of it is even substantially biased—then you might leak the private key. RFC 6979 defines a way to derive the per-signature secret by a pseudorandom function of the message under the secret key, which obviates the need for an entropy source at signing time—or at least mitigates a broken one.

But you could also just use Ed25519, which has this design built-in so you never need to worry about an entropy source at signing time, and has a clearer security story, and is an all-around better design.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.