Comment Re:Simple, politically incorrect solution (Score 1) 138
Depends on what kind of LongBow you mean.
Depends on what kind of LongBow you mean.
Hey, look: a bell curve!
Well, except for the bump at "100 bpm or greater". I didn't realize so many squirrels read slashdot.
It has a decent UI
Really? Why Johnny Can't Encrypt: A Usability Evaluation of PGP 5.0. Yeah, it was a while ago and some things have improved, but most of the issues remain and I doubt another focus group study would find significantly different results.
The problem is that designing a UI that makes it easy for people who don't know anything about cryptography or security to achieve useful cryptographic security is really, really hard. Almost as hard as educating everyone about cryptography and security enough that they can achieve useful cryptographic security with PGP.
If this technology matures to the point that it's stable on every desktop OS, then the OS is reduced is reduced to simply being a platform
Java did that years ago. Notice how it destroyed Microsoft?
Android security team, eh? Are you the guy who thinks that my phone implicitly trusting the Chinese government, Turktrust, et al is perfectly reasonable, while at the same that constantly complaining about my own personally verified CA is "WorkingAsIntended"?
No.
Still seems more "cute" than "cool".
It's actually really convenient. You'd have to try it to see just how smooth it is. Much easier than the "share" button.
I know everybody talks about encryption, but the word itself is just the tip of security. What's the key size? What's the algorithm?
It uses Linux dm_crypt. Here's the source code that configures it, and protects the dm_crypt master key: https://android.googlesource.c...
What data is encrpyted?
The
Most of the rest of your post is speculation assuming that Google is intensively mining everything backed up. I'm quite certain that's not true, but I probably shouldn't comment in more detail.
The only thing it will do is keep your private information out of the hands of someone who picked up your lost phone and decided to keep it (or sell it).
Yes, that's what device encryption is for.
(Disclaimer: I'm an Android security engineer. I'm speaking for myself, not for Google.)
You need your head read. Google has shown time and again that it does not care about your security. There is no need to trade off convenience for security in cloud backup. Encrypt locally and send the data encrypted to backup. This would be great but i bet that Google also holds they keys and decrypts on their end. Google says it wouldn't be able to use your data for their massive data mining and information theft machine if it were properly encrypted. This is why the data sits on their servers unprotected by encryption, they are the antithesis of your guardians of security. If you value your data, turn off all Google services and manage your own backups.
There are two different threat models to consider. Device encryption protects against one, but not the other.
The purpose of device encryption is to protect your data from someone who obtains physical possession of it, because it was lost, stolen, confiscated, etc. The goal really isn't so much to protect it from law enforcement or the NSA -- if the NSA is interested in your data, they'll get it, period -- but against people who might want to, for example, steal your bank account information, etc.
Device encryption obviously does nothing to keep your data secret from someone you actively send the data to. If you have Google's backup services enabled on your phone, then it will back up a bunch of stuff. I don't know everything that's backed up, but I think Wifi configuration is, your list of apps are, the list of accounts on your phone, your contacts, and similar. Separately from device backup, you can also have the Google+ app upload your photos and videos automatically, and you can also configure the device to report your location, in various ways and for various services (there are several controls). Whatever you have backed up is (a) not protected by device encryption and (b) cannot be secure from whoever you backed it up to unless you have some sort of encryption key which the holder does not.
It's also clear that anything that is stored by Google and which isn't encrypted with some key not available to Google is also accessible to the US government and local law enforcement, assuming they have the legal right to demand it from Google. Device encryption does not do anything to defend against that. This is all obvious and not in dispute. It also doesn't make device encryption worthless, it just means that it defends against different threat.
Also, I have to say that from my perspective as a security engineer at Google you couldn't be more wrong about Google's concern for user security. Actually, if you look at the company's track record on security technology creation and deployment, I think that point is unarguable. Perhaps what you really meant to say is that Google doesn't care about your privacy, which is different from (but connected to) security. From my perspective, I think that's also wrong. It seems to me that what Google wants to do is to get your permission to make a trade, your data for targeted advertising in exchange for Google's services, and if you don't want that trade, Google wants to enable you to opt out of it (hence all of the opt out tools, privacy dashboard, etc.). Obviously, if Google is not careful to protect users' privacy, no one will be willing to make that trade, so Google is very, very careful.
(Disclaimer: I'm a Google engineer, but I'm speaking for myself, not in an official capacity.)
Google has pointed out that Android already offers the same feature as a user option and that the next version will enable it by default.
Why isn't it already the default setting?
(Android Security Team member here... though these are my own perceptions and opinions, not an official statement.)
Two reasons:
First, because it's not completely trivial to make it work correctly, all the time, every time, on hundreds of different devices. Android uses dm_crypt, so the foundation is solid, well-proven code, but that doesn't mean there aren't tricky corner cases. With the huge number and variety of Android devices out there, you can be certain that if there's a way it can go wrong, it will. So, conservatism suggests it's a good idea to make it optional for a while and shake out any issues. It's been optional for three years now, and is in use on many devices (I don't know how many; I'd guess tens of millions, though), so it's time to take the next step.
Second, performance was a problem. Not run-time performance -- AES is really fast -- but the initial encryption required reading and writing many gigabytes so it took a long time just to do that much I/O. Encrypting by default means that either the device has to be encrypted in the factory, which would be a major production bottleneck, or else users would have to wait 20 minutes for their phone/tablet to start up just after they unbox it. That's a bad user experience. For L this was optimized so it only encrypts blocks that are in use. Since on a new device very little of the data partition is in use, very little has to be encrypted. That makes the initial encryption very fast (a few seconds).
There's actually another device encryption-related improvement coming in L. I'd love to describe it in detail since I worked on parts of it, but the article doesn't mention it so I'll hold off.
What is algebra, exactly? Is it one of those three-cornered things? -- J.M. Barrie