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

[Robert Moskowitz <[e-mail]>]

I failed to be clear in that 8-bit processors were in the sensor 
segment.  DSRC (IEEE 1609) is not so constrained (real electrons and 
such) and 32 bit is the norm.  My bad.

On 07/28/2014 11: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.

V2X almost always has the wherewithall for 32bit.  Potentially some 
roadside sensors might be so constrained, but not likely once you factor 
in the cost of an 802.11p radio, you might as well pay the little extra 
for 32 bit processors.

>
>> 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.

Imagine a congested roadway with every car screaming out what it is 
encountering and every car trying to validate those signed messages.  
Definitely more validations than signings.

>
>> 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.

Kind of what I was saying without going into the details of needing low 
over-the-air demands.  Spectrum, PHY contention algorithms, LBT (listen 
before transmit, or some such acronym) all add up to needing to be brief 
in what you transmit.  So it is recongnized that 32 byte keys are called 
for; but what of the key is actually sent?  And as William says, how big 
is the signature of the packet.  Is the key sent with every signed 
message or only when a new car is 'heard from'?  There are a number of 
optimizations to conserve the vary limited airway.

>
>> 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.

No.  Elsewhere; and still potentially in cars.

>
>> 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.

It was smartgrid related I saw the regulator reference.  The rule making 
is still a piece of work-in-progress for V2X.  But USDOT could come out 
with rules still this year.

>
>> 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.
>
> Cheers,
>
> William
>