# Why is 224 bit ecdsa faster than 192 bit ecdsa?

I ran several benchmarks using openssl on 2 different computers and I got a surprising result.

for the Nist 192 bit curve the benchmark result is

>openssl speed ecdsap192
sign    verify    sign/s verify/s
192 bit ecdsa (nistp192)   0.0001s   0.0003s  11980.6   3481.6


for the Nist 224 bit curve the benchmark result is

>openssl speed ecdsap224
sign    verify    sign/s verify/s
224 bit ecdsa (nistp224)   0.0001s   0.0001s  13740.5   6948.8


So verifying a nistp224 ecdsa signature is twice faster than with nistp192.

I really expected nistp224 to be slower as it handles bigger numbers. Why isn't it so?

• Implementers put a lot of effort into speeding up the variants we use in practice. For example the paper Emilia Käsper - Fast Elliptic Curve Cryptography in OpenSSL presents an optimized P224 implementation. Sep 19 '14 at 19:25
• It's not just P-192 that is inefficient. P-256 is significantly faster than P-384, to the point where one of my servers started choking up when using P-384, but not when using P-256 or even P-521. May 28 '18 at 2:26
• Heh, my machine reports 0.0000s for P256 sign. Fortunately we still have the sign/s :) May 28 at 11:12

Both curves have similar form and primes close to powers of two ($$2^{192}-2^{64}-1$$ and $$2^{224} - 2^{96} + 1$$), so you wouldn't expect large differences in performance – all things equal, P-224 might be anywhere from 30% to 60% slower due to the computational scaling of curve operations.

However, in practice different implementations will have different performance and some curves' will be better optimized. In this case it looks like P-192 might only have a 32-bit portable implementation and P-224 an optimized 64-bit one:

Changes between 1.0.0h and 1.0.1 [14 Mar 2012]

[...] Add optional 64-bit optimized implementations of elliptic curves NIST-P224, NIST-P256, NIST-P521, with constant-time single point multiplication on typical inputs. [...]

(Note: I haven't actually checked if P-192 is unoptimized. You should do it with your version if you are interested.)

As for why they would optimize P-224 better, it is the minimal acceptable size according to e.g. NIST recommendations. Doesn't make much sense to spend time optimizing something that's recommended not to be used.

• Based on the size, P224 should be 50-60% more expensive since the size of the exponent increases as well. So the scaling has an exponent between 2.6 and 3 depending on the multiplication algorithm. Sep 20 '14 at 11:08
• @CodesInChaos, yeah, I'll fix the percentage. Of course, it's a theoretical number that assumes exponentiation takes 100% of the time and the CPU isn't limited by e.g. cache effects, etc.
– otus
Sep 20 '14 at 11:45