Some cryptographers feel that the ultimate goal for an encryption scheme is semantic security or, even better, perfect security.
An encryption scheme that supports de-duplication also allows the backup server -- and the attacker, who we assume steals every backup tape that the server sysadmins send to the off-site backup location -- to detect which parts have changed and which parts stay the same.
Such an encryption scheme is, by definition, not semantically secure.
I don't see how to build an encryption scheme that supports de-duplication without leaking the fact that two different chunks of plaintext are identical, which apparently makes all such schemes vulnerable to a "learn the remaining information attack", a kind of chosen-plaintext attack.
(I hear "the BEAST attack" is related.).
Other cryptographers feel that host-proof protocols are so useful that it may be worth deliberately building encryption algorithms that support de-duplication and other useful features.
They argue that deliberately designing an algorithm to be non-semantically secure -- i.e., allowing the attacker to know that one piece of plaintext is the same as some other piece of plaintext, "leaking" that information to an attacker -- is not a big deal if the amount of information leaked is very small.
"Doing deduplication ... leaks information..., but this leakage is often small enough to be ignored entirely." --
Looking for cryptographic secure hash algorithm(s) that produces identical root hash for differently sliced hash list
There already exist a few crypto algorithms that support de-duplication:
Tarsnap divides files into variable-length chunks of average size 64 kB.
(Colin Percival mentions this in a blog post; I believe the exact details are in the tarsnap "chunkify.c" program text).
rsyncrypto divides files into variable-length chunks of average size 4 kB.
Content hash keying, also called convergent encryption, uses chunks the size of the entire file (at least in the Tahoe 0.9.0 implementation).
... any others?
It can be proven that the smaller the chunks are, the more information leaks to the attacker.
If the chunks are 1 character, the result is a simple substitution cipher, as used in cryptoquotes which are easily completely broken by amateur cryptotographers every day.
Two-character chunks are more difficult to break, but the Playfair and four-square cipher can still be completely broken with pencil-and-paper techniques.
With chunks of 128 bits and longer --
other than the attacks mentioned above that are inherent to deduplication-friendly encryption --
there doesn't seem to be any known attack against de-duplication-friendly encryption that is feasible with current technology.
"always produce the same result for a given input?"
It is unclear what you are asking. Are you searching for:
deterministic encryption always produces the same ciphertext when given the same key and the same plaintext, but (in general) completely different ciphertext with any other key and the same plaintext. The rsyncrypto and Tarsnap systems do this, which means that the server cannot do de-duplication when two different people try to backup the same file; de-duplication only happens when the same person backs a file that is the same (or very similar) to a previous file from that same person.
convergent encryption always produces the same ciphertext when given the same plaintext, no matter who encrypts it. When 100 different people try to back up the same file, the server only needs to store 1 copy of (the encrypted version of) that file.
With convergent encryption, the "learn the remaining information attack" can be an offline attack -- once the attacker gets an encrypted file, the attacker can make any number of guesses limited only by the speed of the attacker's computer.
Systems that use deterministic encryption -- even if they don't use convergent encryption -- are less vulnerable to a "learn the remaining information attack", but not immune.
With deterministic encryption, the "learn the remaining information attack" is an online attack: the attacker can make guesses limited by how often he can trick the person that has the encryption key into encrypting those guesses on behalf of the attacker.
Tricking a person into encrypting some plaintext chosen by the attacker is inherently going to be slower than an offline attack, and there are many ways to rate-limit such an attack to even slower rates.
How hard is it to trick a person into using his secret key to encrypt guesses supplied by the attacker?
Easier than you might think -- cryptanalysts at Bletchley Park doing "gardening", BEAST, CRIME, and BREACH show that chosen-plaintext attacks (CPA) are not only theoretically possible, but have have been shown to be practical.
The BEAST, CRIME, and BREACH attacks allow an attacker to recover secret authentication cookies, even though the attacker never learns the encryption keys, and the encryption itself (AES encryption, with ephemeral keys generated by Diffie-Hellman key exchange) is arguably not broken.
Further reading:
