More Encryption Is Not the Solution 207
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.'"
Air America (Score:2)
And who says the government doesn't already run some of these services themselves?
quick key repetition (Score:4, Interesting)
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 (Score:4, Interesting)
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: (Score:3)
Re:quick key repetition (Score:5, Informative)
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: (Score:3)
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) t
Re: (Score:3)
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: (Score:3)
Re: (Score:2)
The CA cannot decrypt data encrypted with a key they signed. All they can do is sign the public key - the private key remains in the control of whoever runs the server using it.
Granted, a CA could (by policy) require you to give them the key... but my response to them would consist of my saying "eat shit and die."
Re: (Score:3)
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: (Score:2)
Re: (Score:3)
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.
Call it the Fermat's Last Theorem Effect (Score:2, Interesting)
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 (Score:5, Insightful)
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: (Score:3)
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
Re: (Score:2)
The password dictionaries are already out there for anyone to download, with hashes and cracked passwords from the LinkedIn, PSN, etc. web site exploits over the last few years. Better than any list of words Google searches might reveal.
Re: (Score:2)
You actually don't believe that Google has access to more keywords and passwords than those in password dictionaries?
Google's list would be a superset since Google crawls all of that. They even had wifi data gathered from around the world. They are likely to have most of the words/passwords that have appeared on the Internet (they even have had a fair bit of USENET).
While that would be a huge number that is still a lot less to go through than say brute forcing AES.
No story? (Score:5, Insightful)
No link to any story at all? Since when does Slashdot provide a private blogging platform on the front page?
Re: (Score:2)
Agreed. And it's not even much of a blurb.
Re: (Score:2, Informative)
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
Re: (Score:2)
Since when does Slashdot provide a private blogging platform on the front page?
That was what Rob Malda started it as...
Re: (Score:2)
Since when does Slashdot provide a private blogging platform on the front page?
You must be new here.
In this scenario, the endpoint is compromised. (Score:5, Insightful)
In that case, indeed, no amount of encryption will save you.
Re: (Score:3)
(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: (Score:2, Interesting)
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: (Score:2, Insightful)
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: (Score:3)
All the government does is say, "give us your data." It's much easier, and effective.
Re:In this scenario, the endpoint is compromised. (Score:5, Insightful)
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.
Re: (Score:2)
Distrust, decentralize, distribute.
Trust no one, nothing, more than anyone, anything else. For example, self-signed certs are just as trustworthy as those signed by a CA.
Decentralize and distribute the information storage. Basically, a P2P/Freenet type of architecture where information is not stored in one place. Your own website could be distributed across multiple machines. When somebody requests a page, you go out and look for your pages from the distributed pool, then come back. But the individual machi
Re: (Score:2)
What I think is strange about the article is that encryption can also be used to just raise the bar.
If we use transport encrypted protocols like HTTPS, IPSEC, etc. everywhere we'll take away their dragnet.
When the police has a warrant they can search your home, but they shouldn't be installing government camera's in every home.
Serve yourself. (Score:2)
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,
Re: (Score:3)
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
Re: (Score:2, Insightful)
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: (Score:3)
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
Re: (Score:2)
http://wallstcheatsheet.com/stocks/your-computer-may-already-be-hacked.html/?a=viewall [wallstcheatsheet.com]
The solution is Global Mesh Networking (Score:2)
Re: (Score:2)
Except for something like that to work, you need connections, and said connections require laying large amounts of fiber. Who is going to build a line that crosses an ocean, or even one that links two major cities?
And there's also the equipment: Even if I have a fiber line heading to Chicago, and a bunch of local people that connect to my hardware, then I need to have the hardware to route their packages to the line. I doubt I can do that with some old linksys router running tomato. I'd need a whole lot of
Re: (Score:2)
Consume more electricity? It's going to be as slow as molasses.
I think fixing the government & service providers is probably easier & better.
Re: (Score:2)
A mesh network would have terrible latency, at least in its current generation.
Links or it didn't happen (Score:5, Informative)
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 [acm.org]
Re:Interesting quote about OSS project (Score:4, Informative)
I think he's referring to when Debian did exactly this to their openssl library.
It took two years for anyone to notice. [swtch.com]
Complete idiocy (Score:5, Insightful)
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: (Score:2)
This is more like everyone buying more locks, but the spooks have an insider at the lock factory making them easy to pick for the feds.
Furthermore, the lock and key guilds are chummy with the merchants who refuse to do business without them.
Re: (Score:2)
Then you don't use those locks or those merchants. There's nothing whatsoever that is forcing us to use Google or Microsoft or Apple or Facebook or...
Why not promote the ability to use our own encryption so that we can send secure data over a third party line. That only breaks down if you have a passive populace who assumes that the end points of the data are the same companies that are compromised; ie, people who use the cloud.
Re: (Score:2)
Indeed. The problem here isn't encryption, it's trusting commercial CAs that are more than likely providing governments with private keys so these governments can proceed with man-in-the-middle decryption. If you create your own CA and properly manage your private keys, then said governments are out in the cold.
Re: (Score:2)
Indeed. The problem here isn't encryption, it's trusting commercial CAs that are more than likely providing governments with private keys so these governments can proceed with man-in-the-middle decryption.
But that's easy to prove.
Just produce one example of a fake key signed by a CA.
CAs who've been shown to produce fake keys generally haven't lasted long.
Re: (Score:2)
huh? who said anything about providing fake keys.
The, um, person who said that CAs would be providing their keys to governments?
The only thing the government can do with a CA key is create fake keys for other sites, signed by that CA. And then, when someone sees one in the wild and publishes the key across the Internet, the CA is toast.
The issue is not that there is anything wrong with the keys, but that you are trusting the provider of them to not be sharing them.
CAs don't provide keys. They just sign them.
Re: (Score:2)
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.
The reason that PGP (or GPG or whatever) encryption isn't standard, despite being suggested for the best part of the last 20 years, is because it is Too Much Effort (tm)
If an easy to use system is implemented ("check here to encrypt all your emails" type easy), then most people won't bother confirming whether the "encryption" uses proper random keys, or conveniently "provided by the software vendor" (read - 'one of those not really random') keys.
And, with propriety software, how (other than sending many tho
Re: (Score:2)
Popular mailers like Thunderbird really do make it that easy.
Re:Complete idiocy (Score:4, Insightful)
Setting up GPG is easy. The difficulties associated with secure key management increase significantly with time.
Re: (Score:2)
The problem I'm encountering is that everybody I know uses webmail (ick). There are some plugins for GPG on webmail, but they seem to have been in a net yet usable state for a while.
Re: (Score:3)
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.
Make the people in power end this (Score:2)
Re: (Score:2)
Wow!
Who would have thought we'd be rooting for Big Media! (and since Murdoch has beaten Ballmer with SkyDrive, then it looks as though Big Media has more clout than Big Software)
Now, can Big Media trump Government? Time will tell
better title:some common encryption practices suck (Score:5, Insightful)
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:better title:some common encryption practices s (Score:4, Informative)
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.
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:2)
I believe functionality like this is already in HSTS and already used by google and chrome
Re: (Score:2)
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 [chromium.org]
and only enabled for google, twitter, tor, and a handful of other sites.
Re: (Score:2)
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?
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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,
In Soviet Russia, the Key generates YOU! (Score:2)
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
SPAM (Score:2)
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 ef
Isn't handing over the Master Key more effective. (Score:2)
Dumb and dumber (Score:3)
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.
We must move on from basic crypto (Score:2)
look, that scenario is less encryption (Score:2)
not more.
that scenario doesn't matter that much anyways when the mails are with big providers.
Rapelcgvba vf urer gb fgnl (Score:2)
So, more OPENSOURCE encryption? (Score:4, Informative)
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...
perfect forward privacy (Score:2)
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.
Client side generates randomness too (Score:2)
Isn't the master encryption key [wikipedia.org] 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
Re: (Score:2)
Isn't the master encryption key [wikipedia.org] 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?
Notice this in the summary:
The key from the other side? Slip that in there somewhere, and I can find it (encrypted in a Set-Cookie header?)
I saw that, but I don't see how that helps since the Set-Cookie header is encrypted by the same symmetric key as the rest of the HTTP traffic. Which they can't read merely by making the server key non-random (or less random) if the client is sending a good random number for generating the master key.
If the NSA coerced the service provider into giving up their private SSL key, then that would probably work work (but I'm not even sure that's sufficient to decrypt a session with PFS)
Under the scenario posed by the summary, the company that owns the server is fully compromised to the extent that they are re-writing their system libraries for the NSA and the client's browser has been re-written so that it leaks the client's DH details of each connection. In this extreme scenario no sort of encryption can help you, although to be honest if they are going to hypothesise this sort of thing they may as well have gone with:
That's not in the summary -
there's another option (Score:2)
Finally get those politicians to abide by the respective constituent document of your country.
There are some proven ways to achieve that.
We can't trust the providers (Score:2)
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.
The answer is to teach kids to be programers. (Score:5, Interesting)
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 [ubuntu.com]
#!/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
Who cares? (Score:2)
Server doesn't create the session key (Score:5, Informative)
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.
More encryption is the answer if YOU control it (Score:2)
Link to TFA (Score:3)
http://queue.acm.org/detail.cfm?id=2508864 [acm.org]
Defense in Depth, and Better Tech (Score:3)
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.
How is that worse (Score:2)
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.
Human rights (Score:2)
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 t
Re: (Score:2)
There is no such thing as a civilized country.
Bad example (Score:2)
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
Re:The NSA says never encrypt... (Score:4, Insightful)
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: (Score:2)
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.
Re: (Score:2)
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.
Re:Passwords don't work either (Score:5, Interesting)
keyspace negawatts (Score:3)
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
Re: (Score:2)
Compromising the ent
Re: (Score:2)
At least in the United States until recently the problem wasn't the parties but the electorate. The electorate is slowly shifting from strongly supportive to somewhat hostile.
Re: (Score:2)
That's not true that everyone is equally hostile. There are liberal democrats and conservative republicans who for years have taken strong stands in favor of privacy.
That one breaks up pretty clean
Re: (Score:2)
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?
In Soviet Russia the Iron solders YOU! (Score:2)
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
Re: (Score:2)
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.