Ruby Bug: SecureRandom should try /dev/urandom first • Hacker News Board

Re: Ruby Bug: SecureRandom should try /dev/urandom first

#121

Post by azet » Wed, May 04, 2016, 4:12 PM UTC

shevy wrote: post #114

azet wrote: post #89

Earlier quoted context omitted.

I don't think it's a culture thing at all. Japanese people are usually extremely polite and sincere. I also don't think this has anything to do with their history. If you look at replies I got from Ruby-core: some people would consider them to be rude as well; I'm constantly told I do not understand what I'm doing, and I've been in engineering for more than 12 years, into crypto for more than five (and been reading c…

Precisely. "The Ruby community even has their own acronym for being nice to other developers: MINASWAN" No, that is not true. That was coined, if I remember correctly, by the pickaxe. Matz is nice, but how does this translate to any other bad suggestion out there? I don't understand that logic. It's also not as if it is ... impossible to make suggestions to ruby core that are accepted? Like hundreds other people mana…

I'd usually not even consider replying to such a post as you clearly have neither read nor tried to understand my comment.

I replied to a post made above, and expressed deepest sympathy for the Japanese people. While I was born in central Europe, I'd rather not be a citizen of any nation. I spend more time abroad than in the country I was born in. Speaking of which: central Europe currently has a huge resurgence of facist ideologies and xenophobia due to migrants from war-torn countries. Something which is utterly inconceivable to most people able to read a history book, given Europe's not so distant past with genocide. Unfortunately, xenophobia and right-wing sentiment is something that every democracy and thus nation faces, Japan isn't exempt from that [0] [1] [2].

(I currently live in Asia and spend a lot of time in Arabic countries, you may reconsider educating me on the subject with references to the bboy scene.)

Aaron

[0] https://en.wikipedia.org/wiki/Category:Far-right_politics_in...

[1] https://en.wikipedia.org/wiki/Political_extremism_in_Japan#R...

[2] https://en.wikipedia.org/wiki/Uyoku_dantai

Re: Ruby Bug: SecureRandom should try /dev/urandom first

#122

Post by zaphar » Wed, May 04, 2016, 4:21 PM UTC

viraptor wrote: post #32

zaphar wrote: post #21

Earlier quoted context omitted.

would you listen to the docs or random-internet-person. I mean given that scenario as you describe it yes, obviously you go with the docs. But these aren't random-internet people. These are the acknowledged experts in the field. If you are writing crypto related code and aren't familiar with these people then there is far more wrong here than just this bug.

I think the problem is that this person is not writing crypto-related code. (or they don't think they do) They write an interface to N underlying interfaces providing RNGs and don't necessarily understand how they work internally or the theory behind them. And that's kind of ok - they made it work correctly, but it could be better. We don't expect person writing a Ruby binding for sqlite to know the theory behind dat…

Except they totally are writing crypto related code. It's called SecureRandom for a reason. If I as a user of Ruby see that code I have certain expectations regarding that. If the Ruby coder maintaining that code is not capable of doing the work required to satisfy those expectations then as I said there is much more wrong than just this bug.

It's reasonable to make this mistake initially sure. But when it's pointed out to you that the documentation is flat out wrong for reasons outside your and others control and you are pointed at articles and research by the experts in this field and you elect to ignore them then the security flaws that will result are very much on you just as much as they are on the linux man page maintainer.

Re: Ruby Bug: SecureRandom should try /dev/urandom first

#123

Post by goldbrick » Wed, May 04, 2016, 4:57 PM UTC

infraruby wrote: post #103

goldbrick wrote: post #102

Earlier quoted context omitted.

Why not just make the argument default to 16? Is something non-obvious going on?

The caller may pass nil explicitly.

I don't understand. You may still pass nil explicitly if the argument defaults to 16?

Re: Ruby Bug: SecureRandom should try /dev/urandom first

#124

Post by JoachimSchipper » Wed, May 04, 2016, 5:56 PM UTC

tptacek wrote: post #111

ben0x539 wrote: post #73

Earlier quoted context omitted.

> They try not to break userland code, yes, but userland code only relies on things the docs say it can, so... Judging from the odd Torvalds-yelling-at-people mail getting linked on HN, it doesn't sound like "it's ok to break userland here because clearly they didn't read the docs" would fly.

The proposed change --- unify urandom/random and permanently lose blocking behavior --- can't possibly break userland. There is no way to write a program that depends on /dev/random blocking, because it does so at random.

I've seen you post that a few times, so two minor nitpicks.

In the mental model in which the /dev/random manpage lives, it makes (some) sense to read /dev/random until you get a short read, then make a userland pool from all the data you've read, "to get as much entropy as possible". That reasoning doesn't actually make sense, of course, but I would be surprised if nobody thought that such a construction would be a good idea.

Separately, there's quite a lot of code - and I've written some - that reads a byte from /dev/random at daemon start, specifically to block until the system has built up enough entropy. FreeBSD blocks reads, even from /dev/urandom, until the [EDIT: estimate of how much entropy has ever gone into the pool] gets high enough, which makes some sense; but there needs to be some way to block-until-random.

Re: Ruby Bug: SecureRandom should try /dev/urandom first

#125

Post by tptacek » Wed, May 04, 2016, 5:59 PM UTC

JoachimSchipper wrote: post #124

tptacek wrote: post #111

Earlier quoted context omitted.

The proposed change --- unify urandom/random and permanently lose blocking behavior --- can't possibly break userland. There is no way to write a program that depends on /dev/random blocking, because it does so at random.

I've seen you post that a few times, so two minor nitpicks. In the mental model in which the /dev/random manpage lives, it makes (some) sense to read /dev/random until you get a short read, then make a userland pool from all the data you've read, "to get as much entropy as possible". That reasoning doesn't actually make sense, of course, but I would be surprised if nobody thought that such a construction would be a g…

FreeBSD blocks until the generator is seeded. I think Linux urandom should do the same thing. But once it's seeded, there is no reason for the generator ever to block again.

Re: Ruby Bug: SecureRandom should try /dev/urandom first

#126

Post by JoachimSchipper » Wed, May 04, 2016, 6:51 PM UTC

tptacek wrote: post #125

JoachimSchipper wrote: post #124

Earlier quoted context omitted.

I've seen you post that a few times, so two minor nitpicks. In the mental model in which the /dev/random manpage lives, it makes (some) sense to read /dev/random until you get a short read, then make a userland pool from all the data you've read, "to get as much entropy as possible". That reasoning doesn't actually make sense, of course, but I would be surprised if nobody thought that such a construction would be a g…

FreeBSD blocks until the generator is seeded. I think Linux urandom should do the same thing. But once it's seeded, there is no reason for the generator ever to block again.

Yes, that's what I meant. Edited for clarity, thanks!

Re: Ruby Bug: SecureRandom should try /dev/urandom first

#127

Post by mioelnir » Wed, May 04, 2016, 7:16 PM UTC

JoachimSchipper wrote: post #124

tptacek wrote: post #111

Earlier quoted context omitted.

The proposed change --- unify urandom/random and permanently lose blocking behavior --- can't possibly break userland. There is no way to write a program that depends on /dev/random blocking, because it does so at random.

I've seen you post that a few times, so two minor nitpicks. In the mental model in which the /dev/random manpage lives, it makes (some) sense to read /dev/random until you get a short read, then make a userland pool from all the data you've read, "to get as much entropy as possible". That reasoning doesn't actually make sense, of course, but I would be surprised if nobody thought that such a construction would be a g…

On 11.x random routinely unblocks before the userland is even started, so from an application standpoint random really never blocks.

Re: Ruby Bug: SecureRandom should try /dev/urandom first

#128

Post by infraruby » Wed, May 04, 2016, 7:22 PM UTC

goldbrick wrote: post #123

infraruby wrote: post #103

Earlier quoted context omitted.

The caller may pass nil explicitly.

I don't understand. You may still pass nil explicitly if the argument defaults to 16?

Yes:

  def f(n = 16)
    n
  end

  p f # => 16
  p f(nil) # => nil

Re: Ruby Bug: SecureRandom should try /dev/urandom first

#129

Post by astrodust » Wed, May 04, 2016, 11:09 PM UTC

tptacek wrote: post #16

astrodust wrote: post #8

Earlier quoted context omitted.

This talk about C++ and rand being harmful is quite educational: https://channel9.msdn.com/Events/GoingNative/2013/rand-Consi... What it points out is that even a good random number generator can be used incorrectly, and without the right tools your efforts to produce truly random numbers are doomed from the start. C++ has an embarrassing wealth of random number generators. The Ruby core has almost nothing that can m…

None of those C++ RNGs are suitable for cryptography. The answer for C++ CSPRNGs is, like in every other language, to use /dev/urandom. Multiple CSPRNGs just mean multiple single points of failure.

Not every random number generator has to be cryptographically secure. Sometimes they just need to be properly random.

Re: Ruby Bug: SecureRandom should try /dev/urandom first

#130

Post by viraptor » Wed, May 04, 2016, 11:58 PM UTC

matt_wulfeck wrote: post #119

viraptor wrote: post #59

Earlier quoted context omitted.

It's configurable. You can even forward host's /dev/urandom as guest's /dev/random.

Actually it's not supported with virtio-rng. Here[0] is a proposed patch to add support. [0] http://www.redhat.com/archives/libvir-list/2016-March/msg010...

I knew you can change the source (it accepts egd after all), but didn't know they actually prevent you from choosing urandom. This is sad :(