Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

Thank You.

share|improve this question
I would say 1024 bit is a minimum. Try to optimize your implementation (if feasible). – Aleph Nov 2 '13 at 18:25
Why are you not using RSA for key exchange and then use symmetric encryption for confidentiality and integrity? – mikeazo Nov 2 '13 at 20:05
@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. – C1D Nov 2 '13 at 20:49
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. – CodesInChaos Nov 2 '13 at 20:58
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? – Maarten Bodewes Nov 3 '13 at 21:13
up vote 4 down vote accepted

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.

share|improve this answer
Try e.g. the BrainpoolP256r1 named curve. The curve you mentioned seems to be listed on the SafeCurves site as unsafe. – NDF1 Jul 2 '14 at 3:39
@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. – Maarten Bodewes Jul 2 '14 at 8:24
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. – NDF1 Jul 2 '14 at 22:40

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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