Keypair key-size does not match default_key_size about jsencrypt

[phillipp]

I generated a sample of 100 private keys each with chrome and firefox with default key size. After that, I parsed the generated keys with openssl.
With both browsers ~33% of the keys were of 1023 bit size, the rest was 1024bit.

Any ideas?

Edit:: I found out that the RSAKey.generate method sometimes generates keys with a modulus which bitlength doesn't match the desired keysize. You can check the bitlength of the generated key with

var crypt = new JSEncrypt();
crypt.getKey().n.bitLength(); // => returns 1023 (bit) or 1024 (bit)

A simple do/while loop could be used to wrap keygen:

var crypt;

do {
  crypt = new JSEncrypt({default_key_size: 1024});
  crypt.getKey();
} while(crypt.key.n.bitLength() != crypt.default_key_size);

@travist Would you like to add that to the library/wrapper or do you think it is out of the scope of your project?

[xeoncross]

+1 thanks for your research @phillipp

[zoloft]

Well actually that cycle would be a killer for key sizes higher than 1024 so I don't think it would good to integrate into the library. But I can do a bit of researches on the issue and try to break the problem down to its root cause. Thank you for the report anyway, was a hard spot!

[phillipp]

I actually use it with 2048 bit keys without problems. It doesn't take too much longer in most cases (the chance that is takes >3.1 times the original runtime is <5%).

I think the underlying problem is that in some cases p and q will be chosen to produce an n that has a most significant bit of 0, so the bitlength is one bit shorter.

This could be avoided if both p and q are chosen with the first two most significant bits set. In that case, n would have exactly the desired bit length. But that would either require patching the upstream RSAGenerate or contacting Tom Wu to change it directly in the lib.

[zoloft]

Well actually I did some changes to the underlying library (tracked in my repo zoloft/jsencrypt-core-libs) so it would not be a problem to do some changes as soon as we track all of them. We decided to do this since we didn't receive any reply from Tom Wu. If you look at the code in the develop branch you will see the .gitmodules file containing this:

[submodule "lib/jsbn"]
    path = lib/jsbn
    url = [email protected]:zoloft/jsencrypt-core-libs.git

unluckily my current work policies do not allow me to work on this project during my current assignment so I cannot work on the next version of the library right now, but if you make a pull request to my repo I would definitely accept it and port to the main repo as soon as I can start working on it again. The next version of JSEncrypt will enable use of WebWorkers, signing and sign verification and generation of SEC keys as well.

As for the timing I guess you have not tried the key generation on a mobile device :)

[phillipp]

zoloft/jsencrypt-core-libs#1