Re: [Cfrg] Curve selection revisited

Paul Lambert <> Tue, 29 July 2014 01:18 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D844C1A0375 for <>; Mon, 28 Jul 2014 18:18:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.267
X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id U6QIJ6jdH5FA for <>; Mon, 28 Jul 2014 18:18:11 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C369F1A031F for <>; Mon, 28 Jul 2014 18:18:10 -0700 (PDT)
Received: from pps.filterd ( []) by (8.14.5/8.14.5) with SMTP id s6T1I5oq027181; Mon, 28 Jul 2014 18:18:05 -0700
Received: from ([]) by with ESMTP id 1ndran1r9y-13 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 28 Jul 2014 18:18:05 -0700
Received: from ([]) by ([fe80::e56e:83a7:9eef:b5a1%16]) with mapi; Mon, 28 Jul 2014 18:18:02 -0700
From: Paul Lambert <>
To: Hannes Tschofenig <>, Michael Hamburg <>, Robert Moskowitz <>
Date: Mon, 28 Jul 2014 18:18:00 -0700
Thread-Topic: [Cfrg] Curve selection revisited
Thread-Index: Ac+qjaBszSri18kSTT+f7xU0/QiRYAAPPxyQ
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-07-28_04:2014-07-28,2014-07-28,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407290016
Cc: "" <>
Subject: Re: [Cfrg] Curve selection revisited
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 29 Jul 2014 01:18:13 -0000

]PS: Regarding the ASN.1 format I am wondering whether the IEEE has done
]some more detailed analysis of the over-the-wire and the software
]implementation cost. This would be useful for us in the ACE working
I know of one IEEE group that is working on raw representation of a point
for Curve25519.
In another - X.509/PKIX formats are proposed largely because they exist.

I'm partial to opaque non-ASN.1 myself.


]On 07/28/2014 07:05 PM, Michael Hamburg wrote:
]> You're going to need a hardware accelerator for some of these small
]> things.  Eg for v2v safety, the real ask has to be "fast and small and
]> easy in hardware".  The best solution to this is binary curves, though
]> they are considered slightly edgy right now.
]> But yeah, 8-bit processor performance is important too.
]> Cheers, - Mike
]> On Jul 28, 2014, at 7:58 AM, Robert Moskowitz
]> <> wrote:
]>> The whole world is NOT TLS.  For example I am working in IEEE 1609
]>> which is Vehicle-to-vehicle safety communications and their need is
]>> for signed data objects that are quickly generated and verified (you
]>> have ~100ms from the braking event to all the cars being able to act
]>> on that information).  I also work in IEEE 802.15.4 highly
]>> constrained devices (some much smaller than what many IETF groups
]>> accept as their lower limit).
]>> 8 bit processors are the norm, and NO, Dr. Moore is NOT going to
]>> change that.  Lower energy demand is much higher on the design plan
]>> than faster processing.  Also whatever is done will be running on
]>> fielded devices for the next 10 - 20 years.  Hardware acceleration is
]>> acceptable, but that could make in-field corrections impossible.
]>> Over-the-air firmware updates may also be impossible (802.15.4k is
]>> 40kb/s) or only done in the dealership (yes!  another recall!).
]>> So getting on to my thoughts of curve selection requirements for the
]>> world of small:
]>> 1) Low over-the-air demands.  Every BIT counts.  We have to live with
]>> 32 bytes; but 64 bytes may be too much.  Oh, IEEE 1609.2 has its own
]>> 'certificate' and signature format as even the standard
]>> asn.1 is too wasteful of the very limited channel.  This applies also
]>> in 802.15.4 where adding another MAC frame might mean that the whole
]>> thing fails because now it is more likely that one frame got lost.
]>> 2) Easy/size of implementation.  There has been lots of chatter here
]>> about how NIST p256 can be implemented wrongly.  Here it is of
]>> greater concern, as it might require a physical swap-out to correct
]>> an implementation error.  Manufacturers look at the cost of a
]>> programmer to save 5K code cheaper than that extra 5K footprint.
]>> So little code and easy to code.  This world is extremely price
]>> sensitive.
]>> 3) Performance on an 8 bit  processor.  Performance is measured in
]>> time and energy.  In-vehicle devices tend to have a ready source of
]>> electrons (except for tire gauges!), but some devices have limited
]>> battery (your front door lock) or NO battery (MEMEs energy harvesters
]>> on bridge stress sensors).  So low energy is as important as quickly
]>> done.  Here 10% faster IS 10% faster; and it could make a
]>> life-or-death difference. (In Positive Train Control, the automatics
]>> MUST take over if the human can no longer respond in time and bullet
]>> trains can take 7Km to stop safely)
]>> 4) preserving ECDSA and ECDHE.  This is what is currently in use, and
]>> in some cases written into regulations (urgh), so we have to still
]>> keep them working.  But if something 'new' and provably good makes a
]>> big difference in one of the previous needs I suspect there will be
]>> an attentive audience.
]>> I have tried to keep things general so as not too much to limit
]>> choices.  I never claimed to be a crytographer or to have the math
]>> skills to evaluate the various contenders.  Others working in this
]>> area might have their own reading on the needs of constrained
]>> devices/communications.
]>> But please just don't solve this for TLS on octo-core 64-bit systems.
]>> On 07/25/2014 01:10 AM, Benjamin Black wrote:
]>>> Inspired by some comments from other and in hopes of returning to a
]>>> more productive debate rather than the pointed back and forth, of
]>>> which I am absolutely guilty, I'm suggesting a few constraints.
]>>> These are not priority ordered and none of them deal with the math,
]>>> instead focusing on process and practice.
]>>> 1) As we are discussing this in the context of TLS, the performance
]>>> of various kx options must be evaluated for ECDHE as typically
]>>> deployed. ECDH is neither common nor recommended in the TLS BCP
]>>> draft. In addition, I hope there will be discussion of benchmarking
]>>> methodology, with the understanding the ultimate choice is for the
]>>> CFRG chairs.
]>>> 2) Performance must be measured using "production-quality"
]>>> implementations. By this I mean implementations which employ the
]>>> sort of techniques/optimizations appropriate for large scale
]>>> deployment. This is specifically intended to exclude discussion of
]>>> how simple or fast an implementation _could_ be, in favor of what
]>>> they actually are in practice. However, the goal is to select curves
]>>> which strike the best balance between various requirements, not
]>>> simply the fastest.
]>>> 3) The timeframe for a decision constrains the scope of this
]>>> process. If a decision is desired within a few months, then it is
]>>> difficult to include options beyond new curves. If a decision can
]>>> take a year, new algorithms could be considered. Given the
]>>> importance, impact, and contentiousness of new algorithms, I believe
]>>> it would be difficult to complete a thorough, careful algorithm and
]>>> curve selection process in a short amount of time.
]>>> 4) The precise set of security levels needed should be specified in
]>>> advance (whether by TLS or CFRG) and curve recommendations delivered
]>>> together for all levels. A stated goal is to use these curves in new
]>>> drafts, and it minimizes work to specify all security levels for a
]>>> proposal in the same draft. This is strictly a practical matter
]>>> recognizing the chairs and area directors have limited bandwidth and
]>>> implementors can get everything done in a single go.
]>>> 5) Selections must efficiently support TLS 1.2. Adoption of new
]>>> curves, and potentially new algorithms, can't be gated on completion
]>>> and widespread deployment of TLS 1.3.
]>>> 6) Drop-in replacement for the NIST curves is _not_ a requirement in
]>>> this process.
]>>> 7) I don't think the chairs are signing up for a full-on, NIST-style
]>>> selection competition and we should aim to keep things are
]>>> lightweight as possible while still achieving the required level of
]>>> rigor. I hope they will address this point soon.
]>> _______________________________________________ Cfrg mailing list
]> _______________________________________________ Cfrg mailing list