Re: Encrypting / Decrypting with file name encryption

[Gerald B. <ge...@le...>]

Shachar:

Okay, got it working now. Thanks for the explanation; makes sense. The
correct trim values seem especially important for name encryption.

Just curious: If name encryption is enabled, does --delete-keys and
--delete options work as expected (remove encrypted files from dest no
longer in src)?

Thanx,
Gerald

On Sat, 2006-14-01 at 23:28 +0200, Shachar Shemesh wrote:
> 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
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Rsyncrypto-devel mailing list
> Rsy...@li...
> https://lists.sourceforge.net/lists/listinfo/rsyncrypto-devel