Subject: [Trans] [trans] #83 (rfc6962-bis): CT should mandate the use of deterministic ECDSA

From: "trans issue tracker" <[email-masked]>
Date: Wed, 01 Apr 2015 14:50:16 -0000

#83: CT should mandate the use of deterministic ECDSA

 RFC:6979 describes how to do deterministic ECDSA.

 certificate transparency logs should be required to use this mechanism,
 for two reasons:

  * using non-deterministic ECDSA with a predictable source of randomness
 means that each signature can potentially leak the secret material of the
 signing key.

  * a log that produces two separate valid STHs with the same timestamp and
 same data but with different signatures should be considered dubious
 (though i don't have a concrete attack i can describe for this scenario
 yet) -- ensuring the use of deterministic ECDSA means that in normal
 operation, regular logs won't produce this behavior.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-trans-
  [email-masked]  |  [email-masked]
     Type:  defect       |     Status:  new
 Priority:  major        |  Milestone:
Component:  rfc6962-bis  |    Version:
 Severity:  -            |   Keywords:
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/83>
trans <http://tools.ietf.org/trans/>

---

From: Russ Housley <[email-masked]>
Date: Wed, 1 Apr 2015 10:58:44 -0400

My understanding is that the first step in generating an ECDSA signature is to generate a random value K.  The private key is disclosed if the same K is used to produce more than one signature.  The chances of generating the same K is vanishingly small if there is a reasonable pseudorandom source.  I would hope that the servers running the logs have a reasonable source of pseudorandom values.

Russ

On Apr 1, 2015, at 10:50 AM, trans issue tracker wrote:

> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 01 Apr 2015 11:31:25 -0400

On Wed 2015-04-01 10:58:44 -0400, Russ Housley wrote:
> My understanding is that the first step in generating an ECDSA
> signature is to generate a random value K.  The private key is
> disclosed if the same K is used to produce more than one signature.

This is true.  AIUI, the private key is also disclosed if an attacker
can learn/predict/guess any single K used for a specific signature.

> The chances of generating the same K is vanishingly small if there is
> a reasonable pseudorandom source.  I would hope that the servers
> running the logs have a reasonable source of pseudorandom values.

I'd hope so too, but there's no reason to rely on that being the case.

The approach outlined in RFC 6979 avoids this risk entirely.

    --dkg

---

From: Watson Ladd <[email-masked]>
Date: Wed, 1 Apr 2015 08:37:09 -0700

> My understanding is that the first step in generating an ECDSA signature is to generate a random value K.  The private key is disclosed if the same K is used to produce more than one signature.  Th…

So these servers wouldn't be running Debian, would they? Or Freebsd
pre-release versions?

In fact, secret keys can be revealed via slight biases or a few leaked
bits of k over multiple signatures.

Sincerely,
Watson Ladd

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin