Re: Why does rsyncrypto require a public key during decryption?

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

 

On 16/06/2015 12:54, compiling entropy wrote: 

> After reading through the man pages and the available documentation a few times, my understanding is that rsyncrypto works by generating a symmetric key for each file you're encrypting, and saving that symmetric key to a file. It then encrypts the file using that symmetric key, encrypts the symmetric key with a public key, and concatenates the encrypted symmetric key to the encrypted file. The purpose of this is so that each file can be encrypted with a different key, but even if you lose the symmetric key file, the data can be decrypted by using the private key (private key decrypts symmetric key in the file, symmetric key decrypts the file itself). 
> 
> I think I'm missing something about how rsyncrypto works, because in the model of understanding I just described, you ought to be able to decrypt files using only the keyfile or private key. While I've seen that you can decrypt the file using just the private key, use of the key file in decryption requires that you also provide the public key. I'm confused as to why this is. It seems as though if you have the symmetric key already, you could just decrypt the data and disregard the embedded copy of the same symmetric key. What is the public key used for during decryption, or what am I missing?

No, you're not missing anything. This requirement is not,
algorithmically, necessary. 

When you're decrypting with the symmetric key available, rsyncrypto uses
the public key in order to know how much of the file's header to skip.
In other words, all it actually needs from your public key is how many
bits it is. Since the first part of the file is the symmetric key,
encrypted using the private key, the key's length is needed in order to
know how much to skip. 

Of course, in retrospect, I could have stored that information inside
the symmetric key file, and made the usage simpler. I'm hoping to, some
day, get around to working on rsyncrypto again, and this will definitely
go there. 

Unfortunately, rsyncrypto's current file format makes it impossible to
encrypt using a stream algorithm. Since this is a kinda important
change, the changes planned for rsyncrypto 2.0 are breaking changes. As
that's the case, I will not do another breaking change (changing the
format of the symmetric key file) for so little gain. 

If this restriction is a problem for the deployment type you are
planning, you can simply generate some random public key for the
decryption machine. So long as it is the same length as the original
encryption key, everything should work fine. 

Shachar