Rsyncrypto - Rsync Friendly Encryption - Recent changes [en]

Algorithm

Shachar — Fri, 30 Oct 2026 20:49:28 GMT

Created page with "= Rsyncrypto Algorithm = Rsyncrypto was designed as part of the backup service offered by [http://www.lingnu.com Lingnu Open Source Consulting]. The challenges such a service poses require an answer to two basic needs: * Transfer incremental data over poor upload bandwidths * Encrypt the data in a way that does not allow the server to decrypt it Rsyncrypto solves this problem by performing an encryption that maintains a "bounded change" property - re encrypting the sam..."

New page

= Rsyncrypto Algorithm =

Rsyncrypto was designed as part of the backup service offered by [http://www.lingnu.com Lingnu Open Source Consulting]. The challenges such a service poses require an answer to two basic needs:
* Transfer incremental data over poor upload bandwidths
* Encrypt the data in a way that does not allow the server to decrypt it

Rsyncrypto solves this problem by performing an encryption that maintains a "bounded change" property - re encrypting the same file after a minor change in the plain text should produce a minor change in the cypher text.

== Basics ==
In an attempt to reinvent as little as possible, rsyncrypto is based on industry standards wherever they apply to its unique requirements. In particular, broadly speaking, rsyncrypto uses the standard method of public key encryption, wh
ere each file gets its own, randomly generated, symmetric key (called "session key"), and that key is encrypted using a public key into the encrypted file. In addition to that, the algorithms used are as standard as possible. Rsyncrypto
uses RSA for the public key encryption and AES for the symmetric key encryption.

Further more, the basic schema of encryption is largely based on [http://en.wikipedia.org/wiki/Cipher_block_chaining CBC] mode encryption.

== What isn't the same ==
Straight out CBC does not provide the bounded change property. When re encrypting a slightly changed plain file, the CBC-encrypted file will be different from the point of the change until the end of the file. This is where rsyncrypto d
eviates from the industry standard.

In particular, rsyncrypto uses a decision function to look at a bounded window of history of plain text. Based on the history, the decision function will "trigger". It is important to understand that, because the decision function looks
only at the plain text as input, even if the file changes in length, once the file before and after the change turn the same, sooner or later the decision function will start triggering at the same points along the data. This will happ
en even without having the old file, encrypted or otherwise, to compare against. This has the very desirable property that rsyncrypto needs very little state about each file in order to repeatedly encrypt it in an rsyncable way. Current version of rsyncrypto needs just 68 bytes of state (assuming 256 bit AES key) in order to encrypt the file again. The old version of the file itself need not be kept.

Plain CBC uses the previous cypher block as a basis for encryption of the current block. This is the mechanism by which a change to the plain text propagates until the end of the file. Since the first encryption block does not have a "previous block", an initial vector (IV) is used as a pseudo previous block for the encryption.

The entire rsyncrypto can be summarized with one sentence. Rsyncrypto uses the standard CBC encryption mode, except every time the decision function triggers, it uses the original IV for the file instead of the previous cypher block.

= The Decision Function =
In the current version, rsyncrypto uses the same decision function used by gzip. This triggers if the sum of the past 8196 bytes divides by 4096 with zero remainder. In other words, if <math>P_i</math> denotes the plain text at position i and n the current position, then the decision function will trigger if <math>\left( \sum_{i=n-8196}^n P_i \right) \equiv 0 \pmod {4096}</math>

Todo

Shachar — Fri, 30 Oct 2026 20:47:50 GMT

Created page with "=Future Plans= Rsyncrypto is currently running at version 1.xx. This version will not receive any more major upgrades. Version 2 is, currently, only in the planning, but the following features are planned for it ==Encryption== * Upgrade the decision function to something with cryptographic strength. Research is currently being done to try and figure out what should be done, and what performance and security implications it will have. * Change the RSA padding style so re..."

New page

=Future Plans=
Rsyncrypto is currently running at version 1.xx. This version will not receive any more major upgrades. Version 2 is, currently, only in the planning, but the following features are planned for it

==Encryption==
* Upgrade the decision function to something with cryptographic strength. Research is currently being done to try and figure out what should be done, and what performance and security implications it will have.
* Change the RSA padding style so repeat encryption will produce identical headers

== Performance ==
* Let he OpenSSL code encrypt more data in one go (currently encrypts one AES block at a time)
* Find a way to utilize more than 1.5 CPUs concurrently

== Modes of operation ==
* Support stdin⇒stdout encryption/decryption
* Allow integration as a rsync "filter"
* Allow password protected RSA keys
* Eliminate the need for an external "gzip" command

Main Page

Shachar — Fri, 30 Oct 2026 20:44:24 GMT

@@ Line 1: / Line 1: @@
-<strong>MediaWiki has been installed.</strong>
+=Rsyncrypto - Rsync Friendly File Encryption=
-Consult the [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents User's Guide] for information on using the wiki software.
+New to this release:
-== Getting started ==
+* Refactored to work with OpenSSL 1.1.0
-* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Configuration_settings Configuration settings list]
+* Upgrade the source to be C++11 compilable, if not compliant.
-* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:FAQ MediaWiki FAQ]
+* --filelist determines whether to treat the name as a directory or a file based on whether the name ends with a slash.
-* [https://lists.wikimedia.org/postorius/lists/mediawiki-announce.lists.wikimedia.org/ MediaWiki release mailing list]
+* --filelist now accepts as mandatory parameter the file list source. The first argument is now the directory in relation to which relative paths are interpreted.
-* [https://www.mediawiki.org/wiki/Special:MyLanguage/Localisation#Translation_resources Localise MediaWiki for your language]
+* Prevent absolute paths from appearing with two leading slashes when --trim=0
-* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Combating_spam Learn how to combat spam on your wiki]