The probability is indeed too low to cause any problems.

However, imagine that a malicious user generates a number of paths "account/container/object" that will hash to the same value by changing "container/object" suffix. (It is possible to perform this attack for md5, see for example http://www.win.tue.nl/hashclash/ChosenPrefixCollisions/ (http://www.win.tue.nl/hashclash/Chose...) ).

Afterwards, the user uploads different files with the names that will have the same hash to OpenStack. The second file overwrites the first. You may think that such a malicious user harms only himself. BUT! The provider can be sued by that malicious user for data loss (we presume an existence of a legal agreement between a provider and a customer).

Of course, malicious user will need to know HASH_PATH_SUFFIX in order to perform this attack. But it is still possible using insider knowledge (for example by dishonest staff at provider's side disclosing HASH_PATH_SUFFIX value or even initiating the attack).

to swift, they are referencing the same object

But for two users that are uploading their files to swift and incidently happen to get the same hash value, these are two different objects. Isn't it a problem?

The probability of hash function giving one output to two different inputs is small, but if swift is ever used as a back-end for gmail or facebook, sooner or later such a situation might happen.

In order to test what will happen then, I have created a dummy implementation of md5 function which always results in the same hash value. Afterwards, I have changed swift.common.utils.py in line 26 to include my dummy version of md5 instead of hashlib.md5.

* TEST *

Actions below test for a situation when hash("accountA/files/file1 + HASH_PATH_SUFFIX") == hash("accountB/files/file2 + HASH_PATH_SUFFIX"):

1) python st -v -A http://10.0.0.2:11000/v1.0 -U accountA:adminA -K passadmina upload files file1 2) python st -v -A http://10.0.0.2:11000/v1.0 -U accountB:adminB -K passadminb upload files file2 3) python st -v -A http://10.0.0.2:11000/v1.0 -U accountA:adminA -K passadmina download files file1

As the result of action 2, file2 will overwrite file 1. As the result of action 3, user from accountA will successfully download the content of the file uploaded by user from accountB.

* POSSIBLE FIX * The path to the file should not depend only on the output of the hash function, but also from some other information that is different for different accounts, for example account name.

we caution deployers to keep it secret in the docs (...) The hash_path_suffix should be kept as secret as an /etc/shadow file or the secret key of a key pair.

I just rechecked the Administrator manual ( http://docs.openstack.org/cactus/openstack-object-storage/admin/os-objectstorage-adminguide-cactus.pdf (http://docs.openstack.org/cactus/open...) ), and what I found with respect to swift_hash_path_suffix was:

"# random unique string that can never change (DO NOT LOSE)"

Maybe I have missed other places where the necessity to keep swift_hash_path_suffix secret were mentioned, but it might make sense to indicate it in Admin manual and also at etc/swift.conf-sample from the distribution. Just as a precaution measure.

This attack vector would require knowing both /<account>/ prefixes and the HASH_PATH_SUFFIX with control only over the middle part with limited data size, which that paper does not describe.

Just a comment. It is still possible to vary the middle part to achieve the same hash value. For example in http://www.win.tue.nl/hashclash/Nostradamus/ (http://www.win.tue.nl/hashclash/Nostr...) there are examples of different PDF files which predict different outcomes of US elections. All of the provided files have the same Md5 hash. If one makes byte-to-byte comparison of two such files, he will note that the prefixes and suffixes are identical.

The above considerations on "keeping hash path value secret" and "risk management" still stay valid. But maybe eventually it might be advisable to refuse from using MD5 even despite its "general availability, good distribution, and adequate speed".