Re: [rdiff-backup-users] Finding/designing a tar replacement

[Ben Escoto]

On Thu, 25 Sep 2003 11:39:00 -0500
Randall Nortman <address@hidden> wrote:
> dd if=/dev/random of=/path/to/image.dat bs=1M count=<xxx>
> losetup -e blowfish /dev/loop0 /path/to/image.dat
>    [You will be prompted for keysize and passphrase]
> mkreiserfs /dev/loop0
> mount -t reiserfs /dev/loop0 /mnt/backup-volume
> 
> If you encrypt in this way, you will not be able to determine file
> names, paths, sizes, or even the amount of the filesystem image that's
> actually used, unless you know the crypto algorithm used (blowfish in
> my example), the key size, and the passphrase.
> 
> The disadvantage of the filesystem-on-loopback methodology in general,
> as others have pointed out, is that the filesystem is created with a
> fixed size and resizing it is inconvenient.

I tried looking for some information on loopback filesystems on the
web, but nothing was at the right level of abstraction.  Do you know
if this is what is basically happening:  when a certain block is
requested, losetup retrieves that block from the file, decrypts it,
and then hands it over.

There is no trouble finding the block because encryption algorithms
don't do compression themselves, and the blocks lengths match up 1-1.
So the 5th encrypted block of 32kB is also the 5th plaintext block of
32kB.

However, once you add compression into the mix, the blocks no longer
match up 1-1, and you can no longer use a simple mapping like losetup.
Of course, you could write a compressed filesystem into the loopback
file, but it seems to me that encryption and compression should happen
at the same level (at the block level?).

Please correct any of the above, it is mostly speculation.

> Instead of actually using this method, you might consider simply
> being inspired by it, and make a filesystem-like archive format
> which is written directly to a file (without need of the loopback
> driver) with block-level encryption and automatic sizing of the
> file.  (Sounds like a disseration topic to me... Hmmm...)

Hopefully it won't be that complicated.  The format of tar and related
archives seems to be very simple, so coming up with a better format
shouldn't be that difficult. (?)  As for the filesystem part, if I
don't end up using an existing file system, I think it will be enough
that the format could in principle be used as a file system (someone
else can write the kernel driver).

Besides, I just finished one dissertation, so maybe I should get a job
before I start another...


-- 
Ben Escoto

pgpasKzcSdVmX.pgp
Description: PGP signature