Re: Moving forward on draft-ietf-tls-ecc-*

[Eric Rescorla <ekr@xxxxxxxx>]

Sheueling Chang <Sheueling.Chang@xxxxxxx> writes:

> 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.

Incidentally, I don't think this claim is correct. While it's
true that at the RSA-2048/ECC-224 level, ECC is about 14 x
(your NDSS 04 paper claims 11x) times faster than RSA, that
doesn't mean that SSL is 14x faster. Indeed, your NDSS 04
paper shows a much smaller advantage:

      Here again, we notice that the use of ECC allows the
      server to handle a larger number of requests (30%-270%
      more) compared to RSA. At current security levels and under
      low load, clients experience comparable latencies for
      ECC-160 and RSA-1024. That is, the time taken for publickey
      operations is low compared to SSL processing overheads
      and network latencies. However, the saturation point
      of the server is reached earlier with RSA-1024 leading to a
      sharp increase in latency at around 110 requests per second.
      For RSA-2048, clients experience 90ms of latency, primarily
      due to the RSA operation on the server, even under low
      server load. In comparison, the exhibited latency for ECC-
      224 is only 35ms or less than 40% of the RSA case.7 In
      addition, the server saturation point for ECC-224 is reached
      significantly later at around 140 requests per second compared
      to 40 requests per second for RSA-2048.

140/40 = 3.5, so the speedup is <4x, not 14x.

The problem, of course, is that there's more going on in SSL than the
PK operation. Again, see Coarfa's NDSS 02 paper, where they simulate
an infinitely fast PK operation and demonstrate that it only provides
a speedup of about 2.4x over RSA 1024.

Amdahl's law strikes again.

-Ekr