Re: ECC Patents

Paul Rubin wrote:
> tomstdenis@gmail.com writes:
> > I think the worst thing they can do if they want to have the acceptance
> > of ECC is stiffle innovation and sit on top of a few patents.
>
> They might want ECC acceptance but they want even more to maximize
> their own profits. Look how RSA screwed up the field for 20 years
> and made out like bandits by doing so.

People still used RSA, just they didn't advertise or do it in the
USA...

The money isn't in holding the idea back it's in providing the
implementation.

And really what is the value? If some non-educated peep like myself
can implement ECC that is competitive then what value do they bring to
the table?

I'd like to think with the dozens of engineers they have they have more
to offer than just the algorithm. Like saying man-years of review and
verification, etc, etc... [something a loner like myself can't do].

> > [Cheap plug: I'm re-writing the ECC in my LTC to be among other things
> > cleaner and faster. It'll support both w-NAF and Fixed point
> > precomputation]
>
> Thing I'm concerned about is that Suite B stuff or whatever it is,
> will be required to do e-commerce with the govt, and as such will
> probably become a de facto industry standard as well. It sounds to me
> like someone pulled a fast one to get some protocol approved that
> requires licensing patents, when as you show, there's plenty of
> alternative approaches.

MQV and EKE are generally totally inappropriate solutions to a problem.
 If you ALREADY have a shared secret you don't need PK at all. You can
do a challenge repsonse session setup using a PRF...

The rest like EC-DH and EC-DSA are not subject to Certicom patents [for
one thing because they existed long before ECC was even an idea].

I'm hoping to get my ECC to the point where it's attractive enough to
pull people in [specially in the embedded market]. I've done test
builds of my TFM library where the fixed bigint size was as low as 576
bits to do things like P-256 ECC work. So I know the libraries can
work in low memory footprints [a point would be 240 bytes in memory
with this setup]. Of course TFM only really works on two non-x86
platforms. I need a MIPS port [and my ARM code tested] to round out
the collection.

By moving to w-NAF and mixed-coordinate points I plan on speeding up
the ECC code a good deal. Of course it'll require some interesting
design choices on how to piece them together (affine requires inversion
which isn't Montgomery friendly).

The fixed point stuff is where I'm really eager to see this fly. For
P-256 with a window of w=6 the memory requirement is 10KB and the
speedup over 5-NAF is 42D + 42A vs. 256D + 42A, assuming A = 2D that's
126 vs. 340 or 2.69x.

It's hard to find an embedded platform [capable of doing ECC] that
can't spare 10KB for an operation.

Tom
Received on Mon Oct 17 20:48:38 2005