Re: metadata

[Tom M. <tme...@vl...>]

Shachar Shemesh wrote:
> If the third argument is a name of a non-existing file, then 
> rsyncrypto assumes that this is the first time such a file is 
> encrypted, and will create the symmetric key file. This is so that 
> future encryption will be able to use the same encryption parameters, 
> and thus create a file that is similar.
> [...]
> Now let's talk about decryption. One is "warm restore", where you 
> still have the symmetric key file for the file you are trying to 
> decrypt. If that's the case, you still need to provide the (RSA 
> assymetric) public key. This is mostly for the technical reason that 
> rsyncrypto needs to know how big the encrypted symmetric key is in the 
> file, and this depends on the size of the public key. We could save it 
> in the unencrypted key, but as you should never ever lose the private 
> key, much less the public key, this did not seem like a big enough 
> trouble to justify the extra work. Also, this gives rsyncrypto a 
> consistant command line across all invocations.

Your comments above, as well as this:

   --fk, --fr
     If command line, or a version with different  defaults,  dictate
     different  values  for  the  --roll-*  options or the -b option,
     these will only affect files for  which  keyfile  does  not  yet
     exist.  specifying  the --fk or --fr will recreate keyfile if it
     has values different than those in the previous key file.

from the man page, plus your comments about storing encrypted file 
names, suggests that there is a need for richer meta data storage in the 
destination file.

It also suggests that the symmetric key files really want to be more 
than just keys, but instead a collection of meta data needed to 
reproduce an identical encrypted file (if the source data doesn't change).

Have you looked at any existing schemes for storing file meta data, such 
as zip or gzip file headers? There may be value in co-opting one of those.

Another issue to consider is how much, if any, of the meta data should 
be encrypted (when part of the destination file)? Even though requiring 
the private key in order to access it may be inconvenient, probably 
makes sense to encrypt everything.

  -Tom

-- 
Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: https://www.linkedin.com/e/fps/3452158/