Re: symmetric keys

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

Shachar Shemesh wrote:
> Tom Metro wrote:
>>I would expect keeping around a copy of the encrypted files to be a
>>win, and thus a popular approach among rsyncrypto users.
> 
> Huh? If storage is cheap compared to CPU, wouldn't keeping around an
> extra 60 bytes file be better than decrypting said file from within the
> big file better?

True.

Although if you compared two scenarios:

1. keeping they keys, but throwing away the encrypted files after each run;

and

2. keeping the encrypted files, but opting not to store the keys in 
external files;

I think #2 would be a big win. In most cases, the prior version of the 
encrypted file will be left untouched. Occasionally, when a file has 
changed, you'll need to decrypt the meta data in order to produce a new 
encrypted file, but decrypting a few kilobytes of meta data from a known 
location should be reasonably quick, as CPU time for 
decompression/compression is proportional to the data quantity.


>>...a user who is looking for a practical
>>(rather than maximum) security environment may choose to ignore the
>>symmetric keys (if there was an option to turn them off) and use a
>>single private key for all operations. I'd start with this as the
>>basic model for rsyncrypto, while continuing to support the more
>>complex approaches for those who desire the greater security.
> 
> Well, it's too late to "start with this as the basic model". Rsyncrypto
> is approaching it's 16th release. If you can come up with a way that
> will not change the meaning of all existing invocations, I'll gladly
> consider it.

I don't think I can, as what I'm proposing is to make an existing 
required parameter, which is interleaved among other parameters, optional.

If you feel the "API" is fixed, the best I can hope for is to get your 
approval for an option that would make storing symmetric keys optional. 
Which I could then combine with a wrapper script to present users with 
the most basic interface.

I think presenting the simplest UI is important, so the solution I'd 
rather see is making the built-in argument syntax follow the simplest 
model, and if necessary, use wrapper scripts to maintain backwards 
compatibility with existing lingnu.com backup users. But obviously it's 
your call.


> Bear in mind that rsyncrypto was designed to be a tool in the Lingnu
> online backup service (http://www.lingnu.com/backup.html). It is
> therefor that scenario that takes outmost precedence in allocating my
> personal time.

Understood.

  -Tom

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