Re: [Cfrg] Curve selection revisited

Mike Hamburg <mike@shiftleft.org> Tue, 29 July 2014 06:48 UTC

Return-Path: <mike@shiftleft.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 A9AAA1ABB1D for <cfrg@ietfa.amsl.com>; Mon, 28 Jul 2014 23:48:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.555
X-Spam-Level: *
X-Spam-Status: No, score=1.555 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, 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 o-y801t1NXPZ for <cfrg@ietfa.amsl.com>; Mon, 28 Jul 2014 23:48:39 -0700 (PDT)
Received: from aspartame.shiftleft.org (199-116-74-168-v301.PUBLIC.monkeybrains.net [199.116.74.168]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09ADE1A00BA for <cfrg@irtf.org>; Mon, 28 Jul 2014 23:48:39 -0700 (PDT)
Received: from [192.168.1.102] (unknown [192.168.1.1]) by aspartame.shiftleft.org (Postfix) with ESMTPSA id A25B53AA27; Mon, 28 Jul 2014 23:48:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shiftleft.org; s=sldo; t=1406616507; bh=34tfT/Yk1Wgyvhop5IF819KbEi2joAn9kv/sMlcD75c=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=gDW2lM9b4LUkuP+7f6TPY7I7UqYcF3iyZMVL9Lw1X/kM8IGSqQCleEE2l2swqhEFk frwrordQpEBxSqXIuSBfUt5+azNogz0CGiRXVmuFm+RyT5uV7K6+a5HvR9xyUlox+T NPaivaC5f7AcFtUNOrNENysxoOmBbt1UUL4L3q4c=
Message-ID: <53D743C1.1010401@shiftleft.org>
Date: Mon, 28 Jul 2014 23:48:33 -0700
From: Mike Hamburg <mike@shiftleft.org>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Paul Lambert <paul@marvell.com>, Hannes Tschofenig <hannes.tschofenig@gmx.net>
References: <CA+Vbu7xroa68=HOZtbf=oz7kK2EeUv_z1okpnjxHPR0ZtHD5cA@mail.gmail.com> <53D66506.4080809@htt-consult.com> <C0C42541-06A2-465B-82CF-00DA63BE1398@shiftleft.org> <419B47D0-2779-4463-A071-DA40F22C370F@shiftleft.org> <53D69280.2090208@gmx.net> <6AA56990-224C-4742-9BD0-A68808B1C944@shiftleft.org> <7BAC95F5A7E67643AAFB2C31BEE662D01EE48963E2@SC-VEXCH2.marvell.com>
In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D01EE48963E2@SC-VEXCH2.marvell.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/vwrHrmBazlLeR0OJUdE67fmsAX4
Cc: "cfrg@irtf.org" <cfrg@irtf.org>, Robert Moskowitz <rgm-sec@htt-consult.com>
Subject: Re: [Cfrg] Curve selection revisited
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: Tue, 29 Jul 2014 06:48:39 -0000


On 7/28/2014 5:33 PM, Paul Lambert wrote:
> Thank you for the details below.  One question on a comment you made:
>> Depending on the exact form of Schnorr, .
> So, what form of Schnorr signatures would you recommend?
>
> Paul
Let x be the secret key, g^k the nonce, e = H(stuff) the challenge and s 
= k - xe the response.

If you want short signatures it has to be (e,s).  Otherwise, (g^k,s) is 
slightly faster and batchable.    The hash should be H(pubkey||g^k||m) 
to prevent collision attacks, because you can and there's little downside.

I don't think there's a good case for setting s = ke - x.  It may resist 
some power attacks more easily, but it increases the attack surface and 
prevents optimizations.

-- Mike