"Iraklis ." <[email protected]> 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.
pgpTwFjb3qAJ7.pgp
Description: PGP signature
_______________________________________________ tahoe-dev mailing list [email protected] https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
