Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

More Encryption Is Not the Solution

Soulskill posted about a year ago | from the more-cowbell-still-in-the-running dept.

Encryption 207

CowboyRobot writes "Poul-Henning Kamp argues that the 'recent exposure of the dragnet-style surveillance of Internet traffic has provoked a number of responses that are variations of the general formula: "More encryption is the solution." This is not the case. In fact, more encryption will probably only make the privacy crisis worse than it already is.' His argument takes a few turns, but centers on a scenario that is a bit too easy to imagine: a government coercing software developers into disabling their encryption: 'There are a whole host of things one could buy to weaken encryption. I would contact providers of popular cloud and "whatever-as-service" providers and make them an offer they couldn't refuse: on all HTTPS connections out of the country, the symmetric key cannot be random; it must come from a dictionary of 100 million random-looking keys that I provide. The key from the other side? Slip that in there somewhere, and I can find it (encrypted in a Set-Cookie header?). In the long run, nobody is going to notice that the symmetric keys are not random — you would have to scrutinize the key material in many thousands of connections before you would even start to suspect something was wrong.'"

cancel ×

207 comments

Sorry! There are no comments related to the filter you selected.

Disturbing (0)

Anonymous Coward | about a year ago | (#44440735)

A harrowing thought indeed.

Just one problem... (0)

Anonymous Coward | about a year ago | (#44440747)

That would probably take less than 500ms.

Air America (1)

hduff (570443) | about a year ago | (#44440751)

And who says the government doesn't already run some of these services themselves?

quick key repetition (4, Interesting)

Dizzer (251533) | about a year ago | (#44440763)

After about 15000 connections you would see the first repetition of a key. That scheme would be discovered in NO TIME.

Re:quick key repetition (1)

Anonymous Coward | about a year ago | (#44440887)

Assuming you're looking for it.

Re:quick key repetition (2)

shentino (1139071) | about a year ago | (#44441151)

The lovely thing is that the CA would probably be forced to cooperate with this.

This is the problem with centralized encryption: single points of failure.

This general situation also reveals that the government already has us by the balls and can decrypt anyone they damn well please anyway.

Re:quick key repetition (0)

Anonymous Coward | about a year ago | (#44441621)

Then we pull the cert of the first CA caught cooperating.

Re:quick key repetition (1)

Anonymous Coward | about a year ago | (#44441643)

I've been making a similar arguement recently. I think it's far better to go to a site and see the SSL cert warning and be aware that SSL is in use and that the feds *probably* didn't hijack it, or if they did at least they would have to do it one site at a time rather than to simply be automagically logged into a site where the CA was approached/threatened by the feds so they can watch you with zero restrictions.

Re:quick key repetition (1, Insightful)

Anonymous Coward | about a year ago | (#44440975)

After about 15000 connections you would see the first repetition of a key. That scheme would be discovered in NO TIME.

Admit it: You're not poring over and analyzing every key that passes through HTTPS. No, seriously, you're not. And you haven't been doing so, EVER, for your entire internet life. Yes, yes, I know, NOW you're going to concoct some harebrained scheme on your firewall to look for it, post it on GitHub, and brag about how l337 you are to all your fellow tinfoil haberdashery fashion designers. But only now that someone's put that idea in your head. You absolutely, ultimately never would've figured that out on your own.

Now, let's say they come up with a completely different scheme. Or, let's say they don't. You never know. Go foil it.

What? No, that's all the information I'm giving you: "A scheme, or maybe not". That's all the information you'd get in that situation. So get to work, hotshot.

Re:quick key repetition (4, Interesting)

Anonymous Coward | about a year ago | (#44441017)

There are better ways to hide the fact that the encryption was gimped:

1: Escrow parts of the private key similar to how Lotus Notes did it when ITAR was in effect, limiting RSA to 64 bits. Impossible to detect.

2: Save the D-H session keys and set them aside.

3: Force Web browser makers to add another CA (who would notice.)

4: Hose the private key generation algorithm, similar to the glitch in Ubuntu.

5: For services that supposedly save the key only on the client side (Wuala), force them to make an update that sends the password over, then another update covering tracks. This could be done for just one account, groups, or all users.

Re:quick key repetition (0)

Anonymous Coward | about a year ago | (#44441275)

>3: Force Web browser makers to add another CA (who would notice.)
you mean you DONT think there would a HUGE uproar on /. when a firefox dev leaked that this had happened?

Re:quick key repetition (-1)

Anonymous Coward | about a year ago | (#44441939)

Yeah, but they would all shut up after a few days and continue taking it in the Ass like they always did.

Re:quick key repetition (1)

Anonymous Coward | about a year ago | (#44441365)

Better solution to 2 for those who want to hurt encryption: always use the same secret on the server side but change everything else. It will look like you are doing it properly but anyone who captures the traffic and knows one secret can figure out the rest.

Passwords don't work either (0)

Anonymous Coward | about a year ago | (#44440769)

People don't want to have a dozen different passwords to remember, too much work and bother.

Re:Passwords don't work either (0)

Anonymous Coward | about a year ago | (#44440905)

People don't want any security whatsoever, they just want things to work as-is. We're lucky we can even get them to type a weak password. They also don't care about security either, they don't mind the government snooping on them as long as their neighbour doesn't learn that they walk around in the house naked... People have their priorities wrong and those in power know it.

Re:Passwords don't work either (5, Interesting)

interval1066 (668936) | about a year ago | (#44441839)

All too true, people don't want to bother with any effort for a return they really can't see. Its hard to appreciate encryption when the effects of opentext on their private lives is difficult to impossible to gauge. Until they get hit. After a small dns server I ran got hit, I didn't really pay much attention to it either. 10 years on I still cover my tracks whenever possible, encrypt my drives (linux and truecrypt make this pretty easy), prefer encrypted smtp providers, and ask people I correspond with for their public encryption key. If they ask me what that is I explain it to them. If they say they don't care then I move on, but if they express interest I help them set up. If they say "no one uses that" I show them that I do, many of my friends do, and to look at the news lately. Its in everyone's interest to manage their privacy. If you are into managing your life like a business then its just another procedure to add to your list. If not, well, I wouldn't want to be you.

Call it the Fermat's Last Theorem Effect (2, Interesting)

Anonymous Coward | about a year ago | (#44440771)

When the government notices lots of encrypted messages that can't be easily cracked by their codebreaking machines, they start to get interested. Real interested. Just like when mathematicians discovered that nobody could prove a simple theorem in high school algebra, every math Ph.D spent some time looking into that until the problem was solved.

Re:Call it the Fermat's Last Theorem Effect (5, Insightful)

TWX (665546) | about a year ago | (#44440913)

Like bank transfers and just about all financial-services communications?

There are so many people that move around in this world that I expect good old-fashioned sneakernet with one-time pads will just become the norm, especially when time is not necessarily of the essence. When more data is needed then micro-SD will be employed, and encrypted connections will be left for when absolutely necessary.

When I was a kid, if my friends and I wanted to meet up, we had to generally all agree where we were going to meet in-advance, generally at school or when we were previously together, or a few of us had to decide and then had to manually pass the word on to others, who in-turn passed the word on to others until everyone was notified. We could coordinate and plan without "the authorities" in the form of our parents really knowing what was going on if we chose to keep them uninformed.

If the evil "they" still want to do us harm they can do it entirely offline. They proved that with how long it took to identify Osama Bin Laden's location, he avoided all outgoing traffic other than couriers and it took years to find him.

The brothers that bombed the Boston Marathon managed to avoid being caught in advance due to a typographical error. A Buttle/Tuttle type of snafu literally lead to the older brother's slipping through the cracks. Even after all of everything that happened, the younger brother was caught because a homeowner noticed some blood on his boat. Helicopters, infrared, and door-to-door searches failed to find him.

It hasn't been demonstrated satisfactorily to me that heavy encryption means that there's anything relevant to the authorities being transmitted therein.

Re:Call it the Fermat's Last Theorem Effect (0)

Anonymous Coward | about a year ago | (#44441117)

When the government notices lots of encrypted messages that can't be easily cracked by their codebreaking machines, they start to get interested.

So just imagine how they'd react if people (or better yet, software) started sporadically sending messages that comprised blocks of data from /dev/[u]random.

Although from some of the spam I get, this may already be happening.

No story? (5, Insightful)

Anonymous Coward | about a year ago | (#44440773)

No link to any story at all? Since when does Slashdot provide a private blogging platform on the front page?

Re:No story? (1)

unrtst (777550) | about a year ago | (#44441145)

Agreed. And it's not even much of a blurb.

Re:No story? (2, Informative)

Anonymous Coward | about a year ago | (#44441295)

Had to dig a little, but found it in the ACM Queue. NB: the article is about a month old.

http://queue.acm.org/detail.cfm?id=2508864

Re:No story? (0)

Anonymous Coward | about a year ago | (#44441319)

Oh it's there, it's just encrypted. ;)

It's Poul-Henning Kamp... (0)

Anonymous Coward | about a year ago | (#44441843)

...so no link is a good thing.

In this scenario, the endpoint is compromised. (5, Insightful)

Arancaytar (966377) | about a year ago | (#44440779)

In that case, indeed, no amount of encryption will save you.

Re:In this scenario, the endpoint is compromised. (2)

Arancaytar (966377) | about a year ago | (#44440797)

(In particular, if you can put pressure on the provider, why bother forcing them to use weak encryption and then wiretapping? Forcing them to give you direct access to servers and connection data would be simpler.)

Re:In this scenario, the endpoint is compromised. (2, Interesting)

Anonymous Coward | about a year ago | (#44441015)

This is actually what the NSA is doing, they require Google/Microsoft/Yahoo/etc as well as ISPs / telcos provide them a room where traffic goes after it's been decrypted. They get all the data in plaintext, so they don't have to worry about it. Use google drive, gmail, skydrive, hotmail, etc? All your data has been turned over already.

Re:In this scenario, the endpoint is compromised. (2, Insightful)

Anonymous Coward | about a year ago | (#44440939)

It has to be emphasised that this therefore DOES NOT lead to the conclusion "More Encryption Is Not the Solution". The (as of yet unlinked) article is wrong on a fundamental level if this is what it tries to argue.

Re:In this scenario, the endpoint is compromised. (0)

Anonymous Coward | about a year ago | (#44441667)

(Different AC here) - someone needs to mod the parent AC up. TFS is deeply, dangerously wrong, and it would be unfortunate if people without much understanding of the topic in question were to believe it.

I almost wonder if its writer is a NSA plant. "Don't use encryption, it won't do you any good!"

Bah.

Re:In this scenario, the endpoint is compromised. (1)

Anonymous Coward | about a year ago | (#44440997)

In that case, indeed, no amount of encryption will save you.

This. Encryption is supposed to protect the data in transit. If the endpoint is compromised, there is no need to weaken the encryption to defeat it: simply access the information after decryption (like the NSA does via Google, Microsoft etc).

How to really use encryption: both end points (aka, where the encryption and decryption happen) are trusted. Ex: send a file you encrypt to some server (say mega, your gmail, whatever) that does not know the key. Since you perform the encryption including software and algorithm selection and key generation, its safe. Then someone you trust (like yourself at some later point) can decrypt it with the key that you didn't give to anyone else. Similar rules apply to directly streaming data to a trusted end point.

If you trust Google (oops, bad idea) and the certificate authorities (maybe bad idea), you can connect to their servers over TLS. Then, before sending any data, you might want to sanity check their certificate and encryption to see if its reasonable to resist man in the middle attacks.

When it comes to the other aspect of privacy: hiding that it is you sending the data (as apposed to hiding what the data is), services like TOR are whats needed. Given that such services use lots of encryption, once again more encryption is part of the answer.

Personally I'd like to see if we could get some partial encryption of destination addresses in at the IP level. If I was in the UK, I'd much rather have them know I'm sending packets through the US than that they are going to a specific IP address there. That would require decryption and modification of a portion of the IP address in packets by the major backbone routers though, which seems like way too much to ask performance wise, not to mention the key distribution and trust problems (and clients would need to know some of the routing tables, and it would prevent multipath. So many issues!). If implemented and if used with end to end encryption like TLS, it would really destroy and hope of their censorship plans. (Yes, this amounts to turning the internet backbone into simplified and much computationally lighter version of TOR)

Re:In this scenario, the endpoint is compromised. (2)

phantomfive (622387) | about a year ago | (#44441191)

Yeah, no one is going to do something tricky about non-random keys (and I do think someone would eventually notice).

All the government does is say, "give us your data." It's much easier, and effective.

Re:In this scenario, the endpoint is compromised. (0)

Anonymous Coward | about a year ago | (#44441627)

If you need the endpoint to have the plaintext: true.
If the endpoint is something like Google Docs, upload e.g. AES-encrypted docs.
Make sure decryption keys are not available to Google, only to computers who need access to the docs (they then must access the docs locally).

Tadaa, some amount of crypto and a reduction of relying on the cloud saved you.

Serve yourself. (2)

intermodal (534361) | about a year ago | (#44440789)

You don't honestly think I liked all that hand-editing and drudging through man files and so on that I had to do to run Linux when I switched twelve years ago, do you? I switched because I knew that the major vendors couldn't be trusted, and that I needed to learn systems that weren't shielded from users auditing them and securing them outside the scope of what was marketable.

Today, I no longer need to rely on major software and service venders for most things. That puts me ahead of the game. Of course, it's only as good as the services I provide for myself, and the security of the ones I use outside my own.

Re:Serve yourself. (2)

Shoten (260439) | about a year ago | (#44440965)

You don't honestly think I liked all that hand-editing and drudging through man files and so on that I had to do to run Linux when I switched twelve years ago, do you? I switched because I knew that the major vendors couldn't be trusted, and that I needed to learn systems that weren't shielded from users auditing them and securing them outside the scope of what was marketable.

Today, I no longer need to rely on major software and service venders for most things. That puts me ahead of the game. Of course, it's only as good as the services I provide for myself, and the security of the ones I use outside my own.

And yet, you're posting on Slashdot. Buying things from Amazon, probably, and banking online as well too. Did you build your cell phone from scratch, and validate all the systems of your cellular provider as well? If you run Ubuntu..or Debian...or Redhat, how will you be sure that the binaries you're getting from apt-get or RPM are the ones that match the source code you can read with your own eyes? (Keep in mind that last month there was a Slashdot article that pointed out the difficulty of getting the exact same binaries produced from the same source code, based on variances on the machines that do the compiling and the optimization flags...so forget about compiling your own binaries and just comparing the hash/filesize tuple.) For that matter, if you're using Gentoo will you read ALL of the source code all over again every time there's an update? What you say sounds great in theory, but in practice I don't believe you're as self-sufficient as you think you are.

Oh, and I remember doing all of that editing and reading of man files too...but I never would have spotted code that was meant to weaken crypto. Editing a config file or reading a man file does not equal a proper code audit.

What's really scary to me about the proposed scenario is this: not only does it plausibly describe a situation where the common man's privacy and security are jeopardized, in that scenario the truly bad guys...the ones who WOULD really be more self-sufficient...would run their own systems to some degree and be outside the scope of much of the tainted encryption. This is much as it was back when our government forbade export of strong crypto; the bad guys got it anyways, and the good guys were kept from using it in many situations.

Re:Serve yourself. (2, Insightful)

Anonymous Coward | about a year ago | (#44441073)

Your mistake is to think in absolutes. It is not because you have multiple non anonymous parts of your life that you should give up on protecting whatever you can of your privacy.

Yes, certainly you are not 100% safe, but an open source OS will be messed with by a large number of people and anyone who finds an irregularity will raise the flag. You cannot have a certainty of security, but you certainly have a lot more chance of detecting misdeeds than with closed source.

Re:Serve yourself. (2)

Shoten (260439) | about a year ago | (#44441315)

Your mistake is to think in absolutes. It is not because you have multiple non anonymous parts of your life that you should give up on protecting whatever you can of your privacy.

Yes, certainly you are not 100% safe, but an open source OS will be messed with by a large number of people and anyone who finds an irregularity will raise the flag. You cannot have a certainty of security, but you certainly have a lot more chance of detecting misdeeds than with closed source.

I think you're missing the point of surveillance and how it works. Surveillance is about interaction between multiple people...who speaks to whom, what is said, transactions between organizations, etc. What you run at home is of no real consequence whatsoever; what is monitored is not what stays inside your own computer. You can have totally secure code at your end, but if the key generation at the other end is in some way compromised, so is all crypto that is supposed to protect your communications with that endpoint. And in the scenario described here, that's exactly the situation.

I would hasten to point out that even now, the surveillance has absolutely no dependency whatsoever on closed source code; the providers are the source of the monitoring, not the software itself. There's no need to go through all the trouble of trying to get code inserted into all those different pieces of software; just go to about a dozen different companies, twist their arms, and at least 95% of the online population will interact with one of them. Add that to monitoring of cellular providers, traffic analysis of backbone providers, and you've got a really rich feed of information...all without a single line of code put into anyone's endpoint systems at home.

Encryption isn't (0)

Anonymous Coward | about a year ago | (#44440809)

Encryption if you can't trust the remote end point.

The solution is Global Mesh Networking (2)

ClassicASP (1791116) | about a year ago | (#44440817)

Decentralize the internet and make it run such that there are no "providers". All internet is available where participants are willing to use it and make it available to others, and all traffic flows in the path of least resistance. Users can also flag and blacklist participants who look suspiciously like big brother, so they get skipped in the chain of communication.

Re:The solution is Global Mesh Networking (1)

hibiki_r (649814) | about a year ago | (#44440933)

Except for something like that to work, you need connections, and said connections require laying large amounts of fiber. Who is going to build a line that crosses an ocean, or even one that links two major cities?

And there's also the equipment: Even if I have a fiber line heading to Chicago, and a bunch of local people that connect to my hardware, then I need to have the hardware to route their packages to the line. I doubt I can do that with some old linksys router running tomato. I'd need a whole lot of hardware to manage all that much traffic, and a lot of electricity spent to keep it running. At that point I better be charging, or I won't be able to afford it. At that point, I am a provider of a big fiber line, and all the people that don't have a long, valuable route coming out of their place are not.

Even if in a network, all members are theoretically peers, there'll be some that are far more important than others. All you have to do is peer into a few important ones.
Not to mention that you can't really run a system for flagging nodes not to use without major risk of sabotage. If some people can gant up together and send a post to -1 because they do not like it, imagine the damage you could do by taking off a few key nodes on a grid.

Re:The solution is Global Mesh Networking (0)

Anonymous Coward | about a year ago | (#44441143)

Well I should have mentioned that its WIRELESS mesh, not wired. And yes, its gonna consume more electricity. But I wonder if that increase in each participants electric bill would just be that of the cost of a cable internet connection. Swap one bill for the other. And of course have some sort of max-concurrent-connection handling place such that requests take a different route when one is is maxed-out. Maybe a max threshhold of 25 or 50. Basically the traffic would flow like water through a sponge. It can't all go through one hole; it passes through one of the many available.

Re:The solution is Global Mesh Networking (1)

neonmonk (467567) | about a year ago | (#44441651)

Consume more electricity? It's going to be as slow as molasses.

I think fixing the government & service providers is probably easier & better.

Re:The solution is Global Mesh Networking (0)

Anonymous Coward | about a year ago | (#44441121)

Allow blacklisting and then big brother will take advantage of it to get rid of dissidents. It's a double edged sword you should avoid at all costs.

They can always argue (0)

Anonymous Coward | about a year ago | (#44440827)

I don't see any logic in that argument.

Current situation: Few of the services are properly encrypted. Key service providers are coercer to work with intelligence services (or they see profit in it) and they get the most of the data anyway. Other open and independent products can be considered safe (as far as crypto is properly implemented.. for which there are no guarantees).

More crypto situation: Most of the services are properly encrypted. Key service providers are still working with intelligence services. However, you now have more options for secure services than before. Some of them might be compromised in the similar way but they would still get less personal data. Which is only a good thing.

Links or it didn't happen (5, Informative)

zacs (12785) | about a year ago | (#44440829)

It would be super cool if there was some kind of technology that allowed you to provide a link to the source material for discussion...

http://queue.acm.org/detail.cfm?id=2508864 [acm.org]

Interesting quote about OSS project (1)

Anonymous Coward | about a year ago | (#44441077)

To an intelligence agency, a well-thought-out weakness can easily be worth a cover identity and five years of salary to a top-notch programmer. Anybody who puts in five good years on an open source project can get away with inserting a patch that "on further inspection might not be optimal."

Anybody got an idea as to the source he's quoting? Is he referring to the OpenBSD incident?

Re:Interesting quote about OSS project (3, Informative)

Qzukk (229616) | about a year ago | (#44441641)

I think he's referring to when Debian did exactly this to their openssl library.

It took two years for anyone to notice. [swtch.com]

Complete idiocy (5, Insightful)

Anonymous Coward | about a year ago | (#44440837)

In other news, locks do not work if someone gains a copy of your key. Therefore more locks are not the solution, and locks actually harm security!

Wait...what?

This is complete rubbish. Of course encryption doesn't work if you are trusting a giant cloud corp. not to have a man on the inside corrupting the encryption process.

That is the exact reason why more encryption is the answer! People need to be taking the issue into their own hands, using their own (open source) personal or community-driven encryption schemes that are provably secure. Trusting a giant corp. to generate your keys for you and presuming that is THE ONLY WAY encryption can work is such fantastically F.U.D I don't even know where to begin.

Re:Complete idiocy (1)

shentino (1139071) | about a year ago | (#44441203)

This is more like everyone buying more locks, but the spooks have an insider at the lock factory making them easy to pick for the feds.

Furthermore, the lock and key guilds are chummy with the merchants who refuse to do business without them.

Re:Complete idiocy (1)

MightyMartian (840721) | about a year ago | (#44441219)

Indeed. The problem here isn't encryption, it's trusting commercial CAs that are more than likely providing governments with private keys so these governments can proceed with man-in-the-middle decryption. If you create your own CA and properly manage your private keys, then said governments are out in the cold.

Re:Complete idiocy (1)

0123456 (636235) | about a year ago | (#44441453)

Indeed. The problem here isn't encryption, it's trusting commercial CAs that are more than likely providing governments with private keys so these governments can proceed with man-in-the-middle decryption.

But that's easy to prove.

Just produce one example of a fake key signed by a CA.

CAs who've been shown to produce fake keys generally haven't lasted long.

Re:Complete idiocy (1)

mstefanro (1965558) | about a year ago | (#44441659)

A government would probably not be able to perform a MITM attack to the masses, as someone would eventually figure it out (pubkeys being different all of a sudden). On the other side, if you are talking about a government going through the trouble of targeting a specific individual with a MITM attack, then he either has powerful enemies or is a suspect. Either way, one is usually aware of being in such a situation. It would therefore be foolish to not take additional precautions to protect yourself.

Re:Complete idiocy (1)

BeerCat (685972) | about a year ago | (#44441383)

Trusting a giant corp. to generate your keys for you and presuming that is THE ONLY WAY encryption can work is such fantastically F.U.D I don't even know where to begin.

The reason that PGP (or GPG or whatever) encryption isn't standard, despite being suggested for the best part of the last 20 years, is because it is Too Much Effort (tm)

If an easy to use system is implemented ("check here to encrypt all your emails" type easy), then most people won't bother confirming whether the "encryption" uses proper random keys, or conveniently "provided by the software vendor" (read - 'one of those not really random') keys.

And, with propriety software, how (other than sending many thousand test emails) would most people test whether the keys used were properly generated, or generated using a pre-defined dictionary?

Re:Complete idiocy (0)

Anonymous Coward | about a year ago | (#44441747)

The reason that PGP (or GPG or whatever) encryption isn't standard, despite being suggested for the best part of the last 20 years, is because it is Too Much Effort (tm)

I have set up GPG many times on many systems, and the level of difficulty of doing so approaches triviality. It's little more complex than pushing "return" a few times to accept some defaults, and mailing a file (your public key) to your buddy. Everything else - including integration into common mailers - is handled automatically. It's as close to a no-brainer as you can get.

If that is what constitutes "just too hard!" these days, then I weep for our species. It's far, FAR easier to set up GPG encrypted mail than, say, to bake chocolate chip cookies, or add up some expenses for a monthly budget. People can do those things, yes? Setting up GPG is easier.

If people don't do it, it's because they don't care.

Re:Complete idiocy (0)

Anonymous Coward | about a year ago | (#44441591)

TNO. Without it, it's blind trust cloud providers will protect your interests.

Regarding your analogy (0)

Anonymous Coward | about a year ago | (#44441683)

In other news, locks do not work if someone gains a copy of your key. Therefore more locks are not the solution, and locks actually harm security!

If an unfounded belief in the security provided by locks leads to a false sense of security, then yes, more locks harm security.

At best, locks prevent casual theft. If possessions that you keep behind the average consumer grade lock haven't been stolen, it is not because of the lock, it is because nobody has decided to steal them. Thus, you have more than likely wasted your money on the lock. Moreover, you may have spent additional money amassing valuables for which you have no meaningful security.

The distinction you make is the concept of "provably secure" encryption. There is no (practical) analog for securing your front door. Obviously, if there was, more locks would be better. If.

The conundrum posed in TFS is that more encryption will likely mean more weak encryption. Most people don't have the means or energy to take the issue in their own hands as you suggest. As with anything, you need to distinguish between a technical solution as you would implement it, and a technical solution as will be sold to the masses who are looking for a magic buzzword product to make their problem go away.

Terrorists on the Internet (0)

Anonymous Coward | about a year ago | (#44440845)

I didn't realize there were so many terrorists on the Internet.
Maybe they are more interested in dissenters?

Make the people in power end this (1)

gmuslera (3436) | about a year ago | (#44440863)

Where i am, with who i talk, what i do in my personal life, that is privacy. But what i write, the photos or videos i take, what i say, that is my intellectual property, and thats the one that the government of US choose to explicitly ignore when is doing all of this . Put the battle in the intellectual property front, where their bosses could be a bit disturbed if people and countries just stop caring about US companies intellectual property, and they could take some action.

Re:Make the people in power end this (1)

BeerCat (685972) | about a year ago | (#44441407)

Wow!

Who would have thought we'd be rooting for Big Media! (and since Murdoch has beaten Ballmer with SkyDrive, then it looks as though Big Media has more clout than Big Software)

Now, can Big Media trump Government? Time will tell

better title:some common encryption practices suck (5, Insightful)

ron_ivi (607351) | about a year ago | (#44440893)

Encryption isn't fundementally the problem here.

The problem is insecure distribution and control of private keys. (i.e. https that depends on trusting Certificate Authorities that appear easy to abuse by governments).

Better solutions could exist --- for example if HTTPS would only work after checking both certificates from a "trusted" certificate authority *and* a self-signed cert. That way all you rely on is that the CA wasn't compromised when you first exchanged the keys for the self-signed cert. Once that happens, even if a CA cooperates with an oppressive regime later, the self-signed cert would keep you safe.

Re:better title:some common encryption practices s (3, Informative)

0123456 (636235) | about a year ago | (#44441167)

Uh, no.

The problem is that the government leans on the server you're talking to and gets your data after it's decrypted.

No amount of encryption can fix that, but the idea that more encryption is not part of the solution is just silly. Obviously it eliminates one means of eavesdropping on your communications.

Re:better title:some common encryption practices s (1)

Charliemopps (1157495) | about a year ago | (#44441195)

Unless the government has compromised nearly every software and hardware vendor in the world... at which point you couldn't even trust the devices you're using to connect. The fundamental problem here is the strength of the governing bodies constitution and the the respect it has for that constitution. If you have, as we do today, a government that considers the constitution to be an outdated stumbling block rather than the backbone of a free society that it is, no amount of security or encryption will save you. They have unlimited time, money and people. They will always win.

Re:better title:some common encryption practices s (1)

MightyMartian (840721) | about a year ago | (#44441197)

If you generate and secure your own private keys and don't use commercial CAs, then what are they going to do? I suppose they could do what the Iranians and Chinese do, which is to use deep packet inspection to sort out that some or all of your traffic is encrypted, and then block it, but if we've reached that point where Western governments are erecting Great Firewalls, then we've reached a point where we're well and truly screwed anyways.

Re:better title:some common encryption practices s (1)

phantomfive (622387) | about a year ago | (#44441207)

The problem comes from keeping all your data on external servers.

Re:better title:some common encryption practices s (1)

mstefanro (1965558) | about a year ago | (#44441865)

That depends on what kind of data you are referring to. If you are talking about e-mails,
then intelligent beings usually realize that very sensitive data is not to be stored there.

For storing your own data, that you are not planning on sharing with anyone, cloud
storage such as Dropbox works wonderfully with Truecrypt. A strong password assures
you no-one will ever get access to your cloud data, unless you are forced to reveal the password.
Truecrypt also offers plausible deniability using a hidden volume, in case you are
forced to reveal your password.

If you are planning on sharing very sensitive data and you are aware that the government
or someone else is as motivated to obtain that data as to go through the
trouble of MITM attacks, then one good solution is to distribute your public key
over a Skype audio+video call.

Now, if you believe the government is as motivated as to try to fake both your and
his voice and movement of lips, then you would have to split your public key and
distribute it through multiple mediums (stenography on an youtube video? mailing lists?).

There *are* some ways of protecting your data ainst a government or anyone else if
it is valuable enough.

It appears a habit of the slashdot commenters to discuss how badly a government
would be able to screw you over, completely missing a simple fact: the amount of
effort any government would put into seeing your data is proportional to how valuable
they believe it is. They will not mount a MITM attack on you using a controlled
CA just to see your vacation pictures. The privacy of your data does not only rely
solely on how abusive a government is, but also on how much effort and thought you put
in keeping it private.
When dealing with highly sensitive data, it is your obligation to be paranoid, not to trust
governments, CAs, companies, ISPs etc. and go to great lengths to assure no-one can gain
access to your information.

Re:better title:some common encryption practices s (0)

Anonymous Coward | about a year ago | (#44441263)

The problem is insecure distribution and control of private keys. (i.e. https that depends on trusting Certificate Authorities that appear easy to abuse by governments).

CAs have *nothing* to do with distribution of private keys!

CAs role is to certify that they have issued a given *public* certificate. CAs sign a public key. That is all. They *authenticate* a certificate. You could easily replace all those CAs with your own. Any secure application would never rely on public CAs, but only on their own.

We trust CAs because it is easier than going to a bank and asking for their certificate fingerprints, then checking them in the browser before accepting connection.

Better solutions could exist --- for example if HTTPS would only work after checking both certificates from a "trusted" certificate authority *and* a self-signed cert.

Clearly, you do not know how HTTPS works or what public key crypto accomplishes.

Re:better title:some common encryption practices s (1)

Njovich (553857) | about a year ago | (#44441341)

CAs have *nothing* to do with distribution of private keys!

A trusted CA can just generate a new private key for the site and go MITM. This is why the CA's are a big issue for private key security, at least with the way HTTPS trust chains are set up in reality. Yes you 'could' delete all CA's in your system and replace them with your own, but who does that?

Re:better title:some common encryption practices s (1)

0123456 (636235) | about a year ago | (#44441545)

A trusted CA can just generate a new private key for the site and go MITM.

And you can see the key has changed, and post it all over the Internet to show that 'trusted CA' is issuing fake keys. And 'trusted CA' goes bust.

It's a really, really, really, really, freaking really dumb way to perform an MITM attack, because an end user can easily prove the attack happened, and show the CA is broken.

Re:better title:some common encryption practices s (1)

mstefanro (1965558) | about a year ago | (#44441911)

If a government controls a CA and would like to see your communications with a server that it does not control, all it can do is mount a MITM attack while you are communicating with that server. Afterwards, it misses its window of opportunity: if the government wants to decrypt the logged communication at a later time, it cannot do so. The damage it can do by controlling a CA is pretty limited.

SPAM (1)

six025 (714064) | about a year ago | (#44440949)

Sad to say this but maybe spam serves a useful purpose after all, it's probably the most realistic option here save fixing the root cause of the problem. If everyone sends millions upon billions of spam emails, the system might be so overloaded as to become ineffective.

On a related note, I've often wondered what some spam emails with gibberish text actually mean. Maybe it's some kind of encrypted communication hiding in plain site - it only takes 1 message to get through to the intended recipient to be effective.

Peace,
Andy.

Isn't handing over the Master Key more effective. (1)

medv4380 (1604309) | about a year ago | (#44440953)

I seem to recall reading something the implied that a Master Key was handed over in some cases by providers. It should just be called a Skeleton Key, but if a government has access to that then why consider this option?

Noise Encryption. (0)

Anonymous Coward | about a year ago | (#44441039)

For most purposes of any typical fruitloop, making as much noise as possible is a better way of hiding in the crowd.

For purposes of not being a target, well, of any use, being everyone else is a good thing.
As you know, there are search engine proxies and plugins that make your personality a random mess, so useless.

Still going to be tracked at the ISP, backbone and society level regardless. Even if you "get the law changed".
Even 1 less attack made the system worth the cost, never mind the other 299.

My suggestion? Don't be a pedo terrorist hacker, and don't ever make dark jokes. If you are in the UK, don't even joke, or be serious. Be as dull as possible.

Dumb and dumber (2)

mbone (558574) | about a year ago | (#44441059)

"...you would have to scrutinize the key material in many thousands of connections before you would even start to suspect something was wrong."

Why should you trust certificate authorities? Do you even know who all your certificate authorities are? I think that this confuses trust for assignment of liability. A CA is good for making sure that someone else is liable if you put your credit card number in a web site shopping page and it gets stolen, and it helps make prevent some guy sitting in Starbucks from stealing credit card numbers, but as far as trust, I don't think it does a thing.

And, guess what, people do do things like scrutinize the key material in many thousands of connections. And, if they don't, as soon as the next Snowden leaks what's going on, they will.

Then the client should supply the symmetric keys (0)

Anonymous Coward | about a year ago | (#44441061)

If the client wants to supply a limited key set, then that's their data to reveal.

Of course, if a host is so compromised that they are limiting the usage of symmetric keys to a known subset, then no amount of encryption should be considered secure. They can still log all the decrypted data, as well as turn over their private key for their certificates. Again, encryption keeps outsiders from seeing your data in transmission. If you can't trust the site you are communicating with, for any reason, encryption can never help you.

Re:Then the client should supply the symmetric key (0)

papafox_too (883077) | about a year ago | (#44441605)

In SSL, the symmetric key is already chosen by the client. This whole story is bullshit. It's an example of what Bruce Schneier calls a Movie Plot Threat [wikipedia.org] , only this time instead of being a terrorist attack, it's based on an evil government threat. This particular scenario is rubbish.

More encryption is the ONLY solution... (0)

Anonymous Coward | about a year ago | (#44441067)

..and when they ban that, increasingly sophisticated steganography.

The way things are going, change will only be effected by political means when the majority of people are under true hardship from an oppressive government. Once you accept that there is no 'easy way out', you might as well try to bring about that endpoint quicker, which is simply by upping the ante in technical ways which force the authorities to respond with ever more heavy handed measures.

What I always use (1)

SnarfQuest (469614) | about a year ago | (#44441069)

I bypass all of those expensive encryption schemes, and encode my data using rot13, twice!
They'll never figure that one out in a hundred years! They only expect you to encrypt things once, so doubling it up provides a much more secure encryption!

It's even easier (0)

Anonymous Coward | about a year ago | (#44441081)

Encryption is only a temporary state of data, who are unencrypted at first and get decrypted at the end. Their value in encrypted state is only that they are encrypted, which isn't really what we have data for. So just attack the end nodes and get access to the clear data before they get encrypted or after they got decrypted.

Over here in Germany we got the advice of the minister of the interior to encrypt our email. Sounds good. But he is also the one who says, that it's necessary to watch all traffic. Why should he give advice that would efficiently weaken his own policy?

Lack of understanding.. (0)

Anonymous Coward | about a year ago | (#44441087)

When using DH key exchange both sides of the connection contribute randomness to derive the symmetric cipher. One side cannot unilaterally weaken the symmetric key.

Encryption is the solution, but not today's model (1)

DJBurgie (679629) | about a year ago | (#44441105)

Assumption: Evil powers still cannot break SSL that works as it should with random data and unknown private keys without centuries or millennia of computer time..

End-to-end encryption only works if the endpoints themselves are doing the encryption. Let's take a few examples:

Social media: Person A posts something online. The endpoints, the real endpoints, are Person A and all of Person A's followers. Is there encryption between Person A and all of Person A's followers? No, not currently, and that is the problem. If there were encryption between these endpoints, the evil powers would pull out their hair. Instead they short-circuit things, compromise the world thanks to Facebook, and get an easy in to everything. They are performing a traditional man-in-the-middle. Encryption, without compromises, is the key.

Instant messages: I send message to Google (Google Talk, Hangout, etc.) and they froward it on to my friends instantly. Are the endpoints doing encryption? No, not usually, and even with Off-The-Record functionality that Google provides, it is still plaintext along the way. This is the problem. It needs to be encrypted by the endpoints.

Skype: Same as above. The service in the middle is the problem.

There are some easy solutions for some of these.

First, the best solution is to be your own service provider somehow. When federation really makes this happen properly and we each control our content with others we trust directly then that will be neat. Maybe we can still use things like OpenID to help handle that authentication in the meantime, but keep in mind that delegating trust to one party means that if another party compromises them then all bets are, again, off. We each need to provide our own trust directly to others so that end-to-end encryption can happen. If the other ends are ever compromised, revoke their trust and then handle things going forward, but at least it's possible to know and handle that situation. I think the right way for this to happen involves our own services becoming insanely simple to deploy, and then running them at home, each of us being our own little provider. I know... too hard for the common user today, but so was accessing data via the Internet twenty years ago.

Second, in the meantime some of these services can be fixed right now. Run Pidgin to connect via Google Talk, or AIM, or ICQ, or anything else that's person-to-person, and implement the Off-The-Record plugin in there. Hooray! True end-to-end encryption. The service provider just sees crap in between, which is SSLized crap, and that's the end of their involvement even if the power scum that force them will take their data at gunpoint. Since he party in the middle has no keys, they have no data. Suddenly the evil powers must start attacking individuals instead of intermediaries which is much harder for them to do.

By the way, never use the same password, or even minor variations on passwords, on any two things, ever. Just don't. When you do, you make it trivial to take everything with the weakest link compromised. Which link will be attacked by anybody really caring? The weakest of course. Make them all strong, and different. LastPass is a good, secure option if you cannot manage passwords on your own without any intermediary (yes, it's work).

Anyway, just some thoughts.

It doesn't have to be all encryption (0)

Anonymous Coward | about a year ago | (#44441115)

Crux of his essay posits the problem with protecting privacy is that the solution will have to be political one and not technological. He doesn't give a reason that it can't be both. You can have strong, ubiquitous encryption and governmental policies that protect privacy. You don't have to just accept the status quo.

We must move on from basic crypto (1)

John Allsup (987) | about a year ago | (#44441123)

The idea behind crypto is to make undesired access to data impractical.  What is required next is to use mathematical techniques to ensure that the data to which undesired access is unwanted cannot be known to exist.  We begin on this road with steganography.  We could also invisage a gameplay-fingerprint scenario where I need to interact with a system in such a way that it can get a basic behavioural fingerprint and then use this to resynthesise data.  This may well result in lossy compression where the output looks similar but is not identical.  We then use language and algorithmic compression techniques from there to shape how things are reconstructed.  I can imagine much covert research into such concepts.

I encrypt everything (1)

Jay Vollmer (2882139) | about a year ago | (#44441133)

I encrypt everything - and I use double rot13 just be be extra sure that no one can read it!

Nothing the EFFs plugin could not deal with... (1)

OdinOdin_ (266277) | about a year ago | (#44441157)

>> you would have to scrutinize the key material in many thousands of connections before you would even start to suspect something was wrong.'

A few iterations of their plugin, to also examine key information and find a safe way to report such concerns.

https://www.eff.org/observatory [eff.org]

The Session Key of the SSL session is what they seek to control. So this is a matter for a secure key exchange protocol to fix.

I don't understand how storing information inside a cookie (which is presumably inside the HTTPS connection) helps the attacker. Since in order to examine it they would have already brute forced their 100 million known keys to find the one that worked. So why do they need any extra information from the cookie.

Maybe a cryptographer can explain if key exchange protocols such as DH are immune to this kind of concern, since don't both ends pick their own random numbers, to derive a usable symmetric cipher key. So as long as each end can trust their own local random number generation isn't the exchange immune to this attack even if you presume the other end uses same (not random number) every time. They still can not control my RNG and my RNG perterbs the resulting master key. So we just need to make sure there is enough entropy from one ends input to satisfy their ends security concerns.

No the real problem here is having the remote endpoint simply persist and store for later lookup, or forward in realtime the agreed key the client and server used of any SSL session along with a timestamp and the IP address and port number tuples. This you can never protect yourself from. You have to ask the question, what data would I trust the endpoint with, just like any other kind of relationship ?

More encryption is good, because then at least there maybe whistle blowers and loss of reputation costing the relevant company some financial penalty, hopefully 10x more than the bribe.

Homomorphic Encryption (0)

Anonymous Coward | about a year ago | (#44441217)

It might not be ready for prime-time, but if you don't trust your hosting provider, then homomorphic encryption may end up being the solution.

look, that scenario is less encryption (1)

gl4ss (559668) | about a year ago | (#44441235)

not more.

that scenario doesn't matter that much anyways when the mails are with big providers.

Rapelcgvba vf urer gb fgnl (1)

jfdavis668 (1414919) | about a year ago | (#44441281)

V guvax gung rapelcgvba vf gur jnir bs gur shgher! Gurer ner whfg gbb znal crbcyr ba gur Vagrearg jub ner bhg gb pbyyrpg rirel fpenc bs vasbezngvba nobhg lbh. Gurl pbagvahr gb svaq havdhr jnlf gb rkcybvg gur zbfg gevivny cvrpr bs vasbezngvba gurl pna tyrna sebz lbh. Rira gur zrer snpg gung lbh rkvfg va n qvtvgny raivebazrag pna or hfrq ntnvafg lbh. Rapelcgvba, lbhe arj gehfgrq sevraq.

Re:Rapelcgvba vf urer gb fgnl (0)

Anonymous Coward | about a year ago | (#44441479)

It's a relief to know the Old Ones [wikipedia.org] are also interested in security practises...

Oh wait, it's just rot13. Then again, the existing model (SSL certs, CAs, etc.), given the topic of discussion, aren't much better.

I see what you did there, Shub-Niggurath!

So, more OPENSOURCE encryption? (3, Informative)

morcego (260031) | about a year ago | (#44441283)

This has nothing to do with encryption, and has everything with software you can't audit and verify yourself is secure.

I mean, do you really think it is that unlikely there are backdoors and/or monitoring hooks in your Cisco router? Or your Linksys AP? Or whatever?

The moment you trust blindly, be it the government or companies in a position to be influenced by others, you are putting yourself at risk.

Saying this is a cryptography issue, and not a "blackbox" issue, makes me wonder about ulterior motives...

Here's the article (0)

Anonymous Coward | about a year ago | (#44441291)

https://queue.acm.org/detail.cfm?id=2508864

He's right.

perfect forward privacy (1)

modmans2ndcoming (929661) | about a year ago | (#44441375)

Simple use a BEAST attack hardened diffie-hellman encryption. ephemeral encryption means a single key or even thousands of keys can not endanger future communications.

Giving vendors access to encryption keys? WTF? (0)

Anonymous Coward | about a year ago | (#44441397)

More Encryption Is Not the Solution

Of course it is. You just need to do the encryption on the client side.

I would never, ever trust a cloud provider to do encryption for me.

Why the hell would anyone give a vendor access to their encryption keys?

A cloud provider gives me space and nothing else. If I don't encrypt a file before I copy it to the cloud, then I get what I deserve, obviously.

More encryption IS the answer (0)

Anonymous Coward | about a year ago | (#44441441)

I [as one of the governments] would contact providers of popular cloud and "whatever-as-service" providers and make them an offer they couldn't refuse: on all HTTPS connections out of the country, the symmetric key cannot be random

Thereby subverting only a small fraction of encrypted communications, and undermining your own e-commerce systems in the process (since unlike most individuals, they actually would have to use the coerced systems). This is why more encryption is the solution: the countermeasure that you mention, is a lot like DRM as a countermeasure to piracy. It won't work against the people you say you're trying to defeat, but it will work against the people who are already on your side. Net Effect: incentive to stop being on your side. Just as DRM only caused more piracy, subverting session key entropy will cause people to diversify their software, deploy things in competing jurisdictions, etc. It's a suicide move. And while the entertainment industry's suicide move was tragic, government eavesdroppers' suicide would be most welcome.

Don't even need to preselect (0)

Anonymous Coward | about a year ago | (#44441537)

Just have the service provider hand over a copy of the random symmetric key to the NSA log server. Nobody would be the wiser.

Or just have over the plaintext contents to the NSA. Then they don't even need to reassemble packets or spend CPU cycles decrypting them.

Client side generates randomness too (1)

hawguy (1600213) | about a year ago | (#44441539)

Isn't the master encryption key [wikipedia.org] used to encrypt the stream made from a hash of a server generated and client generated random number? That would seem to make it a moot point whether or not the server keys are random as long as the client hasn't been compromised and is using a good random number. The server could be issuing "0" as its "random" number and the key would still be random.

The gain access to the data stream, the government would need access to the server's private key (or signed fake certificate so they could execute a man in the middle attack). With Perfect Forward Secrecy, would possession of the private key allow one to decrypt the stream?

Re:Client side generates randomness too (0)

Anonymous Coward | about a year ago | (#44441927)

Isn't the master encryption key [wikipedia.org] used to encrypt the stream made from a hash of a server generated and client generated random number? That would seem to make it a moot point whether or not the server keys are random as long as the client hasn't been compromised and is using a good random number. The server could be issuing "0" as its "random" number and the key would still be random.

The gain access to the data stream, the government would need access to the server's private key (or signed fake certificate so they could execute a man in the middle attack). With Perfect Forward Secrecy, would possession of the private key allow one to decrypt the stream?

Notice this in the summary:

The key from the other side? Slip that in there somewhere, and I can find it (encrypted in a Set-Cookie header?)

Under the scenario posed by the summary, the company that owns the server is fully compromised to the extent that they are re-writing their system libraries for the NSA and the client's browser has been re-written so that it leaks the client's DH details of each connection. In this extreme scenario no sort of encryption can help you, although to be honest if they are going to hypothesise this sort of thing they may as well have gone with:

Obama's drone has fired a Hellfire missile at your location. WHERE'S YOUR GALOIS FIELD NOW, TER'IST?

there's another option (1)

Mister Liberty (769145) | about a year ago | (#44441549)

Finally get those politicians to abide by the respective constituent document of your country.
There are some proven ways to achieve that.

The NSA says never encrypt... (0)

Anonymous Coward | about a year ago | (#44441601)

So Slashdot publishes another NSA black-propaganda article. Rather like Slashdot's frequent warning that erasing data on your hard-drive is a waste of time, because forensic teams have 'magic' methods to directly read the surface of your platters, recovering such data. It is all part of the same nonsense designed to discourage the sheeple from using best methods to protect their security/privacy.

1) Decent encryption CANNOT be broken by the NSA.
2) Decent encryption (software, not the ALWAYS compromised hardware solutions) is free and easy to deploy
3) Encryption for networks (including the Internet) should be 'end-point' encryption under the control of the users themselves.

Has does the NSA attack such encryption (for general surveillance, not targeted individuals, obviously)? Well, by getting the owners of Slashdot to run stories like this for one. Bad-mouthing the best methods ALWAYS reaps dividends, and is insanely cost-effective. But things are not so nice these days. Microsoft, for instance, is introducing deep NSA monitoring tools into its new operating systems, especially the update of Windows 8. The idea is that the OS is 'trojan friendly' allowing techniques like message queue hijacking (of which the key-logger is a trivial example) to be unstoppable when the NSA uses facilities Microsoft has created for this purpose.

Most encrypted data will be created as 'plain text' (or the equivalent) and viewed as the same at some point. The NSA simply work with Microsoft to have access to the data BEFORE Truecrypt hides it, or after the user reads it from a Truecrypt volume.

The so-called 'protected path' that all computer companies are obliged by Law to place in new video hardware (in the name of making DRM unbreakable) actually provides a hidden resource where YOUR unencrypted data can be intercepted without your knowledge. Microsoft can simply request your graphics card to take regular snapshots of your screen, and you will never know this because the message stream to the GPU (for protected path functions) is encrypted with protected path control keys. A full screen JPG is quite a small file even for a high-resolution screen, and can be sneaked out to an NSA server with you standing ZERO chance of noticing the traffic blip.

All Windows 8 computers with a recent GPU (including integrated GPUs from Intel or AMD) can be remotely instructed to secretly capture your screen data and silently upload this to a server of Microsoft's choosing. Again, if you LOOK for this behaviour, you will see undocumented driver activity to the GPU, and small encrypted data packets sent to Microsoft servers. By definition, you can prove nothing because THEY encrypt (funny how it is you that is told encryption is pointless).

NSA full surveillance GETS the fact that it doesn't cover people using proprietary or rare/old computing systems, and doesn't care. NSA full surveillance only ever gets the majority who use the latest gizmos. I mean, don't carry a cell phone and obviously the NSA can't track you that way- but does this option mean the NSA go "damn, we might as well end our cell phone monitoring program"?

You want end-point encryption...
You want an open-source OS to replace Windows, so NSA back-door capabilities are severely compromised...
You NEVER want to trust corporations- by law they are required to lie to the sheeple if they are engaged in any way with the NSA...

In the end, it is hard to imagine the people winning. The ARM SoC parts are like the GPU systems from Nvidia and AMD, but a million times worse. Everything passes through the hardware blocks of the SoC, meaning that the NSA can always tap into your raw data, and you will never know. The SoC can even hold code inside the chip itself, controlling the monitoring of your screen and inputs. You won't know when this code is inserted or running. You won't know if the data leaving your device is an encrypted copy of your screen or recent inputs.

Saying "who cares so long as *I* can lock down my tablet" is moronic. I mean not using the tablet in the first place also gives 'perfect' security, but what help is that? It is how the vast majority will need to use the device that matters.

Encryption WORKS (unlike what the shill who wrote the article claims) which is why THEY use it. The problem is before and after. You don't get to 'trojan' NSA computers, but they (thanks to Microsoft, Nvidia, AMD et al) get to 'trojan' yours. Your government considers it completely acceptable to gather a copy of every screen from every computer as many times a minute as technology currently allows.

Re:The NSA says never encrypt... (3, Insightful)

hawguy (1600213) | about a year ago | (#44441733)

Microsoft can simply request your graphics card to take regular snapshots of your screen, and you will never know this because the message stream to the GPU (for protected path functions) is encrypted with protected path control keys. A full screen JPG is quite a small file even for a high-resolution screen, and can be sneaked out to an NSA server with you standing ZERO chance of noticing the traffic blip

I took a full screen snapshot of my 1920x1080 screen (maximized browser window with this Slashdot page loaded, so there's a lot of white space on the screen) and saved it as a JPG. The size of the default quality JPG was 480KB (which looked about the same as the corresponding PNG which was only 275KB). I created JPG's of decreasing quality until the text became mostly illegible, that happened at a quality level of "7" (on a scale of 1 - 100 with 100 being the best). The resulting JPG ended up being 95KB in size.

That's not exactly what I could call "quite a small file", and though many people wouldn't notice that size file going out periodically (every hour? every minute?), it's big enough that some would - especially paranoid people that are worried about someone spying on them. 95KB sent out every minute would be around 15kbit/second on average, so it's definitely enough to be noticable.

We can't trust the providers (1)

Karmashock (2415832) | about a year ago | (#44441715)

No one trusted the NSA before. That wasn't news. Who was giving away their encryption keys to the NSA before? Not with their knowledge or willingness. The new information is that the providers betrayed the users.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>