Re: symmetric keys

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

Shachar Shemesh wrote:
> Not storing a symmetric key would mean that you have to provide both a
> private key (rather than a public key today) and a previously encrypted
> file (the whole size of the file, rather than just 60 or so bytes)
> during encryption. Right now, you have very little state to store
> between encryptions...

Ah, this is a critical bit of rsyncrypto "philosophy" that I was 
missing. I ran across mention of this concept - needing only a small 
amount of state information - (though I don't see it in the guide, the 
man page, or the email I was quoting from) but it didn't add up at the time.

So this explains why key files exist as separate files. The idea is that 
you encrypt a batch of files, rsync the encrypted files to some remote 
location, then you have the option of blowing away the encrypted files - 
treating them essentially as temporary files. Subsequent encryption runs 
  then make use of your key files to produce new encrypted files that 
are minimally changed from the previous encryption cycle.

The reason why this logic wasn't apparent to me initially is that in my 
mind I was planning on keeping the encrypted files locally, so the keys 
are simply redundant.

If we presume that change is infrequent among the file set (reasonably 
safe, otherwise rsync wouldn't be an advantage) and that storage is 
probably a less limited resource than CPU in many cases, I would expect 
keeping around a copy of the encrypted files to be a win, and thus a 
popular approach among rsyncrypto users.

You must have been thinking along these lines as well, as you have a -c 
switch that skips encrypting files that haven't changed. (Have you 
considered optionally using MD5/SHA hashes instead of relying on 
timestamps?)

(In an ideal scenario, you'd have encryption hardware, and you could 
simply patch rsync to perform its differencing against an encrypted 
version of the source file in memory. That plus a bit of meta data 
stored in the file system to make it easier to determine which files 
have changed, ought to do it. But back to reality...)


> The third argument...the symmetric AES key...[is used] so that repeated
> encryption of the same file will be possible with minimal changes to the
> file. It will do our rsync friendliness no good to re-encrypt a file
> with a different key.

Right, another important point. As I was playing around with rsyncrypto 
repeatedly encrypting the same file I noticed a different key was 
generated each time. That made me wonder how changes could be minimized 
in the crypt text, but before I followed through on that thought, I went 
on to other things. Of course the answer, as you point out, is that if 
the key already exists, it's used for all subsequent encryptions of that 
file, thus keeping the crypt text deterministic.

This might also be thought of as a justification for having separate key 
files, but the key files can be extracted from the encrypted files in 
cases where the user is keeping them on hand.

Although, that then means...

> In the case of a total loss of all files, it is assumed you will still
> have the private key. ... The fourth argument in such a case MUST be the
> private key, as we will need to open the RSA encryption of the symmetric
> key inside the encrypted file.

...you need to have the private key on hand, even when encrypting, just 
so you can extract the symmetric key. This leads to your point:

> ...it allows us to not store the RSA private key, which is sensitive
> information, on the machine that does the encryption.

Hmmm...is keeping the private key "private" really an advantage, given 
the way rsyncrypto works?

Conceptually, this sounds appealing. I could see, for example, not 
wanting to have my private key be sitting on a shared web server that I 
might be rsyncing encrypted files from.

Lets consider some scenarios:

Lets assume on the machine doing the encryption, I only have the public 
key, and that machine gets compromised. As an attacker, what are my 
options? I can 1. use the symmetric keys, which rsyncrypto currently 
encourages me to keep on hand, and decrypt the files, or 2. I can look 
at the plain text of the original files, because they exist on the 
machine doing the encryption.

If some intermediary machine is compromised, say the machine where the 
encrypted files are archived, having the private key on the encryption 
machine hasn't altered the situation.

Sure, you could come up with a scenario where the encryption machine is 
like an appliance and only momentarily stores the plain text and key 
files before discarding them, but that doesn't seem to describe typical 
usage.

And no doubt that the private key is more valuable, in that it acts like 
a master key to unlock all your files. But practically speaking I don't 
think keeping the private key any more secure than the original plain 
text is buying you added security, and the "master key" nature can be 
mitigated by using different private keys for each collection of files.

A typical PKI scenario - where one party might be less trusted and can 
only encrypt using the public key - doesn't really fit rsyncrypto, as 
the party doing the encryption only needs the symmetric keys to be able 
to extract the plain text, and rsyncrypto gives them the keys (which 
they are then free to distribute to third parties). Of course the 
encrypting party also has access to the plain text. PKI is more about 
authentication than data protection.


> ...the public key can be built from the private key, when encrypting
> either the private or the public RSA key can be given as afourth argument.

Even better. So that means 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.


> I'm afraid you slightly misunderstood the remaining two
> arguments, which is why you think only one of them is required at every
> given point.

I'm not sure it's a misunderstanding so much as a different perspective. 
  If what I've discussed above is correct, then it does seem possible to 
eliminate the key files.


>>Have you considered having generation of the key files being optional
>>and only enabled if a switch is specified?
> 
> I have now, and rejected the notion :-). Feel free to try and convince
> me based on the newly gained knowledge.

I gave it a shot. Did it work?


> I hope this sheds more light on the command line uses.

Yes, indeed. Thanks for the detailed reply.

  -Tom

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