Path: csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!panix!usenet.stanford.edu!not-for-mail From: Ole Tange Newsgroups: gnu.bash.bug Subject: Re: $RANDOM not Cryptographically secure pseudorandom number generator Date: Sat, 15 Dec 2018 23:22:07 +0100 Lines: 77 Approved: bug-bash@gnu.org Message-ID: References: <868cc2da-cf67-298f-4640-ab1afcf857e0@case.edu> <4bc5800d-0dfb-17a5-0b20-9f4bef5a60b6@case.edu> NNTP-Posting-Host: lists.gnu.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: usenet.stanford.edu 1544926103 17704 208.118.235.17 (16 Dec 2018 02:08:23 GMT) X-Complaints-To: action@cs.stanford.edu Cc: bug-bash To: Chet Ramey Envelope-to: bug-bash@gnu.org X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0nukn9O2fFD/U6pZaW0gczf1YxAoYQNivUzancXTTZs=; b=izmFTlywDVa0KEzsjlimgnW2so57wbInAgYAUFy+Cw3wh39wHwBodRF0A54/jYr8tF FygQ8T5TlhRj8ErAEWueWkSp1/1U+jq+R/wTKb08RIQD8Yx6DYAeGuicj/5aLGZuzcbv WvrOkwu+5jSN3nLg4F+DqHFf26Q/D5s5QNaARlz9eiJDIqD4cFbS5+jytqi9sX99xAug oMNHvvon4auKFbwjX370BoK1qiueIAIOXoPzuC+fKDd2TbDL015+yfvXYpf36ZwCYwSD TkZtjevzcOmtQMqbUHD7YP7xV78ttpSKv+OV3FyjsR/faIbCpid6rppkXaYSyBLIZT1k oGTg== X-Gm-Message-State: AA+aEWZ12gM8Il8oGerr6XG+v68BCGSOMw3EPJcRH+bS1jsRRW6WutEQ ZVf57psmA/m2RvUPTJY1sfYs7jJ8BOsDjy483+A= X-Google-Smtp-Source: AFSGD/WWaheHEQOFQ62ZIn1Gx92M/iipIbW77/kFKbvdNypMHfsIHliA/ZiI9buiB24r5NnHnlpJw0ofUAxyc8NIf/I= X-Received: by 2002:a24:7fce:: with SMTP id r197mr7538581itc.4.1544912541001; Sat, 15 Dec 2018 14:22:21 -0800 (PST) In-Reply-To: <4bc5800d-0dfb-17a5-0b20-9f4bef5a60b6@case.edu> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.85.166.180 X-Mailman-Approved-At: Sat, 15 Dec 2018 21:08:22 -0500 X-BeenThere: bug-bash@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Bug reports for the GNU Bourne Again SHell List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Xref: csiph.com gnu.bash.bug:14918 On Mon, Dec 3, 2018 at 9:18 PM Chet Ramey wrote: > On 12/3/18 11:31 AM, Ole Tange wrote: > > On Mon, Dec 3, 2018 at 3:56 PM Chet Ramey wrote: > > > >> There has to be a compelling reason to change this, especially at a point > >> so close to a major release. I would think that a major release would be the perfect opportunity to change this: Major releases in general are known for not being 100% compatible with earlier releases. > > The reason for my submission was that I needed a bunch of random > > numbers in a shell script, but I needed them to be high quality. > > Luckily I did not just assume that Bash delivers high quality random > > numbers, but I read the source code, and then found that the quality > > was low. I do not think must users would do that. > > This is always requirements-driven. Nobody expects to get cryptographic- > quality PRNGs out of the shell (or any of the libc interfaces, tbh), While I did not *expect* it, I honestly had hoped for it. Otherwise I would never have raised this. I feel a bit as if I am saying: "Hey this using environment variables to store function definitions seems like it could be a problem, but I do not have an exploit. I do, however, have an easy fix so that it will not be a problem in the future." And you replying: "Come back when you have an exploit." And then we simply wait for Shellshock to happen. > that's never been promised or expected. You can't really expect that from > something that only promises 16 bits. The naive user may assume that he can simply concatenate values and get 128 bits: echo $RANDOM-$RANDOM-$RANDOM-$RANDOM-$RANDOM-$RANDOM-$RANDOM-$RANDOM But I hope we agree that he will not get 128 bits of randomness no matter how many values he concatenates. Or he might expect that this is not an infinite loop: while [ ! $RANDOM = $RANDOM ] ; do true; done just like this is not: while [ ! $RANDOM = $(( 1+$RANDOM )) ] ; do true; done (This one came as a surprise to me - I had totally expected $RANDOM would give the same value twice 1 time in 65536 tries on average. Tested on 4.4.19) At the very least make it clear from the documentation what $RANDOM can be used for. The man page does not warn about the low quality either, and it does not point to a way to get high quality numbers. Somehow we expect the user to simply know this without giving him even a hint about this. > However, for common scripting tasks like generating temporary filenames, > it's perfectly adequate. I hope that we agree that you should never use $RANDOM for generating temporary file names in a dir that an attacker has write access to. mktemp is made to do that in a secure fashion. But your comment actually emphasizes my point: We _will_ have users who are naive enough to use $RANDOM in ways you and I would not do, because we know it is unsafe. Let's make those usages a little safer. /Ole