I’m not sure the best way to make use of it as a source of random decimals — there are surely a dozen ways to do so — but this works:

  printf %d 0x`
    head -c 1000 /dev/urandom
    | shasum 
    | head -c 8
  `

AFAIK it's the true source of randomness in any unix.

> I’m not sure the best way to make use of it as a source of random decimals — there are surely a dozen ways to do so — but this works:

`od(1)` will do binary to binary to decimal:

    > head -c4 /dev/urandom | od -An -vtu4
               4119929390                                                

    > head -c4 /dev/urandom | od -An -vtu4
               3540752584                                                

    > head -c4 /dev/urandom | od -An -vtu4
                998126897

The use of "true" here seems ambiguous.

Does this statement mean that you discourage creation of cryptographic applications with shell scripts, you discourage use of shell scripts to orchestrate applications that use /dev/urandom for any reason, or something else entirely?

The linked gist doesn't appear to be making the case for using its recommendations in cryptographic applications so what I'm ultimately after is what the commenter thinks is being done in the shell that's inappropriate.

However, all software random number generators are pseudo random, including cryptographic ones. They are called CSPRNGs, which stands for Cryptographically Secure Pseudo Random Number Generator.

My favorite tool for this is "openssl rand" and I can find the manual page on rhel7 with "man rand."

Here are 8 bytes of randomness in base64:

  $ openssl rand -base64 8 
  mGHxYcVOmA8=

The shell's $RANDOM is somewhat less trustworthy than other sources here. It also does not appear to be POSIX, but comes from ksh88, where it is described as returning a random integer between 0 and 32767 each time it is referenced. If unset in a script, it cannot be used again for the life of the shell.

    function password_generate { head -c ${1-12} /dev/urandom | base64; }

  # uname -a
  HP-UX prdcrm B.10.20 A 9000/800 862741461 two-user license

  # ls -l /dev/urandom
  /dev/urandom not found

  # openssl rand -base64 8
  v51U1RvSD2Q=

https://lwn.net/Articles/889452/

Pragmatically, they are equivalent for most scripting use cases.

  RD=$(dc -e 16i`xxd -c $N -g $N -l $N -p /dev/urandom | tr a-f A-F`p)

This goes from good practice to necessary as a cron job uses increasing resources or talks to a centralized service.

Puppet implements this as splay: https://www.puppet.com/docs/puppet/7/configuration.html#spla...

Say you want to generate a strong password, you can use this handy function that works in bash and zsh:

    function gen_passwd() {
       openssl rand 240 |\
       LC_CTYPE=C tr -dc '[:graph:]' |\
       cut -c 1-${1:-20}
    }

    karellen@localhost:~$ keepassxc-cli generate -lU
    hpJUwcYZnzJyAbrnvTWnTzrlqzqcdvsl
    karellen@localhost:~$ keepassxc-cli diceware
    diabetes dinginess goldfish purr cried expenses related

    sort -R /usr/share/dict/words | head -n 4| sed 's/.*/&/;$!s/$// ' |tr '\n' '-' |sed 's/-$/\n/'

    sort -R /usr/local/share/eff_short_wordlist_1.txt |awk '{print$2}' | head -n 4| tr '\n' '-' | sed 's/-$/\n/'

> The shuf, shred, and sort commands sometimes need random data to do their work. For example, ‘sort -R’ must choose a hash function at random, and it needs random data to make this selection.

> By default these commands use an internal pseudo-random generator initialized by a small amount of entropy, but can be directed to use an external source with the --random-source=file option. An error is reported if file does not contain enough bytes.

-- https://www.gnu.org/software/coreutils/manual/html_node/Rand...

(emphasis mine)

You might end up with a fairly easy-to-brute-force password using that method.

They say "never roll your own crypto", but I think that advice probably holds pretty well for password generators(/managers). I'll stick with using a dedicated program. I reckon it's far less likely to have obvious blunders than something that's just been cobbled together using whatever tools happened to be lying around nearby.

I use it for usernames since Bitwarden doesn’t support diceware names.

It is also seeded.

[1]: https://git.gavinhoward.com/gavin/bc

    echo "rand()" | bc

    echo "irand(<bound>)" | bc

It can also be used to generate either really small or really large integers, arbitrary size. My bc will take care of everything behind the scenes.

If you want to generate a real between 0 and 1, use this:

     echo "frand(<places>)" | bc -l

If you want an arbitrary real (not between 0 and 1), use this:

    echo "ifrand(<bound>, <places>)" | bc -l

    echo "seed = $SEED; rand()" | bc

    echo "seed" | bc

    OUT=$(echo "rand(); seed" | bc)
    RAND=$(echo "$OUT" | head -n1)
    SEED=$(echo "$OUT" | tail -n1)
    RAND2=$(echo "seed = $SEED; rand()" | bc)

This pattern works because the `seed` variable is updated after every call to the PRNG.

Does that help?

> I could do more experiments and try to definitively determine what's happening, bottom line, don't use $RANDOM, even for unimportant random numbers.

  hexdump -e '"%d"' -n2 /dev/urandom

I can only think of one-liners in R or maybe python.

    normal_random() {
        start=$1
        end=$2
        range=$(echo "$end - $start" | bc -l)

        awk -v start=$start -v range=$range -v seed=$RANDOM '
        BEGIN {
            srand(seed);
            u1 = rand();
            u2 = rand();
            z0 = sqrt(-2 * log(u1)) * cos(2 * 3.14159265358979323846 * u2);
            z1 = sqrt(-2 * log(u1)) * sin(2 * 3.14159265358979323846 * u2);

            random_number = start + (z0 * (range / 6)) + (range / 2);
            printf("%.0f\n", random_number);
        }'
    }

EDIT: Nope, there's definitely something wrong with this, possibly the rand() call(s)? Can anyone guess? (A real-world example of the perils of relying on chatGPT!) EDIT2: Figured it out. srand with no args seeds to the current second, making any run of this function within the same second produce the same result. Fixing this left as an exercise to the reader EDIT3: I fixed it by seeding it externally via $RANDOM.

"The Box-Muller transform generates two normally distributed random numbers, z0 and z1, using the two uniformly distributed random numbers u1 and u2. However, only z0 is used in the provided function to create the random number within the given range. If you want to additionally supply z1 in the output, you can." It then provides the modified code.

   echo "$SRANDOM"
   for r in {1..5}; do printf "%s\n" "$SRANDOM"; done 

PORT=$(shuf -i 1000-2000 -n1)

aria2c --listen-port=$PORT ...other...options...

  $ for i in {1..999999}; do echo $((RANDOM-RANDOM)); done | sort -nu | grep -E '^-?.$'
  -9
  -8
  -7
  -6
  -5
  -4
  -3
  -2
  -1
  1
  2
  3
  4
  5
  6
  7
  8
  9

I remember learning about the enigma machine and how it had a flaw where a letter could not be transformed into itself. And knowing that, for example, an A could never be a A was critical to cracking the enigma code. Because of that knowledge, my cryptographic intuition is that any seemingly minor fact like this could actually be a critical flaw.

https://gist.github.com/pmarreck/e65f457e8755e461a87db7c94d4...

  rand() {
    local r4
    IFS= read -rk4 -u0 r4 < /dev/urandom || return
    local b1=$r4[1] b2=$r4[2] b3=$r4[3] b4=$r4[4]
    print $(( #b1 << 24 | #b2 << 16 | #b3 << 8 | #b4 ))
  }

    if (( RANDOM % 2 == 0 )); then echo Yes; else echo No; fi

    bit=$(od -An -N1 -i /dev/urandom)
    if (( $bit &1 ))
        then echo "Yes"
        else echo "No"
    fi

read -r < /proc/sys/kernel/random/uuid

MYRAND=$(( 0x${REPLY%%-*} ))

`( yes '00' | head -n 100000 | tr -d $'\n') | xxd -r -p | aespipe -e AES256 -P <(echo 'your-seed')`