[cryptography] Weak random data XOR good enough random data = better random data?

Lodewijk andré de la porte l at odewijk.nl
Tue Sep 2 19:13:45 EDT 2014

Thanks for the responses everyone!

Reg. making a CSPRNG in JS: I don't have experience and wouldn't trust it.
Using someone else's is even worse, I find other's often do things even
worse (somehow). And seeding it would sort of have moved the problem rather
than solving it. A PRNG shouldn't be able to generate entropy out of
nothing and I don't really feel like doing the cryptanalysis (or trusting
someone else's ;) (but it's probably a decent way to do it, I've seen a JS
Fortuna for example)

Everyone else told me basically the same thing, but somehow it all made
complete sense only after James' comment.

It sounds like what you want is a way to generate randomness a user
> can trust, in a browser lacking crypto.getRandomValues.  That's hard
> to impossible - it's why crypto.getRandomValues was made.  I believe
> state of the art prior to crypto.gRV was using mouse movements and
> other server-unpredictable events.

That's exactly it! I'm not 100% on the security of the wiggle-mouse based
entropy, still seems a bit too sketchy to me. I'd also prefer not to annoy
users any more than I have to. It's also just a lot of hassle. Do
touchscreens provide the same entropy? What about a user with a *very* slow
phone (maybe an update in the background)? Prefer avoiding dragons, even if
they seem small enough to slay.

If I just hand the user data it's deferred computing, not clientside
crypto. There's also the question of whether crypto.getRandomValues can be
trusted. Where does the browser get it's entropy? Does the browser add
flaws? HTML runs on a wide device landscape, PC's, Game Consoles,
SmartTV's, e-readers, smartphones, etc. (in the future they'll support the
current HTML5 or I may support them, now I doubt many would run my website

As an added bonus I can more easily reach users that just don't care. If
you get a stern warning to upgrade or suffer decreased security and ignore
it, I'd like to say I don't have to care. The problem is that users are
unknowing, so you can't expect them to respond to such a warning. Now I can
rest easy knowing I gave them good randomness. The client-side randomness
assurance couldn't be important to people running aged software.

So, thanks everyone, for checking my sanity. Wouldn't know what to do
without a list like this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20140903/ccb47b61/attachment.html>

More information about the cryptography mailing list