2
$\begingroup$

I am currently working on a secure messaging website and I had been using RSA 2048 for encryption, decryption and signing of messages but I found it to be EXTREMELY LAGGY so i've moved to 1024.

I did a timing test and these are my results (this was a test of generating a private key from the same string in cryptico.js):

2048 | 6403ms (6 seconds)  
1024 | 515ms (0.5 seconds)  
 896 | 89ms (0.08 seconds)

I would like to know if if 896 or 1024 are un-secure for use with messaging and what the best key size would be?

Improve this question
$\endgroup$
7
  • $\begingroup$ I would say 1024 bit is a minimum. Try to optimize your implementation (if feasible). $\endgroup$
    – Aleph
    Nov 2, 2013 at 18:25
  • $\begingroup$ Why are you not using RSA for key exchange and then use symmetric encryption for confidentiality and integrity? $\endgroup$
    – mikeazo
    Nov 2, 2013 at 20:05
  • $\begingroup$ @mikeazo, that actually seems like a good idea. I think I will implement that ASAP but the only problem is that 6 seconds is still a long time waiting for the key to be generated, I think i'm going to stick with 1024 for now. $\endgroup$
    – C1D
    Nov 2, 2013 at 20:49
  • 2
    $\begingroup$ Since SSL already blocks most attacks, the gain by using JS crypto on top of that can only be meaningful with keys that even a powerful attacker can't break. At minimum 2048 bit RSA or 224 bit ECC. $\endgroup$
    – CodesInChaos
    Nov 2, 2013 at 20:58
  • 1
    $\begingroup$ I've answered this, but in my answer I've presumed you are talking about key pair generation and not signing (as indicated in your question), could you please make sure that this is correct? $\endgroup$
    – Maarten Bodewes ♦
    Nov 3, 2013 at 21:13

1 Answer 1

Reset to default
4
$\begingroup$

In common cryptographic protocols there is only a need to generate RSA asymmetric keys now and then, say once a year. The key pair generation does not have to take place in the same environment either; e.g. you could use openssl command line if that is available. Note that RSA key pair generation time depends on finding large primes; the runtime is not static - it changes on each run.

If your protocol does have to rely on asymmetric key generation then you would do well to switch to Elliptic Curves. Elliptic curve key pair generation is very fast and private key operations are faster as well. Verification is slower than RSA though, at similar security levels.

Try e.g. the BrainpoolP256r1 named curve. Warning; EC crypto is not for the weak of heart.

Improve this answer
$\endgroup$
3
  • $\begingroup$ Try e.g. the BrainpoolP256r1 named curve. The curve you mentioned seems to be listed on the SafeCurves site as unsafe. $\endgroup$
    – NDF1
    Jul 2, 2014 at 3:39
  • 2
    $\begingroup$ @NDF1 That's correct. But to understand what that means you should understand what "unsafe" means on that website. And you probably have to understand Bernstein as well. "Unsafe" on that website does not mean "broken". You should however validate public keys for BrainpoolP256r1. $\endgroup$
    – Maarten Bodewes ♦
    Jul 2, 2014 at 8:24
  • $\begingroup$ My understanding of unsafe curves means that secure implementations of those curves are theoretically possible but very hard. Thus you are likely to mess it up and make your software exploitable by real attackers. Also most of the unsafe curves have erroneous efficiency constraints that make some of them bad for security. It would seem to make implementation easier and your software more secure to ignore the unsafe curves and simply use the safe ones. $\endgroup$
    – NDF1
    Jul 2, 2014 at 22:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.