Idea #4424
Updated by Peter Amstutz over 9 years ago
The md5 algorithm is well known to be insecure. Attackers can force hash collisions on arbitrary data, for example http://natmchugh.blogspot.com/2014/10/how-i-created-two-images-with-same-md5.html?m=1
In the case of Keep, this exposes an obvious vulnerability. If an attacker known the hash of a block, he or she could subvert the permission system this way:
# Generate a block that collides with the desired hash
# Upload the collision block and receive a signed token
# Use the signed token to request the block
We may be able to tighten Keep's behavior to make this attack more difficult, such as doing a byte-for-byte check that the uploaded block matches a known block. However, given this is a general vulnerability that attacks the assumptions of content-based addressing, it seems very likely that there are other more subtle attack vectors.
We need to start thinking about moving to a best practices cryptographic hash. SHA-1 (used by git) is already considered vulnerable so we should look at SHA-2 or SHA-3.
Fixing this is likely to be somewhat difficult and disruptive, since there is already a lot of code that makes assumptions about the format and length of content hashes used by Keep, which would become longer with a stronger hash function.