Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

It works for the MOB and gangs... want a rival killed? start rumors they are working for the cops, fbi, are dirty and skimming from the boss, etc.. Keep it up and word wil spread and get back to his guys who end up "fixing the problem".

Works in the non-cime world as well. Sysadmin acting like a BOFH? start planting small rumors he is stealing or hacking from work. Want to put questions in the minds of people who might switch from windows? put out there a "rumor" that it has Government backdoors in i

It works for the MOB and gangs... want a rival killed? start rumors they are working for the cops, fbi, are dirty and skimming from the boss, etc.. Keep it up and word wil spread and get back to his guys who end up "fixing the problem".

Interestingly, I was reading this morning about the FBI in the 70s spreading false claims that members of radical groups were actually FBI informants in the hope of disrupting said radical groups.

The fact that Theo used his position of power to show the email to everyone does mean that he is at least tacitly endorsing and/or making the claim. Otherwise he could have just ignored it.

After reading TFA, I came to the conclusion that Theo believes it is true. He used the excuse that exposing the dastardly FBI shenanigans justified the posting of a private email. If you don't think the FBI did it, you can't use it as the excuse for posting the email.

It was his e-mail, because it was sent to him. He’s the one who gets to decide whether it’s private or not.

There is someone else’s private e-mail, and then there is my e-mail. Whether or not I want my e-mail to be private is my decision. If you send me an e-mail, unless you specifically request otherwise, assume I can do whatever I want with it. Including post it online.

The normal length for classified material is 50 years. That isn't to say it can't last longer or be declassified earlier, but 50 years is the normal NDA length. Why would this be any different? In particular there was the implication that they'd been heavily pushing it because of the backdoor. Ok but they had to know that the NDA was about to expire and thus the jig would be up and it would be, if anything, harmful.

Makes no sense. I am not buying this in the slightest without some proof. Some guy claiming something in an e-mail isn't proof, that is Internet nuttery as normal.

The normal length for classified material is 50 years. That isn't to say it can't last longer or be declassified earlier, but 50 years is the normal NDA length. Why would this be any different?

FTA -

"...sent to him by Gregory Perry, who worked on the OpenBSD crypto framework a decade ago."

I think that 50 years sounds normal for an agency whose job has become protecting secrets. A decade does not sound like something that would benefit them at all. That's what seemed strange to me about the original article.

this reminds me of how the CEO of Green Hills was spreading FUD saying how insure Linux was because anyone could embed backdoors in not only Linux but into gcc. He was trying to say how much better their software was because it was not open source. Some of this stuff just doesn't add up when you look at the bigger picture and what the motivation behind the info often tells the real story. For Green Hills, Linux is a threat to their business model so they wanted to spread FUD to limit its effects. I wonder w

Not my point. This is probably going to come as quite a surprise to you, and you probably don't much care, but there's more at stake here than the backdoor. Jason Wright, FBI plant or no, will never be able to fully clear his name, and for some will always be "the guy who might be a FBI plant". God help the guy if someone finds some sort of bug; no matter how innocuous, it will be cited as "proof". I clearly don't know how "douche" is defined in your world, but in mine throwing someone under the bus with

Back before I used Linux (in college), I made a habit out of making all Linux users paranoid by saying if I were the CIA / FBI / NSA / other TLA, I would worm somebody in as a contributor and do my best to put hidden backdoors into all open source operating systems. I know if I were in any of said agencies and had no respect for privacy, I would.

Whereas you can be sure no one at Microsoft or Apple is coding backdoors for a TLA ?

More like, you KNOW there are backdoors in Windows, Mac OS X, iOS, and all the other products they have. But don't switch to open-source purely because it's open-source and therefore, backdoors can't be hidden in the code. Even very careful audits can still miss cleverly hidden backdoors.

The silly thing about this issue is that no one can confirm or deny it, short of a full on hard core code review. The people who did it cer

There was never any OpenBSD contributor named Scott Lowe. Did anyone actually bother to read the source material or check facts, before claiming as such?

The finger was being pointed at Scott Lowe FOR HIS Virtualization BLOG, which are merely articles that discuss the use of OpenBSD.

The mailing list author, was making a totally reckless claim with no proof shown that He was advocating OpenBSD for the benefit of the FBI
which is downright ludicrous attention whoring attempt on the part of someone reposting that claim without corroboration.

A mailing list posting by one person is not a credible source to be taken at face value. Information needs to be corroborated. Posting some random person's vague accusations as front page news borders on gross negligence.

It looks to me like de Raadt received an email from this Perry saying that he had some kind of NDA with the FBI that was part of a project the FBI hired Perry to do to add a back door to the OBSD ipsec stack, and the tone *seems* to be "ha ha ha, I screwed you" a little bit, shown by his comment about OBSD's DARPA funding. de Raadt isn't confirming or denying, he's simply saying "Look, this asshole is making claims." Claims that should be easily refuted if the OBSD stack is as heavily audited as the group c

The raw and cold truth is that contributors to all the open OSs can't really be vetted. Not in a meaningful way. And the number of people who are deep low level 'hackers' capable of writing the code is relatively small. The numbers able to code audit to a level of examination are even fewer. So yes, the code is open, the code is visible, the code can and could be audited. But here is the thing, being auditable is not the same as being audited. And personally, I would not be shocked if a full audit was run if something might be found.

That being said, this is one step better than closed source, where some of the above is not possible or viable, and in cases where money crosses palms, may in fact be unwanted.

Further to this though, I personally don't expect government to simply roll over and die. I expect them to take steps to try and stay one step ahead of bad things, and the relaxing of technology limits has benefitted people across the world, even if I were to make a case that the cost is that at the point of a pyramid - the goves can hunt down the world culprits and suspects. In some cases - releasing the tech in fact has your enemy using that tech after some time and you get to tap into it.

It seems unlikely that someone could hide one or more backdoors in such a ubiquitous piece of code without _anyone_ else ever spotting it.

It also seems unlikely because Perry didn't share actual technical details of the backdoor(s) so their existence can be proven. Surely when making such a radical claim its just human nature to also justify it with all the evidence you have.

Case in point, I literally just spotted a bug in python's socket recv call (as of yet unreported) which leaks memory given the right error conditions. The code hasn't been modified for seven months and the file has existed for many, many years. The only reason I spotted it is because I was looking for very specific but unrelated behavior. Regardless, subtle errors and by association, malicious code, can easily exist for very long times, even surviving multiple code reviews.

Funnily, that's exactly what happened to me - I wondered what people were talking about when they said it was a dupe. This is the only website I've ever had to block a submitter on, and kdawson the ONLY author I've ever had to block on any website because every submission I read from them annoyed me or was blatantly complete bollocks.

'This is the only website I've ever had to block a submitter on, and kdawson the ONLY author I've ever had to block on any website because every submission I read from them annoyed me or was blatantly complete bollocks.'

BTW the Indian extremists have been infiltrating Microsoft for years and have places many back doors into Windows so they can shutdown all our systems. Their main target is the thought control experiments based in Montauk NY at the secret underground base their. They are hoping that they can remotely activate it and then while we are under their control gain access to the secret base under the new Denver Airport.

I've been following slashdot for over 10 years and I finally registered an account just a few weeks ago. Why? Because I got so sick of kdawson's inflammatory Fox-news-esque junk articles that I finally decided to register just for the sole purpose of kill-filing him.

No, I don’t think so, because they do sometimes edit the stories. I know they edited one that I posted, they converted it from a logically divided 3-paragraph submission into a single glob of text, just like any other story.

What backdoor? Nobody has found ANYTHING yet. They just have a rumour, duly propogated onwards because of its *potential* security applications, that someone may have once been paid to do such a thing. Doesn't mean it's true, that they succeeded, or that it hasn't been removed since.

It's impossible to prove something *isn't* there, of course, but it would be a cinch to prove it *was*. Nobody has yet stepped forward with anything even approaching a slight vulnerability in their IPSec implementation that

go there and read, look at the winning and runner up entries... If you are a competent coder you can hide things right in front of someone and they will not spot it. It's scary as hell what some of these guys can do.

If you are a competent coder you can hide things right in front of someone and they will not spot it. It's scary as hell what some of these guys can do.

Which is why I think the best solution would be to rewrite the module from scratch and then do the audit on that version of it. Preferably developed by people who have never touched that part prior and written to spec without referencing the original code. After all, this is probably the most paranoid group in all of open source. Although speculation of a potential exploit might not be enough to drive all that.

If you are a competent coder you can hide things right in front of someone and they will not spot it. It's scary as hell what some of these guys can do.

If you're a competent coder you can make what looks like obvious mistakes that any proper editor should be able to distinguish as an error. (The top two runner ups on that page are obvious coding errors that any code review should pick up. The third is something that testing and a good code review should catch.)

Now, all of that said, I had a hojillion code reviews working for A Very Large Multinational Computer Operating System Company that came back with the only comment being: "looks good". I caught at

The allegation is inclusion of a side-channel in the crypto algorithm for leakage of key bits.

If you know about crypto coding, you'll know instantly why that would be easy to hide and hard to find.

IPSEC is a well-documented standard: you can't just stick 'random numbers' which happen to contain parts of the key in the data stream as you could with some home-grown crypto system. The fact that it is a standard which has to interoperate with other implementations of the standard eliminates most of the usual methods of deliberately leaking keys.

Certainly there could be deliberate timing effects, etc, but everyone these days should be using crypto implementations which protect against such things.

padding, back then it was random in OpenBSD, hard to verify, never looked at by software. Now it's speced in a verifiable manner. Either nobody knew or nobody was forth coming with the information that it was a useful side channel back then.

Does IPSEC really allow random padding? If so, the design is even worse than I imagined... I thought people figured out that non-deterministic padding was bad well over 10 years ago.

However, if i's padded pre-encryption it's far less useful for an attacker since either it would have to somehow leak key bits into the encrypted data (which would require code that was obviously monumentally broken) or it would only leak key information to the system on the other end of the IPSEC link.

This means that a code audit would find this so-called back door, yes?

Nope. OpenBSD is audited, but the auditors are human (well, some aren't, but they can only spot categories of bug that are well documented). The code is not formally, mathematically verified (doing so for nontrivial C code is basically impossible), so there's always the possibility of a bug and, as the OpenBSD team says, the only difference between a bug and a vulnerability is the intelligence of the attacker.

Regular code audits increase the probability that a backdoor would be found, but they don't guarantee it. That's why this is such effective FUD: it's basically impossible to prove that it's not true.

Yeah either way, this is a tiny blow to the BSD's just because it's something one could say against them. All these years of pushing BSD out to everyone and now this! Boy, am I gonna hear it today! Or tomorrow if they don't keep up with the news.