>>>>> "Martin" == Martin Rex <m...@sap.com> writes:
Martin> Sam Hartman wrote: >> > I'm OK with this text. I tried to come up with a way to briefly >> discuss how error detection is very related to things like >> protecting against substitution of content (the internet mirror >> case) but failed to come up with something brief. So, I'm fine >> with what you have. Martin> The use of MD5 _is_ a security problem in integrity Martin> protection scenarios. Agreed. My point was close but not identical to yours. My point was that even when you think you're just talking about error detection, it takes effort to tell whether you are really talking about error detection (OK) or integrity protection (not OK). Martin> When used for checksums when mirroring sites, a Martin> "contributor" could precompute a collision for a file he Martin> contributed in order to perform an MITM attack on specific Martin> downloads (substituting a trojaned package with the same Martin> md5sum into the download while leaving the file on the Martin> Download servers clean. An excellent point! In my original long message on this topic I pointed out that if the checksums are ever separated from the file then you're talking about integrity protection not error detection in most threat models. I was thinking of the case where you have a mastersite listing checksums and a bunch of mirror sites. (That is, the checksums in something like a Debian Packages file are very much integrity checksums not just error detection checksums; there's a reason we no longer rely on MD5.) However you point out that even if there is only one site, when there can be separation--even after the fact--then MD5 may be problematic. Some threat models may reject the case where the original distributor performs a precomputation attack, but for other threat models, this is a realistic attack. After this discussion, I continue to believe that determining whether a particular use of MD5 is safe is quite tricky. Therefore, it is very reasonable to ask that the security assumptions be described and analyzed. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf