[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Moving forward on draft-ietf-tls-ecc-*
Hello, Eric,
When a user attempts to make a secure SSL connection with
a server, the true cost to a user is the time he/she
has to wait for the connection. This includes
1. the client cryptographic operation,
2. the server cryptographic operation, and
3. other overhead for SSL processing and network delay.
As you can see, the server crypto cost adds directly
to the client side of cost matrix.
ECC's efficiency will allow a server to simultaneously respond
to 14x more client connections which translates directly to
much less wait time for each client.
Now considering the next wave wireless Internet
with millions of smart phones.
These devices are attached with SIM cards.
This kind of smartcard attached platforms makes
client signing very easy. This signing capability provides
non-repudiation for merchants, and will further promote
ecommerce transactions beyond what is possible on
today's PC platforms.
Look at this usage scenario,
a signing on a 8-bit device like ATmega128 using a
RSA-2048 private-key op will add an additional
83 seconds to the client cost, whereas an ECC-224 signing
only adds 2.19 seconds.
In other words, a cell phone user might have to hold for
83 seconds to complete the transaction using RSA.
At that point in time, it might become more obvious that
ECC is the only feasible solution.
--
____
/___/\ Sheueling Chang Shantz
/__ \\ \ Distinguished Engineer
/___\ \\ / Sun Labs, Networking & Security
/___/ \/ / / Sun Microsystems, Inc.
/___/ / \//\ 2600 Casey Ave, M/S UMTV29-112
\___\//\ / / Mountain View, CA 94043
\___/ / /\ /
\___/ \\ \ Phone: 650-336-1676
\___\ \\ Fax: 650-969-7269
\___\/ Email: sheueling.chang@xxxxxxx
Happiness and freedom begin with a clear understanding of one principle:
some things are within our control, and some things are not.
Eric Rescorla wrote:
I'm not disputing these performance numbers, but I think they
rather miss the point.
There are really two common scenarios in which SSL/TLS is used:
(1) PC client (fast client, fast server)
(2) Handheld client (flow client, fast server)
In either situation, the vast majority of connections involve
anonymous clients and authenticated servers.
So, the cost matrix looks like this:
Client Server
-----------------------------------------------
RSA | 2 pubkey ops 1 private key op
ECC | ECDSA vfy + ECDH ECDH
Now, RSA public key ops are MUCH faster (a factor of 2-3 on your
8-bit platforms) than ECDSA verifies or ECDH operations.
This is basically a no-op in the PC client case because the
client is so fast anyway, but in the Handheld client case,
it's a big lose for ECC.
Because ECDH is much faster than an RSA private key operation,
the party who benefits from ECC is the server. However, this
is not a particularly interesting optimization because with
commodity hardware acceleration, the RSA private key operations
are no longer the dominant performance cost of TLS, as shown
by Coarfa et al.[1].
The only situation in which ECC actually has a significant
impact on performance is when client authentication is involved,
but then that optimization could be easily realized simply
by adding ECDSA certificate types rather than an entirely
new set of cipher suites.
-Ekr
[1] C. Coarfa, P. Druschel, D.S. Wallach, "Performance Analysis
of TLS Servers", Proc ISOC NDSS 2002.
> Sheueling Chang <Sheueling.Chang@xxxxxxx> writes:
>
>>Here is some Elliptic Curve (ECC) and RSA performance comparison
>>data for your information.
>>
>>This is benchmark data taken from optimized RSA and ECC implementations
>>running on large platforms with 64-bit processors, and separately,
>>on tiny devices such as Berkeley/Crossbow Motes with Atmel
>>ATmega128 8-bit processors.
>>
>>As you can see, ECC's performance advantages on small devices
>>such as smart cards is quite impressive.
>>
>>On server platforms (64-bit processors), ECC offers roughly
>>4x the performance advantage for today's key sizes
>>(ECC-160 vs. RSA-1024).
>>
>>By the end of the decade, RSA key sizes are expected to
>>grow to 2048-bits.
>>
>>At that time, Elliptic curve has roughly
>>14x the performance advantages (comparing ECC-233 vs. RSA-2048).
>>
>>On small devices with 8-bit processors:
>>ECC is 13x faster (ECC-160 vs RSA-1024, today's key)
>>ECC is 38x faster (ECC-233 vs RSA-2048, future key size).
>>
>>For mid-size platforms, such as Nokia phones, one can expect
>>the advantages to range somewhere in between 14x - 38x.
>>
>>I have also included two technical papers here for your reading.
>>They were published in the NDSS 2004 and CHES 2004 Conferences.
>