Re: [rdiff-backup-users] Pretty pictures and new version of proposal

[Kevin Spicer]

On Mon, 2003-09-29 at 20:25, Ben Escoto wrote:

> Well, if something like gnupg is used, it already gives you the option
> of signing (as well as encrypting) input data, so this method could be
> used on all of the blocks.  Similarly, I think gzip puts some CRC
> check by default into its output.  So I think bits getting flipped
> will be noticed pretty early.
> 
> However, the format is pretty fragile if a block becomes too long or
> too short.  That would mess up all the lengths and could make the rest
> of the archive unreadable.  However, other formats like tar don't seem
> to be robust in this way either, and maybe those kinds of errors don't
> happen very much (?).

Only on vital archives, on the day someone types rm -rf * ;)

I think in situations like that the best effort approach is ideal, the
ability to restore at least up to the error is important.  If I lost a
disk and could restore all but the last few blocks of an archive, with
the confidence that each block that was restored had been
cryptographically signed and was intact I'd be a lot happier than if I
couldn't restore any of it - or could restore the same amount, but not
know if it was intact.
Not signing individual blocks also opens up an avenue of attack, an
attacker could make changes to the archive, then corrupt the final
single signature  (so that anyone attempting a restore is between a rock
and a hard place - either restore data of unknown soundness, or don't
restore).  Admittedly this is very unlikely to happen in practice, but
could be considered a weakness.

On non stream based restores it would be possible to find the index and
seek backwards from the index to find blocks after the corrupted one. 
To achieve this the index pointer at the end of the file should give an
offset from the end of file (rather than start of file) for index
position and the index should also reference its own position from start
of file (recorded_index_start_position).
These two pieces of information would permit any file to be found from
in two ways...
a) From the index entry as an offset from the start of file
(file_start_position).
b) Seek back (recorded_index_start_position - file_start_position) from
index_start_position.







BMRB International 
http://www.bmrb.co.uk
+44 (0)20 8566 5000
_________________________________________________________________
This message (and any attachment) is intended only for the 
recipient and may contain confidential and/or privileged 
material.  If you have received this in error, please contact the 
sender and delete this message immediately.  Disclosure, copying 
or other action taken in respect of this email or in 
reliance on it is prohibited.  BMRB International Limited 
accepts no liability in relation to any personal emails, or 
content of any email which does not directly relate to our 
business.