Generating an RSA keypair in JavaScript

Question

I recently found this RSA JavaScript library: http://www.ohdave.com/rsa/. However, it requires that the key be pre-generated. Here are my questions/issues:

1. I'd like to generate an RSA keypair in the JavaScript (so that I don't have to change the code every time I want a new keypair.)

2. While I understand how this can be used to send secure data, if I'm not mistaken this library cannot be used for the client to receive secure data from the server (because the public and private exponents, and the modulus, are transmitted plain-text from the server). Am I mistaken?

I'd love some discussion about this. I'm no security expert, but I have a pretty firm grasp on asymmetric encryption.

Answer 1

I'm not a security expert either, but here are my thoughts:

1. You can't generate the keypair in Javascript on the client size, since you want the receiver (the server) to know the private key, and client to only know the public key. You could expose a RESTful URI that gives you a new public key on each request, but the client and server will need to know which key pair is being used (which could be stored in some session state). Alternatively the server could generate a new pair every N seconds to avoid this overhead. AFAIK, you shouldn't really need to generate new pairs if your keys are of sufficient length, and a lot of secure sites renew their keys every N years only.

2. If you look at the library closely, the one function, encryptedString(key, s), only uses key.e and key.m (via key.barret). I.e. you only need to send these two variables in plain text in order to encrypt your data. You can keep key.d private on the server side. So you can use the code to send data securely, just not in its current form...

Answer 2

Generating the keypair requires a strong random number generator (I don't think you have one in JavaScript), and quite a bit of computation (for primality testing). Then once you have your pair, when you transmit your public key up to the other side, there's an opportunity for man-in-the-middle attack since there is no integrity check on the public key transmission.

You will get secure transmission to whoever has the private key. It's not clear from your question whether that is the client or the server. You can initialize a shared secret by having whoever has only the public key generate a shared secret, encrypt it and send it to whoever has the public key.

You can get a similar feature set (dependence on random number generator, vulnerability to MITM, ability to create shared secret for use as session key) but with much less computation by performing a Diffie-Hellman key exchange instead.

You are probably better off figuring out how to configure SSL on your server.