0
$\begingroup$

I recently came across a project called rsyncrypto that sacrifices some security so that you can have rsync-friendly files. My understanding is that it 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).

The project seems to require the use of the public key in addition to the symmetric key file for decryption, however, and I'm confused as to why this is. It seems like if you have the symmetric key in a file already (which you do, generated by the program), you could just decrypt the data and disregard the embedded copy of the same symmetric key. I know that this is a question better posed to the maintainer, but he seems to have disappeared years ago. Anyone familiar with the program (or even if you're not) that could explain to me why you might need the public key in addition to the symmetric key for decryption? The most likely explanation I can think of is that I'm missing something about how this program works, but all the reading I've done doesn't seem to have cleared anything up about this.

Disclaimer: Thusfar my google-fu has been strong and I have never needed to post a question on any forum before, so this is my first. Please be gentle. =)

Improve this question
$\endgroup$
7
  • 3
    $\begingroup$ Considering you have not tried asking this on the project's active mailing list, sent a private message via sourceforge with the question, but neglected to turn on any ability to answer, your assertion that the maintainer (me) you assertion that I disappeared years ago seems suspect. Feel free to ask this question on the project's mailing list, where it belongs. sourceforge.net/p/rsyncrypto/mailman/rsyncrypto-devel $\endgroup$ – Shachar Shemesh Jun 15 '15 at 12:31
  • $\begingroup$ Don't use security protocols that aren't even well described. It is impossible without the source to validate this protocol. $\endgroup$ – Maarten Bodewes♦ Jun 15 '15 at 16:37
  • $\begingroup$ @ShacharShemesh I don't see any signature or authentication tag in your code. Do you rely on CBC only? Which padding mode? $\endgroup$ – Maarten Bodewes♦ Jun 15 '15 at 16:48
  • 1
    $\begingroup$ @ShacharShemesh I apologize for the evidently hasty assertion that you'd disappeared; I suppose this stemmed from the date on the most recently released version of the software: July 23rd 2008, and the wiki that hadn't seen any updates since 2012. I didn't see any contact information anywhere on the wiki, and I guess I didn't realize that just anyone could post to mailing lists. I had also misconfigured my sourceforge account. Again, completely my bad. $\endgroup$ – compilingEntropy Jun 16 '15 at 9:43
  • $\begingroup$ @MaartenBodewes I find the comment format one in which it is really hard to conduct a productive discussion. Either ask this as a separate question, or (better), do so on the mailing list, please. $\endgroup$ – Shachar Shemesh Jun 16 '15 at 10:14
1
$\begingroup$

For completeness / posterity / future inquisitors, this is the response I got when I asked on the mailing list. I have also included it below because links sometimes break.

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

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.