[tahoe-dev] a fundamental problem
zooko at zooko.com
Tue Sep 18 17:56:28 UTC 2007
Niels Ferguson wrote:
> they do they become a subpoena target which can be expensive and
> threaten the company's reputation. If they don't have access to the
> encryption key it is hard to ensure availability of the backup.
> That is a hard choice to make.
On Sep 14, 2007, at 1:23 AM, Andy Green wrote:
> It's not a hard choice at all, it's freaking obvious.
I think that Niels was right -- it is a hard choice to make. Many of
the users of a commercial backup service expect that if their hard
drive crashes *and* they have long since forgotten their password,
that the company whose services they have hired will still retrieve
their data for them. Forgetting your password and having it returned
to you by the service provider is the standard way that things are
done nowadays -- observe banks, web-based e-mail, social sites, etc..
We could, of course, simply exclude those people from using our
product, but this would potentially put us out of business, and
anyway it wouldn't be doing those people any favors anyway, would
it? Presumably they would just go ahead and store their data with
one of the numerous other backup companies that will provide recovery
for them even if they forget their key.
So what can we do?
1. We can offer, as Mozy does, the option of sending the key to us
or keeping it to yourself.
2. We can extend that, as Peter mentioned, to offering the option of
sending the key to someone *else*. Perhaps you trust Allmydata, Inc.
to maintain the network and the software that makes sure that the
ciphertext is available, but you trust someone else (your lawyer,
maybe?) to hold the decryption key.
3. We can further extend that by using secret sharing to make it so
that there are multiple people who hold shares of the key, and some
combination of them (e.g. two out of three) is necessary to recover
4. We can "solve the password problem" by developing a new
technology that allows people to authenticate themselves without
having to remember a password.
For example, you know the "security questions" that some banks ask
sometimes? Suppose you hashed your answers together to produce a
password. Then you wouldn't have to remember a password, you would
only have to remember the answers to the security questions.
(Obviously the questions used by banks would be poor choices for this
technique, as someone other than you can often figure out what your
Or here's another idea: present four photographs to the user and ask
them to select their favorite one. They've now produced two bits of
information, and they will probably be able to reproduce the same two
bits later. Iterate that process to generate enough bits of
information to make a good key.
In all of these options (not just number 4!) usability/customer
relations is the hard part.
More information about the tahoe-dev