Re: [Cfrg] [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement

Adam Back <adam@cypherspace.org> Sun, 12 January 2014 15:37 UTC

Return-Path: <adam@cypherspace.org>
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 3F1031ADFB6 for <cfrg@ietfa.amsl.com>; Sun, 12 Jan 2014 07:37:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 Ew22T29iAslr for <cfrg@ietfa.amsl.com>; Sun, 12 Jan 2014 07:37:13 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id E0AA71ADF78 for <cfrg@irtf.org>; Sun, 12 Jan 2014 07:37:12 -0800 (PST)
Received: from netbook (c107-70.i07-27.onvol.net [92.251.107.70]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MLeY7-1W25ye10CZ-000JYb; Sun, 12 Jan 2014 10:37:00 -0500
Received: by netbook (Postfix, from userid 1000) id 6D6F62E0888; Sun, 12 Jan 2014 16:36:53 +0100 (CET)
Received: by flare (hashcash-sendmail, from uid 1000); Sun, 12 Jan 2014 16:36:49 +0100
Date: Sun, 12 Jan 2014 16:36:49 +0100
From: Adam Back <adam@cypherspace.org>
To: Robert Ransom <rransom.8774@gmail.com>
Message-ID: <20140112153648.GB19922@netbook.cypherspace.org>
References: <87eh4e7a2y.fsf@latte.josefsson.org> <52D18475.10709@akr.io> <20140112062942.GA32437@LK-Perkele-VII> <52D29153.7000301@akr.io> <52D2AA91.8050804@fifthhorseman.net> <CABqy+spcrf+pOJaknOQoU+rVUvBrTyYZPCcJ9EpebuQm_=8anw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Disposition: inline
In-Reply-To: <CABqy+spcrf+pOJaknOQoU+rVUvBrTyYZPCcJ9EpebuQm_=8anw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Hashcash: 1:20:140112:rransom.8774@gmail.com::i9mInesJsiT+9LhZ:000000000000000 0000000000000000000000002kS5
X-Hashcash: 1:20:140112:dkg@fifthhorseman.net::HHJq1geF86g7I17n:0000000000000000 0000000000000000000000000bNV
X-Hashcash: 1:20:140112:cfrg@irtf.org::3L52hXQioAWu3ErJ:0000BDEb
X-Hashcash: 1:20:140112:adam@cypherspace.org::wM35QCNHxW/Bk8Ds:00000000000000000 0000000000000000000000005Mfd
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V02:K0:Th/po1KErTToUcB7J/CFEP7raA/Ccw0tfQ1qxizIXqO IWx+LT2WhlozGieF9Pe/MJQzoqcMXrilm/MxjpanC9f3wJh70P J/gd2HtUtpm20qn85+Fka+Hxaj1qdWJ3AHaksw75p0anWoD4VF FPk1SFkiphV38Vuqj/LchRzKMdsOKzfx/4e9cWcSVHe46t8ydX so87cFueHYFjp0/oBDR+Jd1q7c08tjO2rIelIWtGmbj15v7lxt fGWKOGrAscNFWEHfhJzHG/rK9BJnepptHtBZBWxlOVI1Zg8tlR 17AJSbdNepUyRTJEtfry2rEOGBe3mHHu7X/VMUKx26/9CPRLEe rCFyGwwVVLYymwBrp6TKrHlXNHdE4M6wPJM1Ps0o1
Cc: Adam Back <adam@cypherspace.org>, cfrg@irtf.org
Subject: Re: [Cfrg] [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement
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, 12 Jan 2014 15:37:14 -0000

On Sun, Jan 12, 2014 at 07:04:00AM -0800, Robert Ransom wrote:
>In the specific case of an EdDSA-like Schnorr signature scheme, the
>*beginning* of the input to the message hash function would be
>unpredictable to the attacker (thus achieving ‘randomized hashing’ for
>free).  This makes collision attacks harder with any reasonable hash
>function.

Actually that is a signature security threat-model artificiality.  While it
is true that it makes birthday collision harder for an attacker using a
signing oracle, if the attacker is the signer, its still the same.  And in
real life we care about that just as much.

Also Alyssa mentioned applications in PBKDF2 and hashcash which are like key
stretching and proof-of-work relying on 2nd-preimage respectively.

Adam