First of all, sorry everyone for not addressing this sooner. The bug does not affect rsyncrypto directly, as it does not generate public keys, but it does affect the rsyncrypto users. I'll issue a standard advisory with this info there again.
Robin Lee Powell wrote: > I did my rsycrypto key creation just like the man page said to: > > openssl req -nodes -newkey rsa:1536 -x509 -keyout backup.key -out > backup.crt > > I probably had the bad openssl at the time. > > Do I need to regenerate? > You, most likely, need to regenerate, and what is decidedly worse, re-encrypt everything. > How can I tell? I haven't had time to research the various solutions thoroughly yet. The length you chose (1536 bits) is not one of the standard lengths for which known bad public key lists were made, so telling will be rather hard. Still, try the following: openssl x509 -in certfile -noout -text Look for the section headed "Subject Public Key Info", in which you will see "RSA Public Key", in which you will see "Modulus". Copy a section of the string of numbers into google and run a search. This will give you an idea of whether anyone else has the same public key as you. There are a few mitigating factors for rsyncrypto, but they really shouldn't be relied on. The most important one is that, unlike ssh, the encrypted key does not advertise the key length of public key. This should not be heavily relied on, as the key length has only several bits of likely entropy (1024, 1536, 2048 and 4096 will likely cover most cases, which means just 4 bits of entropy), and the key itself only has 16 bits (that's the bug, after all). As such, a determined attacker can, fairly easily, brute force her way through it. Also on the minus side is the fact that the symmetric key (what is being encrypted with public key) has a magic number at the beginning, so it is fairly easy to know whether you broke the certificate or not. Another somewhat mitigating factor is the fact that the public lists of weak keys are no use to an attacker, as they do not contain the private keys. Their only use is to know whether your key is vulnerable, which is nice, because it, for once, gives the good guys an edge. Finally, you will need to make a security/performance tradeoff decision revolving around the question "how likely it is that someone has already broken my key". If you feel it unlikely, simply generate a new private key and re-encrypt everything using the same symmetric keys. This will save re-sending everything, as only the key headers will be sent. The down side is that had the assumption been wrong, not only could the attacker read every file you had so far (which is unavoidable at this stage), she can also read future encryptions with the symmetric keys stored. Only go this route if you understand the risks and am willing to take them. If, on the other hand, you want to be sure, then you will need to re-encrypt everything from scratch. New keys, new file map, everything. It is best to simply encrypt to a new location altogether, so that nothing from the possibly compromised keys is used. I hope this helps Shachar ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Rsyncrypto-devel mailing list Rsyncrypto-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rsyncrypto-devel
