encryption is not gravy
benlog.com
benlog.com
There are lots of technical issues with just slapping some crypto on to an existing service. User management of passwords/keys seems trivial compared to these problems.
That's not how it works.
People didn't leave Hotmail because the "educated" left, they left it because Google gave several GBs for free, the interface was simpler, the search better and MS was out of fashion.
If you're not a large market you don't get a service, or you only get niche vendors to cater to you. You can bypass this by setting trends for the "uneducated" (whatever that means), else we will all be using Lisp Machines or Smalltalk environments.
Privacy is becoming a large problem in the internet and encryption will likely be part of the solution. Without encryption, the ownership of data is on the service provider instead of the person.
Privacy is a feature just like free storage. One day, privacy can be available to the masses just like storage is today. (also think back how many people actually wanted or needed multiple gb of free storage for their emails until one was provided by a service like gmail)
The BIGGEST deepest pockets would pay handsomely for this.
That is to say, you can't be sure. However, Dropbox is a company in good legal standing, and they have a lot to lose if they offered client side encryption and then leaked the passphrase.
Spideroak (definitely) and Backblaze (I think?) already have client software which offers client side encryption. Whether you trust them is up to you.
The product is in beta right now but I'd love some more people to try it out. If you sign up at http://safeboxapp.com, you'll get a download link to try it out.
How does it compare to BoxCryptor where you can also access your files using EncFS?
Please tell me you are sending out invites today.
I'm sure the rync delta transfer algorithm still works fine with encrypted files, but the changes for encrypted files are going to be calculated as 100% so you're not going to save anything.
You'd still need to pull it all down and apply the deltas each time you put it somewhere new, but it would work. Possibly with a 'full version' on some longer schedule. As a bonus, you'd get automatic history, which Dropbox stores anyway.
It's still got issues, no doubt, but it could be done, no?
There is also a project called ddar, which is designed to provide merely the de-duplication of tarsnap so you can setup your own repository (tarsnap only works with its service).
I don't think this is necessarily the case with all encryption mechanisms.
I'd be very surprised if this were patentable. The same basic technique was mentioned offhand in literature as early as 2003 (http://static.usenix.org/events/hotos03/tech/full_papers/mis...), and I suspect the idea's even older.
I'd love to know how they are doing it, though. I'm not sure I believe there is a way to do it that doesn't allow Bitcasa to read the file (at least not one using well-researched encryption technologies). It seems like they are likely using your key as a key encryption key for the actual key to the file, but for that to work, they have to be able to tell you the real encryption key, which means they have access to the contents.
I'd love to be proven wrong, though, because we could use it. :)
All alternatives would be reasons to politely decline taking part. So IF there will be compromises in the future for the scenario where users cannot back up their own key, I do hope that the current behavior will always be a viable option either. I'd rather risk losing my data through my own stupidity (been there, often enough) than pushing my browsing history (potentially sensitive) or even passwords (..) to a random service on the net.
http://lists.canonical.org/pipermail/kragen-hacks/2012-April... demonstrates encoding an 80-bit random number (which is plenty secure with a reasonable key derivation function) as each of "point pleased intense de maybe fairly arms", "bejuso jejigi nububi bidoda gahano", "ADD DOTE BID HILT LAUD MAIN CALF CITY", and "仴薦肨縨猯鹽", any of which is eminently practical to memorize. I use this program to generate my login passwords these days.
(80 bits is not enough for a key for something like AES, because you can try a lot of different keys per second. It's plenty if you have a decent key derivation function to add a 25–35-bit work factor.)
This is different from a user-chosen password because users are often highly predictable in their password choice.
https://wiki.mozilla.org/Identity/CryptoIdeas/01-PBKDF-scryp...
But unless you have a crazy long passphrase, you're not going to get 128 bits, let alone 256.
As I explained in a late edit to my comment, this is distinct from your "password-derived key" case because it eliminates the major drawback of that case: "This is not as secure as the previous setting, since most user passwords are not nearly as strong as full-strength crypto keys." If you generate high-entropy passphrases, that problem goes away.
128 bits is overkill for defense against brute force. You can do maybe 2³⁰ crypto operations per second in a custom crypto-cracking processor, pack maybe 2²⁰ of them onto a custom chip, use maybe 2²⁰ custom chips in your Crypto Cracking Center in your evil genius volcano base, and let it run for maybe a year, 2²⁵ seconds, before you get bored. That's still only enough to search 2⁹⁵ keys, so you should be pretty safe with keys that need 2¹⁰⁰ operations to crack, at least for a few years. Or, if you don't have a supervillain or major intelligence agency devoting their full computational resources to reading your browser bookmarks, 2⁸⁰.
I do think it's actually feasible for someone to memorize an 11-word phrase encoding a 128-bit key, but it would take several minutes and careful practice over the next few weeks to be sure they didn't forget it, and using a decent PBKDF with a 7- or 8-word passphrase is probably a better option.
Seems like a good idea: If you forget your passphrase, you can recover your data with this.
This is only the case because the car company is sitting on a database of everyone's keys. It amounts to server-side security. If a security professional were designing a "secure" car, they would demand one which is truly bricked if you lose the keys.
I expect that part of the issue with cryptography is explaining to users why their data needs to be more secure than their car.
It really comes down to two options: take care of your key by yourself, have best security and highest risk of loss or share your key with somebody else, reduce your security, and have a fallback against key loss.
My company is working on easy-to-use security. One of the things we are looking at is a middle-ground using key-splitting algorithms to give you very nearly as much security as the first with the fallback of the second.