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

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

#91

Post by azet » Wed, May 04, 2016, 11:59 AM UTC

disposeofnick9 wrote: post #81

binkert wrote: post #77

Earlier quoted context omitted.

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.

Users of languages can't be expected to. Therefore the language designers and maintainers themselves, especially if they're working on the stdlib, should do so, IMO. It's not only education for a proficient programmer, it helps to understand the underlying system you're building on and it's security assumptions.

The random char device code isn't that hard to understand, and if you're not a strong C programmer (the Ruby-core people are good C programmers, I suppose) - there's a paper explaining how it works: https://eprint.iacr.org/2012/251.pdf

Aaron

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

#92

Post by tptacek » Wed, May 04, 2016, 12:07 PM UTC

matt_wulfeck wrote: post #54

tptacek wrote: post #12

Earlier quoted context omitted.

It's not the prevailing sentiment "on HN". It's the prevailing sentiment among virtually all experts everywhere . I can make a list of those experts, but I'll leave it to someone else, so as not to bogart an lay-up high-quality upvote magnet comment. The reason this is a problem is simply that the Linux maintainer is obstinately wrong. Theodore Ts'o was on HN a year or so ago, and in defending the current design (and…

Cryptographers really are part of the problem. Do you ever Read the discussions in the metzdowd/crypto list? Nobody agrees on anything.

The metzdowd list is a running joke among practitioners. The direct answer to your question is "no."

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

#93

Post by onli » Wed, May 04, 2016, 12:44 PM UTC

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…

> What else is the authoritarian source?

Basically everything else. If you see how manpages are written, or just how often they are out of date, you quickly arrive at the conclusion that they are not authoritative source at all. Add in the political plays done in this area. Being stubborn over a wrong manpage is very frightening, especially in a security context. This thread shakes my believe in ruby as a language.

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

#94

Post by infraruby » Wed, May 04, 2016, 1:01 PM UTC

wrs wrote: post #39

To make this discussion really useful: what's the easiest way for a Ruby application to make SecureRandom use /dev/urandom, without waiting for Ruby-core to be convinced?

  require "securerandom"

  module SecureRandom
    F = File.open("/dev/urandom")

    def self.random_bytes(n = nil)
      F.read(n || 16)
    end
  end

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

#95

Post by jhall1468 » Wed, May 04, 2016, 1:05 PM UTC

krzyk wrote: post #45

jhall1468 wrote: post #23

Earlier quoted context omitted.

Well, to be honest, this isn't the man page creating problems; this is the Ruby core team stubbornly refusing to fix a known problem. Using the man page as justification for their refusal is both stupid and weird. Who uses the Linux man page to determine their security?

Well, manpage has always been the source of information, the only better one is kernel source. I think majority would choose it over what some random (an average user doesn't know experts from crypto field by their names) people wrote on a forum on the Web.

I'd hope the Ruby core team is slightly above average users, and even if not, they could easily verify the claims. They selected not to purely out of stubborness and an unwillingness to admit they were wrong.

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

#96

Post by nilved » Wed, May 04, 2016, 1:33 PM UTC

binkert wrote: post #77

educar wrote: 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.

I think that's hardly the case. If Linux users were reading the source code, we wouldn't have such an embarrassing track record when it comes to security. Major security issues like Heartbleed existed in code for years.

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

#97

Post by dchest » Wed, May 04, 2016, 1:45 PM UTC

forgotpwtomain wrote: post #80

dchest wrote: post #70

Earlier quoted context omitted.

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.

Why would you use a PRNG with unknown cryptographic properties, not designed by a cryptographer, as opposed to one of the NIST's DRBG or a good stream cipher, such as ChaCha?

Weakness: https://eprint.iacr.org/2006/438 — "huge subsets of internal states which induce a strongly non-uniform distribution in the 8192 first bits produced"

Finally, why is deterministic PRNG suggested as a replacement for OpenSSL's random number generator? In general, the advice to write your own userspace PRNG replacement for OpenSSL is not a good advice, because many people are not competent enough to do it.

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

#98

Post by sibrahim » Wed, May 04, 2016, 1:49 PM UTC

Thiez wrote: post #58

sibrahim wrote: post #19

Earlier quoted context omitted.

I had a rather specialized case where it was the pragmatic choice (note, not technically required): running a lottery with potentially litigious losers. If you used a CSPRNG with a seed space smaller than the set of possible lottery outcomes, losers could argue (misleadingly, since we still couldn't feasibly bias the result) that not all outcomes were equally probable and try to get the results thrown out. That is, t…

Why not use a hardware rng in that case? Seems a lot safer if you have to deal with litigious people.

We did, in a way. One of the sources used was random.org (uses radio receivers tuned to static from atmospheric noise: hardware RNG as a service). I also had less than 3 weeks to take it from proposal to production.

Combining two independent sources obtained by different people and using a cryptographic commitment scheme ensured that 1) no one person could fix the results or make it nonrandom (protection against Eddie Tipton-style attacks), 2) if at least one of the independent sources was random, the result would be.

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

#99

Post by nabla9 » Wed, May 04, 2016, 1:57 PM UTC

azet wrote: post #89

kangar00 wrote: post #87

Earlier quoted context omitted.

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 c…

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

If you have organization with strict good manners policy and problems arise, this kind of passive-aggressive behavior is exactly what you should expect. "company policy" and PC rules can't make people better persons.

NOTE: This is not my opinion about Ruby-core team. I just want to point out that being polite does not mean that you interact well with others.

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

#100

Post by x1798DE » Wed, May 04, 2016, 2:06 PM UTC

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…

The part of the man page that can be considered a spec is the part that describes the behaviour, and the arguments in favor of always using /dev/urandom over /dev/random are based on the described blocking behaviour.

I'm fairly sure they would have to change the nature of /dev/urandom in such a way as would invalidate the other parts of the documentation in order to make the erroneous parts of the man page contain valid concerns.