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

[William Whyte <[e-mail]>]

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.

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

Cheers,

William