Insecure/Breakable Encryption When Encrypting Filenames

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Set CryptSync to encrypt filenames.

What is the expected output? What do you see instead?
Expect filenames to be encrypted in a secure way. Instead, encryption takes 
place in an insecure manner meaning 1) Information about filenames is 
potentially recoverable and 2) In certain scenarios where techniques can be 
used to break MD5 hashing, full decryption of all files may be possible!

What version of the product are you using? On what operating system?
Windows 8.1 64-bit

Please provide any additional information below.

First of all, both MD4 and RC4 used by CryptSync are *vulnerable* algorithms 
which have well-documented exploits reducing their usefulness for security 
purposes. Use of these should be discouraged and they should be replaced by 
more modern algorithms, such as SHA-256 and Salsa20 or better. Weaknesses in 
RC4 mean that one usually must discard the first 256 bytes of data produced by 
it as these initial bytes are not sufficiently random and can leak information 
(these bytes do not appear to be discarded by CryptSync, meaning RC4 will leak 
information).

Secondly, stream ciphers like RC4 should never use the same key on more than 
one message. From a cursory glance through the code, it seems CryptSync uses 
the hash of the user's password as the key for RC4 for each and every filename. 
This is completely insecure and causes key and message leakage. In this case, 
this means that by because of the user of the same key for each filename, if 
attackers can obtain several encrypted filenames this will be sufficient to 
obtain both the unencrypted filenames and also the key used to encrypted them 
(the MD5 hashed password).

Thirdly, if attackers gain access to the MD5 hashed password, there is a 
significant possibility that even more severe damage may be done. In this day 
and age, many individuals use relatively simple passwords and reuse passwords 
on multiple websites. Since no attack mitigation takes place in CryptSync when 
the password is hashed, this means that various attacks can readily be used to 
discover passwords from their hashes for a large number of passwords. 
Mitigation such as hashing with a slow algorithm suited for hashing passwords 
(MD5 is designed to be fast, meaning it is totally unsuitable for hashing 
passwords), salting, or other techniques are required to avoid brute-force 
attacks. Attacks on many well-known sites have meanwhile led to the creation of 
numerous widely-available rainbow tables which can be used to identify 
previously compromised passwords based on their hashes. Should a user's 
password be compromised due to being relatively simple or having been leaked 
through an attack on an external site, an attacker could then **fully decrypt 
all files encrypted by CryptSync**! And all an attacker would need for this to 
happen is a list of filenames encrypted with CryptSync!

Original issue reported on code.google.com by belt...@ymail.com on 11 Feb 2015 at 2:31

[GoogleCodeExporter]

Seem to have garbled my submission. The middle paragraph should read:

Second, stream ciphers like RC4 should never use the same key on more than one 
message. From a cursory glance through the code, it seems CryptSync uses the 
hash of the user's password as the key for RC4 for each and every filename. 
This is completely insecure and causes key and message leakage. In this case, 
this means that due to the reuse of the same key for each filename, if 
attackers can obtain several encrypted filenames this will be sufficient to 
obtain both the unencrypted filenames and also the key used to encrypted them 
(the MD5 hashed password).

Original comment by belt...@ymail.com on 11 Feb 2015 at 2:38