Platform dependent RNG entropy might be insecure

[shelby3]

The documentation is out-of-sync with the code, in that the browser's built-in high-end RNG (window.crypto.getRandomBytes) is used by default (when available) which afaik essentially supplants the entropy that would otherwise be collected from the mouse. I suggest that an API should be added to optionally disable this default. I provided some rational and details in another issue's thread.

Note there is a tradeoff on the amount interaction the user must do before sufficient entropy has been collected.

[enriquez]

The result of a browser's built in secure random function is mixed into sjcl.random. I don't think it replaces it.

sjcl.random is just an instance of sjcl.prng with the paranoia level set to 6 and getRandomBytes already mixed in. You can create your own instance of sjcl.prng and decide if you want to add getRandomBytes yourself, but I don't think there is any benefit to leaving it out. You would just be leaving out a source of entropy (even if it is insecure).

var random = new sjcl.prng(10) // level 10 paranoia

// collect mouse movements, key press, etc...
random.startCollectors()

// listen for "seeded" or "progress" events.

// throw getRandomBytes into the mix.
var ab = new Uint32Array(32);
window.crypto.getRandomValues(ab);
random.addEntropy(ab, 1024, "crypto.getRandomValues");

[shelby3]

Nilos implied the browser's random entropy was sufficient to displace all the contribution from the mouse entropy at least in the default implementation.

Is your point that you force additional entropy to be used? (apologies I didn't have a spare moment to study the code again)

I am not sure if the following quoted statement can be assumed to be true?

"I don't think there is any benefit to leaving it out. You would just be leaving out a source of entropy (even if it is insecure)."

Wouldn't locally cyclic patterns in some segment of the entropy be exploitable?