Re: [Cfrg] IEEE 1609 requirements (was Re: Curve selection revisited)

Watson Ladd <> Tue, 29 July 2014 04:14 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 574CC1A01E6 for <>; Mon, 28 Jul 2014 21:14:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id r05cqtyoiod0 for <>; Mon, 28 Jul 2014 21:14:18 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4EC271A0020 for <>; Mon, 28 Jul 2014 21:14:18 -0700 (PDT)
Received: by with SMTP id b6so5393382yha.22 for <>; Mon, 28 Jul 2014 21:14:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IMKKf4ogNR4ik4LQJGEEsd/4m6QljCCMWgqCJ1+6iwI=; b=LMSEEitupsoDjMeaDsW7sSZ+GOoYlDhg/lKzru5tGemHPIvqWg0ygsqu3FzS/Ic5Ek 8bCqt980jPRZEhvi+hzGNTQkkkCv8cruPDJdZSgrylW3Mirj3Nlvc+ToM9F91hrib6UP 4vtpQBBRSIcBh2boYPuS6HAYJnOup/SDa6sOuQOmzOuAgRLv1HTyKmtnGIaPh3HU9h34 bEAUg+WFrtwpS8rZsfPwf0tPXASzvK/PRjvhiX+0p6A2/gdm2Ncw+2/J57Q2cSC8bG16 q4HFg2nuugN1QRtvbxUFFNPJ2wEfH3nTzDflQsNPdG8jOJsHCwyh9b1iyXQiHrXn+UeQ zV0g==
MIME-Version: 1.0
X-Received: by with SMTP id d13mr10048402yho.133.1406607257598; Mon, 28 Jul 2014 21:14:17 -0700 (PDT)
Received: by with HTTP; Mon, 28 Jul 2014 21:14:17 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Mon, 28 Jul 2014 21:14:17 -0700
Message-ID: <>
From: Watson Ladd <>
To: William Whyte <>
Content-Type: text/plain; charset=UTF-8
Cc: "" <>, Robert Moskowitz <>
Subject: Re: [Cfrg] IEEE 1609 requirements (was Re: 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 04:14:20 -0000

On Mon, Jul 28, 2014 at 8:59 PM, William Whyte
<>; wrote:
> Hi all,
> Some notes on Bob's comments in the context of vehicle-to-vehicle
> communications. He's on point in general but I have a few corrections,
> below.
> One thing to say in general about the V2V safety communications: these
> are devices that, as Bob says, have a very long lifetime and may be
> hard to upgrade in the field. They also need to be produced in
> reasonable volumes and be durable. These all push the groups working
> on V2X communications in the direction of using crypto technology
> that's already widespread, so both the US and the EU groups working on
> this are currently using NIST p256 and it would be difficult to
> persuade them to change at this point (with some exceptions, see
> below).
> Personally, I regret that we're using the NIST curves, given the poor
> quality of their generation process, but I don't see the marketplace
> as yet having picked a winner from the alternatives.
>> 8 bit processors are the norm, and NO, Dr. Moore is NOT going to change
>> that.
> It's not clear that this is the case for V2V safety communications.
> Collision prediction is fairly processor-intensive. All the prototypes
> I know of have been on 32-bit processors. I don't see an ability to
> support 8-bit processors as particularly important.
>> Hardware acceleration is acceptable, but that could
>> make in-field corrections impossible.
> One potential bottleneck bottleneck is verification of incoming
> messages. There may be 1000 incoming messages per second. Verifying
> all of these requires hardware acceleration on any realistic
> automotive device and for any choice of curve that I'm aware of.
> Another alternative is to only verify certain messages, for example
> from cars that might potentially cause a hazard. Hardware acceleration
> is possible, but raises costs and risks locking in a particular crypto
> solution. Europe and the US are taking different approaches to this:
> in the European system, the intent is that every message is verified,
> while in the US the emphasis is more on verify on demand.

Batch verification of some variants of Schnorr is extremely efficient,
thus reducing
per-signature costs. I assume this has been considered.

>> 1) Low over-the-air demands.  Every BIT counts.  We have to live with 32
>> bytes; but 64 bytes may be too much.
> Spectrum is another very constrained resource. If we could potentially
> shave 16 bytes off every signature that's something we could be very
> interested in.
>> 3) Performance on an 8 bit  processor.  Performance is measured in time and
>> energy.
> As above, I don't think 8-bit performance is huge for V2V communications.
>> 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.
> If the expert judgement of the technical working groups is that a
> different algorithm than ECDSA is better, we don't believe there would
> be a regulatory barrier to using that other algorithm.
>> But please just don't solve this for TLS on octo-core 64-bit systems.
> Yes! In particular, whatever choice is made by CFRG is likely to be
> more widely supported in hardware than any alternative, so CFRG's
> choice will be the strongest candidate to replace ECDSA if it has
> sufficient advantages.

Well, unfortunately we are not adopting Schnorr signatures at this
time. (We probably should).
I also don't see us working on binary curves, which are natural
candidates for hardware due to easier
arithmetic (no carries). But fundamentally we're here with a very
specific request: do your own homework
if that request ignores you.

(Adoption in hardware is likely to be slow)

Watson Ladd
> Cheers,
> William
> _______________________________________________
> Cfrg mailing list

"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin