5 ms·

This may not be cryptographically secure. Shuf can default to using a small amount of entropy.[1,2,3] To be certain, you can add the --random-source option:

by 1e-9 6y ago

This may not be cryptographically secure. Shuf can default to using a small amount of entropy.[1,2,3] To be certain, you can add the --random-source option: shuf --random-source=/dev/urandom -n 4 /usr/share/dict/words [1] https://www.gnu.org/software/coreutils/manual/html_node/Random-sources.html https://www.gnu.org/software/coreutils/manual/html_node/Rand... [2] https://github.com/coreutils/coreutils/blob/v8.5/gl/lib/randread.c https://github.com/coreutils/coreutils/blob/v8.5/gl/lib/rand... [3] https://github.com/coreutils/coreutils/blob/v8.32/gl/lib/randread.c https://github.com/coreutils/coreutils/blob/v8.32/gl/lib/ran... Edit: As ThA0x2 points out in a reply, the latest version of shuf uses /dev/urandom to generate a default nonce, which vastly improves upon older versions. As long as your version of coreutils is at least 8.6 or later and your OS has /dev/urandom, the default should be fine. If you don't have /dev/urandom, even the latest version of shuf (version 8.32, as of June 15, 2020) will still default to an insecure nonce.

deleted 6y ago
[deleted]
dllthomas 6y ago
I'm curious how practical an RNG attack actually is here (which absolutely isn't meant to serve as criticism of your surfacing the issue!). In any case, I expect it's much harder than a random "free password gen!" website saving results on the sly (... which is meant to be mild criticism of your framing, but not your recommendation :-p).
- rmrfstar 6y ago
  Depends on the situation. I definitely wouldn't try this on a freshly booted Raspberry Pi, for example.
- ThA0x2 6y ago
  shuf uses randint(), which defaults to /dev/urandom as the nonce source: https://github.com/coreutils/coreutils/blob/v8.31/gl/lib/randread.c https://github.com/coreutils/coreutils/blob/v8.31/gl/lib/ran... It's going to be as practical to attack as anything that uses /dev/urandom.
  - dllthomas 6y ago
    For sufficiently recent versions of shuf. It looks (... at a skim of the history, I could be confused) like older versions use pid, ppid, uid, gid, and time. In that case that's likely to be more practical than brute force if you've generated a password with notionally more than ~40 bits of entropy. That said, I suspect most people are indeed on a platform with a sufficiently recent version of shuf. (And a sufficiently old version may lack the random-source option.)
    - ThA0x2 6y ago
      RHEL 6 will be EOLd this November. That's the last supported version of RHEL that has this issue. Ubuntu 13.04, RHEL 7 and later don't suffer from this issue. I'd say almost everyone reading these comments is on a platform that does not suffer from this issue.
  - deleted 6y ago
    [deleted]
ThA0x2 6y ago
shuf uses randint(), which defaults to /dev/urandom as the nonce source: https://github.com/coreutils/coreutils/blob/v8.31/gl/lib/randread.c https://github.com/coreutils/coreutils/blob/v8.31/gl/lib/ran... Your "--random-source=/dev/urandom" line is superfluous. My original line is as secure as yours.
- 1e-9 6y ago
  Interesting. They stopped using /dev/urandom as the default random file in version 7.3, which created the insecure default situation. Later, in version 8.6, they updated to use a default nonce from /dev/urandom. It's odd that the documentation has not be updated. Perhaps it's because the latest version will still default to an insecure nonce if there is no /dev/urandom?
  - ThA0x2 6y ago
    If you're on a Linux OS that's from ~2013 or later, then you're most likely on a version of coreutils that will default to /dev/urandom. The master branch of coreutils is using getrandom(2). It will continue to draw entropy from the urandom source by default.
    - 1e-9 6y ago
      The latest versions of RHEL/CentOS 6 use coreutils version 8.4, so I assume their shuf defaults to insecure. I imagine that RHEL 5 ELS must have the same issue. I don't know of any other currently-supported Linux or BSD versions that might be a problem.
      - ThA0x2 6y ago
        RHEL 5 is from 2007, and is already past end of life (end of extended support is this November). RHEL 6 is from 2009, and it's end of life is this November. Both of those OS are not from 2013 or later. They may have minor versions that were released later, but minor versions typically don't make significant changes to core packages. RHEL 7 (2014) and Ubuntu 13.04 both have coreutils 8.20 or newer.

by 1e-9 6y ago

deleted 6y ago

[deleted]

dllthomas 6y ago

I'm curious how practical an RNG attack actually is here (which absolutely isn't meant to serve as criticism of your surfacing the issue!). In any case, I expect it's much harder than a random "free password gen!" website saving results on the sly (... which is meant to be mild criticism of your framing, but not your recommendation :-p).

rmrfstar 6y ago
Depends on the situation. I definitely wouldn't try this on a freshly booted Raspberry Pi, for example.
ThA0x2 6y ago
shuf uses randint(), which defaults to /dev/urandom as the nonce source: https://github.com/coreutils/coreutils/blob/v8.31/gl/lib/randread.c https://github.com/coreutils/coreutils/blob/v8.31/gl/lib/ran... It's going to be as practical to attack as anything that uses /dev/urandom.
- dllthomas 6y ago
  For sufficiently recent versions of shuf. It looks (... at a skim of the history, I could be confused) like older versions use pid, ppid, uid, gid, and time. In that case that's likely to be more practical than brute force if you've generated a password with notionally more than ~40 bits of entropy. That said, I suspect most people are indeed on a platform with a sufficiently recent version of shuf. (And a sufficiently old version may lack the random-source option.)
  - ThA0x2 6y ago
    RHEL 6 will be EOLd this November. That's the last supported version of RHEL that has this issue. Ubuntu 13.04, RHEL 7 and later don't suffer from this issue. I'd say almost everyone reading these comments is on a platform that does not suffer from this issue.
- deleted 6y ago
  [deleted]

ThA0x2 6y ago

shuf uses randint(), which defaults to /dev/urandom as the nonce source: https://github.com/coreutils/coreutils/blob/v8.31/gl/lib/randread.c https://github.com/coreutils/coreutils/blob/v8.31/gl/lib/ran... Your "--random-source=/dev/urandom" line is superfluous. My original line is as secure as yours.

1e-9 6y ago
Interesting. They stopped using /dev/urandom as the default random file in version 7.3, which created the insecure default situation. Later, in version 8.6, they updated to use a default nonce from /dev/urandom. It's odd that the documentation has not be updated. Perhaps it's because the latest version will still default to an insecure nonce if there is no /dev/urandom?
- ThA0x2 6y ago
  If you're on a Linux OS that's from ~2013 or later, then you're most likely on a version of coreutils that will default to /dev/urandom. The master branch of coreutils is using getrandom(2). It will continue to draw entropy from the urandom source by default.
  - 1e-9 6y ago
    The latest versions of RHEL/CentOS 6 use coreutils version 8.4, so I assume their shuf defaults to insecure. I imagine that RHEL 5 ELS must have the same issue. I don't know of any other currently-supported Linux or BSD versions that might be a problem.
    - ThA0x2 6y ago
      RHEL 5 is from 2007, and is already past end of life (end of extended support is this November). RHEL 6 is from 2009, and it's end of life is this November. Both of those OS are not from 2013 or later. They may have minor versions that were released later, but minor versions typically don't make significant changes to core packages. RHEL 7 (2014) and Ubuntu 13.04 both have coreutils 8.20 or newer.