Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

Nerval's Lobster writes "Following reports that the NSA aggressively targets Google and Yahoo servers for surveillance, Yahoo is working to encrypt much of the data flowing through its datacenters. 'As you know, there have been a number of reports over the last six months about the U.S. government secretly accessing user data without the knowledge of tech companies, including Yahoo,' Yahoo CEO Marissa Mayer wrote in a Nov. 18 blog posting. 'I want to reiterate what we have said in the past: Yahoo has never given access to our data centers to the NSA or to any other government agency.' In order to make Yahoo's systems more secure, she added, the company is introducing SSL (Secure Sockets Layer) encryption to Yahoo Mail with a 2048-bit key. That security measure will supposedly be in place by January 8, 2014. Beyond that, Yahoo plans on encrypting all information that moves between its datacenters by the end of the first quarter of 2014. Around that same time, the company will give users the option to encrypt all data flowing to and from Yahoo; it will also 'work closely with our international Mail partners to ensure that Yahoo co-branded Mail accounts are https-enabled,' Mayer wrote. (While it's not a crushing expense for massive companies such as Yahoo, introducing this sort of security does add to infrastructure and engineering costs, and takes time to actually put in place.)"

Not mentioned was which encryption schemes Yahoo is considering. Maybe it's simply HTTPS, but is that good enough? Are there other possibilities?

Since the NSA has backdoored encryption schemes in the past, how can Yahoo determine if the scheme they implement is actually going to prevent the NSA from decrypting it? It's a serious question, and you can patly answer "you can't", but if I were responsible for implementing this scheme, this is the question I would pose to the team and require some sincere digging because it would be an even bigger embarrassment to implement the encryption, and then read another Snowden-esque revelation showing it was for nothing, and I was made a fool of.

I can middle-man the entire credential exchange - pretending to be the secure channel requestor and resubmitting the altered request for response. I can then pretend to be the responder, etc. This is how SSL examination proxy works as an edge device.

And do you trust all the ssl certificate authorities? How many of those are based in the US and thus fall under the jurisdiction of the NSA? Come to think of it so does yahoo, who's to say the government wont simply demand that they hand over all their keys?

FISA courts aren't really courts in that the court doesn't have the same degree of authority nor the same checks as a normal court. That's why I consider it semi-bypassing. It is arguably either a court only in name or a weak court. On the other hand this structure is overseen by congress.

Not mentioned was which encryption schemes Yahoo is considering. Maybe it's simply HTTPS, but is that good enough

HTTPS isn't an encryption scheme, it's a mechanism to establish a (theoretically) secure channel of communications. The actual ciphers to be used are negotiated between server and client, and can range from "You're kidding, right?" (RC4) to "The Federal Government claims it's good enough for Top Secret data." (AES-256)

As with everything, there's a level of third party trust (the certificate authorities) or shoe-leather (exchanging keys in person) that's required regardless of the ciphers you end up using. That's a whole different discussion though.

As with everything, there's a level of third party trust (the certificate authorities) or shoe-leather (exchanging keys in person) that's required regardless of the ciphers you end up using. That's a whole different discussion though.

You're of course right in pointing out the distinction between the transfer protocol and the encryption.

I don't believe Yahoo (or any other big player) facilitate the shoe-leather alternative though, it's third party certification or nothing.

We already assume they have the capability of brute forcing all encryption within a reasonable time frame. Something hilariously well protected? 3-6 months.

That being said, the NSA, still only has so many units of discrete work it can perform in a given period . Now, unless you are going to try to convince me that the NSA has computing power many orders beyond the total computing power of the entire planet, it means there is still safety in numbers.

Mass. Surveillance.

That's the real game. That's the real threat to privacy and freedom. If everyone makes sure that the NSA has to waste those work units decoding a pair of testicles you sent to your best friend, the NSA is still left with picking and choosing its battles .

I'm okay with that. If the NSA really can break all of my communication and files within a week or two, but can only do it for several dozen Americans at a time during that period, we are all still protected as a whole. The NSA can still do its job. Yes, there was an original job they ostensibly are supposed to perform in my best interests.

The sheer magnitude of what would need decryption for mass surveillance makes it illogical to worry about, IF WE ARE USING ENCRYPTION EVERYWHERE AND ZERO-KNOWLEDGE 3RD PARTY SERVICES. I can't stress that last part enough.

They can't brute force. Do the math. There are 2.8x10^147 primes which are good candidates for 1024-4096 bit keys. If you were to use every atom in the universe to compute 1 prime per nanosecond you still ain't close to brute forcing your way out.

We don't know what they have. Never underestimate the "geek factor". There may very well be a vulnerability that we have no idea of that reduces the complexity sufficiently that decryption is possible within a viable time frame.

I'm taking a conservative view point on what real risk the NSA could pose with ubiquitous encryption.

There are many algorithms for reduction of the decryption problem. Orders of magnitude get pulled off aver 5 years or so. But that ain't brute force.

I'd say right now it is likely the complex reduction algorithms still aren't good enough to overcome the sheet mathematical complexity given 256-bits. Certainly for something like 1024-4096 nowhere near.

Yes, that is how encryption works. But if your key is large enough, the time & energy to brute force it will take much longer than your lifespan. As an example I just googled, brute-forcing AES-128 at 10 Petaflops would take 10 quintillion years (10^18). http://www.eetimes.com/document.asp?doc_id=1279619 [eetimes.com]

The _real_ concern is that the NSA knows of weaknesses in these encryption schemes, and doesn't have to brute force it.

The simplest concern is the way sites are authenticated by certificate authorities... Some of those certificate authorities are under US jurisdiction and thus beholden to the NSA, and others are under the jurisdiction of other governments who may well want to do the same thing.

No one is ever going to brute force a 256-bit symmetric key. Even if you imagine a matrioshka brain (turn the entire energy output of a star into computation) it would take longer than the age of the universe. A 128-bit symmetric key is safe from brute force vs all realistic threats.

If the math is flawed, OTOH, or your "random" key wasn't so random, it's easy (there is deep suspicion about the RNG built into Intel procs these days).

To brute-force a 4096-bit key pair in a reasonable time would require not acres of computers, but entire galaxies composed of nothing but computers. And these computers would have to be able to communicate with each other instantly and not be limited by the speed of light.

No, not really. In security, you don't have infallible trust in a system which isn't verifiable -- which means, just because Yahoo says they are doing transport encryption in their data center doesn't automatically make that system trustworthy. You need proof that they have done what they said. Otherwise, it's just their word.

Secondly, Yahoo's biggest problem is the data laying on the disks. They can encrypt the traffic all they want that doesn't do anything for the mail stores on disk. Ms. Mayer is basic

Most of the SANs I've seen support disk encryption and IPSec encryption between the SAN and the host or OS talking to it. If your OS writes encrypted data to storage (encrypted filesystem) as well, you have two layers of encryption on the platter and two layers of encryption in transit.

Of course that doesn't address weaknesses in ciphers or key exchange systems, but it seems like it would make it a lot harder to get at the data because the only place it is decrypted is during interprocess communication (decrypting from the filesystem and before re-encrypting it for final transit to client).

Not that this trivializes that risk, but it seems to make it a lot tougher.

I'd be surprised if any "big data" uses SAN. I don't know about Yahoo, but Google, MS, and I'm pretty sure Amazon all use simple direct-attach storage. It's a bit silly to be worried about anyone reading the data off of 10000 servers through some backchannel without being noticed. Encrypting the links between those servers would accomplish a lot, IMO.

It depends on where the "brains" are. Facebook (IIRC) has the redundancy on the backend app layer where coupled with NoSQL, if something drops... there is some redundancy built in somewhere to pick it off, or drop a couple tuples, but the tables still have their integrity. Whole servers can drop off the map, and Facebook will keep going. Isn't pretty, but their model really can handle stuff getting tossed here and there.

Apple, on the other hand, uses Teradata systems with NetApp appliances on the backend, so one large cloud provider does go with the more traditional storage stack model found in the enterprise. However, unlike losing a FB post or two, a user losing chunks of their data would not be a good thing, so Apple's model tends to be more rigidly ACID compliant.

Only a small fraction of people understand the technology enough to know that proof is required, not only proof that encryption is being used but also that its implemented correctly and the keys are securely stored.

The vast majority of people will just read the marketing literature and assume that yahoo aren't trying to mislead them. They don't understand how these things work and don't care to, they simply put blind trust in what they're being told.

For [1], printing the key out in a sequence of QR codes (or variant) would probably be a good compromise between plaintext paper and disc. QR codes have better built in error correction than teams of people typing in a long sequence of arbitrary characters...

I've tried that, with varying success. A lot of readers will not work with the larger QR codes (which would be needed for decoding a 2048-4096 bit key block), and other readers just give up with regards to alignment if the block is too big.

If there is very standard code system which would work for this (a QR variant, since it does have built in error correction), it is a good thing to have included with a human readable (and retypable) output.

Well,My Guess is SSL/TLS is fine but the trust system is broken against a motivated state actor.

(forgive my terminology...it's been a while since I've delt with certificates)1.) Steal the private key from Google, Yahoo, etc.2.) Force a trusted certificating authority to issue a leaf/signing certificate. Then the government can issue SSL certs for Yahoo, Google, etc on behalf of that certificating authority who gave them a leaf certificate.3.) Steal the signing certs of a root authority4.) Setup a shell trus

...how can Yahoo determine if the scheme they implement is actually going to prevent the NSA from decrypting it? It's a serious question

Yes it is. And these SE-Corps (looking at you GOOGLE!) should be much more vocal and transparent in letting the public know the predicaments they as a Corporation are in, what factors are there to consider, and their respective weights, what the options are that they're contemplating, and what their decisisions, when made, are based on.

In short -- your users may be searchers, and as such they are learners They are not dumb and will not be kept in the dark!To NOT mention, to AVOID SUBJECT, to be SILENT, ar

Since the NSA has backdoored encryption schemes in the past, how can Yahoo determine if the scheme they implement is actually going to prevent the NSA from decrypting it?

You have to understand that any key based encryption technique is breakable. It doesn't matter what key based technique you use, it can eventually be brute forced. All you can hope to do is make it take a very long time to decode, so long that the message becomes not worth the effort.

There are "unbreakable" techniques, but they all require a one use a random pad that both parties know, but never disclose or reuse. That's about the *only* way to make sure the NSA cannot decode your stuff. Good luck doing

Since the NSA has backdoored encryption schemes in the past, how can Yahoo determine if the scheme they implement is actually going to prevent the NSA from decrypting it?

Use multiple encryption schemes from different providers, and shuffle them around intermittently. So that one week the NSA can decrypt the data stream to reveal material that has been encrypted by a Russian system, but the next week they get something that has been encrypted by a Chinese system. And the same goes for the Russians at their t

I love how so many people here are so sure the NSA can do magic on encryption... it's like complexity doesn't exist. They can solve any problem expressible in a general formal system! Halting problem? Fuck the halting problem, that's like stealing candy from a child.

I just picked that comment because it said "thru [sic] ssl", and I interpreted as "breaking DH" or something. But I was referring to a somewhat spread sentiment that breaking encryption is just a matter of developing technique, which may not be the case (hence my sarcastic reference to the halting problem & Godel's incompleteness theorem).

The issue is not whether they can brute force encryption.We already assume they have the capability of brute forcing all encryption within a reasonable time frame. Something hilariously well protected? 3-6 months.

If you secure your own inter-datacenter links, you accept only certs signed by your own private CA, hence the compromised CA is not a problem. And even if your private CA is compromised, ephemeral DH exchange ensures stored traffic remains difficult to decipher.

The DH exchange only works if you don't get Man-in-the-Middled. Thats the point. Once the certificate authority is compromised, they can create a cert that makes them appear as the server you think you're supposed to talk to, so you do the DH exchange with their server, so the DH exchange isn't a problem. Then they just make another connection on to the destination which does a whole new DH exchange for keys.

Yahoo CEO Marissa Mayer wrote in a Nov. 18 blog posting. 'I want to reiterate what we have said in the past: Yahoo has never given access to our data centers to the NSA or to any other government agency.

The operative phrase here is "our data centers". A little less than half the data centers that Yahoo have their servers in are not owned by Yahoo, they lease space there. So, Yahoo's data flows in and out of the cage(s) they have their servers in into the house network. You can work it out from there.

While I would have agreed with you two weeks ago, bizarrely, I have recently started getting a ton of spam in my Gmail account - really obvious stuff that should have been filtered. And Yahoo has been almost perfect filtering the same crap. Several people I have talked to have noticed the same thing. It's almost like someone at Google accidentally turned off the spam filter...

Maybe Google has decided "Why make it easier to pick out what our customers are interested in - or, for that matter, why reduce the volume of electronic transmissions that must be analyzed? Let the spam flow!".

Doesnt do any good, if the law enforcement organizations (etc), have a warrant they can record all traffic from your IP/Phone. Depends on the company, but at AT&T Wireless they could turn on full sniffing from a mobiles internet traffic and record all TCP/UDP and even overlay it with location based service (tower strength triangulation). My boss said they had a group to assist in warrants, but after I setup the servers and routers, I NEVER saw an email, name or department identified, and I worked there for years setting up hardware from old packet data to 3G routers before I left.

So anyways, they record the entire SSL handshake so they can decrypt the session. You too can even try it for yourself in wireshark.

And who knows what is going on at the AT&T datacenters in those secret rooms...

Let's be real about this -- if the N.S.A. wants data on any particular Yahoo user, or on all Yahoo users for that matter, it's not going to make one wit of difference if Yahoo encrypts its data or not. All the N.S.A. has to do is issue a national security letter, and Yahoo will cough-up whatever they got. Yahoo's encrypting the data on disk or in transit through their datacenters is little more than a pathetic attempt to lure customer's into believing that Yahoo is doing something to protect their data when, in fact, there's little Yahoo can do to prevent the N.S.A. for getting its hands on your data.

I agree with someone who suggested one of the early pre-NSA encryption schemes.

You'd be better to roll your own, mind you. Remember, they already have your make files if you used Win 8 or Win 8.1, since it "indexes your local drive for fast search" which is a polite way of saying "spies on you".

I don't just blame the NSA for this situation. The providers are at fault for assuming that leased lines can be run unencrypted between their data centers because they're "private". Any time data enters or leaves a data center, one should assume it is being monitored. Everyone knows that's the most basic tenet of security.

But all these lazy vendors from Google to Yahoo and Microsoft and hundreds of others have taken the easy, lazy way out for years.

You are assuming the NSA didn't "suggest" that the lines between data centers be in plain. Also there is no sane reason for the NSA to ever set foot in a yahoo data center. That would introduce a huge speed bump in their access to the data. Much better to just have a direct line in, with full root/admin access to everything.

I remember the paranoid rantings of those in the FreeS/WAN community back in the day (that's IPSec software for Linux fyi) about needing opportunistic encryption support and DNS based keys so any two hosts on the Internet could communicate securely and prevent Big Brother from listening.I also recall that I wished it would work, and set up my own hosts with it, but it never did work well and there just weren't enough participants to hit critical mass.Thirdly I remember a quote from my old BBS days... "Its

This is an issue with a wrench. You can have it encrypted 5 different ways, but when the NSA comes a knocking, DEMANDING The data, and your alternative is to get shut down, go to jail, etc... guess what, they key's become suddenly available anyway.

Its another type of brute force encryption hacking that always succeeds. The RIAA and MPAA figured this out (mostly) long ago when they realized that from a technical standpoint it is a no win situation. At