15 ms·

Here's my ldpreload hack: rerouting /dev/rand to dev/urand -- because I disagree with gpg's fears on entropy. Now it's as fast as generating a private key with

Here's my ldpreload hack: rerouting /dev/rand to dev/urand -- because I disagree with gpg's fears on entropy. Now it's as fast as generating a private key with ssh-keygen or openssl: https://github.com/matthewaveryusa/dev_random_fix https://github.com/matthewaveryusa/dev_random_fix

segfaultbuserr 8y ago
Why don't you replace it system-wide?
- matthewaveryusa 8y ago
  It's a shared system and I'm not going to prohibit the free exercise of other people's religions even though mine is clearly better.
- mikepurvis 8y ago
  Agree, couldn't this be done with a bind mount or something?
  - segfaultbuserr 8y ago
    The catch is old programs that depend on the blocking behavior of /dev/random during early boot could be an issue. Unlikely to be a problem on a server, though...
    - masklinn 8y ago
      If they're doing the replacement at runtime, the cold start is probably long done with.
  - jrockway 8y ago
    A bind mount? Just open up the source code and add a "u" where necessary.
    - vageli 8y ago
      > A bind mount? Just open up the source code and add a "u" where necessary. So, recompile every program and every subsequent update to use this functionality or...bind mount. One of these sounds easier than the other.
MereInterest 8y ago
My layman's understanding of the two is that /dev/urandom will happily output more bits than it has been seeded with, and so is unsuitable for use in cryptography, as it can output correlated values. Is my understanding here incorrect?
- segfaultbuserr 8y ago
  (edit: I see my parent post is being downvoted. How can this be? The commenter is just asking a question...) It is incorrect. Both /dev/urandom and /dev/random are connected to a CSPRNG. Once a CSPRNG is initialized by SUFFICIENT unpredictable inputs, it's forever unpredictable for (practically) unlimited output (something 2^128). If the CSPRNG algorithm is cryptographically-secure, and the implementation doesn't leak its internal state, it would be safe to use it for almost all cryptographic purposes. However, the original design in the Linux kernel was paranoid enough, it blocks /dev/random (even if a CSPRNG can output unlimited random bytes) if the kernel thinks the the output has exceeded the estimated uncertainty from all the random events. Most cryptographers believe if a broken CSPRNG is something you need to protect yourself from, you already have a bigger trouble, and it's unnecessary from a cryptographic point-of-view to be paranoid about a properly-initialized CSPRNG. /dev/random found on other BSDs is (almost) equivalent to Linux's /dev/urandom. However, /dev/urandom has its own issues on Linux. Unlike BSD's implementation, it doesn't block even if the CSPRNG is NOT initialized during early boot. If you automatically generate a key for, e.g. SSH, at this point, you'll have serious troubles - predictable keys, so reading from /dev/random still has a point, although not for 90% of the programs. I think it's a prefect example of being overly-paranoid about unlikely dangers, while overlooking straightforward problems that are likely to occur. The current recommended practice is to call getrandom() system call (and arc4random()* on BSDs) when it's available, instead of reading from raw /dev/random or /dev/urandom. It blocks, until the CSPRNG is initialized, otherwise it always outputs something. *and no, it's not RC4-based, but ChaCha20-based on new systems.
  - loeg 8y ago
    > /dev/random found on other BSDs is equivalent to Linux's /dev/urandom. This isn't quite true. The BSDs random (and urandom) block until initially seeded, unlike Linux's urandom. Then they don't block. (Like the getrandom/getentropy behavior.) > The current recommended practice is to call getrandom() system call (and arc4random() on BSDs) when it's available, instead of reading from raw /dev/random or /dev/urandom. It blocks when the CSPRNG is initialized, but otherwise it always outputs something. +1 (I'd phrase that as "blocks until the CSPRNG is initialized," which for non-embedded systems will always be before userland programs can even run, and for embedded should not take long after system start either).
nemonemo 8y ago
I am curious. How do you know if this is secure or not? Is there any publication or article available for this slightly time-saving but potentially dangerous choice?
- segfaultbuserr 8y ago
  1. The official man page. The /dev/random interface is considered a legacy interface, and /dev/urandom is preferred and sufficient in all use cases, with the exception of applications which require randomness during early boot time; for these applications, getrandom(2) must be used instead, because it will block until the entropy pool is initialized. 2. https://www.2uo.de/myths-about-urandom/ https://www.2uo.de/myths-about-urandom/
  - tomjakubowski 8y ago
    Not that I disagree with you, but which are the official man pages for /dev/urandom? It's my recollection that the advice therein varies from OS to OS.
    - segfaultbuserr 8y ago
      This page is part of release 4.16 of the Linux man-pages project. A description of the project, information about reporting bugs, and the latest version of this page, can be found at https://www.kernel.org/doc/man-pages/ https://www.kernel.org/doc/man-pages/. And only Linux has /dev/urandom.
      - deleted 8y ago
        [deleted]
      - floatboth 8y ago
        BSDs (incl. macOS) have /dev/urandom, but it's the same thing as /dev/random. Both don't ever block after they've been filled initially at boot time.
- loeg 8y ago
feisuzhu 8y ago
You can just replace the /dev/random device file with /dev/urandom
kelnos 8y ago
You can also just simply delete /dev/random and symlink it to urandom. Or delete it and create a character device at /dev/random that uses urandom's major/minor numbers.
Maskawanian 8y ago
Here's mine: https://github.com/dsaul/UDELibXprop-Legacy https://github.com/dsaul/UDELibXprop-Legacy I was writing a dock program over a decade ago, and java programs didn't put the PID on the window, whereas everything else did. Had to fix it somehow...

segfaultbuserr 8y ago

Why don't you replace it system-wide?

matthewaveryusa 8y ago
It's a shared system and I'm not going to prohibit the free exercise of other people's religions even though mine is clearly better.
mikepurvis 8y ago
Agree, couldn't this be done with a bind mount or something?
- segfaultbuserr 8y ago
  The catch is old programs that depend on the blocking behavior of /dev/random during early boot could be an issue. Unlikely to be a problem on a server, though...
  - masklinn 8y ago
    If they're doing the replacement at runtime, the cold start is probably long done with.
- jrockway 8y ago
  A bind mount? Just open up the source code and add a "u" where necessary.
  - vageli 8y ago
    > A bind mount? Just open up the source code and add a "u" where necessary. So, recompile every program and every subsequent update to use this functionality or...bind mount. One of these sounds easier than the other.

MereInterest 8y ago

My layman's understanding of the two is that /dev/urandom will happily output more bits than it has been seeded with, and so is unsuitable for use in cryptography, as it can output correlated values. Is my understanding here incorrect?

segfaultbuserr 8y ago
(edit: I see my parent post is being downvoted. How can this be? The commenter is just asking a question...) It is incorrect. Both /dev/urandom and /dev/random are connected to a CSPRNG. Once a CSPRNG is initialized by SUFFICIENT unpredictable inputs, it's forever unpredictable for (practically) unlimited output (something 2^128). If the CSPRNG algorithm is cryptographically-secure, and the implementation doesn't leak its internal state, it would be safe to use it for almost all cryptographic purposes. However, the original design in the Linux kernel was paranoid enough, it blocks /dev/random (even if a CSPRNG can output unlimited random bytes) if the kernel thinks the the output has exceeded the estimated uncertainty from all the random events. Most cryptographers believe if a broken CSPRNG is something you need to protect yourself from, you already have a bigger trouble, and it's unnecessary from a cryptographic point-of-view to be paranoid about a properly-initialized CSPRNG. /dev/random found on other BSDs is (almost) equivalent to Linux's /dev/urandom. However, /dev/urandom has its own issues on Linux. Unlike BSD's implementation, it doesn't block even if the CSPRNG is NOT initialized during early boot. If you automatically generate a key for, e.g. SSH, at this point, you'll have serious troubles - predictable keys, so reading from /dev/random still has a point, although not for 90% of the programs. I think it's a prefect example of being overly-paranoid about unlikely dangers, while overlooking straightforward problems that are likely to occur. The current recommended practice is to call getrandom() system call (and arc4random()* on BSDs) when it's available, instead of reading from raw /dev/random or /dev/urandom. It blocks, until the CSPRNG is initialized, otherwise it always outputs something. *and no, it's not RC4-based, but ChaCha20-based on new systems.
- loeg 8y ago
  > /dev/random found on other BSDs is equivalent to Linux's /dev/urandom. This isn't quite true. The BSDs random (and urandom) block until initially seeded, unlike Linux's urandom. Then they don't block. (Like the getrandom/getentropy behavior.) > The current recommended practice is to call getrandom() system call (and arc4random() on BSDs) when it's available, instead of reading from raw /dev/random or /dev/urandom. It blocks when the CSPRNG is initialized, but otherwise it always outputs something. +1 (I'd phrase that as "blocks until the CSPRNG is initialized," which for non-embedded systems will always be before userland programs can even run, and for embedded should not take long after system start either).

nemonemo 8y ago

I am curious. How do you know if this is secure or not? Is there any publication or article available for this slightly time-saving but potentially dangerous choice?

segfaultbuserr 8y ago
1. The official man page. The /dev/random interface is considered a legacy interface, and /dev/urandom is preferred and sufficient in all use cases, with the exception of applications which require randomness during early boot time; for these applications, getrandom(2) must be used instead, because it will block until the entropy pool is initialized. 2. https://www.2uo.de/myths-about-urandom/ https://www.2uo.de/myths-about-urandom/
- tomjakubowski 8y ago
  Not that I disagree with you, but which are the official man pages for /dev/urandom? It's my recollection that the advice therein varies from OS to OS.
  - segfaultbuserr 8y ago
    This page is part of release 4.16 of the Linux man-pages project. A description of the project, information about reporting bugs, and the latest version of this page, can be found at https://www.kernel.org/doc/man-pages/ https://www.kernel.org/doc/man-pages/. And only Linux has /dev/urandom.
    - deleted 8y ago
      [deleted]
    - floatboth 8y ago
      BSDs (incl. macOS) have /dev/urandom, but it's the same thing as /dev/random. Both don't ever block after they've been filled initially at boot time.
loeg 8y ago

feisuzhu 8y ago

You can just replace the /dev/random device file with /dev/urandom

kelnos 8y ago

You can also just simply delete /dev/random and symlink it to urandom. Or delete it and create a character device at /dev/random that uses urandom's major/minor numbers.

Maskawanian 8y ago

Here's mine: https://github.com/dsaul/UDELibXprop-Legacy https://github.com/dsaul/UDELibXprop-Legacy I was writing a dock program over a decade ago, and java programs didn't put the PID on the window, whereas everything else did. Had to fix it somehow...