Subject: Advisory - Rsyncrypto maybe affected from Debian OpenSSL reduced entropy problem Date: Friday 23 May 2008 From: Shachar Shemesh <shachar@xxxxxxxxxx> To: L-rsyncrypto <rsyncrypto-devel@xxxxxxxxxxxxxxxxxxxxx> Background Rsyncrypto[1] is a file encryption tool. It has a single RSA key that encrypts symmetric AES keys per file. The files themselves are subject to an encryption method that is based on CBC, but does a security-performance trade off. In particular, the files are encrypted in such a way that re-encrypting, using the same key, a file that was slightly modified will result in slightly modified cypher text. This is needed so that the file will retain wire efficiency when transferred using rsync[2]. Rsyncrypto does not generate the RSA itself. Instead, the rsyncrypto manual instructs the user to use openssl in order to generate a private key and a X509 certificate, and rsyncrypto will use either one of those. Vulnerability Rsyncrypto itself is unaffected by the openssl vulnerability introduced into Debian[3][4]. The common use scenario, however, will lead users toward generating predictable keys. This advisory is in place to warn users about possible exposure. As with the original advisory, this problem will affect you even if you are not currently running on a vulnerable machine, or even on a Debian or derivative OS. If your keys were generated on a vulnerable machine, then your data is at risk. Solution First of all, users should make sure that they are running a version of openssl that does not exhibit the problem. See the OpenSSL advisory for your platform for details. Users should regenerate the RSA key and X509 certificate used, and re-encrypt all files using the new key. User should perform a clean re-encryption, disregarding all context files rsyncrytpo saves, including the file name mapping file and the symmetric key files. This will, unfortunately, result in an encryption set that will not be transferable in a rsync friendly way. Less Secure Solution - Security Performance Trade Off If the user is 100% sure that no attacker has had a chance to save an encrypted file for later attack, one can make do with regenerating a new RSA key and re-encrypting the files using the existing state files (file name mapping and symmetric key files). This will result in encrypted files that have only their header different, but otherwise have the same name and data pay load. This should result in an easy rsync transfer of the files to the remote location. Be warned, however, that should the assumption of no malicious access prove wrong, the attacker could recover the symmetric key used for encrypting the specific file. This means that the attack could read the file before the key update (unavoidable), but also read ALL FUTURE ENCRYPTIONS DONE WITH THE SAME KEY. In other words, if the attacker had any access to the file in the past, they can read all future versions as well unless the symmetric key is also replaced. Mitigating Factors None that may be relied on. Rsyncrypto does not broadcast the public key used to encrypt the file. This makes an attacker's life harder, as she has to guess the key length as well as the actual key. Be warned, however, that small files leak the length of the key by nature of their size. Encrypting an empty file, for example, will always result in a same size cypher text file. Also notice that key lengths are rarely an arbitrary number. They are usually either 1024, 1536, 2048 or 4096 bits, which means that the attacker only has two more bits of entropy to go through. In short, do not rely on any of the mitigating factors. [1] - http://sourceforge.net/projects/rsyncrypto [2] - http://samba.anu.edu.au/rsync/ [3] - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0166 [4] - http://www.debian.org/security/2008/dsa-1571
