On RC4 based PRNGs

[bantu]

Hey David,

I have used seedrandom in a project about two years ago. I just came across it again and noticed that you're still actively maintaining it. This kind of surprises me considering that it is based on the RC4 / ARC4 / Arcfour stream cipher which is being considered insecure.

It is my understanding that a CSPRNG based on an insecure cipher results in an insure CSPRNG. Without looking too deep into cryptographic papers, I for example found: http://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator#Designs_based_on_cryptographic_primitives and http://en.wikipedia.org/wiki/RC4#RC4-based_random_number_generators

So it looks like using a PRNG based on a different design, e.g. Fortuna, would be a better idea security wise. Maybe that is a misunderstanding on my side you can clear up.

Thanks a lot.

Cheers, Andreas

[bantu]

I've noticed that you're not actually claiming that seedrandom is a cryptographically strong PRNG. If that is by design, what is the point of seedrandom, especially compared to Math.random()? The only difference seems to be that it is seedable.

[Protonk]

@bantu Being seedable (and consistently so cross platform) is actually quite valuable. It's very useful for computations that need a source of randomness but also need to be testable/repeatable.

[bantu]

@Protonk That's fine. I think I just somehow got the impression that seedrandom was supposed to be a CSPRNG. Not exactly sure why right now.

[davidbau]

The goal of seedrandom.js is to be a high-quality cross-platform seedable PRNG without too much complexity. It is important that seedrandom.js will always provide the same PRNG sequence for the same seed, regardless of where or when it is used. The cryptographic properties of the PRNG are only a secondary consideration.

Second point, though - seedrandom uses RC4-DROP-256, not just RC4. The advantage of using RC4 is that the code is fast and small in Javascript, and RC4 is very well-studied. But RC4 by itself has been attacked.

The big 2001 FMS attack on RC4 (that compromised WEP) attacked the key scheduling algorithm, but the vulnerability could be avoided by dropping the first few bytes of the output. So, as advised by RSA, seedrandom.js drops the first 256 bytes before using RC4.

Good thing, because more sophisticated attacks have been devised that involve the more of the leading bytes of RC4. The recent attack on RC4-in-TLS (http://www.isg.rhul.ac.uk/tls/) attacks biases in the first 256 bytes of output - those bytes that we discard. With all the attention on RC4, more serious vulnerabilities will probably be found. Still, because our library discards the part of the stream that has been attacked, the published attacks so far do not seem to affect users of seedrandom.js. (As far as I know.)

The main disadvantage of using seedrandom.js as a CSPRNG is the future. I will not change the algorithm in the future, even if RC4-DROP-256 becomes compromised. If you need a PRNG library that will sacrifice reproducibility in order to stay ahead of the security research, you should look elsewhere.

[marcvs]

unsubscribe marcus@hardt-it.de

On Sunday 14 December 2014 01:22:35 David Bau wrote:

Closed #10.

---

Reply to this email directly or view it on GitHub: https://github.com/davidbau/seedrandom/issues/10#event-207233341

M.