Comments on: Java Security FUD http://www.nomachetejuggling.com/2007/02/27/java-security-fud/ How a random programmer views the world. Sat, 22 Nov 2008 07:48:16 +0000 http://wordpress.org/?v=2.5 By: Michael Bevilacqua-Linn http://www.nomachetejuggling.com/2007/02/27/java-security-fud/#comment-7744 Michael Bevilacqua-Linn Tue, 17 Apr 2007 23:45:38 +0000 http://www.nomachetejuggling.com/2007/02/27/java-security-fud/#comment-7744 Fun fact, you can fairly easily recover the last seed in a java.util.Random with just a single nextLong(). Not that it matters. Why bother trying to make the output of a LCG "more random". It works perfectly for what it's intended to do. Simple, quick, everyday psedorandomness. There are other algorithms that are more suited for when you need randomness for cryptographic, or other hard to predict, purposes. Oh, and I'm one of those folk that tries to avoid Java whenever possible :-) Fun fact, you can fairly easily recover the last seed in a java.util.Random with just a single nextLong(). Not that it matters. Why bother trying to make the output of a LCG “more random”. It works perfectly for what it’s intended to do. Simple, quick, everyday psedorandomness. There are other algorithms that are more suited for when you need randomness for cryptographic, or other hard to predict, purposes.

Oh, and I’m one of those folk that tries to avoid Java whenever possible :-)

]]> By: Rod http://www.nomachetejuggling.com/2007/02/27/java-security-fud/#comment-6185 Rod Mon, 19 Mar 2007 08:39:27 +0000 http://www.nomachetejuggling.com/2007/02/27/java-security-fud/#comment-6185 Juhani: I don't think so. For one thing, this was linked to in a CURRENT discussion about Java, as an example of Java's inferiority. The fact that it's old doesn't matter - people are still saying Java is slow, and it hasn't been slow for a long time. Old, outdated aspects of Java are relevant today because people are still using them, so showing why an older criticism is false is still valuable. Also, the Random implementation hasn't changed - if you load his applet, you still see the effect. This makes it somewhat relevant today as well. It's also worth pointing out that SecureRandom, in fact, DID exist at the time he wrote that page, so it was just as wrong then as it is today. :) Juhani:

I don’t think so. For one thing, this was linked to in a CURRENT discussion about Java, as an example of Java’s inferiority. The fact that it’s old doesn’t matter - people are still saying Java is slow, and it hasn’t been slow for a long time. Old, outdated aspects of Java are relevant today because people are still using them, so showing why an older criticism is false is still valuable.

Also, the Random implementation hasn’t changed - if you load his applet, you still see the effect. This makes it somewhat relevant today as well.

It’s also worth pointing out that SecureRandom, in fact, DID exist at the time he wrote that page, so it was just as wrong then as it is today. :)

]]> By: Juhani http://www.nomachetejuggling.com/2007/02/27/java-security-fud/#comment-6151 Juhani Sun, 18 Mar 2007 19:43:27 +0000 http://www.nomachetejuggling.com/2007/02/27/java-security-fud/#comment-6151 I really like your blog, but one thing bothers me with this post. It says in the code that it is written in 1998. That's kind of a long time ago, don't you think? I have no idea how Java has developed but I'm still thinking it's a bit out-of-date proving a nine year old point on Java randomness wrong? Or is it? I really like your blog, but one thing bothers me with this post. It says in the code that it is written in 1998. That’s kind of a long time ago, don’t you think?

I have no idea how Java has developed but I’m still thinking it’s a bit out-of-date proving a nine year old point on Java randomness wrong? Or is it?

]]> By: John http://www.nomachetejuggling.com/2007/02/27/java-security-fud/#comment-4136 John Wed, 28 Feb 2007 18:58:08 +0000 http://www.nomachetejuggling.com/2007/02/27/java-security-fud/#comment-4136 Somehow I knew that sending you that link would provoke you. ;) The analysis you provide is great, but I think you do miss his point. It's a well-known effect of LCGs that the low-order bits of the output are non-random. His suggestion (under the "proposal" link) was to take high-order bit and add that into the result before using it. This would only add one bit-shift operation and one addition : it's doubtful that those could cause any program to run significantly slower. (And if it does, we're back to the "Java really /is/ slow" argument. ;) The only time you could even possibly notice it is if you're generating millions of random numbers, and if you're doing that you'd probably really want a different algorithm /anyway/. Ergo, this simple change would significantly add to the quality of the "default" random number generator. Also, it should be pointed out that there's a huge gap between Random and SecureRandom that could be meaningfully populated with other classes. SecureRandom isn't exactly the next step up, so much as the final step in the trade-off between random and fast. For instance, the Mersenne Twister algorithm is both fast and very random. (In fact, if you reference http://cs.gmu.edu/~sean/research/, the guy there claims it's faster than Random.) Incidentally, this "random isn't" complaint is a common in C++ as well. Most default random number implementations are trash. Thus, I agree that the title "Sun Redefines Random" title is a bit uncharitable. Further, he's picking on a pretty well-known issue with the underlying algorithm, so he's not "groundbreaking" by any means. However, I think the solution he suggests has some merit, and this could be a place that Sun could improve on other languages. Somehow I knew that sending you that link would provoke you. ;)

The analysis you provide is great, but I think you do miss his point. It’s a well-known effect of LCGs that the low-order bits of the output are non-random. His suggestion (under the “proposal” link) was to take high-order bit and add that into the result before using it.

This would only add one bit-shift operation and one addition : it’s doubtful that those could cause any program to run significantly slower. (And if it does, we’re back to the “Java really /is/ slow” argument. ;) The only time you could even possibly notice it is if you’re generating millions of random numbers, and if you’re doing that you’d probably really want a different algorithm /anyway/. Ergo, this simple change would significantly add to the quality of the “default” random number generator.

Also, it should be pointed out that there’s a huge gap between Random and SecureRandom that could be meaningfully populated with other classes. SecureRandom isn’t exactly the next step up, so much as the final step in the trade-off between random and fast. For instance, the Mersenne Twister algorithm is both fast and very random. (In fact, if you reference http://cs.gmu.edu/~sean/research/, the guy there claims it’s faster than Random.)

Incidentally, this “random isn’t” complaint is a common in C++ as well. Most default random number implementations are trash. Thus, I agree that the title “Sun Redefines Random” title is a bit uncharitable. Further, he’s picking on a pretty well-known issue with the underlying algorithm, so he’s not “groundbreaking” by any means. However, I think the solution he suggests has some merit, and this could be a place that Sun could improve on other languages.

]]>