I believe that mode has been renamed EME2 because people were having a
fit over the *.
On May 14, 2009, at 12:37 AM, Jon Callas wrote:
I'd use a tweakable mode like EME-star (also EME*) that is designed
for something like this. It would also work with 512-byte blocks.
For what it is worth, in the Tahoe-LAFS project [1] we simply use CTR
mode and a unique key for each file. Details: [2]
Tahoe-LAFS itself doesn't do any deltas, compression, etc., but there
are two projects layered atop Tahoe to add such features -- a plugin
for duplicity [3] and a new
On May 11, 2009, at 7:06 PM, silky wrote:
How about this.
When you modify a file, the backup system attempts to see if it can
summarise your modifications into a file that is, say, less then 50%
of the file size.
So if you modify a 10kb text file and change only the first word, it
will
On Tue, May 12, 2009 at 10:39 AM, Jerry Leichter leich...@lrw.com wrote:
On May 11, 2009, at 8:27 PM, silky wrote:
The local version needs access to the last committed file (to compare
the changes) and the server version only keeps the 'base' file and the
'changes' subsets.
a) What's a
On May 11, 2009, at 7:08 PM, Matt Ball wrote:
Practically, to make this work, you'd want to look at the solutions
that support 'data deduplication' (see
http://en.wikipedia.org/wiki/Data_deduplication). These techniques
typically break the data into variable length 'chunks', and
de-duplicate by
How about this.
When you modify a file, the backup system attempts to see if it can
summarise your modifications into a file that is, say, less then 50%
of the file size.
So if you modify a 10kb text file and change only the first word, it
will encrypt that component (the word you changed) on
On Mon, May 11, 2009 at 2:54 PM, Jerry Leichter leich...@lrw.com wrote:
On May 11, 2009, at 2:16 PM, Roland Dowdeswell wrote:
On 1241996128 seconds since the Beginning of the UNIX epoch
Jerry Leichter wrote:
I'm not convinced that a stream cipher is appropriate here because
if you change the
Jerry Leichter wrote:
Consider first just updates. Then you have exactly the same problem as
for disk encryption: You want to limit the changes needed in the
encrypted image to more or less the size of the change to the underlying
data. Generally, we assume that the size of the encrypted
Jerry Leichter wrote:
To support insertions or deletions of full blocks, you can't make the
block encryption depend on the block position in the file, since that's
subject to change. For a disk encryptor that can't add data to the
file, that's a killer; for an rsync pre-processor, it's no big
On Tue, May 12, 2009 at 10:22 AM, Jerry Leichter leich...@lrw.com wrote:
On May 11, 2009, at 7:06 PM, silky wrote:
How about this.
When you modify a file, the backup system attempts to see if it can
summarise your modifications into a file that is, say, less then 50%
of the file size.
On May 11, 2009, at 8:27 PM, silky wrote:
The local version needs access to the last committed file (to compare
the changes) and the server version only keeps the 'base' file and the
'changes' subsets.
a) What's a committed file.
b) As in my response to Victor's message, note that you can't
I'd use a tweakable mode like EME-star (also EME*) that is designed
for something like this. It would also work with 512-byte blocks.
Jon
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography
I recently stumbled across two attempts to solve a cryptographic
problem - which has lead to what look like rather unfortunate solutions.
The problem has to do with using rsync to maintain backups of
directories. rsync tries to transfer a minimum of data by sending
only the differences
On Mon, May 11, 2009 at 02:16:45PM -0400, Roland Dowdeswell wrote:
In any case, there are obvious, well-understood solutions here: Use
counter mode, which propagates changes by a single block of the
cryptosystem. Or use any other stream cipher mode. (An interesting
question is
14 matches
Mail list logo
