# Known risks for publishing ECDSA public keys and signatures

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?

• 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. – VincBreaker Aug 7 '18 at 8:52
• @VincBreaker: Thanks for your answer. By deduction, I assume you mean brute force methods? – Kees Aug 7 '18 at 9:20
• 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. – Maarten Bodewes Aug 7 '18 at 12:08
• 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. – Maarten Bodewes Aug 7 '18 at 12:10

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.