For our privacy-preserving protocol, an encrypted channel is established. In ord
ID: 652998 • Letter: F
Question
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
Explanation / Answer
BouncyCastle has a really bad ECC implementation. It uses affine coordinates which incur a huge performance hit (factor 20 or so) since it computes a field inversion after every single step. Good implementations use Jacobi coordinates (or a similar approach) where denominators are kept and there is only one field inversion at the end.
It's also potentially vulnerable to side channel attacks since it branches on secret data (only relevant to signing, not verification).
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.
Related Questions
Navigate
Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.