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

An Analysis of OpenSSL's Random Number Generator

eprint.iacr.org

Post reply on HN
Print view View original

31–37 of 37 posts

Re: An Analysis of OpenSSL's Random Number Generator

#31

Post by Natanael_L »

Natanael_L wrote: post #26
plaguuuuuu wrote: post #20

Earlier quoted context omitted.

that sounds unsafe

A hash of the private key isn't actually bad to use for entropy. It's what's done in deterministic EC signatures, deriving the k value from the private key + message.

As long as the hash function is strong, why exactly would this be weak? Downvoting me implies you believe these people are wrong too;

https://tools.ietf.org/html/rfc6979

> It is possible to turn DSA and ECDSA into deterministic schemes by using a deterministic process for generating the "random" value k. That process must fulfill some cryptographic characteristics in order to maintain the properties of verifiability and unforgeability expected from signature schemes; namely, for whoever does not know the signature private key, the mapping from input messages to the corresponding k values must be computationally indistinguishable from what a randomly and uniformly chosen function (from the set of messages to the set of possible k values) would return.

> d. Set: > K = HMAC_K(V || 0x00 || int2octets(x) || bits2octets(h1))

> where '||' denotes concatenation. In other words, we compute HMAC with key K, over the concatenation of the following, in order: the current value of V, a sequence of eight bits of value 0, the encoding of the (EC)DSA private key x, and the hashed message (possibly truncated and extended as specified by the bits2octets transform). The HMAC result is the new value of K. Note that the private key x is in the [1, q-1] range, hence a proper input for int2octets, yielding rlen bits of output, i.e., an integral number of octets (rlen is a multiple of 8).

Re: An Analysis of OpenSSL's Random Number Generator

#32

Post by neerdowell »

jjnoakes wrote: post #30
neerdowell wrote: post #24

Earlier quoted context omitted.

/dev/urandom isn't reliable; it fails in a chroot, if file handles are exhausted, etc.

It fails in a poorly set up chroot, not any old chroot. It also fails in a poorly set up root file system in the same way. No chroot needed. I can't remember ever running out of file descriptors unless a program had a leak. But if you want to argue that position too, make sure you mention that cputime and memory could also be exhausted, leading to... well... any other method failing in a similar fashion. A system cal…

> It fails in a poorly set up chroot, not any old chroot.

It fails for any program that calls chroot(2) and chroots to a location that hasn't had /dev/urandom constructed, which is... almost every program that sandboxes by calling chroot(2).

> I can't remember ever running out of file descriptors unless a program had a leak.

You've probably never used ulimits or login groups then.

> But if you want to argue that position too, make sure you mention that cputime and memory could also be exhausted, leading to... well... any other method failing in a similar fashion.

You're writing a library and in one of the functions you call arc4random(3). How would you handle memory being exhausted at the time when arc4random is called? Hint: you wouldn't. You'd let the OS handle it, probably by terminating something. Which might be the running process or another process.

New situation, you're writing a library and in one of the functions you open() a file handle and read() from it. How would you handle that operation failing? Thought about it? Got your answer? Good.

Now see the comments in LibreSSL for why your answer to that is wrong: https://github.com/libressl-portable/openbsd/blob/cb62fd8b9b...

> But calling /dev/urandom unreliable is a little bit intellectually dishonest.

/dev/urandom is not a high-availability randomness source, therefore it is unreliable. It is not intellectually dishonest, it is a statement of fact.

Re: An Analysis of OpenSSL's Random Number Generator

#33

Post by jjnoakes »

neerdowell wrote: post #32
jjnoakes wrote: post #30

Earlier quoted context omitted.

It fails in a poorly set up chroot, not any old chroot. It also fails in a poorly set up root file system in the same way. No chroot needed. I can't remember ever running out of file descriptors unless a program had a leak. But if you want to argue that position too, make sure you mention that cputime and memory could also be exhausted, leading to... well... any other method failing in a similar fashion. A system cal…

> It fails in a poorly set up chroot, not any old chroot. It fails for any program that calls chroot(2) and chroots to a location that hasn't had /dev/urandom constructed, which is... almost every program that sandboxes by calling chroot(2). > I can't remember ever running out of file descriptors unless a program had a leak. You've probably never used ulimits or login groups then. > But if you want to argue that posi…

> It fails for any program that calls chroot(2) and chroots to a location that hasn't had /dev/urandom constructed, which is... almost every program that sandboxes by calling chroot(2).

Yeah. Those programs fail if they try to do anything with the file system they weren't set up for. Running external commands via the shell? Better have /bin/sh. Running executables? Better have the libraries set up. Resolving hostnames? Better have the files in /etc and nsswitch and others. Probably want a /dev/tty. /dev/null. /proc mounted. /sys mounted. Or, if you are really a super bare bones app which knows it doesn't need any of that stuff, you pre-read /dev/urandom before you chroot(2) or you use the system call.

None of that means /dev/urandom is unreliable.

> You've probably never used ulimits or login groups then.

Sure I have. But I have never run anything that needed more than 32 open files at a time. If your limits are pathologically low, you can come up with any scenario where trivial programs fail to work. But such a discussion isn't productive.

> [bunch of nonsense]

Returning an error code seems to be a fine option if your library is asked to perform a task and it can not. I see nothing in LibreSSL which indicates that this is a bad idea.

What IS a bad idea is falling back to some nonsense like getuid() + getpid() + time() instead of returning some error. If you can't access a random number generator and you need a random number (and especially if you are a cryptography library) then return a failure error code.

But that's orthogonal to this discussion (why did you bring up LibreSSL?)

> /dev/urandom is not a high-availability randomness source

Well by your definition, nothing is high-availability, so everything is unreliable. So I guess you are right, in your world, but your argument just became meaningless.

A system call is better, but /dev/urandom is fine.

Re: An Analysis of OpenSSL's Random Number Generator

#34

Post by jasonvorhe »

geofft wrote: post #18
slavik81 wrote: post #16

Earlier quoted context omitted.

The usual time I've been concerned has been after creating a new virtual machine. Right after creating a new DO droplet I need to do a bunch of things to set up my application, like seed my CSRF token generator. Of course, /dev/random would block for ages at that point, so I instead generate the seed on a different machine.

Ugh, yes, the practice of short-lived machines throws off the assumption of "when it was last shut down." You are totally right that this is a concern. The ideal solution to this would be for hypervisors to just pass a random seed to their guests. (There is even a full virtio-rng device in qemu, it just seems to have /dev/random semantics from a quick glance.) I don't know how we get to the point of convincing the bi…

Wouldn't it help to run something like havaged on the virtualization host that's feeding entropy to the virtualized nodes?

Re: An Analysis of OpenSSL's Random Number Generator

#35

Post by jquast »

jasonvorhe wrote: post #34
geofft wrote: post #18

Earlier quoted context omitted.

Ugh, yes, the practice of short-lived machines throws off the assumption of "when it was last shut down." You are totally right that this is a concern. The ideal solution to this would be for hypervisors to just pass a random seed to their guests. (There is even a full virtio-rng device in qemu, it just seems to have /dev/random semantics from a quick glance.) I don't know how we get to the point of convincing the bi…

Wouldn't it help to run something like havaged on the virtualization host that's feeding entropy to the virtualized nodes?

yes

Re: An Analysis of OpenSSL's Random Number Generator

#36

Post by KMag »

caf wrote: post #29
ryuuchin wrote: post #4

I can't understand Why OpenSSL continues to use it's own PRNG implimentation when we have /dev/urandom and CryptGenRandom which are known to be good. This is basically what BoringSSL does (although if you have rdrand then it will get filtered through a ChaCha20 instance). I'm pretty sure OpenSSL doesn't even reseed its PRNG on Windows unless the calling application does it so I'm not sure how that's safe either. If y…

Seeding a userspace CSPRNG from /dev/urandom or getrandom(2) is actually the right approach. The kernel pool is a resource shared among all processes, with the locking and therefore scalability constraints that implies.

Also, it's a good idea to reseed your userspace CSPRNG from the kernel's entropy source periodically. This is precisely what OpenBSD did with their arc4random and arc4random_buf library calls. (Don't worry, they now use ChaCha20 instead of arcfour/RC-4, but have kept the function name unchanged, since it's a backward-compatible change... the only way a caller can tell RC-4 from ChaCha20 is by detecting small statistical biases in RC-4's outputs.)

Re: An Analysis of OpenSSL's Random Number Generator

#37

Post by maxerickson »

miles wrote: post #13
ryuuchin wrote: post #4

I can't understand Why OpenSSL continues to use it's own PRNG implimentation when we have /dev/urandom and CryptGenRandom which are known to be good. This is basically what BoringSSL does (although if you have rdrand then it will get filtered through a ChaCha20 instance). I'm pretty sure OpenSSL doesn't even reseed its PRNG on Windows unless the calling application does it so I'm not sure how that's safe either. If y…

"/dev/urandom and CryptGenRandom which are known to be good" Check out "A good idea with bad usage: /dev/urandom" : http://insanecoding.blogspot.com/2014/05/a-good-idea-with-ba... Just stumbled onto it in the new submissions queue: https://news.ycombinator.com/item?id=11485876

That article says //Continue filling with other sources where it should say //exit with an error.
Post reply on HN