Re: Encrypting / Decrypting with file name encryption

[Shachar S. <rsy...@sh...>]

Gerald Boersma wrote:

>Shachar:
>
>That worked! But I am still not quite there...
>  
>
Quoting the man page:

> --trim=num
>               Determine how many directory levels to trim from  the 
> beginning
>               of  the  srcdir path when creating directories under
> dstdir. The
>               default value is 1. See THE TRIM OPTION for more details.

And, also:

> THE TRIM OPTION
>        When running rsyncrypto in  recursive  mode,  the  directory 
> structure
>        under  srcdir  is  re-created under dstdir, with one directory
> stripped
>        from the path. In other words, if we have a directory 
> structure  which
>        has:
>
>        a/b/c/file
>
>        running  rsyncrypto with srcdir of "a/b", and dstdir of "f"
> will create
>        "f/b/c/file".
>
>        The --trim options lets the user say how many parts to trim
> from srcdir
>        when  creating  directories  under  dstdir and keydir. If, in
> the above
>        example, we said --trim=0 then "f/a/b/c/file" would have been 
> created.
>        Likewise,  if we said --trim=2 then "f/c/file" would have been
> created.
>
>        It is an error to give a trim value which is higher than the
> number  of
>        directory  parts  actually  in  srcdir.  In the above example,
> --trim=3
>        would result in an error.


>So now, along the same lines, I try the following to encrypt:
>
>rsyncrypto --name-encrypt=/home/gerald/backup/data.names -c
>--delete-keys -v -r
>--trim=2 /home/gerald/data /home/gerald/backup/files/data 
>/home/gerald/backup/keys/data /home/gerald/backup/backup.key
>  
>
As you obviously wish to have the destination directory
(/home/gerald/backup/files/data) encapsulate the fact that it is a
backup of the directory "data", it makes most sense to trim all
directory components. This means you would probably want a trim value of
"3" for such an operation.

I highly suggest you run the operation several times, with trim value
ranging from 0 to 3, and compare the "data.names" files created in the
process. This may greatly help you to understand the trim value. Also,
try the operation without the filename encryption.

In case of doubt - the data.names file can be easilly translated into a
standard text file by passing it through "tr '\0' '\n'" (without the
double quotes, but with the single quotes).

>Everything seems to encrypt fine; all files appear where I expect.
>
>I then try the following to decrypt:
>
>rsyncrypto --name-encrypt=/home/gerald/backup/data.names -c -v -r -d
>--trim=4 /home/gerald/backup/files/data /home/gerald 
>/home/gerald/backup/keys/data /home/gerald/backup/backup.key
>
>and I get the error:
>
>Filename translation not found(filemap): Success
>  
>
Right. Let's see what is going on here. You had files a, b and c under
/home/gerald/data. These were mangled and saved under
/home/gerald/backup/files/data/12378412983 (random set of bytes). Each
such byte is mapped to "data/a", "data/b" etc (i.e. - we trimmed the
"home" and the "gerald" parts, but not the "data" part).

Now, when you run the decrypt operation, you are asking to decrypt all
files under /home/gerald/backup/files. There are no such files!!!.
rsyncrypto is looking for its "filemap" file, and does not find it. If
you gave a trim value of 5 instead of 4, you would be looking under
/home/gerald/backup/files/data, and all files would have been there.

>These files are also placed in /home/gerald/data/data instead
>of /home/gerald/data.
>  
>
Let's recap. Total failure to restore is due to incorrect trim option on
decryption, which causes rsyncrypto to not find the file maps and to
search for the keys in the wrong place.

Correct restore with erronous paths at the begining of the restore point
are due to wrong trim value during encryption, which causes rsyncrypto
to save too much of the path under which the files were located. This
problem, at least, can be easilly fixed by manipulating the file names
translation file, which is almost textual (null terminated instead of
newline terminated).

I hope things are clearer now.

          Shachar

-- 
Shachar Shemesh
Lingnu Open Source Consulting ltd.
Have you backed up today's work? http://www.lingnu.com/backup.html