IETF Logo Mail Archive

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

Watson Ladd <watsonbladd@gmail.com> Wed, 01 April 2015 15:38 UTC

Return-Path: <watsonbladd@gmail.com>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9F121ACEC8 for <trans@ietfa.amsl.com>; Wed, 1 Apr 2015 08:38:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-F3ppK5YNLL for <trans@ietfa.amsl.com>; Wed, 1 Apr 2015 08:38:50 -0700 (PDT)
Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F8D11ACDE5 for <trans@ietf.org>; Wed, 1 Apr 2015 08:37:10 -0700 (PDT)
Received: by wgdm6 with SMTP id m6so57685332wgd.2 for <trans@ietf.org>; Wed, 01 Apr 2015 08:37:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Ihf4gSxr/ZSDoHBN/MCMXj3hvKomG4zUyeBPGuwDETc=; b=Ul438wuJ5c4G6J+30pSMfLCFLQICAEDN5PS74sbxc8T/OPhv6J+i4Xo++Q+obp3hTB 9eDXPlaANqLK58Z1dDa9SZbOHqVSJxyqG9aq37Zev5UnswtfgoFufTsH03pbOD5E+J9h ffCjz2VWAeK0qVHdPqoaWjlmj5JX0PnGOq+27VCvS5dHoo0wCe+cX9C5zMjAuSswQKDA s2iD8gsBAH2xRj6zxt8sA5NSonrmiPgTPV1yLWmqFSFI8/aI/0bDrPTLAdrJscLY7C2M pcSDii+UR65jmVtNwjfHSUwfFq8e6Bduz0BeYIbuOeWrsjLfUAJWZ22DDqPNCCnmP4Dg rjZw==
MIME-Version: 1.0
X-Received: by 10.194.9.98 with SMTP id y2mr86915115wja.85.1427902629284; Wed, 01 Apr 2015 08:37:09 -0700 (PDT)
Received: by 10.194.136.233 with HTTP; Wed, 1 Apr 2015 08:37:09 -0700 (PDT)
In-Reply-To: <F1F5B0F5-5840-4859-9954-7E5D7B6B1949@vigilsec.com>
References: <061.2bfddb2a99fba55e98e48bb1cf4767e9@tools.ietf.org> <F1F5B0F5-5840-4859-9954-7E5D7B6B1949@vigilsec.com>
Date: Wed, 01 Apr 2015 08:37:09 -0700
Message-ID: <CACsn0cmj_AneKtAbaJM9C-qKASnoLn=jgU+EBORd8HqgEG7Wug@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Russ Housley <housley@vigilsec.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/trans/ERuZxiwCipT3FukvOJGMuv8VJ4w>
Cc: "trans@ietf.org" <trans@ietf.org>
Subject: Re: [Trans] [trans] #83 (rfc6962-bis): CT should mandate the use of deterministic ECDSA
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Apr 2015 15:38:53 -0000

On Wed, Apr 1, 2015 at 7:58 AM, Russ Housley <housley@vigilsec.com> wrote:
>  * using non-deterministic ECDSA with a predictable source of randomness
> means that each signature can potentially leak the secret material of the
> signing key.
>
> 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.

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

>
> Russ
>
>
> On Apr 1, 2015, at 10:50 AM, trans issue tracker wrote:
>
>> #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-
>>  dkg@fifthhorseman.net  |  rfc6962-bis@tools.ietf.org
>>     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/>
>>
>> _______________________________________________
>> Trans mailing list
>> Trans@ietf.org
>> https://www.ietf.org/mailman/listinfo/trans
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans



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

v2.23.0 | Report a Bug | By Email