Even back in the early 1980's college students would add things like "bomb terrorist hijack communist assassinate" in their signature because of the rumors that the Usenet was being monitored by NSA programs that where basically data-mining for words like that. I had a friend who was pretty paranoid about it, so I wrote an email to him begging him to give up his plan to blow up a bunch of people. He didn't think it was very funny. I suspect some poor NSA schmuck has had the displeasure of being assigned to read most of what I say on line ever since... sorry if it's true!

I agree. The real firestorm was when Fox News was stoking Tea Party fear of Obama spying on Americans. It was so effective, Fox News had to stop for fear of actually forcing the Tea Party congressmen to vote against continuing surveillance, which as you know, they didn't do - our Tea Party Freedom Fighters voted to continue with zero change, right along with everyone else in congress.

The outrage might be stronger here on slashdot, but most of us haven't heard a single new revelation, only confirmations. On the plus side, my wife and friends no longer think I'm a paranoid conspiracy theorist for believing many of the leaks posted here on slashdot over the years.

I just read TFA and associated paper, and the petition. Linus was right, the petition was pointless, and motivated by confusion on the petitioner's part. However, the paper points out some scary issues in the Linux PRNG. It's tin-foil hat stuff, but it shows how one user on a Linux system could write a malicious program that would drain the entropy pools, and then feed the entropy pool non-random data which Linux would estimate as very random. If this attack were done just before a user uses /dev/random to generate a cryptographic key, that key could be compromised, meaning the attacker may be able to guess it.

The paper echos a call for Linux to stop estimating entropy, meaning effectively we'd just have /dev/urandom only, and people who require cryptographically strong random bits would have to look elsewhere. As a practical matter, I disagree. /dev/random may not be 100% secure, but it's handy.

Let me try again using software this time instead of hardware. If I let my PC count from 0 to 2^32 in a loop until I hit enter, then the lowest bits will be very random, while the highest aren't very random at all. If I do this over and over, and XOR all the bits of all the counter results together, I can easily create crypto-grade random bits. If a hacker manages to add a signal of his design to my counter values, it has no impact on the randomness of my generated bits. This is obvious once you know that XORing a non-random value on top of a random value in no way reduces its randomness. If a random value v has exactly 50% probability of being 1, then I can flip the value by XORing 1 onto it, and it still has exactly 50% chance of being 1. Now if the hacker could AND values onto the counter values, I'd lose randomness, but any operation that is mathematically a permutation, like addition or XOR, does not reduce randomness.

The system I built does the same thing, generating 40 million 8 bit values per second that are similar to the counter values described above. The low bits are highly random, and the high bits are not. If you simply add a signal to these values it has zero impact on the randomness of the result, just like with the counter values. Now if your signal overloads the amplifier, causing clipping, then the output might be 255 for many samples. That would brake the RNG, just like AND-ing 0's onto my counters would do.

Anyway, this is not rocket science. People seem to think you can't make good random data without a Ph.D. in cryptography, but in reality, all you need is a source of *some* randomness and the XOR operation. The math is pretty simple, too.

There's a simple fact that makes hardware RNGs easy. It really isn't rocket science.

XORing bits that each contain a small amount of true randomness leads quickly to high quality true randomness. Model the output bit stream from the hardware RNG as v(i) for the i-th bit. Assume each v(i) is 1 with probability 0.5 + e(i), where e(i) is an error function of magnitude 0.5. e(i) can be a function of previous v(i), a periodic signal, or some clever signal injected directly from the NSA. However, with magnitude 0.5, all you have to do is XOR the v(i) values together until you achieve the desired level of true randomness.

For bits v(1) and v(2), v(1) XOR v(2) has probability of being 1 = (0.5 + e(1))(0.5-e(2)) + (0.5 - e(1))(0.5 + e(2)) = 0.5 -2*e(1)*e(2). If e is bounded in magnitude by some number, like 0.4, you can easily compute how many bits you must XOR together to get the desired randomness. For a very poor quality RNG output error of 0.4, I need to XOR the output stream 7 times, generating 1 output bit for each 128 from the hardware RNG. The resulting error in randomness would be less than 1 part in 10^12.

No, a 120MHz radio signal cannot bias my generator unless the signal is so strong that the noise signal goes outside the ADC input range. Simply adding non-random bias to a random signal does not reduce the randomness in the signal. Simply XORing all the ADC output bits together for 80 cycles, where the low 4 bits correlate sample-to-sample less than 1%, and you get an error of less than 1 part in 10^50 of non-randomness. Add any signal you like to the noise, and it wont make any difference, so long as you don't clip.

You're thinking of a primitive hardware RNG that amplifies the signal to a single bit. Such generators are far slower (1 bit per sample, rather than 8, and you have to wait for the entire signal to become uncorrelated) and susceptible as you suggest to bias. Why would anyone waste most of the randomness in a signal by amplifying it to the rails?

Here's the math I did to prove to myself that the non-randomness error is tolerable.

I saw 1% correlation between successive samples of the 4th lowest bit of the ADC (the upper bits, were worse, the lower are even more random). So, model the low 4 bits probability of being 1 as 0.5 + e, where e is an error of 0.01. XORing two together, the probability of being 1 is (.5 + e)(.5 - e) + (.5 - e)(.5 + e) = 0.5 - 2e^2, so the new error is 2e^2, or 0.0002. Merge again, and it's 80*10^-9. Once more and it's 12.8*10-18. Then 327*10-30, and finally 215*10-57. That's what I'd get merging 32 of the low 4 bits , but I actually merged 40, and while the high bits are highly correlated, they still do add randomness.

I built this in the mid 90's, and at the time the old DOS-based Diehard tests were the best I could find. Certainly the stream should be whitened before used in cryptography, but the data directly from the board passed the Diehard tests without whitening. However, the board XORed 80 bits from the A/D to produce a single output bit (or more - this was software controllable). Since the 8-bit randomness accumulator was rotated 1 bit every sample, each bit was XORed 10 times with each of the A/D outputs. I did some simple correlation analysis on the raw A/D output, and found that the 4th lowest bit had significant, but small correlation - I forget now, but something like less than 1/128th bias to the previous bit. The lowest 3 bits were even more random, and I did not detect correlation other than what I could explain through non-linearity of the ADC. I also looked at the analog signal, and it was a best described as biased random walk, where the signal prefers to return to 0 more the further from 0 it got. It had strong random components at the limit of my scope's frequency: 100MHz.

While it was based on zener avalanche noise, real zeners are designed to minimize this noise. I used the reverse Vbe breakdown of a cheap NPN transistor instead, which was a far superior noise source. I had a couple clever tricks In my design, but frankly saving a transistor or two isn't going to make the world a better place. There's nothing wrong with the designs I find with Google, like this one.

Yes. Hardware high-speed super-random number generators are trivial. I did it with amplified zener noise through an 8-bit 40MHz A/D XORed onto an 8-bit ring-shift register, generating 0.5MB/second of random noise that the Diehard tests could not differentiate from truly random numbers. XOR that with an ARC4 stream, just in case there's some slight non-randomness, and you're good to go. This is not rocket science.

No, RNGs are easy. Super easy. Just take a trustworthy source of noise, such as zener diode noise, and accumulate it with XOR operations. I built a 1/2 megabyte/second RNG that exposed a flaw in the Diehard RNG test suite. All it took was a 40 MHz 8-bit A/D conversion of amplified zener noise XORed into an 8-bit circular shift register . The Diehard tests took 10 megabytes and said if it found a problem. My data passed several times, so I ran it thousands of times, and found one test sometimes failed on my RNG data. Turns out the Diehard tests had a bug in that code. Sometimes the problem turns out to be in the test, not the hardware.

RC4 (aka ARC4) is not "broken". Unknown Lamer is confused. WEP is broken because it had a flawed implementation of ARC4. Just hash the key, drop the first 1K bytes of output, and no known program can even differentiate ARC4 output from truly random numbers with less than a megabyte of data. If the NSA can crack ARC4, then they've beaten a huge collective effort of the world's cryptography community.

But... md5? Surely that's just for non-secure CRC, right? Android wouldn't do anything as dumb a signing document MD5 hashes, would they?

One more example - not from Silicon Valley! Why are the big cell service providers so dumb? Coverage sucks everywhere, yet it takes tiny Republic Wireless in North Carolina to figure out that cell phones should switch to VoIP when WiFi is available? Why is it so hard for big companies to do the obvious right thing?

Why can't cell phone companies make good cell phones? Why did Apple and then Google have to show them how? Why didn't Sony build iPods? How did they let Apple do it first, years after Sony should have dominated the market? Why can't big car companies make a good electric car? Why did Tesla have to show them how? Why is GM even offering this stupid model, and why did BMW offer an even dumber one? Is it to prove to themselves that electric cars are a bad idea? Why are all of these examples Silicon Valley innovations?

Honestly, I just can't figure out whats wrong with GM, BMW, Motorola (before being bought - the Moto-X rocks), Sony, and so many other large iconic corporations. It's one thing to lack a marketing genius like Steve Jobs. It's another to be so incredibly stupid that even the average slashdot geek can see your product will be a dismal failure. There is simply no way that this car, or BMW's freak-show of an electric car will succeed. Why are they wasting their time and money? Why are they so stupid?

Honestly, I don't know. I know a bit about business, but I can't make sense of corporations acting so illogically.

Thanks for the link. The batteries, which are a pretty major component by cost, are made in Japan by Panasonic. I was really hoping Tesla would find a way to work with an American battery vendor, but that didn't work out so well for Fisker, so I can't say I blame them. The steering column and maybe a handful of other stuff is made by Mercedes, who owns a small percentage of Tesla. This probably accounts for why it has a lower percentage made in the US/Canada.

I agree they need to put philosophy aside, and more funding would do wonders. However, it's the philosophy of most Linux distros that make Linux a difficult market to sell pre-compiled binary games, or any other application. Pre-compiled binaries work. Just look at Java as an example. I install the Oracle JRE, and host Minecraft on Linux 24/7 with no issues. If I try to use OpenJDK, forget it. Updates break it, whether it's a Minecraft update or an OpenJDK update.

I'm currently working on a Linux port of a text-to-speech back-end for use with applications like Orca, which is a screen reader for the blind in Linux. The first version was super-easy. It's just a self-extracting shell script with the jar files pre-built. All the TTS engine interfaces are written in C, but they don't rely on any shared libraries. I ship both the compiled binaries and jar files in the self-extracting shell file. This think works on every version of every distro I've tried it on so far. This is especially important for the blind, who cant easily fix their system after an update breaks something in the TTS stack. As a result, most blind guys who use Linux simply avoid updating.

So, I've got something here blind Linux users want and need, and all I want to do is share it for free, including source code. Given the open sharing and caring community we have in Linux land, getting it to blind users should be very easy, right? Nope. There is simply no distribution channel for pre-compiled binaries in Linux land that is anything like Android's Play Store. Instead, most blind guys use some flavor of Debian derived distro, where the only TTS engine that reliably works after an update is espeak. To reach these guys, I'll have to go through a ridiculous process to build a .deb and .rpm package, find a sponsor, get into Unstable releases, and wait a couple years until most blind guys update their distro.

It's not a whole lot better for game developers, who also have to typically build stand-alone binaries and post them to their web site, with no standard channel for Linux distribution.