File responses should have a filehash object instead of a string.
leper opened this issue · 4 comments
The current API (v1) hard-codes MD5 as the file hash. MD5 should be considered broken as collision attacks are relatively easy to do and do not take long.
To make the API easier to update/extend in the future (without even bumping the API version) having filehash be an object would be a lot nicer.
filehash: {
md5: "abcd",
sha256: "1234",
sha3-512: "5689"
}
By just providing multiple hashes adding better hashes is easily doable, without breaking users of the API, and allowing nice updates. In case some hash is severely broken in the future one could even just drop that one from a new version of the API.
A good suggestion - will discuss within the team.
Fantastic idea, allows future updates easily - will get this implemented. Also while MD5 is unreliable due to collisions, this feature is primarily there as an integrity check, but we will look to adding stronger methods.
Yes, all of MD5 and the SHA family of hashes are just to verify integrity of the file transfer (one could also use CRC for that if one wanted to).
About something stronger that is the main point of #31.
We have added this object to allow for future HASH methods. Thanks again for the suggestion