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

Ruby Bug: SecureRandom should try /dev/urandom first

bugs.ruby-lang.org

Post reply on HN
Print view View original

71–80 of 138 posts

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

#71

Post by throwaway2048 »

viraptor wrote: post #62
matt_wulfeck wrote: post #55

Earlier quoted context omitted.

true but even if we don't want to use /dev/random, there's still software using it all over the place that we don't necessarily want to patch. I end up installing haveged just because I don't want the system mysteriously locking up because some random daemon wants to create a 4096 bit key on first startup.

Replacing random with urandom for one app is just one LD_PRELOAD away. Similar to https://rafalcieslak.wordpress.com/2013/04/02/dynamic-linker... you can replace open("/dev/random") with open("/dev/urandom")

Its much easier and less error prone to just replace the device node.

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

#72

Post by masklinn »

ryuuchin wrote: post #18
viraptor wrote: post #4

So once again, the man page for urandom creates more problems than solutions. ( https://bugzilla.kernel.org/show_bug.cgi?id=71211 )

Obligatory "How To Safely Generate A Random Number" link[1] that I always wind up posting in threads like these. There's also the getrandom syscall[2] which uses the /dev/urandom pool. [1] http://sockpuppet.org/blog/2014/02/25/safely-generate-random... [2] http://man7.org/linux/man-pages/man2/getrandom.2.html

> There's also the getrandom syscall[2] which uses the /dev/urandom pool.

Sadly they just had to include GRND_RANDOM then compound that with GRND_NONBLOCK.

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

#73

Post by ben0x539 »

derefr wrote: post #67
Orangeair wrote: post #38

I really don't like the sentiment of "We shouldn't change it unless the man page says we can". That's exactly the kind of senseless bureaucracy that the open source community should be avoiding.

The manpages for syscalls and device nodes are basically their API specifications. They tell you what behaviours can be guaranteed (i.e. what properties are a part of the interface contract) and what behaviours cannot (i.e. what properties are implementation details of the current implementation, and could change at any time.) Just because the implementation of /dev/urandom has good properties that make usable as a s…

> 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.

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

#74

Post by lifthrasiir »

educar wrote: post #65
Perceptes wrote: post #30

This is sad and embarrassing for every involved party. The people leaving rude, entitled, hyperbolic comments in the thread, the Ruby developers who refuse to look into the best practice suggested by experts in the field, and the man page maintainer who refuses to update the man page in accordance with similar information.

Agreed that tensions are running high. But I think the ruby devs are in the right here. They are just following the man page. What else is the authoritarian source? How is one supposed to know who wrote those blog posts? Just because it is linuxexpert.com does not mean they are linux experts. It's funny, if people changed it randomly following blogs then people will claim this is some NSA conspiracy :-) How does one…

> They are just following the man page.

I think Ruby devs' position is more than this. By keeping the faulty man page, Linux maintainers are implicitly communicating that they intended `/dev/urandom` to be a limited and less recommended way of doing things. The intention is important: even though `/dev/urandom` is actually better in the current kernel it may not in the future. It is not the only answer, as other languages did another choice, but it is perfectly reasonable to be conservative like this.

We badly need to change that intention, really.

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

#75

Post by viraptor »

throwaway2048 wrote: post #71
viraptor wrote: post #62

Earlier quoted context omitted.

Replacing random with urandom for one app is just one LD_PRELOAD away. Similar to https://rafalcieslak.wordpress.com/2013/04/02/dynamic-linker... you can replace open("/dev/random") with open("/dev/urandom")

Its much easier and less error prone to just replace the device node.

I'd rather go for a limited scope. But yes, one way or another, you don't have to suffer just because someone hardcoded /dev/random in the app.

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

#76

Post by zurn »

jrochkind1 wrote: post #49
zurn wrote: post #44

Earlier quoted context omitted.

If you look at the bug filed against the man page, it doesn't exactly make a strong case. It just suggests some weasel words, about qualifying "large amount of data" etc. ( https://bugzilla.kernel.org/show_bug.cgi?id=71211 ) So bug report understates the issue, nobody has gotten around to writing a good quality patch, everyone is just loudly complaining elsewhere.

Actually, I'd say that issue/bug filed two years ago _does_ make a strong case that the current man page is insufficient, that it's actually the current man page that's full of ambiguous language and "weasel words". But you may make a good point that perhaps nobody has submitted a good patch yet -- you're right that issue isn't a good patch, just an invitation to enter into a discussion toward one (an invitation that…

> it's actually the current man page that's full of ambiguous language and "weasel words".

The report suggests "clarifying" what the man page means by the (completely incorrect) statement that "Users should be very economical in the amount of seed material that they read from /dev/urandom"

Probably the reporter was just being polite, but in the absence of other comments in the bug or any kernel developers weighing in, it just sounds like an editorial suggestion coming from a single Linux user. Remember that the man-pages project is separate from kernel development.

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

#77

Post by binkert »

educar wrote: post #65
Perceptes wrote: post #30

This is sad and embarrassing for every involved party. The people leaving rude, entitled, hyperbolic comments in the thread, the Ruby developers who refuse to look into the best practice suggested by experts in the field, and the man page maintainer who refuses to update the man page in accordance with similar information.

Agreed that tensions are running high. But I think the ruby devs are in the right here. They are just following the man page. What else is the authoritarian source? How is one supposed to know who wrote those blog posts? Just because it is linuxexpert.com does not mean they are linux experts. It's funny, if people changed it randomly following blogs then people will claim this is some NSA conspiracy :-) How does one…

The authoritative source in Linux is the code and always has been.

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

#78

Post by fulafel »

derefr wrote: post #67
Orangeair wrote: post #38

I really don't like the sentiment of "We shouldn't change it unless the man page says we can". That's exactly the kind of senseless bureaucracy that the open source community should be avoiding.

The manpages for syscalls and device nodes are basically their API specifications. They tell you what behaviours can be guaranteed (i.e. what properties are a part of the interface contract) and what behaviours cannot (i.e. what properties are implementation details of the current implementation, and could change at any time.) Just because the implementation of /dev/urandom has good properties that make usable as a s…

It would be nice if Linux man pages were on some level authoritative, but they aren't being maintained by the kernel developers and it's well known that they don't really live up to traditional Unix/BSD standards.

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

#79

Post by caf »

derefr wrote: post #69
caf wrote: post #47

Earlier quoted context omitted.

/dev/urandom is a shared resource across all processes, and that implies locking/synchronization that can run you into scalability issues if you are trying to generate a large volume of random numbers in parallel on multiple cores.

I'm surprised there's no talk of essentially making reads from /dev/urandom occur via a VDSO that grabs a seed for each process from the common pool, and then runs entropy generation from then on in the process's address space.

You really want a separate instance of the CSPRNG per thread, not per process.

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

#80

Post by forgotpwtomain »

dchest wrote: post #70
forgotpwtomain wrote: post #33

Earlier quoted context omitted.

ISAAC ( http://burtleburtle.net/bob/rand/isaacafa.html ) for a CSPRNG. But what is your use-case for something non-standard? Just use /dev/urandom

No, no, no, don't use ISAAC.

Do you have a citation you can provide? I don't know of any research that has shown a significant weakness in ISAAC.
Post reply on HN