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

[Watson Ladd <[e-mail]>]

On Mon, Jul 28, 2014 at 8:59 PM, William Whyte
<[e-mail]> 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
> [e-mail]
> 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