Re: [Cfrg] RFC 6090 correctness

Watson Ladd <watsonbladd@gmail.com> Sun, 16 March 2014 01:42 UTC

Return-Path: <watsonbladd@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC5E1A0233 for <cfrg@ietfa.amsl.com>; Sat, 15 Mar 2014 18:42:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_22=0.6, SPF_PASS=-0.001] autolearn=no
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 1nan89NSqEtl for <cfrg@ietfa.amsl.com>; Sat, 15 Mar 2014 18:42:18 -0700 (PDT)
Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 840301A022A for <cfrg@irtf.org>; Sat, 15 Mar 2014 18:42:18 -0700 (PDT)
Received: by mail-yh0-f44.google.com with SMTP id f10so4100155yha.31 for <cfrg@irtf.org>; Sat, 15 Mar 2014 18:42:11 -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=8iWs2iwzeVYM4Qn3QfOaACMGT0b8xSEmkXzCMEF3NqY=; b=ZsUjVYvJltkYJnRN8JJ0as1qGAyvlP78LII+nCHP4T9MdNZZd47GkFcgzH2S/cFRtp Bf6BPhZVFMSIHJPtyE5me6OLqRhNPjmlH/FX+WDcdsMGCFqWW/6A1SUlXVW8Wdx1zTSu HaZOVjo0wigZfhvOP5Gu1/dGXZDQ/eYKie5Pvn3AbyFk0nV8DBLcFTZgQFZ/v/KMP72n Y0mIWEGIIO+lHdoorwEf1Rt7pKCRB2Vrw1a3vesguHIEDbYL+SKK7aDIFwC6zhZ4zLTa 441rUepqpEsbAc1K2hZx0SwYjg99r04nmcpKklrwgkQPthe06xpXsZSm5VrASnRwPmwJ FiHg==
MIME-Version: 1.0
X-Received: by 10.236.30.230 with SMTP id k66mr3639554yha.57.1394934130956; Sat, 15 Mar 2014 18:42:10 -0700 (PDT)
Received: by 10.170.80.214 with HTTP; Sat, 15 Mar 2014 18:42:10 -0700 (PDT)
In-Reply-To: <28EB012B-C9FE-4CF4-A039-E9DA5ECCD787@vpnc.org>
References: <CACsn0ck+8Rhxc1_4bp9za7n+Pe5Oan755CoxBs1ZnPFuruG6OQ@mail.gmail.com> <28EB012B-C9FE-4CF4-A039-E9DA5ECCD787@vpnc.org>
Date: Sat, 15 Mar 2014 18:42:10 -0700
Message-ID: <CACsn0cke8h-evUmQOQ3ehxiwzmU5CzTnQLrQMzh6s50egxosuA@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/AOii4vXUpPTs2jQGGglPkE9R3Pw
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] RFC 6090 correctness
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sun, 16 Mar 2014 01:42:20 -0000

On Sat, Mar 15, 2014 at 5:44 PM, Paul Hoffman <paul.hoffman@vpnc.org>; wrote:
> Please note that RFC 6090 already has a bunch of errata; see <http://www.rfc-editor.org/errata_search.php?rfc=6090>;. Maybe Watson and Tanja can coordinate on a concise statement of the current error and turn in a new errata. It would also be grand if people on the list went through the RFC with a finer-tooth comb than they did before it was published and report anything else.
>
> There are enough errata that it feels like the RFC should be updated to deal with them all.

I've submitted an erratum, but there are multiple possible fixes.
Furthermore, the nature of this error is significant: it may be
possible to exploit this mistake in implementations that slavishly
adhere to the RFC. One example of this causing security problems is in
Petersen commitments: ag+bh is usually computed by taking
(a-b)g+b(h+g) and so on recursively. If g and h are crafted so that
h+g results in 2g, not h+g, the commitment doesn't bind to any value
of b. Note that this doesn't require knowing the discrete log of g to
the base h, and in fact is compatible with some "nothing up my sleeve"
means of point generation.

Sincerely,
Watson Ladd
>
> --Paul Hoffman
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg



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