Hacker Newsnew | past | comments | ask | show | jobs | submit | breathoftea's commentslogin

generator.c:

    // For each byte in the buffer, use its value to index into another
    // byte and XOR the two.
This seems to be the only mixing that happens in the entire algorithm, after the initial rand seeding.

I'm not a cryptographer, but this smells extremely insecure to me. If the random seed is all zeroes this generator will generate all zeroes for perpetuity, no?

Even if you get a decent initial seed, I still strongly suspect this RNG strategy will be very statistically leaky, will tend to equilibria, and will generally be easily breakable in practice. An RGB visualization in the context of RNG means next to nothing.

Please children, don't do your own crypto.


It also uses 100% CPU until the threads are stopped. The author did not make any claims that it was cryptographically secure. It's just a toy that he shared - an interesting way to perhaps generate something useful from something that is normally undesirable.


I suppose the 100% CPU is (very) unnecessary.

Maybe I'll include a variable sleeping time determined by current buffer values. That way, thread synchronization would be further disorganized, and CPU power wouldn't be wasted quite as much.

In that case, it's important that mutations take place between every byte outputted tough.


The visualisation means next to nothing for proving it's good. But the visualisation seems to show patterns, which says plenty.


If I look at it too long, I see "patterns" in the output of OS X's /dev/random too: http://codeanarchy.com/files/yarrow.png

Random doesn't always look random. To make matters worse, we're biased towards seeing patterns in noise: http://en.wikipedia.org/wiki/Clustering_illusion


...and my repost from https://news.ycombinator.com/item?id=4821942.

A bookmarklet (paste in address bar) to show truly random and "evened out" dot distributions side by side. (Don't laugh at my Javascript):

javascript:"<html><body><canvas id=\"tutorial\" width=\"200\" height=\"200\">foo</canvas><-><canvas id=\"tutorial2\" width=\"200\" height=\"200\">foo</canvas><script>var canvas = document.getElementById('tutorial');var ctx = canvas.getContext('2d');ctx.fillStyle = \"rgb(000,0,0)\";for (var i=0;i<400;i++) {ctx.fillRect (Math.random() * 200,Math.random() * 200, 2, 2); };</script><script>var canvas = document.getElementById('tutorial2');var ctx = canvas.getContext('2d');ctx.fillStyle = \"rgb(000,0,0)\";for (var i=0;i<20;i++) for(var j=0;j<20;j++) for(k=0;k<1;k++) {ctx.fillRect (i * 10 + Math.random() * 10, j * 10 + Math.random() * 10, 2, 2); };</script></body></html>"


"Patterns"? Of course there are patterns. If there were no patterns, that would be suspicious. Do you claim to be able to look at a picture of a random number generator data and determine the quality based on that? You do realize that even perfectly random data may have patterns?


It serves mostly as a litmus test against blatant predictability. As said above, sequential lines or otherwise obvious shapes would indicate poor randomness.

I wouldn't evaluate a generator solely on the basis of a bytemap. But these visualizations are of value.


It seems to be an improvement from the notoriously poor rand() of PHP.

(not confident in the credibility of this article) http://boallen.com/assets/images/randbitmap_computer.png


It's not a PHP function, it's a C library function that PHP is using.

On Linux rand() doesn't suffer from the problem.


"Patterns" doesn't mean much. Repeated diagonal lines would be obviously broken.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: