"
I didn't ask you to agree with me."
Who said you did?
"
I was merely asking for some resolution between two MD5-related blog entries and your comments to me."
Understanding of the connection should be pretty clear based on the commentary in
an earlier post of mine. I tried to point that out in
my just previous post, where I said "I actually quoted (and linked to) that article in my first response to you, elaborating upon the difference between the MD5 dangers to passwords and the effective lack of danger for software download verification in the common case."
"
The word, use, is a directive or imperative for the reader."
It's a headline -- truncated in construction, implying more context. In this case, what it implies is "how and why to", making the full-length (and unacceptably long) version of it "How and why to use MD5 hashes to verify software downloads". Even that is truncated and implying more context, however. By the time I'm done adding in what was truncated and implied, to satisfy you, the headline would be a reprint of the article.
"
It isn't just receivers of files who are readers of your blog entries. Software developers and program managers are amongst your readers."
If you don't get the impression that this particular article was specifically targeted to downloaders of software, then one of two things has happened: either I utterly failed to make my point, or you (probably intentionally) misread my meaning, perhaps because you wanted some way to "prove" me "wrong". I'm pretty sure I made numerous references to downloading, and none specifically to the reader providing downloads, so I'm going to hazard a guess that the failure was on your part in this case. Maybe I'm mistaken.
In any case, you never criticized the clarity of my writing style. You've only attacked the motives you've assigned to me -- which were not, in fact, the motives I had in composing that article.
"
MD-5 hash collisions have been detected and demonstrated by hash researchers."
. . . to which I obliquely referred in this article, and more explicitly referred in the later article to which first I, then you, linked. This is not news to me, nor is it news to many of my readers by now. Furthermore, it in no way contradicts anything I've said.
"
NIST (and others) recommends against using them for cryptographic functions and recommends the adoption of stronger or multiple hash algorithms for future applications."
That's great. I recommend stronger algorithms than MD5 for most purposes, too -- including for providing software downloads. However:
1. Sometimes, when downloading, that's all the provider has given us. We work with what we have.
2. Much of the time, it's difficult to make a point and ensure that others will understand it without first making a different point. At some point in the future, I may write an article specifically about using stronger cryptographic hashing and signing functions to verify downloads, but first I need an article like this one to which I can link in that article for some of the background and foundation of that other article.
You obviously haven't noticed, but I have a tendency to link to older articles when writing newer articles because it can provide more complete reference material. The fact that you jumped on this as though it were my Last And Only Word on the matter of cryptographic hash functions, despite my very obvious reference to the fact that MD5 isn't the strongest cryptographic algorithm in the world, seems to be at the root of your disagreement with me. Did it ever occur to you to assume I'm not a complete idiot before assailing my statements with assignment of motives (MD5 advocacy) that are not, in fact, mine?
"
It shouldn't matter whether your articles were about passwords or file downloads."
Really, I'm not sure you know what you're talking about. I'm trying to drag the vast, encryption-unfamiliar mass of IT professionals into the realm of security knowledgability, not get back-pats from technology purists who never actually deal directly with the outside world. I'm addressing people downloading software, and I went to some pains to specifically address those people -- I'm not telling programmers to provide MD5 hashes with their software when distributing it. If you can find a statement of mine that says otherwise, I'll eat my computer.
"
MD-5 has weaknesses and isn't a compensation for the trust relationship you might have the the source."
Well, good! I wouldn't want to think I was wrong when I specifically pointed out that it's
not a "compensation" (aka "replacement") for the trust relationship with the software distributor. You present sentences like these as though they refute my statements, which is confusing, considering they're basically paraphrases of my statements in the very article you criticize!
"
There are man-in-the-middle exploits and rootkiit viruses that could take advantage of the MD-5 weakness(es) to distribute malware, even from a trusted source."
Um, no, there aren't. This is where I start doubting you know what you're talking about, again. See previous comments about the difference between a collision weakness and a preimage weakness. A collision weakness is a problem when you cannot necessarily trust someone, but a cryptographic hash or digital signature can be used to technically verify that the other party is treating you fairly in this instance. It is
not a problem when you simply cannot trust the medium of transfer. That's why the only way the collision weakness is a problem for file verification is if the distributor is trying to pull a fast one on you -- and, when dealing with software downloads, even that danger is so vanishingly small that in cases like the MD5 collision weakness it's probably ignorable. Preimage weaknesses basically allow you to forge a successful hash check; collision weaknesses do not.
There's also the collision weakness problem involved in authentication, of course, but that's only because the content
doesn't matter in that case: only the hash does. That means that a collision weakness increases the number of matching permutations, thus potentially reducing the necessary time for a brute-force attack (in some cases).
Please read up on collision vs. preimage weaknesses before revisiting this particular branch of your so-called argument.
"
How I got to the article isn't important."
I didn't say it was, except to point out two things: 1. that it's obvious you aren't paying much attention to what I'm saying -- since I specifically linked to, and quoted from, the other article; 2. that you apparently have a hypocritical tendency to declare my statements null, void, and irrelevant if they come from other articles while, ironically, you quote
the same article in a response to me, thus making it clear that there's a double-standard which makes the same behavior for you "okay".
"
If someone disagrees with you, it is OK to pounce on them?"
Much of the problem here is that you
didn't disagree with
me -- you just disagreed with things I didn't say, and accused me of saying them.
"
If someone comments that the underlying technology might be flawed, it is OK to pounce on them?!?"
Is it okay to "pounce on" me for "recommending" a flawed technology when, in fact, I only recommended learning how to use it and
even pointed out that it's a flawed technology myself in the article to which you objected? Is it not okay for me to
point that out?
"
I'm not belittling this blog entry."
Maybe not with that sentence -- or maybe you aren't trying to belittle the article. Maybe you're just trying to belittle me. Frankly, I don't care either way -- I just don't want you playing Character Assasination Games and trying to pump up your own ego by distracting people from actually learning something from the article.
"
I think it is also important for folks to know about MD-5 weaknesses if they are planning/disigning/writing/deploying a file distribution system"
Feel free to give me hell if I write an article about those topics, rather than about being on the receiving end, in which I talk about MD5 without pointing out there are better options.
"
might be relying on the strength of MD-5 to ensure integrity of the files they download from their trusted sources."
It's better to use MD5 than nothing at all, when MD5 is all that's available for a given download. It's also the case that MD5's weakness is not as notable in the context of receiving files from trusted sources -- as I pointed out, and even tried to explain in response to you taking issue with it, but that you seem unwilling to grasp.
