# ECDSA vs RSA: Performance on Android platform and surprising results

For our privacy-preserving protocol, an encrypted channel is established. In order to protect our system from man-in-the-middle attacks, signature-based approach is used. After we've implemented it with RSA, we decided to optimize the protocol a bit by using ECDSA. The result was very surprising: on Android, signing and verifying in case of ECDSA was 10 times slower than for RSA with the corresponding key length!

Any viable explanation for this?

Maybe the android smart phones don't have hardware support for elliptic curves, and for RSA operations they do?

The exact parameters are below:

RSA:   signing: 52ms,  verifying:   6ms
ECDSA: signing: 692ms, verifying: 975ms

Smartphone: Samsung Galaxy S Advance, GT-I9070P with CPU: 1 GHz STE U8500 DualCore
Crypto-lib: SpongyCastle 1.50.0.0
Elliptic curve used: 224 bit, secp224r1
ECC signature: SHA256 with ECDSA
RSA 2048 signature: SHA1 with RSA

-
Why are you using SHA256 with ECDSA and comparing that with SHA1 with RSA? You should be keeping the hash function constant between the two to make the comparison fair. I'd be curious to see how that changes your numbers. – mikeazo May 13 '14 at 14:01
Did you use the same providers for both? Try getProvider() on the signature. It may be that ECDSA ran as byte code using Spongy and that the other ran using OpenSSL in the background. Also, the hash algorithm gains in imporance the bigger the data. – Maarten Bodewes May 13 '14 at 14:44
To add to owlstead, BigInteger is really slow for certain operations. If the RSA code is not using BigInteger, but the ECDSA is, that would be your reason right there. – mikeazo May 13 '14 at 14:49
One real possibility is that RSA 2048 has a native provider (perhaps tied to the so-called hardware-backed keystore), while all the others are using BigInteger. See this useful answer and my confirmation comment – fgrieu May 13 '14 at 15:46
Initially I thought this should be considered off topic. After seeing CodesInChaos' answer, though, I'm not so sure. Yes it is about implementation, but it is more in the weeds of crypto than any other SE site (likely) cares about. Personally I'm okay with in-the-weeds implementation type questions. – mikeazo May 13 '14 at 17:41

As another ECC benchmark you could look at the the ref10 branch of str4d/ed25519-java. This uses a different elliptic curve, Ed25519, but the main difference is that the implementation has been optimized more than the one you tested. But this is still new and experimental code, so be careful.
@mikeazo It uses its own BigInteger library. But even with pure java code you can get much better performance. – CodesInChaos May 13 '14 at 17:30