[Box Backup] A few questions about BoxBackup
Ben Summers
boxbackup@fluffy.co.uk
Tue, 15 Feb 2005 16:47:52 +0000
On 15 Feb 2005, at 12:06, Gary wrote:
> Ben,
>
>> No. This would not do what you want anyway, because the keys to
>> decrypt the files are on the local machine. Therefore anyone with
>> sufficient access to the local machine would be able to download
>> the "encrypted" files. For someone on the local machine with access
>> to the keys (ie root or physical access to the box), the files on
>> the store should be considered in plaintext when evaluating security.
>
> That is correct, but I was thinking of backing up some files that I
> have on CD-ROMs, etc. to have a backup in case they are lost/damaged
> (without the requirement to keep them locally on hard drives). In any
> case, perhaps local key storage could be somewhat softened by using key
> challenge passwords?
Soon!
>
>> bbstored cannot recreate the files, because it does not have access
>> to the keys.
>
> Right. But it would be possible for the server to re-construct an
> encrypted file from rsync slices, md5 it, and send the signature back
> to the client. The client could re-entrypt that file locally, generate
> another md5, and compare it (without complete re-download).
That might work, yes. Depends on the compression always giving the same
results, so an upgrade of zlib could make your backups appear to fail.
>
>> What it does is simply send the encrypted checksums that
>> the client sent it the last time it was uploaded -- no processing is
>> done on the server. It will send one checksum per block in the file,
>> because that is the unit in which is it compressed and encrypted.
>
> Hmmmm, hmmmmm, so, if I understand correctly, for example block-level
> hard disk corruption on the server side (in encrypted data area) would
> not be detected by -aq, as only (last known) checksums are extracted
> from the store by bbstored? Also, should rsync slice implementation
> fail (imperfect reconstruction bug), -aq would not detect it either,
> right?
Correct. Which is why you should not use the -q option unless you need
to. Without it is much better.
>
>> * the load on the client and server
>> * the latency of your network link
>> * the usage of your network link -- is something uploading or
>
> As far as I can tell there is nothing going on on client/server, nor on
> the network link, but I will keep looking into this.
Thanks.
Ben