Post a comment?
Are you mad? I wouldn't dare post a comment here in case the NSA had a backdoor...
Linux supremo Linus Torvalds has jokingly admitted US spooks approached him to put a backdoor in his open-source operating system. During a question-and-answer session at the LinuxCon gathering in New Orleans this week, Torvalds and his fellow kernel programmers were asked by moderator Ric Wheeler whether America's g- …
If Spooky Five Eyed Monsters have a backdoor into here on El Reg, they be desperately slow to realise what they should be doing to control the future with IT and media .... and that would indicate that they do not have the intelligence in-house to make good and better beta use of that which be shared freely in comments made here oft and at times on these leading tales with following threads.
More Herman Munster monster types than big scary master race types, methinks. ...... http://memecrunch.com/image/50915d72afa96f2b9a00006f.jpg
Is it mad or smart to post here if one would expect/hope/suspect/invite spooks to phish here and poach/net/capture some prime game with the simplest of ignorant megabuck lures/jackpot lottery prizes, which have no one asking awkward questions about instant flash wealth for services to be rendered .... or not to be rendered but to be held in temporary abeyance until such times as intelligent things will not collapse dumb systems and algorithms in a global flash crash?
So, he was joking then? Which would seem to make sense, if I were going to put a backdoor into an open source product, I'd compromise a distribution rather than the source.
How many people compile from source and then compare the binaries that they've compiled with the ones supplied by the distribution? I'm guessing in the region on none, there are simply too many variables which would end up with fractionally different binaries.
Many a true word spoken in jest.
He answered EXACTLY as I'd have answered in his position if I HAD been whispered to. Gave us as honest an indication as he could without breaking any secret court secret orders. Doesn't mean he yielded of course, just that it is (or would be) up to us to find them. (Try doing that with Windows/iOS/OSX/etc..)
This post has been deleted by its author
"If I were the NSA, I would just have the "right" people placed in a company like RHEL, where the compiler could be doctored, and the doctored binary and clean source code could then be distributed.
Any recompile would, of course, inject Trojan horse code - regardless of how closely the source was inspected: Neither the compiler source, nor the project source code would contain any evidence"
But they'd also have to dodge an independent compile using another toolchain's compiler: one outside NSA control.
In the end, a compiler could probably be vetted a few times, down to the machine code, and its binary code hashed a few ways (just in case the spooks have a way to create a preimage trojan for one of them--it would be statistically infeasible to tamper with the code AND match the hashes on two different hash familities). Once that could be verified, then you can compile against that one and establish a chain of trust that shows the code wasn't tampered without it showing up in the source. I don't think we're at the stage were we need such anal retention YET...but it's still an option.
It does mean "no" but more of a question, 'no?' . I had an Indian colleague who although the lead architect insisted on requesting agreement at almost every sentence 'no?'. Tried to stop her doing it as it rather undermined her own arguments showing what appeared to be a lack of confidence 'no?'. It all comes down to the politeness of Indian society.
"He nodded his head", "He shook his head" is YES and NO. In the plus 50 countries have been to, this is the only thing that never fails. It would surprise me if Bushmen and what ever you could find in South America or the Pacific Islands did not understand the difference. Either you are a troll, stupid or just uneducated. Perhaps not totally uneducated as you managed to write Bulgarians if not Finns.
As for this interview, it was honest, no company advertising, imagine a third sofa with Ballmer and Elop taking part.
>There's really only about three distributions, which are used as a forking point for most of the others. Red Hat, Debian and Suse, I'd go with that.
Well make it RedHat, Suse and xBuntu and you have 90+ percent of the Linux boxes compromised. And those are the packages most likely used "as is" rather then checked and recompiled because they target the "I want to USE the maschine not fiddle with it" part of Linux.
Add in that all three are done by companies and there are legal means to get a company to "play nice and shut up" and the chances increase that there is "something nice" in there. With the Kernel Devs none the wiser.
If I am going to the bother of compiling the binaries, why would I not simply use them, as in Gentoo? If I did either, could I be confident that nothing was missed in my code examination? What about the compiler, the linker, and so on? If I compared results to the distributor's, how would I decide whether a difference indicated a fault in the distributed binary, the source, or simply noise introduced by differences in the two Make environments?
The question ultimately resolves to one of trust: how far shall I trust the kernel and other developers, knowing that they are fallible and conceivably corruptible humans not all that different from me? Should I reckon them more or less trustworthy than those of Microsoft, Apple, or Google? Why?
For that matter, why should I consider as The Guardian, Spiegel, The New York Times, the Washington Post, or even The Register more trustworthy than the US and UK governments and their accomplices in Canada, Australia and New Zealand? I have little personal knowledge of any of them, and all of them, whether government or press, may have motives for shading or spinning the truth. The documents I have seen are worrisome for sure, but are open to a range of interpretations not all of which support a claim that the governments are much interested in imposing a totalitarian regime. But are these documents to be considered trustworthy as given, inasmuch as they have an unverified history that depends on the questionable trustworthiness of a single individual?
NSA dont have to ask Linus Torvalds himself anymore. They can just submit a patch, because there are so many patches into Linux all the time, it is hard to check all new code. Apparently, this attempt was blocked. But how many more are not blocked? In Windows, NSA can not submit a patch, so NSA must ask Microsoft to deliberately insert a patch. But for Linux, there is a very high code turnover, so it is not hard to submit some new code:
http://www.theregister.co.uk/2003/11/07/linux_kernel_backdoor_blocked/
"If you were the NSA, how would you backdoor someone's software? You'd put in the changes subtly. Very subtly."
"Whoever did this knew what they were doing," says Larry McVoy, founder of San Francisco-based BitMover, which hosts the Linux kernel development site that was compromised. "They had to find some flags that could be passed to the system without causing an error, and yet are not normally passed together... There isn't any way that somebody could casually come in, not know about Unix, not know the Linux kernel code, and make this change. Not a chance."
You don't have to manually check all the patches, regression tests & unit tests can do that stuff for you more reliably (and in the case of wait4 a priv-escalation test should be pretty easy to engineer). Sufficiently motivated users can implement their own tests too.
Having said that writing your own tests against closed-source software is often a lot harder because typically it is insufficiently documented for you to infer what the valid states/inputs and outputs of the system are.
I was worried by the fact that vendors place backdoors in software as a matter of routine (eg: default admin accounts+passwords) *before* the Ed Snowden decided to strip away any of the comfy illusions I had about the surveillance regimes we operate under...
This post has been deleted by its author
"...Strange then that [all code] does get checked..."
Sure it gets checked. But the point is that it is not checked thoroughly. It is only skimmed and lot of subtleties are not catched. There are question marks in the code that gets accepted, because the code turn over is so high, no one can thoroghly check all code. Lot of code that no one really understands gets accepted. Maybe they contain subtle back doors?
http://www.forbes.com/2005/06/16/linux-bsd-unix-cz_dl_0616theo.html
"....Lok Technologies , a San Jose, Calif.-based maker of networking gear, started out using Linux in its equipment but switched to OpenBSD four years ago after company founder Simon Lok, who holds a doctorate in computer science, took a close look at the Linux source code.
“You know what I found? Right in the kernel, in the heart of the operating system, I found a developer’s comment that said, ‘Does this belong here?’ “Lok says. “What kind of confidence does that inspire? Right then I knew it was time to switch....”
“You know what I found? Right in the kernel, in the heart of the operating system, I found a developer’s comment that said, ‘Does this belong here?’ “Lok says. “What kind of confidence does that inspire? Right then I knew it was time to switch....”
Specifically to switch to giving stupid interviews to Forbes to increase the visibility of his obscure company.
The kernel has many comments about whether code could be improved and this is probably one of them. Logically, Lok is saying that coders should write comments as if they were writing marketing copy.
Aside from anything else, if Lok was competent to be writing code he should have been able to answer the question himself.
Frankly, I'd be more worried if the code *didn't* contain comments as such. There's no such thing as perfect code. Sometimes what you're writing seems pretty damn good, but sometimes there's a question mark about the better approach to take to solving a problem or its organisation. "Does this belong here" is a perfectly good comment to place by code. A more experienced coder may see the comment and think "Hmmm, no, I'll move it elsewhere and explain in the commit message my reasoning". Without the comment, probably no-one is going to review it and it'll be left there forever.
Given that "perfect" code is a highly subjective affair and given that time constraints exist, the search for perfection is fairly futile and not productive. "Better" is better than "Not better", so if a clear improvement is there to be made, subject to one or two doubts, it should be implemented, with a comment explaining the doubts so it can be picked up for further improvement down the line.
Linus is wrong about Chipzilla. It contributes nothing further to the randomisation if it has a predictable sequence. It's like wrapping an already random stream in see-through paper, that's all. It can't add further entropy if it is no longer usefully randomising. Dunno why he doesn't get that point. Using it just wastes processor cycles.
The issue was not about wasting cycles - it's about whether it can *reduce* entropy. Linus thought this was absurd because even if the data was not random, it wouldn't reduce entropy. That's true so long as the data is produced without any knowledge of the other random data it will be combined with - but the sufficiently paranoid observe that we can't check that's the case.
There is a very easy way to check: just plot or interpolate to expression the output of this supposed random generator.
I used to write random number generators and test them, way-back-when, and the first thing I would do was plot it - human brain is very good at seeing patterns. I was amazed how difficult it really is to create a random number (it's impossible, basically - but you can get closer by degrees and there are now good mathematical models for it - if they aren't NSA'd too that is ;)
"human brain is very good at seeing patterns."
The human brain is indeed a pattern matching engine. That is how it works.
Unfortunately it even sees patterns when they really don't exist. That is how we end up with superstition.
Pseudo-random numbers, as used by GPS, look entirely random and would not be caught by your plot test.
"Linus thought this was absurd because even if the data was not random, it wouldn't reduce entropy. That's true so long as the data is produced without any knowledge of the other random data it will be combined with - but the sufficiently paranoid observe that we can't check that's the case."
Given most of the other inputs to /dev/random (the true RNG stream) are environmental, they'd have to subvert the environment to a great degree to be able to know the state of even one of the input streams to the point of being able to counter it.
And there are other true random sources of bits besides radioactive decay. You can use a reverse-biased transistor, shot noise, avalanche noise (this is what the Entropy Key uses), and so on. Then there are projects like HAVEGE that emply the hectic, multitasking nature of modern CPUs to draw entropy.
It contributes nothing further to the randomisation if it has a predictable sequence
Every pseudorandom number generator in existence has a predictable sequence (hint: that's why they have pseudo- in the name). However, because exploitation of said sequence is dependent upon knowledge of the initial seed value, simply seeding a PRNG with data from a local nondeterministic source practically negates any advantage. Even the compromised Intel PRNG would not be easily exploited unless the application used a deterministically-determined seed value and output a large sequence of unmodified values from the PRNG.
So provided the PRNG is seeded from a non-deterministic local source which is mathematically independent from the other inputs, using its values would contribute to the randomization.
Every pseudorandom number generator in existence has a predictable sequence
True but "predictable" covers a massive range from "bleeding obvious" to "almost totally incomprehensible to anything less than a Culture ship Mind" and all points between.
As far as I know nuclear decay is the only easy genuine random source available but a bit tricky to include in a little chip at a suitably low cost.
"As far as I know nuclear decay is the only easy genuine random source available but a bit tricky to include in a little chip at a suitably low cost."
What about Americium-241 based smoke detectors? We already have widespread, low-cost "nuclear" gear in our homes in this form - why couldn't we use this same technology as an RNG in our computers as well?
As far as I know nuclear decay is the only easy genuine random source available
Completely wrong. Others are thermal noise (in analogue electronics), and turbulence (in airflow). Your audio input jack and hardware can be a very effective random source. For best effect, connect a thermal noise source instead of a microphone: it's trivial to build one from a few discrete electronic components, and power it off a USB port.
But even a microphone listening to background noise will do. Even if the spooks have a hi-fi uncompressed bug in your office, it won't be recording exactly the same audio stream. The least significant bit per sample will be random, which is quite a reasonable source of entropy to blend into an entropy pool. (If you stick your random noise microphone to your PC's fan grille, it'll be more than one random bit per sample).
Finally, for an entropy pool you don't need random in the sense of passing all statistical tests for a random source. It just has to be non-reproducible and not remembered by anything. So the "signal" bits of the background noise in your office also qualify to a greater or lesser extent.
Every pseudorandom number generator in existence has a predictable sequence (hint: that's why they have pseudo- in the name).
No, this is yet another example of equating two distinct concepts - determinism and randomness. It's possible to be completely non-deterministic but still not random. It's the kind of subtlety which is why encryption and related areas are best left to real experts as opposed the "I read a web page once" types. I certainly no expert either but I have studied deeply enough to realise it is a lot more complex than people generally assume.
A simple everyday example of the difference between the two would be what was found shortly after the introduction of the Euro coins: because the two faces are designed independently (one centrally and one on a national basis) certain Euro coins are not perfectly balanced and so have a slight preference for one side or the other when tossed. The result of an individual toss is still essentially unpredictable but in the long-term a marked bias shows up.
Tossing such coins thus yields a pseudorandom sequence, even though the individual values remain entirely unpredictable.
A biased sequence can still be random in some senses. The comment to which you reply is correct: all pseudo-random sequences are deterministic, because that's what the term means: a pseudo-random sequence is an algorithmically produced sequence which passes whatever your favourite statistical tests for randonmess are.
You're correct that non-determinism and randomness are different: in mathematical modelling of systems, a "non-deterministic" choice is one that is not made by the system of interest, but by its environment: e.g. a vending machine has a non-deterministic choice between receiving a "tea" button press and a "coffee" button press, as which one happens depends on the environment (the user). In theory of computation, a non-deterministic algorithm really means one where all possible choices are explored in parallel; or alternatively, you can take a lucky guess as to which choices you should make.
"Random" refers either to statistical properties of a sequence - and such a sequence can be a determined thing, just not determined by any computable function - or to a primitive notion of probability. In the probabilistic case, biased outputs are included: for example, if you generate a sequence of bits every second by seeing whether an atom of uranium has decayed in that second, that sequence is, as far as we know, truly random in every probabilistic sense of "random". The ratio of zeroes to ones, however, depends on how much uranium you have. In the algorithmic case, a biased sequence is not random becase it can be compressed - if the string has ten times as many zeroes as ones, then you can trivially compress it by coding sequences of zeroes, and you'll win - but it can still be a random sequence in the probabilistic sense.
Cryptographers want sequences that are random in both senses.
"A biased sequence can still be random in some senses. The comment to which you reply is correct: all pseudo-random sequences are deterministic, because that's what the term means: a pseudo-random sequence is an algorithmically produced sequence which passes whatever your favourite statistical tests for randonmess are."
In isolation a biased sequence can't be considered to be random. To quote Knuth, "A distribution is generally understood to be uniform unless some other distribution is specifically mentioned" (TAOCP vol 2 section 3.1).
As for the meaning of pesudorandom, that simply implies an approximation of randomness. It says nothing about how the sequence in generated.
Surely, in the case you present, the *sequence*, e.g. HTHHTHTTTH.... is random, but the *probability* of the next toss being H or T is slightly biased. The point about a pseudorandom generator algorithm is that it's entirely and absolutely predictable. If you set up two, side by side with the same starting parameters, they'll produce exactly the same sequence which however looks (more or less) random.
That's not the case with the Euro coins. Even in a high-precision coin-tossing machine in a vacuum (patent pending) the sequence is going to vary based on unpredictable (read: random) variables.
This, by itself, is the case for open source operating systems such as Linux. They *can't* put a back door in, because it would be quickly spotted by everyone who audits the kernel source (and the rest of the source that makes up a Linux operating system -- yes, we call that Linux too, not silly names like GNU).
It also pretty much proves that every major closed source operating system absolutely has government back doors in it. If you use Windows, the government has the key to your computer. If you use Apple, the government has the key to your computer. If you use Linux, the government at least has to crack your encrypted communications first.
Any possible backdoor would be done in such a way as to appear as a bug that grants privilege escalation for plausible deniability. And we all know Linux is notorious for its many, many bugs that the kernel devs should classify as security vulnerabilities, but refuse to do so.
I see you attempted to backdoor this thread and I caught you out.
There are examples of bugs/backdoors/whatever you call them lasting years in open source projects because nobody caught them.
I'm quite the open source fanboy but I wouldn't go so far as to think it's perfect. Mainly my higher confidence in open source programs is that someone else will find the problems, but if everybody's thinking that...
"They *can't* put a back door in, because it would be quickly spotted by everyone who audits the kernel source (and the rest of the source that makes up a Linux operating system -- yes, we call that Linux too, not silly names like GNU)."
So what would happen if someone did spot something out of place in the kernel source?
Wouldn't it be fair to say that if that person starts asking on the kernel mailing list they'll just get ridiculed and optionally insulted for not understanding the module they're commenting on?
Wouldn't it be fair to say that if that person starts asking on the kernel mailing list they'll just get ridiculed and optionally insulted for not understanding the module they're commenting on?"
If someone did spot something they would get a fair audience if they could demonstrate the issue or give a reasonable explanation.
They would get ridiculed if they continued to press a point that could only be explained by six rolls of tin foil.