Warning! New cryptographic modes!

[Jerry Leichter]

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.

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?

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


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