Multiple networks elliptic curve cryptography testing

As I have had to give a talk about elliptic curve cryptography for the testing community in Czech Republic at the regular pro[test] event held in Prague two weeks ago, I wondered what could be actually tested about ECC in real-world scenarios. As I was digging through my notes, I realized there is something everybody really hates – waiting for web page to load. And with HTTPs everywhere now the crucial part slowing the whole browsing experience down is how fast the connection can be established. That is because encrypted connection requires exchanging quite a lot of information at the beginning and can go on without much overhead afterwards.

The part taking place at the very beginning of each and every TLS connection is called handshake. Figuratively speaking the name describes it pretty well. Both parties introduce themselves and exchange something for further reference. As clients on the Internet are usually semi-anonymous, the server side introduces itself in greater detail – but both parties have to do their par of the key exchange task. The introducing and key-exchanging part at the server side is usually combined and typical handshake goes like this:

1. Client sends „hello“ packet with its public data for key-exchange and usually some nonce (random piece of junk that should not be used twice) for the server to sign.
2. Server examines the incoming „hello“ and composes reply by sending its public data for key exchange, a signature of client nonce and the rest of the message and a certificate chain to prove it is really this server the client wants to talk to. Also the server calculates a shared secret from its private data for the key-exchange and public data sent by the client.
3. Client verifies the signature and if everything is all right, it also calculates the shared secret by using its secret key-exchange data and the public key-exchange data sent to it by the server.

And voilá, the encrypted connection is established. I left out the boring details of ensuring both parties use the same protocol and key-exchange method, but let’s just say they do ensure it.

During this handshake quite a lot of data must be sent over the wire. Both the key-exchange part and server verification part including the certificate chain is not negligible. A typical certificate chain using the RSA certificates might look like this:

And that means packet fragmentation. Yes, the thing you thought you do not need to worry about these days is still here and rocking your connections. Before we get to measure how much it takes to send such RSA chain, here is another chain, ECDSA-based this time:

That looks much better. But what is the real difference? How do these two alternatives perform compared to each other respectively?

When looking for answer to this question I decided there is a need for hard data. Therefore the tests were designed to be robust and easily repeatable. As you can see I created a three-level RSA certificate chain and similar ECDSA chain. The HTTPS server was setup for each type of certificates and also an appropriate key-exchange algorithm was chosen. For RSA it was standard Diffie-Hellman, for ECDSA it was elliptic-curve Diffie-Hellman algorithm. Then on each type of connection 10000 (ten thousand) TLS handshakes were performed using HTTP(s) HEAD method to minimize overhead yet simulating real-world scenario as close as possible.

We started our testing in the lab with 100Mbps fiber connection to our data center. The results were strikingly clear. Although the difference really does not matter in this case, it was exciting to see a clear separation of most probable handshake times. The difference between ECC and IFC (integer-factorization cryptography) was less than 30ms.

Then we moved on to 4G LTE network. It was a bit slower than dedicated fibre connection so the distinction between IFC and ECC became bigger – but still both were pretty fast. The difference was also about 30ms.

Then came a big surprise. The TLS handshakes performed over a 3G network were performed a bit faster than on the 4G LTE network. On the other hand the distribution was more spread. Yet the difference rose slightly to 40ms.

The 2G network was not so much of a surprise. Slow as hell with high latencies and huge difference of 240ms between IFC and ECC. That means you can save a quarter of second on average by using ECC TLS handshakes on 2G networks.

The conclusion is simple – if there is even the slightest possibility of encountering a 2G network en route between your clients and servers – use as much ECC as possible. It makes huge difference. If this is not your case, consider using ECC anyway as it has more room for enlarging the security parameter of ciphers used at much lower cost than with IFC.

That’s all for today and see you soon (and today I mean that).

Cheers!