On Sun, 10 May 2009, Jerry Leichter wrote:
> 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 between new and old versions of files.
> Suppose, however, that I want to keep my backup "in the clo
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 pro
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.
---
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
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
On Tue, May 12, 2009 at 10:22 AM, Jerry Leichter 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.
> >
> >
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
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 cha
On Mon, May 11, 2009 at 2:54 PM, Jerry Leichter 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 data t
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 it'
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
On Tue, May 12, 2009 at 10:39 AM, Jerry Leichter 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 "comm
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 encrypt
To handle smaller inserts or deletes, you need to ensure that the
underlying blocks "get back into sync". The gzip technique I
mentioned earlier works. Keep a running cryptographically secure
checksum over the last blocksize bytes. When some condition on the
checksum is met - equals 0 mo
On May 11, 2009, at 5:13 PM, Victor Duchovni wrote:
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 cip
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
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 data then you'll reveal the plaintext.
Well, XOR of old a new plaintext.
On 1241996128 seconds since the Beginning of the UNIX epoch
Jerry Leichter wrote:
>
>So here we have it all: A new cryptographic mode, documented only in
>C code, being proposed for broad use with no analysis.
>
>In any case, there are obvious, well-understood solutions here: Use
>counter mo
On Sun, May 10, 2009 at 4:55 PM, Jerry Leichter wrote:
>
> 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---
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 b
20 matches
Mail list logo
