David E. Ross wrote: > For example, a hash mismatch would cause the downloaded file to be > deleted. Also a misformed hash would block downloading. Both of these > create denial-of-service opportunities; all a hacker has to do is alter > the hash in the anchor (link) that would be used to initiate downloading.
I don't see a big problem here. If an attacker can modify a site's download link (or the download itself), then it's already game over. They could just point the download link at a trojan, non-existant file, or a blob of random bits. I think you're really reaching for a problem here... > Of course, the Web author could accidentally provide a bad hash. Doctor, it hurts when I do this! > Such a forgetful author might also > forget to change the hash in the anchor when changing the file that the > link downloads. Each of these situations results in the page's author > creating his or her own denial-of-service. That's a feature, not a bug. :-) But it's also no different than a page author creating a "denial-of-service" by forgetting to change the filename when they release a new version and delete the old one, or various other ways of shooting yourself in the foot. > I much more favor providing both the target file and a separate file > containing the hash, as is done on the Mozilla FTP site. And how do you verify the contents of the hash file? Another hash file? :) Justin _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
