#136 Insecure/Breakable Encryption When Encrypting Filenames

[Anonymous]

Originally created by: belt...@ymail.com

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!

[Anonymous]

Originally posted by: belt...@ymail.com

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).