[tahoe-dev] proposal: add padding

[Greg Troxel]

"Iraklis ." <leontiad at gmail.com> writes:

> That would destroy any dedup service if different random bytes are
> appended. Even if the same number of random bytes are appended for
> equivalent encryption keys. Or i am missing sth?

[top-posting repaired by trimming!]

That's an excellent point.

Besides that, I think I'd want padding to be optional, unless it's small
(a few % on most/(all?) usage patterns).

When hiding the file structure is desired, people tend to use systems
like TrueCrypt, NetBSD's cgd, where a large file is treated as a virtual
disk and entirely encrypted, metadata and all.  Or WDE, which is this
approach taken to the limit.  But, these schemes don't interact well
with backups (because "the file" has changed), or usage over a network.

cfs, on the other hand, does not hide file structure (beyond padding to a
cipherblock size, I think), and as a result backing up the ciphertext
has properties similar to backing up the plaintext in terms of being
able to use dump(8) incrementally, which is good for effeciency and bad
for hiding the directory and file structure.


So I think before we add padding as a non-experimental features, we need

  a paper analyzing the block-level-crypto vs encrypted files trade
  space, and discussing the understand-file-size threat model

  a discussion of the threat model.  While it's easy to say "it would be
  nice if an attacker couldn't understand file structure", if we really
  mean "someone should not be able to guess if you are storing MP3s",
  that's something else, and not fixed by padding to multiple of 512
  bytes.


It's possible tahoe should be left as is, and a higher-level "structure
confidentiality" system map arbitrary files wtih a particular layout to
a collection of fixed-size files with a database organization.   That's
almost like FFS, but perhaps optimized for the back-end properites.

Alternatively, one could look at things like bup, which do splitting
based on rolling checksums and hash-level dedup.  By using bup and
storing in tahoe, one probably gets most of the desired properties.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20130709/655f1dd4/attachment.pgp>