Re: cvs commit: src/lib/libc/stdlib rand.c
On Sun, Feb 16, 2003 at 22:08:10 -0800, Kris Kennaway wrote: > when they should not. I've given examples of two of them, and there > are probably lots of others I haven't noticed. For example, I just > checked, and libICE appears to use rand() for cookie generation. This > is completely bogus, and insecure. Usually applications we build (like awk, etc.) could be fixed by simple one line change: srand(something) -> sranddev() It completely eliminates first value correlation problem. -- Andrey A. Chernov http://ache.pp.ru/ msg52685/pgp0.pgp Description: PGP signature
Re: cvs commit: src/lib/libc/stdlib rand.c
Thus spake Jacques A. Vidrine <[EMAIL PROTECTED]>: > On Mon, Feb 17, 2003 at 04:40:48PM +1100, Tim Robbins wrote: > > I disagree. It's safe to use rand() in games and in certain kinds of > > simulations when you don't care that the distribution isn't quite > > uniform, > > Safe, maybe. But I think it still shouldn't be used. > See my posting of two years ago: > > http://groups.google.com/groups?&selm=97b83t%2414q3%241%40FreeBSD.csie.NCTU.edu.tw&rnum=1 > > > > BTW, I don't care if linking a program with rand() gives an obnoxious > warning or not. Just pointing out that rand() is less useful than it > might seem. Yes, as with most interfaces, there are ways to use rand() incorrectly. But there also exist ways to use it correctly. That's why people would get annoyed if their programs that have compiled for years start coughing up spurious warnings. rand() is not like gets(); it is almost impossible to use the latter in a robust program. On the other hand, I like the idea of people going out and fixing all the programs that use rand() incorrectly. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/lib/libc/stdlib rand.c
On Mon, Feb 17, 2003 at 04:40:48PM +1100, Tim Robbins wrote: > I disagree. It's safe to use rand() in games and in certain kinds of > simulations when you don't care that the distribution isn't quite > uniform, Safe, maybe. But I think it still shouldn't be used. See my posting of two years ago: http://groups.google.com/groups?&selm=97b83t%2414q3%241%40FreeBSD.csie.NCTU.edu.tw&rnum=1 > BTW, I don't care if linking a program with rand() gives an obnoxious warning or not. Just pointing out that rand() is less useful than it might seem. Cheers, -- Jacques A. Vidrine <[EMAIL PROTECTED]> http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/lib/libc/stdlib rand.c
On Mon, Feb 17, 2003 at 17:39:55 +1100, Tim Robbins wrote: > > variant (which generates bad quality ones), the only problem remains is > > first value monotonically increased with the seed. > > Here's an interesting picture of that: http://people.freebsd.org/~tjr/rand.gif > Nothing surprising here. It is common and know problem for all mod-type PRNGs. There is even good methods exists to eliminate this thing, see http://www.physik.uni-giessen.de:8081/PhysOfFinance/PoF09.pdf "Shuffling Algorithm" section for example. But all such methods will be incompatible with rand_r()... -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/lib/libc/stdlib rand.c
On Sun, Feb 16, 2003 at 10:31:25PM -0800, David Schultz wrote: > > Note that I was only suggesting this patch be committed to -current > > for purposes of finding out what these applications are, and fixing > > them as appropriate. > > Then how about wrapping the warning in an #ifdef, so people who > want to find inappropriate uses of rand() can do so for as long as > they want, and everyone else who uses -CURRENT is not affected? That sounds fine to me. Kris msg52544/pgp0.pgp Description: PGP signature
Re: cvs commit: src/lib/libc/stdlib rand.c
On Mon, Feb 17, 2003 at 08:53:09AM +0300, Andrey A. Chernov wrote:
> On Mon, Feb 17, 2003 at 16:40:48 +1100, Tim Robbins wrote:
>
> > I don't think rand()
> > needs a warning message like gets() &c. because it's not as dangerous.
>
> Wait, what kind of warning __warn_references() produce? I was under
> impression that it is compile-time only.
I was referring to the __warn_references() warning in gets(), not the
annoying message written to standard error.
>
> > What I suggest instead is to remove the pathetic "insults" in rand(3)
> > ("bad" random number generator, obsoleted) and add a BUGS section
> > which describes the problem.
>
> I agree. It can be done not instead only but in addition to compile
> time warning.
>
> > I'd much prefer that rand() generated higher quality numbers, though.
>
> Current formulae generates acceptable quality numbers. Unlike in old
> variant (which generates bad quality ones), the only problem remains is
> first value monotonically increased with the seed.
Here's an interesting picture of that: http://people.freebsd.org/~tjr/rand.gif
Tim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/lib/libc/stdlib rand.c
Thus spake Kris Kennaway <[EMAIL PROTECTED]>: > On Mon, Feb 17, 2003 at 04:40:48PM +1100, Tim Robbins wrote: > > > I disagree. It's safe to use rand() in games and in certain kinds of > > simulations when you don't care that the distribution isn't quite > > uniform, or when you prefer speed over quality. I don't think rand() > > needs a warning message like gets() &c. because it's not as dangerous. > > The problem is that there are a number of applications that use it > when they should not. I've given examples of two of them, and there > are probably lots of others I haven't noticed. For example, I just > checked, and libICE appears to use rand() for cookie generation. This > is completely bogus, and insecure. > > Note that I was only suggesting this patch be committed to -current > for purposes of finding out what these applications are, and fixing > them as appropriate. Then how about wrapping the warning in an #ifdef, so people who want to find inappropriate uses of rand() can do so for as long as they want, and everyone else who uses -CURRENT is not affected? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/lib/libc/stdlib rand.c
On Mon, Feb 17, 2003 at 04:40:48PM +1100, Tim Robbins wrote: > I disagree. It's safe to use rand() in games and in certain kinds of > simulations when you don't care that the distribution isn't quite > uniform, or when you prefer speed over quality. I don't think rand() > needs a warning message like gets() &c. because it's not as dangerous. The problem is that there are a number of applications that use it when they should not. I've given examples of two of them, and there are probably lots of others I haven't noticed. For example, I just checked, and libICE appears to use rand() for cookie generation. This is completely bogus, and insecure. Note that I was only suggesting this patch be committed to -current for purposes of finding out what these applications are, and fixing them as appropriate. > I'd much prefer that rand() generated higher quality numbers, though. Me too, but that is apparently not possible because of API constraints. Kris msg52536/pgp0.pgp Description: PGP signature
Re: cvs commit: src/lib/libc/stdlib rand.c
Thus spake Kris Kennaway <[EMAIL PROTECTED]>: > I think we should commit this patch (to -current) and fix all the > problems that pop up. For example, it's used in awk (which started > this set of changes), and in some of the XFree86 libraries. ... > +__warn_references(rand_r, > + "warning: rand_r() does not produce high-quality random numbers and should not >generally be used"); Many programmers who use rand() are aware that it isn't very good, but don't care for their particular application. For instance, for games or for randomized backoff in network protocols, you might just want a sequence of numbers that looks kinda random, and you don't care that there happens to be a pattern in the lowest-order bits that you see only if you look carefully. rand() isn't like gets() because it's nearly impossible to write a robust program using gets(). It might make sense to put in the warning just to check whether someone used rand() when they really wanted cryptographic-quality randomness, but people would probably get annoyed if the next release of FreeBSD nagged them about every use of rand(). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/lib/libc/stdlib rand.c
* De: "Andrey A. Chernov" <[EMAIL PROTECTED]> [ Data: 2003-02-16 ] [ Subjecte: Re: cvs commit: src/lib/libc/stdlib rand.c ] > On Mon, Feb 17, 2003 at 16:40:48 +1100, Tim Robbins wrote: > > > I don't think rand() > > needs a warning message like gets() &c. because it's not as dangerous. > > Wait, what kind of warning __warn_references() produce? I was under > impression that it is compile-time only. I don't like the idea of this, people using rand incorrectly deserve to get their foot shot off. People using it legitimately don't need to have their heart skip a beat whenever thye link on FreeBSD because it looks like there's some danger to using rand(), when it is perfectly good at what it does, for a lot of common uses. Thanx, juli. -- Juli Mallett <[EMAIL PROTECTED]> - AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer - ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD - Never trust an ELF, COFF or Mach-O! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/lib/libc/stdlib rand.c
On Mon, Feb 17, 2003 at 16:40:48 +1100, Tim Robbins wrote:
> I don't think rand()
> needs a warning message like gets() &c. because it's not as dangerous.
Wait, what kind of warning __warn_references() produce? I was under
impression that it is compile-time only.
> What I suggest instead is to remove the pathetic "insults" in rand(3)
> ("bad" random number generator, obsoleted) and add a BUGS section
> which describes the problem.
I agree. It can be done not instead only but in addition to compile
time warning.
> I'd much prefer that rand() generated higher quality numbers, though.
Current formulae generates acceptable quality numbers. Unlike in old
variant (which generates bad quality ones), the only problem remains is
first value monotonically increased with the seed.
--
Andrey A. Chernov
http://ache.pp.ru/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/lib/libc/stdlib rand.c
On Sun, Feb 16, 2003 at 08:57:29PM -0800, Kris Kennaway wrote:
> On Sun, Feb 16, 2003 at 07:52:35PM -0800, Andrey A. Chernov wrote:
>
> > So, monotonically increased seed->first value correlation problem remains...
>
> I think we should commit this patch (to -current) and fix all the
> problems that pop up. For example, it's used in awk (which started
> this set of changes), and in some of the XFree86 libraries.
>
> Kris
>
> Index: stdlib/rand.c
> ===
> RCS file: /mnt2/ncvs/src/lib/libc/stdlib/rand.c,v
> retrieving revision 1.14
> diff -u -r1.14 rand.c
> --- stdlib/rand.c 5 Feb 2003 21:25:50 - 1.14
> +++ stdlib/rand.c 8 Feb 2003 06:07:55 -
> @@ -86,6 +86,8 @@
> #endif /* !USE_WEAK_SEEDING */
> }
>
> +__warn_references(rand_r,
> + "warning: rand_r() does not produce high-quality random numbers and should not
>generally be used");
>
> int
> rand_r(unsigned int *ctx)
> @@ -99,6 +101,9 @@
>
>
> static u_long next = 892053144; /* after srand(1), NSHUFF counted */
> +
> +__warn_references(rand,
> + "warning: rand() does not produce high-quality random numbers and should not
>generally be used");
>
> int
> rand()
I disagree. It's safe to use rand() in games and in certain kinds of
simulations when you don't care that the distribution isn't quite
uniform, or when you prefer speed over quality. I don't think rand()
needs a warning message like gets() &c. because it's not as dangerous.
What I suggest instead is to remove the pathetic "insults" in rand(3)
("bad" random number generator, obsoleted) and add a BUGS section
which describes the problem.
I'd much prefer that rand() generated higher quality numbers, though.
Tim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/lib/libc/stdlib rand.c
On Sun, Feb 16, 2003 at 20:57:29 -0800, Kris Kennaway wrote: > On Sun, Feb 16, 2003 at 07:52:35PM -0800, Andrey A. Chernov wrote: > > > So, monotonically increased seed->first value correlation problem remains... > > I think we should commit this patch (to -current) and fix all the > problems that pop up. For example, it's used in awk (which started > this set of changes), and in some of the XFree86 libraries. I agree. (diff is for old rand.c, but idea is clear in anycase). I have no fancy ideas how to fix correlation problem AND keep rand_r() compatibility at the same time. All linear mod-type generators share this problem with monotonic seeding and usual solution is shuffling array (more complex code than I use), but it will be incompatible with rand_r() again. If we back out most of changes and return to very first formulae with overflow, we 1) Make monotonic increasing for seed->first_value less visible. 2) Not fix seed->first_value correlation (taking some parts of bits will show repeated pattern). 3) Make distribution and lower bits bad. -- Andrey A. Chernov http://ache.pp.ru/ msg52528/pgp0.pgp Description: PGP signature
Re: cvs commit: src/lib/libc/stdlib rand.c
On Sun, Feb 16, 2003 at 07:52:35PM -0800, Andrey A. Chernov wrote: > So, monotonically increased seed->first value correlation problem remains... I think we should commit this patch (to -current) and fix all the problems that pop up. For example, it's used in awk (which started this set of changes), and in some of the XFree86 libraries. Kris Index: stdlib/rand.c === RCS file: /mnt2/ncvs/src/lib/libc/stdlib/rand.c,v retrieving revision 1.14 diff -u -r1.14 rand.c --- stdlib/rand.c 5 Feb 2003 21:25:50 - 1.14 +++ stdlib/rand.c 8 Feb 2003 06:07:55 - @@ -86,6 +86,8 @@ #endif /* !USE_WEAK_SEEDING */ } +__warn_references(rand_r, + "warning: rand_r() does not produce high-quality random numbers and should not +generally be used"); int rand_r(unsigned int *ctx) @@ -99,6 +101,9 @@ static u_long next = 892053144; /* after srand(1), NSHUFF counted */ + +__warn_references(rand, + "warning: rand() does not produce high-quality random numbers and should not +generally be used"); int rand() msg52526/pgp0.pgp Description: PGP signature
