Live data from Hacker News

Ruby Bug: SecureRandom should try /dev/urandom first

bugs.ruby-lang.org

81–90 of 138 posts

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

#81
post #77
post #65

Earlier quoted context omitted.

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.

Code is useless if no one knows how to use it properly and it's not communicated clearly. Users certainly can't be expected to read every line of code. That's like shipping a car with no user manuals and saying "take the engine apart and see how it works." Arrogance.

Clearly document system behavior or code is essentially useless.

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

#82
post #20

Earlier quoted context omitted.

Why are the man pages not so clear?

I'm not sure. I think part of the problem is that Linux still uses entropy estimation. This is also one of the issues I have with the proposed replacement[1][2] for Linux's current CSPRNG implementation since it still retains entropy estimations. [1] https://lwn.net/Articles/684568/ [2] https://news.ycombinator.com/item?id=11561340 (HN thread for [1])

Btw Linux / Fortuna

http://lkml.iu.edu/hypermail/linux/kernel/0504.1/1964.html

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

#83

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.

Some of this is certainly my own fault (context: I'm the rude guy in the thread). There were two comments made by myself that were considered "rude": one early on, where I actually didn't even mean to be. And my last reply was bascially a rage-quit.

But I put all relevant information, academic and engineering-wise in the thread to try to convince Ruby-core to change their opinion. I replied to false assumptions and comments as best as I could.

I'm also only a human and since this bug has been open for 2 years, I've used SecureRandom extensively in the past, this was a very frustrating experience for myself and all the commenters involved. I certainly do not have the most "diplomatic" approach (as a friend put it). I know that. But I'm not really sorry about that either, it's just who I am. I'm a nice guy IRL people tell me, but I can get obnoxious when people don't listen to severe security issues and always refer to upstream, have been so in quite a few projects and standards processes.

I'll work on that, promise ;)

Aaron

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

#84
post #48

Earlier quoted context omitted.

> We don't expect person writing a Ruby binding for sqlite to know the theory behind database indexes and who are the acknowledged experts in that field. We don't? More to the point, do we expect them to close a bug related to those things without educating themselves on the subject enough to make a rational decision on it?

I don't think it's reasonable to expect they already know that. Whether they should educate themselves... that's up for discussion I guess. The maintainer here effectively says: I read the docs and don't see a reason for a change; if the docs are wrong, prove it by changing them, if there's a bug in dependency handle the issue there. It's not the best solution, but if I ignored everything I know about this issue, I t…

The probability distribution function of average coder understandable-documentation decays exponentially with subject matter expertise, in most cases. Furthermore, it is often semi-rational, usually unconscious non-/for-profit "job-securitization" to lay landmines and obscure functionality to reinforce in-group, elite, "arcane knowledge" hoarding and seem "expert."

A startup founder often wants to work themselves out of a job to do more useful things, most will do all they can to insulate themselves into indispensability (a lot of technical people are super insecure, I'm proly one of them, and a lot of corporate gigs are cut-throat fiefdoms).

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

#85
post #48

Earlier quoted context omitted.

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…

> We don't expect person writing a Ruby binding for sqlite to know the theory behind database indexes and who are the acknowledged experts in that field. We don't? More to the point, do we expect them to close a bug related to those things without educating themselves on the subject enough to make a rational decision on it?

I think it would be entirely reasonable for the person maintaining a Ruby binding for sqlite to follow the sqlite documentation and close any bugs telling them to go against that documentation, yes.

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

#86
post #11
post #6

Earlier quoted context omitted.

I've used Mersenne Twister[0] in the past. [0] http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/emt.html If you're talking about an RNG library for cryptographic purposes, then it depends on your use case.

It does not depend on your use case. The answer, in all cases, is just to use /dev/urandom.

Are there not cases where blocking if there is insufficient entropy is the correct thing to do? Particularly if we're talking about important random numbers like long-lived private keys.

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

#87
post #83

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.

Some of this is certainly my own fault (context: I'm the rude guy in the thread). There were two comments made by myself that were considered "rude": one early on, where I actually didn't even mean to be. And my last reply was bascially a rage-quit. But I put all relevant information, academic and engineering-wise in the thread to try to convince Ruby-core to change their opinion. I replied to false assumptions and c…

Every interaction I've had with the Ruby core team has involved rudeness on their part.

I understand that Japanese culture is really different and that as a country they've really had horrible things done to them over the last hundred years that are inexcusable to say the absolute very least.

But just like any country, there are people with great people skills and people with no people skills. The Ruby core team lacks people skills. Whether it is a result of cultural problems that are a result of terrible things happening there, I can't say, but it really does Ruby a disservice.

All they need to do is listen and consider, but they don't, really.

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

#88

Earlier quoted context omitted.

Does it really? From https://bugs.openjdk.java.net/browse/JDK-4705093 : > If you call: new SecureRandom() on Linux and the default values are used, it will read from /dev/urandom and not block. (By default on Solaris, the PKCS11 SecureRandom is used, and also calls into /dev/urandom.)

I ran strace on both OpenJDK 7 and 8. It appears to open both /dev/random and /dev/urandom, but it only read from /dev/urandom. From reading the source code, it appears that /dev/random is used if you call SecureRandom::generateSeed, but /dev/urandom is used for SecureRandom::next. Of course, you can change a whole heck of a lot of stuff by setting properties on the command line or changing $JAVA_HOME/lib/security/ja…

Yep, shouldn't have second-guessed myself. Teach me to comment at 4am.

http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/s...

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

#89
post #83

Earlier quoted context omitted.

Some of this is certainly my own fault (context: I'm the rude guy in the thread). There were two comments made by myself that were considered "rude": one early on, where I actually didn't even mean to be. And my last reply was bascially a rage-quit. But I put all relevant information, academic and engineering-wise in the thread to try to convince Ruby-core to change their opinion. I replied to false assumptions and c…

Every interaction I've had with the Ruby core team has involved rudeness on their part. I understand that Japanese culture is really different and that as a country they've really had horrible things done to them over the last hundred years that are inexcusable to say the absolute very least. But just like any country, there are people with great people skills and people with no people skills. The Ruby core team lack…

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 cypherpunk lists since I was 15). I'm certainly not an academic cryptographer nor among the best engineers in the field, but I think I know a fair bit about the topic by now. I've contributed to many security projects, academic publications and standards processes -- this was certainly among the worst experiences I've had so far (you'd think IETF is worse, no. heated discussions all the time, but people stay focused and technical, listen to comments made by domain experts et cetera and act on them).

The Ruby community even has their own acronym for being nice to other developers: MINASWAN (https://en.wikipedia.org/wiki/Yukihiro_Matsumoto). I'm puzzled by the outcome of this discussion, but am assured by other security engineers and cryptographers that bugs they opened were treated equally badly, often ignored, even if they were non-disclosed, heavy security issues.

No idea. I'm not part of Ruby-core, neither Japanese. In my travels I've encountered many cultures and peoples, Japanese are amongst the most polite and friendly people I've met. Often very shy in that regard, like many asians (this is indeed a culture thing & certainly not a bad one). Some are xenophobic, but I wouldn't say that they all are, that's just false, I've met so many open-minded Japanese that I'd never generalise in that regard.

Aaron

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

#90
post #76

Earlier quoted context omitted.

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…

Yes, it reads to me like they were just being polite. The first couple sentences make it clear they think /dev/urandom is the right tool for "daily tasks" and that the man page is misleading people into thinking otherwise.

They begin with the most indisputable ways the man page is insufficient, as a way of starting the conversation -- which was never taken up.

Perhaps an actual patch would have been just accepted? Maybe the problem is the issue-submitter assumed there was someone on the other end who understood the kernel features and was interested in discussing making the man pages better.

Post reply on HN