[Tom Widmer]
> If I understand you correctly, I have a feeling that this is
> fundamentally a bad idea, since Subversion stores data using diffs.
Actually binary deltas (and yes, it makes a difference in context).
> Since encrypted data looks identical to random binary data, all diffs
> will necessarily be as large as the file being committed (or 2x the
> size possibly: 1x to remove the old file + 1x to add the new file).
Not _quite_. Block ciphers operate on fixed blocks (hence the name),
of typically 8 or 16 bytes. Depending on the mode, each block may be
encrypted independently of its neighbors, one IV per block, or the IV
may be reset after a given number of blocks (often used for whole-disk
encryption, for example, to avoid rewriting too many disk blocks on
updates). Thus, if you're storing fixed-size records, such that any
changes will not alter the offsets of your unchanged data, then the
delta of the encrypted data will be bounded on both sides, though still
larger than that of the unencrypted data.
Of course, in the general case, Subversion is used for variable-length
records (line-oriented text), and offsets of unchanged regions _do_
change. And then, Tom is correct: the delta of the encrypted stream
will extend from the first change all the way to the end of the file,
and any storage mechanism (including a Subversion server) that does not
have access to plaintext will not be very efficient.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
Received on 2011-07-26 19:48:56 CEST