# Are convergently-encrypted ciphertexts safe from collision attacks?

Convergent encryption uses a message digest of the plaintext as the key to encrypt the plaintext to produce the ciphertext.

This is useful for automatic content sharing because it produces a deterministic ciphertext between unrelated parties who encrypt it without revealing contents to parties who never encrypted it. Weaknesses exist, but it can be a useful thing for automatic content sharing in storage systems.

e.g.

compute SHA256 of plaintext -> KEY1

Use KEY1 to encrypt plaintext using AES256 with CBC -> ciphertext

compute SHA256 of cyphertext -> ID1

When sharing, it would be nice to avoid malicious collisions (e.g. widely distributing the funny graphic in email, identified by ID1, and converting it to something obscene in automatically-shared storage that also happens to have ID1).

The straightforward way is to make sure the hash algorithm is secure. SHA256 is reasonably secure even against collision attacks, which is a greater vulnerability than the preimage attacks.

But let's say you want to store your blocks in a medium that identifies objects by a weaker hash, such as MD5, which is vulnerable to collision attacks. In the above example, this means that ID1 is computed or verified using MD5 instead of SHA256, because it is done by the system when storing the ciphertext. Specifically AWS S3 supports MD5 on objects, specifically not intended for security but it is there. KEY1 is still computed using SHA256 since that is not part of the object identification/verification process.

The question is, does the process of convergent encryption protect adequately against collision attacks to make them infeasible like preimage attacks of MD5?

It seems like on the one hand, producing a plaintext that after encryption with a known key collides might not be difficult because you can decrypt anything with a symmetric key.

But convergent encryption means that as you mutate your cyphertext looking for a collision changing the plaintext, the key changes as well. Colliding cyphertexts can be produced, but finding cyphertexts that can be mapped back to a plaintext whose MD used as a key produces the cyphertext during encryption seems difficult.

Is it likely that there is a practical way to compute collisions, or did the convergent encryption preprocessing make the weaker MD5 of the storage medium no longer vulnerable to collisions of content that originated as plaintext?

All I have to go on is that it boggles my mind how this collision could be computed, but this sort of instinct can be wrong, so I was wondering whether anyone else had thoughts on whether it might be achieved.

• The idea is lacking the information which kind of symmetric cipher you're using to encrypt the content. And that is crucial for the whole idea: Given a plaintext $m$ and a ciphertext $c$, is it possible to find a key $k$ s.t. $E_k(m)=c$? This can be easy (obvious example: OTP) or difficult/practically impossible (current block ciphers). But it has to be specified. – tylo Apr 21 '17 at 13:30
• Edited to specify AES256 in the example. – N. Arendse Apr 21 '17 at 14:03