Re: metadata

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

Tom Metro wrote:

> Your comments above, as well as this:
>
>   --fk, --fr

...

> 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.

Yes and no. There is a need for richer metadata storage, and I'm working
on such a thing right now. I don't see how that stems fromt he sources
you point out, though.

> 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).

The symmetric key is all the information about the encryption procedure
(keys, parameters, etc.). The file itself is the data. I'm adding a
third location where file metadata is stored (file names, modification
dates, permissions etc.). I don't think it's necessary to break
backwards compatibility in order to store it inside the actual file.

> 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.

You obviously subscribed to the list after I put up the link to
http://cvs.sourceforge.net/viewcvs.py/rsyncrypto/rsyncrypto/docs/filelist.txt?view=markup.
That's the format I'll be storing the metadata.

> 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.

That's why I need to store the filenames in a seperate file. In 0.16 the
encrypted directory will be a series of files of equal length names
composed of a series of random characters (well, a base64 encoding of a
few random bytes, if you want the specifics). The translation will be
stored in a file called "filelist", which will be itself encrypted using
the usual rsyncrypto mechanisms. The specifics of said file are detailed
in the link above.

>  -Tom

          Shachar