close
The Wayback Machine - https://web.archive.org/web/20200918035114/https://github.com/jedisct1/libsodium/issues/594
Skip to content

/ libsodium

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Are we using /dev/urandom on Mac OS and is that a bad idea? #594

Closed
NodeGuy opened this issue Sep 10, 2017 · 5 comments
Closed

Are we using /dev/urandom on Mac OS and is that a bad idea? #594

NodeGuy opened this issue Sep 10, 2017 · 5 comments

Comments

@NodeGuy
Copy link

@NodeGuy NodeGuy commented Sep 10, 2017

The manual states:

On other Unices, the /dev/urandom device is used

I assume that applies to Mac OS. On Mac OS, /dev/urandom (which is the same as /dev/random) has several problems:

  • Beware of /dev/random on Mac OS X
  • Yarrow requires entropy estimation, which is a very big challenge for implementation. It is hard to be sure how much entropy to collect before using it to reseed the PRNG. This problem is solved by Fortuna (PRNG), an improvement of Yarrow. Fortuna has 32 pools to collect entropy and removed the entropy estimator completely.[1]
  • Yarrow-160 uses SHA1, which has widely been considered deprecated due to its first public collision.[1]

From the Yarrow paper:

Like any other cryptographic primitive, a Yarrow generator has a
limited strength which we express in the size of the key. Yarrow-160
relies on the strength of three-key triple-DES and SHA-1. Systems that
have switched to the new cryptographic mechanisms (such as the new AES
cipher, when it is selected) in the interests of getting higher security
should also use a different version of Yarrow to rely on those new
mechanisms. If a longer key is necessary, then a future "larger" version
of Yarrow should be used; it makes no sense to use a 160-bit PRNG to
generate a 256-bit key for a block cipher, if 256 bits of security are
actually required.

From Mac OS's man page for /dev/urandom:

Yarrow is a fairly resilient algorithm, and is believed to be resistant to non-root. The
quality of its output is however dependent on regular addition of appropriate entropy. If
the SecurityServer system daemon fails for any reason, output quality will suffer over
time without any explicit indication from the random device itself.

Paranoid programmers can counteract this risk somewhat by collecting entropy of their
choice (e.g. from keystroke or mouse timings) and seeding it into random directly before
obtaining important random numbers.

Should Sodium supply its own CSPRNG (such as Fortuna, the improvement over Yarrow that FreeBSD switched to but Mac OS did not) instead of reading from /dev/urandom when on Mac OS?

[1] https://en.wikipedia.org/wiki/Yarrow_algorithm#Cons
@NodeGuy
Copy link
Author

@NodeGuy NodeGuy commented Sep 10, 2017 •
edited

Hmm, I just found this blog article which suggests that using a user space CSPRNG is a bad idea:

https://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/

It looks like the correct security fix is for me to stop using Mac OS. :-(
@NodeGuy NodeGuy closed this Sep 10, 2017
@jedisct1
Copy link
Owner

@jedisct1 jedisct1 commented Sep 12, 2017 •
edited

/dev/urandom should be totally fine.

The mailing list post you mention was sent 15 years ago, and refers to a section of the man page that doesn't exist any more. The current code is here: https://github.com/opensource-apple/xnu/tree/53c5e2e62fc4182595609153d4b99648da577c39/osfmk/prng

SHA-1 collisions are also irrelevant to its use within a PRNG.

libsodium does ship with a userland PRNG even though it is not thread-safe and is never used by default. You can enable it with randombytes_set_implementation(&randombytes_salsa20_implementation). But macOS is fine, really.
@NodeGuy
Copy link
Author

@NodeGuy NodeGuy commented Sep 13, 2017

That man page is still in my copy of OX X El Capitan and the code you linked to is the same problematic Yarrow code but I appreciate your reassurance, thank you.
@FSMaxB
Copy link

@FSMaxB FSMaxB commented Sep 14, 2017

@NodeGuy: The Yarrow code is still there, but I don't see it used in random.h and random.c (maybe I'm wrong?).
@NodeGuy
Copy link
Author

@NodeGuy NodeGuy commented Sep 15, 2017

At a cursory glance this comment in random.h suggests otherwise:

/*
 * Wrapper for requesting a CCDRBG operation.
 * This macro makes the DRBG call with pre-emption disabled to ensure that
 * any attempt to block will cause a panic. And the operation is timed and
 * cannot exceed 10msec (for development kernels).
 * But skip this while we retain Yarrow.
 */
#define YARROW 1

https://github.com/opensource-apple/xnu/blob/53c5e2e62fc4182595609153d4b99648da577c39/osfmk/prng/random.h#L76-L83
@dhardy dhardy mentioned this issue Feb 18, 2019
Closed
Repository owner locked and limited conversation to collaborators Aug 28, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
@jedisct1 @NodeGuy @FSMaxB
You can’t perform that action at this time.