Von: Peter Samuelson [mailto:peter_at_p12n.org]
> [Tom Widmer]
> > Since encrypted data looks identical to random binary data, all
> > 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),
> 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
> 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
> of the encrypted data will be bounded on both sides, though still
> 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
> extend from the first change all the way to the end of the file, and
> storage mechanism (including a Subversion server) that does not have
> access to plaintext will not be very efficient.
Maybe even this behaviour is considered a potential information leak
(the position of the first change may already be sensitive information),
and each file is re-encrypted with a different random IV (which is
prepended to the file) on each change.
This is the safest way, but also very inefficient because diff cannot
optimize at all.
Security always has a price...
We software Automation.
3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 |
Email: email@example.com | Web: http://www.3s-software.com
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects:
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner |
Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
Received on 2011-07-27 15:59:40 CEST