Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Use better methods for generating entropy #6
The jsbn libraries are a bit old, last modified in 2009 to be exact. Crypto in the browser has come a long way since then, and I generally feel that the way it generates entropy could be greatly improved.
Using time to generate random values is well, not random. Math.random() is not as good as using crypto.getRandomValues, and while the RNG included in jsbn does attempt to use crypto.random, that API seems to be very old and not supported on modern browsers.
Up to you if you would like to accept this, as you state that the jsbn files have been copied over exactly. Not sure what your stance is on modifying them. This pull request does a few things:
I am currently using these changes in a live system (http://www.cyanogenmod.org/blog/cyanogenmod-account) that has a lot of "tinfoil hat" users, and would love to see them upstream :)
I love this idea... My only issue with it is that it is modifying the jsbn library when I would prefer not to fork that library. It does seem, however, that we may be able to duck punch these methods within the jsencrypt.js file so we achieve the same result without modifying the core library.
But... then again... duck punching is pretty sloppy and almost more so than hacking a core library. I really do wish that Tom Wu would manage his repo and accept upstream changes since that would be the ultimate solution. What I may propose is that these changes do get accepted with an included *.patch file in the jsbn directory so that anyone is aware of the changes that have been made to it.
Sure, duck punching these methods would work, but I agree that it is dirty. If we are duck punching, we might as well just modify the code, the result is the same.
I'm fine with including *.patch files, however, I don't really feel that that is necessary either. This is a git repo after all, if you want to see the changes that is trivial. I suggest we simply update the README with links to the changes instead of including patch files, but it doesn't really matter either way.
Let me know how you would like to move forward.
added a commit
this pull request
Aug 22, 2013
First of all great work @ctso.
Probably i will make this modifications next weekend, if you can wait i will make a PR.