Cringely Gives KnowNow Some Unbelievable Free Press... (fwd)

Eric Rescorla ekr at rtfm.com
Tue Feb 5 11:11:19 EST 2002


Although the headers and quoting have gotten munged, this
appears to be a reply to my message.

Eugene Leitl <Eugene.Leitl at lrz.uni-muenchen.de> writes:

> -- Eugen* Leitl <a href="http://leitl.org">leitl</a>
> ______________________________________________________________
> ICBMTO: N48 04'14.8'' E11 36'41.2'' http://www.leitl.org
> 57F9CFD3: ED90 0433 EB74 E4A9 537F CFF5 86E7 629B 57F9 CFD3
> 
> ---------- Forwarded message ----------
> Date: Tue,  5 Feb 2002 11:10:49 +0100 (CET)
> From: Robert Harley <harley at argote.ch>
> To: fork at xent.com
> Subject: Re: Cringely Gives KnowNow Some Unbelievable Free Press...
> 
> Eugene Leitl wrote:
> >If you want to see EC used you need to describe a specific algorithm
> >which has the following three properties:
> >
> >(1) widely agreed to be unencumbered, [...]
> 
> No problem.  Use a random secure curve over a binary field with a
> polynomial basis (or over a random prime field).  Do it in software
> using standard text-book algorithms.  Use a protocol that is
> in the clear such as plain Diffie-Hellman key exchange.
And this is how fast?

> EL:
> >(2) significantly better than RSA (this generally means faster)
> 
> This seems a little bit simplistic...  Whatever way you cut it, RSA
> will beat ECC on public key ops (encryption, signature verification...)
> whereas ECC will beat RSA on private key ones (decryption, signing...)
> 
> The speed argument can be compelling or not depending on what you want
> to do.
It's the only real argument that ECC's got going for it. RSA can
be made arbitrarily fast by making it arbitrarily slow.

> EL:
> >Until someone does that, the cost of information in choosing an EC
> >algorithm is simply too high to justify replacing RSA in most
> >applications.
> 
> Personally, I no longer trust RSA for long term security.
> 
> This is public-key crypto, not symmetric, so a break of your RSA key
> means that all your encrypted traffic becomes readable rather than
> just one message.  E.g., if a few years ago you used 512-bit RSA to
> encrypt a will that was not to be read by anybody until you die,
> that's tough because it could be read today.  Doesn't matter that you
> moved to 768 bits and then 1024 in the meantime.
If you care about Perfect Forward Secrecy, you shouldn't be using
RSA at all. You should be using DH with a fresh key for each
exchange. The probability that in the next 50 years your key will
be compromised in some other way than factoring is sufficiently
high to motivate this tactic. (In my view, it's vastly higher
than that of your key being broken by factoring).


This message actually makes my point quite nicely.  I frequently see
long detailed arguments by ECC proponents about how wonderful ECC is
and how it should replace RSA. This is one such argument. That's not
what's needed.

For ECC to take off, someone will have to actually write it into
protocols. This requires someone to identify a specific ECC algorithm
that meets the properties that I laid out, and document those
properties with literature citations, performance numbers, securtiy
estimates, etc. That's what's needed before the COMSEC people will
feel comfortable adding ECC to their systems.

Until someone's willing to step up to the plate on that, we're not
going to see ECC deployment in standard protocols.

-Ekr

-- 
[Eric Rescorla                                   ekr at rtfm.com]
                http://www.rtfm.com/

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com



More information about the cryptography mailing list