Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Myths about /dev/urandom (2014)

2uo.de

Post reply on HN
Print view View original

11–20 of 70 posts

Re: Myths about /dev/urandom (2014)

#11

Post by adrianmonk »

tptacek wrote: post #6
adrianmonk wrote: post #4

> I just claim that it's bad to block when the entropy estimate is low. As always when it comes to engineering, good and bad can only be defined when you are specific enough about what it is you're trying to accomplish. Is it a single-user client system with an intelligent user who won't try to subvert security (maybe because you've defaulted to /dev/urandom but given them a choice to override and use /dev/random), a…

First problem with this response: programmers have a terrible understanding of what "crucial importance" is. In fact, most things in cryptography that want random values need unpredictable values. The old Linux man page creates the impression that you want "good" random for keys, and "mediocre" random for everything else, which is false. Second problem is, there is no such thing as "good" and "poor" random. There are…

> programmers have a terrible understanding of what "crucial importance" is.

If you cannot understand requirements, you cannot produce satisfactory software.

Anyway, it was intentional that I gave an example where an educated end user is able to make the choice rather than a programmer having to guess.

> The old Linux man page creates the impression that you want "good" random for keys, and "mediocre" random for everything else, which is false.

It certainly is false, and it is a myth that many people believe, but it isn't what I was saying.

> Once you read seeded state, you're done; blocking serves literally no purpose.

As the article explains under the last section ("Not everything is perfect"), /dev/urandom does not guarantee that you are reading seeded state.

Also, those numbers' unpredictability rests on the crypto being really good. Which I'm sure it is, but crypto weaknesses have been discovered in the past. It would be defensible to seek additional protection against that possibility for peace of mind if peace of mind is more important to you than running time and/or availability.

Re: Myths about /dev/urandom (2014)

#12

Post by TheDong »

Johnny555 wrote: post #8

On a VM that someone else runs (i.e. Google or AWS), is either /dev/random or /dev/urandom cryptographically secure? If no, are there any "safe" choices? (other than an external source like an HSM or hardware random number generator)

Most vms / cloud providers can provide a virtualized source of entropy to be mixed into the pool (google "virtio-rng"). Good OSs (like linux with the right virtio modules) will use that to have a high amount of entropy very early into boot. If that's what you're asking, then the answer is "yes, clouds have good urandom available, usually earlier than on real machines".

If instead you're asking "but can the cloud compromise me?" then the answer is "you're wrecked".

If you do not trust the hardware your vm is running on (be it real or virtual hardware), then you have no hope.

Any source of random numbers you read from will read those numbers into memory. The hypervisor or sufficiently-malicious-hardware will then be able to read your memory and get the data, even if it came from an hsm.

The "safe" choice is to trust that your hardware/hypervisor is not stealing such data.

If you can't trust that, you may have to start fabricating your own processors and running your own data-centres.

Be sure to hire better physical security than AWS has or else it's all for naught when someone comes in and yanks your memory to read it.

Re: Myths about /dev/urandom (2014)

#13

Post by Taniwha »

Taniwha wrote: post #5

(disclaimer I sell a HW random number generator) I think both the diagrams here are simplistic - in reality pre 4.8 there were 3 pools (an input pool and 2 output pools, one of which blocked) and post 4.8 where there are 2 pools, an input pool and a blocking pool (urandom now pulls from the input pool thru a CSPRNG). One big downside of the new (post 4.8) architecture is that urandom_min_reseed_secs is ignored - pre-…

BTW - a tiny bit of python to keep /dev/urandom fed post 4.8 - useful if you have a hardware RNG (either an external one or the one in your CPU):

  #! /usr/bin/python
  #
  #       OneRNG /dev/urandom tickler
  #       (C) Copyright Paul Campbell Moonbase Otago 2018
  #       Released under a GPL 3.0 license
  #
  import time

  with open("/dev/random", 'rb') as r:
          while True:
                  with 
  open("/proc/sys/kernel/random/entropy_avail", 'r') as e:  
                          iv = e.read()
                          print(iv)
                          if iv > 1500:
                                  x= r.read(1000)
                          e.close()
                  time.sleep(1)

Re: Myths about /dev/urandom (2014)

#14

Post by jMyles »

tptacek wrote: post #3
jMyles wrote: post #2

This document is very informative for sure, but I don't really think it's dispositive for many of today's use cases for randomness. In fact, I think this document is pretty dangerous. I referenced this document here in this stackexchange question, which I think has a good and lively discussion about the real stakes of /dev/urandom today: https://security.stackexchange.com/questions/186086/is-alway...

I don't think you're going to find too many cryptography engineers recommending that you use /dev/random, or, for that matter, the blocking variant of getrandom(2). This might be a live debate on message boards, or on the wrong stack overflow boards --- though Pornin's answer[1] on this question is one of the all-time good Stack Overflow answers --- but among practitioners, this is long settled. [1]: https://security…

Well, perhaps you have a better answer to my question than forest's answer, to which I awarded the bounty. For my money, I think that's one of the finest and most balanced pieces of writing on this topic available on the internet today.

> I don't think you're going to find too many cryptography engineers recommending that you use...the blocking variant of getrandom(2).

It depends on what you mean by "the blocking variant". To quote Cory Benfield:

> Can we please try to be clear about what kind of blocking we mean? getrandom(flags=0) absolutely can block: that's what the original issue was all about. To ensure it never blocks you need to call getrandom(GRND_NONBLOCK): that's why the flag exists.

It may (or may not) surprise you to learn that PEP 524, which uses this (sometimes blocking) variant of getrandom, has been accepted.

Here's a discussion of the matter featuring several reputable, kickass security-minded python people discussing the matter and indeed endorsing the sometimes-blocking (flags=0) variant of getrandom:

https://bugs.python.org/issue27266

For full transparency: I read your post on this topic before I posted my question and found that, as far as I was able to read, it added nothing new to the public discourse on this topic. It does not seem to overcome the very real and well-sourced concerns raised by forest in his answer to my question.

Anyway, I'm not sure what you mean by "the wrong stack overflow boards" - can you tell me which are right and which are wrong?

The link which you've provided, which of course I had already read thoroughly, as I pointed out in my question, is not from Stack Overflow, but from Security StackExchange, just like my question.

I haven't yet marked an answer correct, so if you actually have something substantive to add that you think is better than forest's answer, it's possible that you can grab the check.

Re: Myths about /dev/urandom (2014)

#15

Post by matbess »

Well written post, I enjoyed it, it makes sense.

The part tearing into the man page was especially excellent!

Following your point a little further.. the thought of updating the man pages with warnings like the following made me laugh:

“AES, SHA-3, RSA, Diffie-Hellman, Elliptic curves, and all those crypto packages you're using, OpenSSL, GnuTLS, Keyczar, your operating system's crypto API, are all theoretically vulnerable to a cryptographic attack. Knowledge of how to do this is not available in the current unclassified literature, but it is theoretically possible that such an attack may exist. If this is a concern in your application, do not use them.”

Re: Myths about /dev/urandom (2014)

#16

Post by matbess »

This article naturally leads to a question that I didn’t see addressed, perhaps you can answer it here:

If it’s unnecessary to ever prefer /dev/random to urandom, then why does /dev/random’s current blocking implementation still exist? Surely between all of the kernel developers, between all of the Unix-ish OS’s, over the last couple of decades would have realized that /dev/random should simply act like /dev/urandom?

Re: Myths about /dev/urandom (2014)

#17

Post by Scaevolus »

matbess wrote: post #16

This article naturally leads to a question that I didn’t see addressed, perhaps you can answer it here: If it’s unnecessary to ever prefer /dev/random to urandom, then why does /dev/random’s current blocking implementation still exist? Surely between all of the kernel developers, between all of the Unix-ish OS’s, over the last couple of decades would have realized that /dev/random should simply act like /dev/urandom?

Because Theodore Ts'o, a major Linux contributor and maintainer, created and maintains /dev/random and blocks attempts to make it nonblocking like every other cryptographically secure random source. It's a political problem, not a technical one.

See https://news.ycombinator.com/item?id=6550256 for a much longer argument about it.

Re: Myths about /dev/urandom (2014)

#18

Post by matbess »

Scaevolus wrote: post #17
matbess wrote: post #16

This article naturally leads to a question that I didn’t see addressed, perhaps you can answer it here: If it’s unnecessary to ever prefer /dev/random to urandom, then why does /dev/random’s current blocking implementation still exist? Surely between all of the kernel developers, between all of the Unix-ish OS’s, over the last couple of decades would have realized that /dev/random should simply act like /dev/urandom?

Because Theodore Ts'o, a major Linux contributor and maintainer, created and maintains /dev/random and blocks attempts to make it nonblocking like every other cryptographically secure random source. It's a political problem, not a technical one. See https://news.ycombinator.com/item?id=6550256 for a much longer argument about it.

I suspected that “politics” was going to end up being the answer to my question. Simply because this seems to be a very contentious issue, even if it doesn’t need to be.

Edit: Thanks for the link!

Post reply on HN