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

Watson Ladd <watsonbladd@gmail.com> Tue, 29 July 2014 04:14 UTC

Return-Path: <watsonbladd@gmail.com>
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 574CC1A01E6 for <cfrg@ietfa.amsl.com>; Mon, 28 Jul 2014 21:14:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r05cqtyoiod0 for <cfrg@ietfa.amsl.com>; Mon, 28 Jul 2014 21:14:18 -0700 (PDT)
Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EC271A0020 for <cfrg@irtf.org>; Mon, 28 Jul 2014 21:14:18 -0700 (PDT)
Received: by mail-yh0-f49.google.com with SMTP id b6so5393382yha.22 for <cfrg@irtf.org>; Mon, 28 Jul 2014 21:14:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.236.202.141 with SMTP id d13mr10048402yho.133.1406607257598; Mon, 28 Jul 2014 21:14:17 -0700 (PDT)
Received: by 10.170.202.8 with HTTP; Mon, 28 Jul 2014 21:14:17 -0700 (PDT)
In-Reply-To: <CACz1E9qP04tnXuCWtiGFrT3FGSR_9SrYpBQQe3F07k3+T2DBZw@mail.gmail.com>
References: <CACz1E9qP04tnXuCWtiGFrT3FGSR_9SrYpBQQe3F07k3+T2DBZw@mail.gmail.com>
Date: Mon, 28 Jul 2014 21:14:17 -0700
Message-ID: <CACsn0ckeUWdbAHmfh7bE1vo1BydReHX+XhT4d8wQPVGbW7eSDA@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: William Whyte <wwhyte@securityinnovation.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/VSBzfV_BDDcRsizkN-jnHTv9KGo
Cc: "cfrg@irtf.org" <cfrg@irtf.org>, Robert Moskowitz <rgm-sec@htt-consult.com>
Subject: Re: [Cfrg] IEEE 1609 requirements (was Re: 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 04:14:20 -0000

On Mon, Jul 28, 2014 at 8:59 PM, William Whyte
<wwhyte@securityinnovation.com>; 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)

Sincerely,
Watson Ladd
>
> Cheers,
>
> William
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg



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