encryption is not gravy

There are many other issues with adding encryption to an existing service. Take Dropbox as an example. If Dropbox allowed each user to manage their own private/public key pair, then Dropbox wouldn't be able to see any of your data, and this couldn't use de-duplication. This means they need to actually allocate 2GB for every free user; no longer could they count on multiple users uploading the same files. Dropbox would have no way of knowing. Additionally, every minor change to a file would result in the entire file needing to be re-uploaded. The "previous versions" of each file would need to be re-worked, etc.<p>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.

For me, the fact that my data is inaccessible on the server is the single most interesting fact about that sync product.<p>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.

While I agree with most of this article, Adida says that a "full-strength, randomly generated, user-managed key" implies that "Enabling a new device requires coordination with an existing device". This is <i>typically</i> the case with current systems, but it is not <i>necessarily</i> the case. It is eminently practical for a human being to memorize an xkcd password with enough entropy to resist brute-force attacks into the foreseeable future.<p><a href="http://lists.canonical.org/pipermail/kragen-hacks/2012-April/000538.html" rel="nofollow">http://lists.canonical.org/pipermail/kragen-hacks/2012-April...</a> 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.<p>(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.)<p>This is different from a user-chosen password because users are often highly predictable in their password choice.

If you install Ubuntu with home folder encryption, it gives you the "unravelled" encryption key for you to write down somewhere.<p>Seems like a good idea: If you forget your passphrase, you can recover your data with this.

&#62; The most expensive cars have unlocking fallbacks.<p>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.<p>I expect that part of the issue with cryptography is explaining to users why their data needs to be <i>more</i> secure than their car.

I wonder if you could set up a "key server". It would be like an online safety deposit box for your key. That way, no matter what computer you're on, you can access the keyserver and authenticate yourself, and it would recover your key.

"Every feature is someone else's bug."