71–80 of 90 posts
Earlier quoted context omitted.
I believe that chops was being sarcastic in ascribing a typical naive and useless attempt at "improving" randomness to "experts". Come on, "super random numbers"??
Yes, it was indeed a joke. And one which has apparentlly fallen flat.
If you have to explain a joke to someone, that means the joke is making fun of them!
Earlier quoted context omitted.
In engineering terms, it's easier to use a reversed-biased diode as a noise source. An input circuit would transfer the diode's random waveform into a shift register as zeros and ones, until the desired word size has been assembled. It's really quite simple, and it could produce a very high degree of randomness. It would differ from typical PRNGs in that the binary sequence could not be reproduced, no matter how much…
In engineering terms it would be easier to cover a shitty webcam with a bag, take a photo, and then use the lower bit of each pixel as the source of entropy. You can use other things, like microphone input, or CPU temperature. No need to buy expensive hardware generators. Then you can use something like Fortuna to generate more random numbers from that seed: http://en.wikipedia.org/wiki/Fortuna_(PRNG)
There's now been reported a way to hack a computer by way of its microphone, so that particular method is out.
> or CPU temperature.
CPU temperature doesn't change enough to serve as a secure source of entropy.
> No need to buy expensive hardware generators.
In fact, there are plenty of projects meant to locate sources of entropy to provide more randomness for computer security purposes. The idea of a hardware source like a reverse-biased diode is just one example.
> Then you can use something like Fortuna ...
Interestingly, the Fortuna scheme relies on system sources of entropy other than its own resources to assure security.
It seems to me that the only major issue here is using a seed which can be trivially brute forced. Even if you don't look around the expected server time in order to guess the seed more quickly, 32 bits is really not hard at all to brute force these days. I don't believe the number of bits the PRNG can generate is an issue here since we only need to uniformly get a number between 1 and 52, though what may be question…
Assume you have a deck of 3 cards. If you switch any 2 cards 3 times, you end up with 27 possibilities. But there are 3! (= 6) permutations. Obviously 27 isn't evenly divisible by 6, so some permutations are represented more than others.
It's not as big an issue, but it is an issue, and it's a mistake many people are likely to make.
Earlier quoted context omitted.
In engineering terms it would be easier to cover a shitty webcam with a bag, take a photo, and then use the lower bit of each pixel as the source of entropy. You can use other things, like microphone input, or CPU temperature. No need to buy expensive hardware generators. Then you can use something like Fortuna to generate more random numbers from that seed: http://en.wikipedia.org/wiki/Fortuna_(PRNG)
> You can use other things, like microphone input, There's now been reported a way to hack a computer by way of its microphone, so that particular method is out. > or CPU temperature. CPU temperature doesn't change enough to serve as a secure source of entropy. > No need to buy expensive hardware generators. In fact, there are plenty of projects meant to locate sources of entropy to provide more randomness for comput…
No, it's not. It's in some server in a datacenter. If you can get to the server, you can just change the Poker code, no need to do any crazy microphone hacking. Plus you'd need to know exactly when and how the microphone was sampled.
> CPU temperature doesn't change enough to serve as a secure source of entropy.
Doesn't matter how much it changes, the lowest bits are random on a large enough time scale.
You can just run the sampler until you get enough bits, it will take a few minutes. Or you can run it constantly and add more and more entropy as you go.
Earlier quoted context omitted.
> You can use other things, like microphone input, There's now been reported a way to hack a computer by way of its microphone, so that particular method is out. > or CPU temperature. CPU temperature doesn't change enough to serve as a secure source of entropy. > No need to buy expensive hardware generators. In fact, there are plenty of projects meant to locate sources of entropy to provide more randomness for comput…
> There's now been reported a way to hack a computer by way of its microphone, so that particular method is out. No, it's not. It's in some server in a datacenter. If you can get to the server, you can just change the Poker code, no need to do any crazy microphone hacking. Plus you'd need to know exactly when and how the microphone was sampled. > CPU temperature doesn't change enough to serve as a secure source of en…
> No, it's not.
Excuse me? Here's the source:
http://www.scientificamerican.com/article/computers-can-be-h...
Here's a quote: "Computers Can Be Hacked Using High-Frequency Sound -- A computer's microphone and speakers can covertly send and receive data"
Which word didn't you understand?
>> CPU temperature doesn't change enough to serve as a secure source of entropy.
> Doesn't matter how much it changes, the lowest bits are random on a large enough time scale.
False. Computer temperatures aren't a decent source of entropy, because they're too likely to remain stable for long periods. And the temperature can be predicted on a daily basis, a dangerous property for a secure source. That's why this source isn't used.
Earlier quoted context omitted.
No! You call a blocking rand function bound by available entropy. If your random source is compromised, adding two numbers from the same broken source does nothing. What you can do though, is XOR numbers from independent random sources to improve the entropy of the final output. (not sure if that's what you meant by adding random numbers together)
Oh, I get it. These are both joke comments that are commenting on the weird number of urban legends surrounding randomness.
You can prove to yourself that XOR-ing independent sources of entropy works:
Just remember that XOR is commutative, so you can rearrange the terms. Then realize that a XOR is how you implement a one-time pad.
So if you xor together 5 sources of "entropy", #1 is super broken and outputs all zeros, #2 is secure and independent, #3 is an NSA program, and #4 and #5 are weak, broken RNG's....then it doesn't matter, because the XOR's can be rearranged in your mind so that it's clear that #2 is still acting as an OTP on the rest (comes last). As long as it is uniform and independent (key really does get thrown away) you are good to go -- by the definition of OTP. If it had less than full entropy, then that means an OTP would leave some recoverable information.
Meanwhile, of course, the sources DO need to be independent. If #3 knows the stream that #2 is outputing, by coming later in the chain and producing its output after #2 has produced it, it can undo it by simply copying the output of #2.
This is why independence is important.
So in summary each XOR independently implements a one-time pad on all the rest of the xor results, whilst throwing away the key. If even one out of one hundred sources is actually random, doesn't matter which one, then the result is just as good as if that were the source yuo were using directly. As long as they are independent sources.
I haven't seen this link posted yet http://www.idquantique.com/random-number-generators/products... Note they claim: "QUANTIS has also been approved by national authorities and can be used for gaming applications." If I were implementing this for a casino, I'd do what other posters have already suggested and use at least two independent hardware sources for my random numbers and XOR them together. IMO Intel's on-chip…
Only if NSA contractors don't play online poker in their spare time.
Earlier quoted context omitted.
No! You call a blocking rand function bound by available entropy. If your random source is compromised, adding two numbers from the same broken source does nothing. What you can do though, is XOR numbers from independent random sources to improve the entropy of the final output. (not sure if that's what you meant by adding random numbers together)
Oh, I get it. These are both joke comments that are commenting on the weird number of urban legends surrounding randomness.
Read carefully what I said. Explained more clearly, XORing is at worst a ceiling function of the entropy of two random sources. If it weren't, that would imply one-time pad is insecure.