Re: [Cfrg] Proposed requirements for curve candidate evaluation

Andrey Jivsov <crypto@brainhub.org> Fri, 08 August 2014 02:22 UTC

Return-Path: <crypto@brainhub.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 536391B2925 for <cfrg@ietfa.amsl.com>; Thu, 7 Aug 2014 19:22:20 -0700 (PDT)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 3_WE875cvcxb for <cfrg@ietfa.amsl.com>; Thu, 7 Aug 2014 19:22:18 -0700 (PDT)
Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:64]) by ietfa.amsl.com (Postfix) with ESMTP id DB9BE1B2924 for <cfrg@irtf.org>; Thu, 7 Aug 2014 19:22:18 -0700 (PDT)
Received: from omta14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by qmta07.emeryville.ca.mail.comcast.net with comcast id c0kz1o0031HpZEsA72NJ8S; Fri, 08 Aug 2014 02:22:18 +0000
Received: from [IPv6:::1] ([71.202.164.227]) by omta14.emeryville.ca.mail.comcast.net with comcast id c2NH1o00D4uhcbK8a2NHS7; Fri, 08 Aug 2014 02:22:18 +0000
Message-ID: <53E43459.4030305@brainhub.org>
Date: Thu, 07 Aug 2014 19:22:17 -0700
From: Andrey Jivsov <crypto@brainhub.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0
MIME-Version: 1.0
To: cfrg@irtf.org
References: <f9d9c886d08e4a4eb09c4a57584f950b@BL2PR03MB242.namprd03.prod.outlook.com>
In-Reply-To: <f9d9c886d08e4a4eb09c4a57584f950b@BL2PR03MB242.namprd03.prod.outlook.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1407464538; bh=dGcWTer4fUGMKyO2pF5RT0P2gSEh3dzdLFw9s1WR3bc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=MtUfT7Q2Z5Z8Lnti7SdAGdkiynrgoKeWCX3ARy68DPy0ZGungEXaUBULW00QH91yn FSA4yEqQr/ZrQ5XxsKQ8tNMuXJ9V59IsVJYGGlouPH3Zf8eeTl0mpLYpeL+YjrAt+u 7oWIL/mZ/3MPCvuW5hVeWIPQ0LqZoCxSVFfSZYHQYN6S8gE+t61FvDnRRUzmzK5P+w J6CspyME7i2+zVUahQn5k09LVCrLZYl4uGjd7lO8tp4dz8KLRs5JY+Sp7t50jS85aw hwx2q/WTl40Bf6IE0xIbK9bf4rTJV0NoNqlSqFwAx6FDpPllIwTFpj00N+CWBC8I04 AgLlRltzXLf/w==
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/bxWQyejlQ0QoTAIvKn9aroax9fc
Subject: Re: [Cfrg] Proposed requirements for curve candidate evaluation
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: Fri, 08 Aug 2014 02:22:20 -0000

On 08/07/2014 07:20 AM, Brian LaMacchia wrote:
> 4.	When evaluating candidate curves for use in ECDHE, "ephemeral" should be defined as "use exactly once in a key exchange" (or for TLS "use in exactly one handshake").
>
> During the second TLS meeting in Toronto, Kenny Paterson gave a presentation summarizing where CFRG was on this question at that time and one of the points he mentioned was that there was not consensus as to what "ephemeral" should mean for purposes of evaluating candidates.  Russ Housley then commented at the microphone that "ephemeral" should mean "used in exactly one handshake".  I strongly concur with Russ's position and suggest that we formally adopt that definition now during the Requirements phase.  The concrete implication of adopting this proposed requirement is that it means when we evaluate ECDHE performance for curve candidates we must include one fixed-base and one variable-base operation.

IMO I would prefer to see the actual numbers, i.e. the break-down of 
performance measurements instead of assuming some "package" of a likely 
usage pattern or combination of fixed-based+variable-based operations.

There is always one variable-base operation (time A).

In addition, there is either of these:
* a fixed-based operation or (a textbook case, time B)
* a fixed based operation plus the precomputation time attributed to the 
fixed base optimization (a short-lived context case, time B+P)
* an (un-optimized) fixed-based operation that uses the same code as 
variable-based operation (a small-footprint case, time A)
* reuse (time ~0)
( + There are other middle-of the road cases... )

A is the most important metric. B<A; the ratio B/A is needed to 
evaluate if the extra implementation effort and complexity is worth it. 
P is penalty and is important in some cases.