Subject: Re: Why ECC?

From: [email-masked] (Peter Gutmann)
Date: Wed, 25 Sep 2002 03:18:31 +1200 (NZST)

Rodney Thayer <[email-masked]> writes:

>Why do we want ECC in OpenPGP?

Because it already contains every algorithm anyone could think of anyway, and a
few more for implementors to ignore wouldn't matter?

Peter.

---

From: Rodney Thayer <[email-masked]>
Date: Tue, 24 Sep 2002 08:30:28 -0700

>few more for implementors to ignore wouldn't matter?

Well as I see it there's the "lifeboat" principle.  If someone, somewhere,
publishes a 3-line perl script that breaks 2048 bit RSA, we'd like to have
a second public key algorithm in the protocol spec so we could switch over.

This has two problems:

-- the powers that be in the IETF tend to spit in your eye when you propose
this class of logic.  Been there, tried that.  They assume RSA is immortal.

-- we alread have DSA for that.  (Well if we want to claim RSA and DSA are
structurally related we don't but that's not the question at hand)

The second thing we're doing is violating the "it should be implementable"
principle.  These RFC's are supposed to be buildable by normal mortals.
Adding 80,000 bells and whistles is stupid -- we get specs that are
hard to implement, hard to interoperate, and hard to read (for things
like security flaws).

So, I come back to my question -- why do we want ECC?  If there isn't
a requirement it fulfills it shouldn't be in the standard -- it just
takes up space and causes problems.

---

From: "Michael Young" <[email-masked]>
Date: Tue, 24 Sep 2002 12:09:20 -0400

> >few more for implementors to ignore wouldn't matter?

I took Peter's comment as a joke, a jab at the load of things already there.

From: "Rodney Thayer" <[email-masked]>
> structurally related we don't but that's not the question at hand)

If we're going to fantasize about future breakthroughs, we could also
speculate that ECC and the integer DLP problems will be structurally related.

> principle.  These RFC's are supposed to be buildable by normal mortals.

I agree with this sentiment.  Interoperability for the masses is
important.  It's also fine to have a place for experimenters to
play, but there shouldn't be much pressure to get such things into
the specification.

> takes up space and causes problems.

At least in the last proposal I read, it takes up a LOT of space.
There were a dozen representation options.  It seemed quite unlikely
that anyone would implement more than a small subset.  Good luck
finding other interoperable implementations.

I'd be very happy for this to remain a separate document.