Re: [Cfrg] (flaws with Curve25519 DH function, if one does not check the output) Re: Elliptic Curves - curve form and coordinate systems
Watson Ladd <watsonbladd@gmail.com> Mon, 16 March 2015 15:39 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 0A1EE1A8757 for <cfrg@ietfa.amsl.com>; Mon, 16 Mar 2015 08:39:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1
X-Spam-Level:
X-Spam-Status: No, score=-1 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, FREEMAIL_REPLY=1, 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 64zPEFT3HT6B for <cfrg@ietfa.amsl.com>; Mon, 16 Mar 2015 08:39:07 -0700 (PDT)
Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (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 838171A1A91 for <cfrg@irtf.org>; Mon, 16 Mar 2015 08:39:07 -0700 (PDT)
Received: by ykek76 with SMTP id k76so19117850yke.0 for <cfrg@irtf.org>; Mon, 16 Mar 2015 08:39:07 -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; bh=P/xGQM+iPUij9Qk/nNbd+v0fynHLI60nhvMaBBiFOYc=; b=V7FO1JgyQtzoe8SZa7akefBOy+2yZmEnZFnijXVgrH+PqXp68DXswLbob3VQljZcsJ RJe1xlMTtVN7eOYmfs3dwyZA3W6H4dQb5eNmDIxr/v+uii1SD+w9KMvHJtx3GSF21jZf 58EkUyS0QnUiac8YNsUFZH3unjeT94UbTixZBwL03eG0AhYGdgTYmUO0WLxIzKjIa0e0 BXdUUgNvpZ6g0PCdiHsFW8Lny9AvY9LJUSRBXAIiEZIVsScc7jlRXWeHaO0lWloyjHDI z8iyyZfAl89iXbPfCkkwiS9ua0n+O47vVWQ9lLUy6FRLNrMZftslT6ktbH++xOMnvAWS ddKA==
MIME-Version: 1.0
X-Received: by 10.236.18.194 with SMTP id l42mr62130422yhl.172.1426520346908; Mon, 16 Mar 2015 08:39:06 -0700 (PDT)
Received: by 10.170.58.201 with HTTP; Mon, 16 Mar 2015 08:39:06 -0700 (PDT)
In-Reply-To: <5506EF80.7010809@gmail.com>
References: <5501E6A5.5040608@brainhub.org> <A6F30412-8E0A-4D8D-9F26-580307B46874@shiftleft.org> <20150316002255.28855.qmail@cr.yp.to> <20150316044906.GA27479@mournblade.imrryr.org> <5506D5BB.3090700@gmail.com> <20150316135620.GC27479@mournblade.imrryr.org> <5506EF80.7010809@gmail.com>
Date: Mon, 16 Mar 2015 08:39:06 -0700
Message-ID: <CACsn0ck6EY1PVB39a6gTxrnxgPTY_quMRGya2jm79CsH4iLC4Q@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Rene Struik <rstruik.ext@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/oprfcN7ETp2AtBzzdxNpzbpzjV0>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] (flaws with Curve25519 DH function, if one does not check the output) Re: Elliptic Curves - curve form and coordinate systems
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: Mon, 16 Mar 2015 15:39:09 -0000
On Mon, Mar 16, 2015 at 7:58 AM, Rene Struik <rstruik.ext@gmail.com> wrote: > Hi Viktor: > > The key words in your email are "depending on", which does suggest that > protocol analysis may become quite unwieldy and error-prone itself. > > For some examples of authenticated key agreement schemes that are supposedly > secure against, e.g., the unknown key share attack, but where this does not > seem to hold any more if the DH key is publicly computable, see, e.g., > > Alfred Menezes, Simon Blake-Wilson, > Unknown Key Share Attacks Against the Station-to-Station (STS) Protocol, > PKC 1999. > > This suggests that what you seem to dismiss as an "attack", may indeed be > one (i.e., one without your quotation marks). No, the protocol analysis is very simple. If you hash the transcript with the shared secret, and use that as the key, you never have to worry about contributory behavior. Even if an attacker dictates the computed key, that key will never match one computed by an honest participant. The problem is this needs to include all messages sent before the key is established. Most protocols do this and don't require contributory behavior. This is a standard technique for simplifying security analysis. Of course, we've always described what's required to ensure contributory behavior in Curve25519, and it's always the case that implementors should know what the protocol requires as far as assuring contributory behavior, namely rejecting 8 inputs. TLS is really the odd man out in requiring contributory behavior. But let's assume that we need contributory behavior. Then simply returning an ignorable error code doesn't work. Instead the function should return 32 random bytes if computing 0, so as to avoid ignoring the errors. Sincerely, Watson Ladd > > Rene > > On 3/16/2015 9:56 AM, Viktor Dukhovni wrote: > > On Mon, Mar 16, 2015 at 09:08:11AM -0400, Rene Struik wrote: > > You are correct: I have no idea where Dan Bernstein got that from. I *did* > comment on the DH function, which, with Montgomery-style specification as > in the "Curve25519" draft, is completely insecure, if one does not check > the output to be nonzero. This is a form of the small subgroup attack and > has been known for over 15 years. > > But in this case the "attack" does not leak any secret key bits > from either party. So depending on the higher level protocol there > may not be any issues, provided such an agreement between M and B > does not enable M to impersonate B in a communication between A > and B. > > I gather then that this is the issue, and that such higher level > protocols should reject the zero public key (or avoid the problem > by ensuring that predictable ECDH output cannot lead to MiTM issues > on other traffic). > > > > -- > email: rstruik.ext@gmail.com | Skype: rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 > > > _______________________________________________ > 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
- Re: [Cfrg] Elliptic Curves - curve form and coord… Viktor Dukhovni
- Re: [Cfrg] Elliptic Curves - curve form and coord… Andrey Jivsov
- Re: [Cfrg] Elliptic Curves - curve form and coord… Michael Hamburg
- Re: [Cfrg] Elliptic Curves - curve form and coord… Rene Struik
- Re: [Cfrg] Elliptic Curves - curve form and coord… Rene Struik
- Re: [Cfrg] Elliptic Curves - curve form and coord… D. J. Bernstein
- Re: [Cfrg] Elliptic Curves - curve form and coord… Rene Struik
- Re: [Cfrg] Elliptic Curves - curve form and coord… Ilari Liusvaara
- Re: [Cfrg] Elliptic Curves - curve form and coord… Alyssa Rowan
- Re: [Cfrg] Elliptic Curves - curve form and coord… Alyssa Rowan
- Re: [Cfrg] Elliptic Curves - curve form and coord… Michael Hamburg
- Re: [Cfrg] Elliptic Curves - curve form and coord… Andrey Jivsov
- Re: [Cfrg] Elliptic Curves - curve form and coord… Ilari Liusvaara
- [Cfrg] (flaws with Curve25519 DH function, if one… Rene Struik
- Re: [Cfrg] (flaws with Curve25519 DH function, if… Ilari Liusvaara
- Re: [Cfrg] Elliptic Curves - curve form and coord… Viktor Dukhovni
- Re: [Cfrg] Elliptic Curves - curve form and coord… Watson Ladd
- [Cfrg] (flaws with Curve25519 DH function, if one… Rene Struik
- Re: [Cfrg] (flaws with Curve25519 DH function, if… Watson Ladd
- Re: [Cfrg] Elliptic Curves - curve form and coord… Michael Hamburg
- Re: [Cfrg] Elliptic Curves - curve form and coord… Nico Williams
- Re: [Cfrg] (flaws with Curve25519 DH function, if… David Leon Gil
- Re: [Cfrg] (flaws with Curve25519 DH function, if… Viktor Dukhovni
- Re: [Cfrg] (flaws with Curve25519 DH function, if… Nico Williams
- Re: [Cfrg] (flaws with Curve25519 DH function, if… CodesInChaos
- Re: [Cfrg] (flaws with Curve25519 DH function, if… Salz, Rich
- Re: [Cfrg] (flaws with Curve25519 DH function, if… Watson Ladd
- Re: [Cfrg] (flaws with Curve25519 DH function, if… Ilari Liusvaara
- Re: [Cfrg] (flaws with Curve25519 DH function, if… CodesInChaos
- Re: [Cfrg] (flaws with Curve25519 DH function, if… Watson Ladd
- Re: [Cfrg] Elliptic Curves - curve form and coord… Alexey Melnikov
- [Cfrg] Elliptic Curves - curve form and coordinat… Alexey Melnikov
- Re: [Cfrg] Elliptic Curves - curve form and coord… Watson Ladd
- Re: [Cfrg] Elliptic Curves - curve form and coord… Dan Brown
- Re: [Cfrg] Elliptic Curves - curve form and coord… Alyssa Rowan
- Re: [Cfrg] Elliptic Curves - curve form and coord… Phillip Hallam-Baker
- Re: [Cfrg] Elliptic Curves - curve form and coord… Tony Arcieri
- Re: [Cfrg] Elliptic Curves - curve form and coord… Ilari Liusvaara
- Re: [Cfrg] Elliptic Curves - curve form and coord… Mike Hamburg
- Re: [Cfrg] Elliptic Curves - curve form and coord… Nadim Kobeissi
- Re: [Cfrg] Elliptic Curves - curve form and coord… Adam Langley
- Re: [Cfrg] Elliptic Curves - curve form and coord… Andrey Jivsov
- Re: [Cfrg] Elliptic Curves - curve form and coord… Adam Langley
- Re: [Cfrg] Elliptic Curves - curve form and coord… Phillip Hallam-Baker
- Re: [Cfrg] Elliptic Curves - curve form and coord… Paul Lambert
- Re: [Cfrg] Elliptic Curves - curve form and coord… Andrey Jivsov
- Re: [Cfrg] Elliptic Curves - curve form and coord… Salz, Rich
- Re: [Cfrg] Elliptic Curves - curve form and coord… Adam Langley
- Re: [Cfrg] Elliptic Curves - curve form and coord… Nico Williams
- Re: [Cfrg] Elliptic Curves - curve form and coord… Michael Hamburg
- Re: [Cfrg] Elliptic Curves - curve form and coord… Michael Hamburg
- Re: [Cfrg] Elliptic Curves - curve form and coord… Dan Brown
- Re: [Cfrg] Elliptic Curves - curve form and coord… Andrey Jivsov
- Re: [Cfrg] Elliptic Curves - curve form and coord… Paterson, Kenny
- Re: [Cfrg] Elliptic Curves - curve form and coord… Andrey Jivsov
- Re: [Cfrg] Elliptic Curves - curve form and coord… Michael Hamburg
- Re: [Cfrg] Elliptic Curves - curve form and coord… Andrey Jivsov
- Re: [Cfrg] Elliptic Curves - curve form and coord… Jakob Breier
- Re: [Cfrg] Elliptic Curves - curve form and coord… Phillip Hallam-Baker
- Re: [Cfrg] Elliptic Curves - curve form and coord… Rene Struik
- Re: [Cfrg] Elliptic Curves - curve form and coord… Watson Ladd
- Re: [Cfrg] Elliptic Curves - curve form and coord… Rene Struik
- Re: [Cfrg] Elliptic Curves - curve form and coord… Nico Williams
- Re: [Cfrg] Elliptic Curves - curve form and coord… Watson Ladd
- Re: [Cfrg] Elliptic Curves - curve form and coord… Rene Struik
- Re: [Cfrg] Elliptic Curves - curve form and coord… Jakob Breier
- Re: [Cfrg] Elliptic Curves - curve form and coord… Ilari Liusvaara
- Re: [Cfrg] Elliptic Curves - curve form and coord… Watson Ladd
- Re: [Cfrg] Elliptic Curves - curve form and coord… Andrey Jivsov
- Re: [Cfrg] Elliptic Curves - curve form and coord… Rene Struik
- Re: [Cfrg] Elliptic Curves - curve form and coord… Michael Hamburg
- Re: [Cfrg] Elliptic Curves - curve form and coord… Salz, Rich
- Re: [Cfrg] Elliptic Curves - curve form and coord… Andrey Jivsov
- Re: [Cfrg] Elliptic Curves - curve form and coord… Michael Hamburg