You say “no, look, I know its hash, it's 1234…”. Note that you need to trust the customer to calculate the hash of the product, and not calculate the hash of some copy of the original or read it off the delivery slip.Įxample of something a hash is not good for: somebody else claims that they're the author of the document. If the hash value is not what you provided, you refuse to provide support. So you get them to calculate the hash of what they want you to support. If you are concerned about this then use a signature of the file instead of a hash, and notarize the signature and the public key but keep the private key to yourself.)Įxample of something a hash is good for: your customer wants support, but you're only prepared to support your original product and not a modified product. (If you publish the hash, then in theory someone could figure out the file from it, but there's no better way to do that than to try all plausible files until they find the right one. You can do that without revealing the file by communicating the hash to a third party who everyone trusts to correctly remember the date at which you showed them the hash this third party could be a public notary, or the Wayback Machine if you put the hash on a web page that it indexes.
The best you can do is to prove that you had the file earlier than anyone else who can prove it. There's no cryptographic way to prove authorship. Knowing the hash of the file doesn't prove that you wrote it. This means that if you keep a trusted copy of the hash (for example you print it out and store it, or notarize it), then you can tell later “yes, this file you're showing me is the same file” or “no, this file you're showing me is different”.
Conversely, this means that if two files have different hashes, then they're different. With a non-broken cryptographic hash like SHA-256, what you know is that if two files have the same hash then they're identical. Since there's risk in using MD5, and zero benefit compared to using SHA-256, use SHA-256. It would be pretty tricky to achieve a collision that way, but it's doable in principle. However, there's a risk that somebody could trick you into injecting this bit, for example by supplying an image to include in the document. You aren't going to craft this bit in the middle. In your scenario, you mostly don't care about collisions, because you'll be producing D1.
#Checksum md5 pdf#
Producing such collisions is trivial on a PC for MD5 and is doable but expensive for SHA-1 (unless you want it for two PDF files, in which case researchers have already spent the money on the calculation to find one and published it). The bit that needs to be calculated will look like garbage, but it can be hidden in a comment, in an image that's shifted off-page, etc. More precisely, for both of these hashes, it is possible to find collisions: it is possible to find two documents D1 and D2 such that MD5(D1) = MD5(D2) (or SHA-1(D1) = SHA-1(D2)), and such that D1 and D2 each end with a small bit that needs to be calculated and optionally a common chosen suffix. Furthermore the fact that these algorithms are already partially broken makes them more at risk of getting more broken over time. They are not obviously unsuitable in your scenario, but they could be exploited with a bit of extra work. There is a SHA-3 but it isn't very widely supported yet and it isn't more secure (or less secure) than SHA-2, it's just a different design.ĭo not use MD5 or SHA-1. In your case the choise between SHA-256 and SHA-512 is indifferent. It's the hash to choose unless you have a good reason to choose otherwise. SHA-2 is the successor of SHA-1 and is considered secure. Use SHA-256 or SHA-512: either of the two “main” members of the SHA-2 family.
0 kommentar(er)
