[tahoe-dev] usage of key file or smart card?

[David-Sarah Hopwood]

The post that I was correcting bounced because I sent it from an
address that wasn't subscribed. Here it is with the correction included.

====
Kevin Reid wrote:
> > On Nov 23, 2009, at 16:43, Stefan Xenon wrote:
> >
>> >> How can a user configure if to use a per-file encryption or
>> >> convergent encryption?

As far as I can see, there is currently no user interface to configure
this: immutable files always use convergent encryption (content-hash-keys).

The bug ticket to allow selecting this from the web interface and
command-line interface is <http://allmydata.org/trac/tahoe/ticket/294>.

> > Convergent encryption is used, by definition, for immutable files --
> > the cap identifies the particular file content.

That isn't true by definition; there are internal APIs that would
allow using random keys for immutable files (see
<http://allmydata.org/trac/tahoe/ticket/293>).

The security guarantee is only that a given cap consistently refers to
a particular file content. Convergent encryption also ensures that
there is a *unique* cap for a given file content and convergence secret.
That is a space optimization, rather than being characteristic of
immutable files.

> > Encryption with a generated keypair is used, by definition, for
> > mutable files -- the read-cap contains the public key, and the write-
> > cap contains the private key.

Note that it's a signature keypair, not an encryption keypair.
The encryption uses a symmetric key derived from the public key and an
encrypted salt. If you know the symmetric key, then you aren't prevented
from encrypting with it, but without the private key you are unable to
sign a new version of the file that will be accepted by other readers.

> > As a matter of current usage, note that most "file" files are stored
> > as immutable files. Currently, directories (which are also files) are
> > always mutable files (i.e. entries can be added and removed) but there
> > is current work on adding immutable directories.
> >
>> >> AFAIK the key is included in the cap. With per-file encryption does
>> >> the user need to note the cap for each file? How does this work for
>> >> a backup scenario where the user also needs to backup the keys
>> >> (separately) but which is not possible if the amount of keys depends
>> >> on the amount of files?
> >
> > The caps to the backed up files are stored in the directories. You
> > only need to keep a cap to the root of your backup directory tree.

Yes. Another reason to do that is to take account of garbage collection:
it is possible to keep caps for individual files without putting them in
a directory tree, but then you would need to renew leases on them to
prevent them from being garbage-collected. If they are in a directory
tree, then you only need to renew a lease on the root.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 292 bytes
Desc: OpenPGP digital signature
Url : http://allmydata.org/pipermail/tahoe-dev/attachments/20091124/7581a121/attachment.pgp