You're talking about two different things here. As others have said, if you XOR good random with 'not very good but non-malicious random' - you are unlikely to reduce the entropy. (And as Seth said, if you XOR good random with malicious random (e.g. a trojaned RDRAND instruction) you're in bad shape.)
But that's not what you asked. On Mon, Jul 28, 2014 at 11:23 AM, Lodewijk andré de la porte <[email protected]> wrote: > That way the user can still verify > that I didn't mess with the randomness, no MITM attacks can mess with the > randomness, but given a good transport layer I can still supplement usually > bad randomness. What this _sounds like_ to me, is that you want to try and make a good faith effort to users that you can't deduce the randomness their browser generates. You ship them high quality RNG output, and then generate some randomness (probably Math.random() based?) and the output should be unguessable by you. But it's not. Math.random()-based random is guessable in 2^X, to varying degrees of X: maybe between 20 & 60? (I'm estimating off recollections of papers from my head.) Math.random() seeded algorithms are also guessable - once seeded an algorithm doesn't make more entropy. 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. -tom _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
