[tahoe-dev] a fundamental problem

[zooko]

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  
the files.

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  
answers are.)

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.

Regards,

Zooko