Warning! New cryptographic modes!

silky michaelslists at gmail.com
Mon May 11 20:27:25 EDT 2009


On Tue, May 12, 2009 at 10:22 AM, Jerry Leichter <leichter at 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.
> >
> > 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's own, and
> > upload that seperate to the file. On the other end, it will have a
> > system to merging these changes when a file is "decrypted". It will
> > actually be prepared and decrypted (so all operations of this nature
> > must be done *within* the system).
> >
> > Then, when it reaches a critical point in file changes, it can just
> > upload the entire file new again, and replace it's "base" copy and all
> > the "parts".
> >
> > Slightly more difficult with binary files where the changes are spread
> > out over the file, but if these changes can still be "summarised"
> > relatively trivially, it should work.
>
> To do this, the backup system needs access to both the old and new version
> of the file.  rsync does, because it is inherently sync'ing two copies,
> usually on two different systems, and we're doing this exactly because we
> *want* that second copy.

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.

So yes, it does increase the amount of space required locally (not a
lot though, unless you are changing often and not committing), and
will also increase the amount of space required on the server by 50%,
but you need pay the cost somewhere, and I think disk space is surely
the cheapest cost to pay.


> If you want the delta computation to be done locally, you need two local
> copies of the file - doubling your disk requirements.  In principle, you
> could do this only at file close time, so that you'd only need such a copy
> for files that are currently being written or backed up.  What happens if
> the system crashes after it's updated but before you can back it up?  Do you
> need full data logging?

I think this is resolved by saving only the last committed.


> Victor Duchovni suggested using snapshots, which also give you the effect of
> a local copy - but sliced differently, as it were, into blocks written to
> the file system over some defined period of time.  Very useful, but both it
> and any other mechanism must sometimes deal with worst cases - an erase of
> the whole disk, for example; or a single file that fills all or most of the
> disk.
>
>                                                        -- Jerry

-- 
noon silky

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list