<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0" xmlns:s="http://www.techrepublic.com/search" xmlns:dc="http://purl.org/dc/elements/1.1/"  xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
    <title><![CDATA[Discussion on Use MD5 hashes to verify software downloads ]]></title>
    <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-247349]]></link>
    <atom:link rel="hub" type="application/rss+xml" href="http://pubsubhubbub.appspot.com/" />
    <atom:link rel="self" type="application/rss+xml" href="http://www.techrepublic.com/forum/discussions/102-247349/rss" />

    <description><![CDATA[]]></description>
    <language>en-us</language>
    <lastBuildDate>2013-06-19T02:51:39-07:00</lastBuildDate>
             

    <item>
        <title><![CDATA[. . . and the most important thing in this little debate:]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-247349-2384616]]></link>
        <description><![CDATA[I figured I should post this separately, so it gets the attention it deserves.  I want to make crystal-clear one of the reasons I have objected so strongly, and at such great length, to your complete mischaracterization of what I said in that article.  Specifically:If you, in the manner in which you've phrased your statements, manage to convince readers that I actually said the things you claim I've said, it can lead to some pretty poor results.  Such readers, if you manage to convince them that I said they should use MD5 instead of (for instance) SHA-256, may then assume that I know what I'm talking about when I supposedly say this and go out choosing MD5 over SHA-256 (or OpenPGP, or whatever).Thus, I would prefer that you cease and desist in all your persistence in putting such words in my mouth so that readers will not be so poorly misled.  I never made any such claims, and I don't want them thinking I did because of what you said.What do you imagine would happen if someone read your comment suggesting I said such a thing, and tried to decide whether to believe you on the subject of the usefulness of MD5 or what you've claimed I said?  Don't you think some of these readers might figure that since I'm the one writing articles, and you're some unknown quantity schlepping in off the Internet to throw much, I'm right and you're wrong?  Ironically, they might then take your inaccurate representation of my words as an indication that I'm exhorting them to use MD5 at the expense of other algorithms, and your inflammatory statements about what I supposedly said may have the interesting (and unfortunate) result of convincing people to do the opposite of what you seem to want them to do.I simply couldn't let that happen, in good conscience.  I had to dispute you to maintain any sense of self-respect on this issue -- to point out where you've misrepresented my words.If you had simply asked whether I'd meant what you instead claimed I meant, and mentioned the collision weakness, I could have answered the question directly and explained the differences between a collision weakness and a preimage weakness.  Instead, you took an accusatory tone, put words in my mouth, and generally created a necessarily combative atmosphere, wherein my only options were to ignore it (which I've already explained I couldn't do in good conscience) or to dispute your claims about my intent and actions (as I did).]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-247349-2384616]]></guid>
        <dc:creator><![CDATA[apotheon]]></dc:creator>
        <pubDate>Sat, 15 Dec 2007 17:13:10 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[You keep attacking straw men.]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-247349-2384613]]></link>
        <description><![CDATA[&quot;I didn't ask you to agree with me.&quot;Who said you did?&quot;I was merely asking for some resolution between two MD5-related blog entries and your comments to me.&quot;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 &quot;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.&quot;&quot;The word, use, is a directive or imperative for the reader.&quot;It's a headline -- truncated in construction, implying more context.  In this case, what it implies is &quot;how and why to&quot;, making the full-length (and unacceptably long) version of it &quot;How and why to use MD5 hashes to verify software downloads&quot;.  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.&quot;It isn't just receivers of files who are readers of your blog entries. Software developers and program managers are amongst your readers.&quot;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 &quot;prove&quot; me &quot;wrong&quot;.  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.&quot;MD-5 hash collisions have been detected and demonstrated by hash researchers.&quot;. . . 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.&quot;NIST (and others) recommends against using them for cryptographic functions and recommends the adoption of stronger or multiple hash algorithms for future applications.&quot;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?&quot;It shouldn't matter whether your articles were about passwords or file downloads.&quot;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.&quot;MD-5 has weaknesses and isn't a compensation for the trust relationship you might have the the source.&quot;Well, good!  I wouldn't want to think I was wrong when I specifically pointed out that it's not a &quot;compensation&quot; (aka &quot;replacement&quot;) 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!&quot;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.&quot;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.&quot;How I got to the article isn't important.&quot;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 &quot;okay&quot;.&quot;If someone disagrees with you, it is OK to pounce on them?&quot;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.&quot;If someone comments that the underlying technology might be flawed, it is OK to pounce on them?!?&quot;Is it okay to &quot;pounce on&quot; me for &quot;recommending&quot; 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?&quot;I'm not belittling this blog entry.&quot;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.&quot;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&quot;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.&quot;might be relying on the strength of MD-5 to ensure integrity of the files they download from their trusted sources.&quot;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.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-247349-2384613]]></guid>
        <dc:creator><![CDATA[apotheon]]></dc:creator>
        <pubDate>Sat, 15 Dec 2007 16:57:32 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Implicit Recommendation]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-247349-2384464]]></link>
        <description><![CDATA[1. I didn't ask you to agree with me.  This far into our online discussion, we don't seem to even be communicating.  I was merely asking for some resolution between two MD5-related blog entries and your comments to me.2 &amp; 6. &quot;I never made a specific recommendation that people should use MD5 ...&quot;The title of your original blog entry begins with the word &quot;Use&quot;, not &quot;Using&quot;.  The word, use, is a directive or imperative for the reader.3. It isn't just receivers of files who are readers of your blog entries.  Software developers and program managers are amongst your readers.  My comments were directed as much to the distributors of files as the recipients of the files.4. MD-5 hash collisions have been detected and demonstrated by hash researchers.  NIST (and others) recommends against using them for cryptographic functions and recommends the adoption of stronger or multiple hash algorithms for future applications.  It shouldn't matter whether your articles were about passwords or file downloads.  MD-5 has weaknesses and isn't a compensation for the trust relationship you might have the the source.  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.5. How I got to the article isn't important.  I didn't know about the other article until your responses prompted me to look at the history of articles you'd written.7. If someone disagrees with you, it is OK to pounce on them?  If someone comments that the underlying technology might be flawed, it is OK to pounce on them?!?It seems that we've spent a lot of time responding to comments without actually helping readers of this blog entry or the subsequent comments.  I even commented on one of my comments.I'm not belittling this blog entry.  It is a good thing for you to inform folks about hashing topics...definition, different algorithms, common uses, weaknesses.  I think it is good for folks to know what tools are available when checking hashes.  That said, 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 or might be relying on the strength of MD-5 to ensure integrity of the files they download from their trusted sources.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-247349-2384464]]></guid>
        <dc:creator><![CDATA[aikimark@...]]></dc:creator>
        <pubDate>Sat, 15 Dec 2007 08:31:28 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[I think you've missed most of the points here.]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-247349-2384115]]></link>
        <description><![CDATA[&quot;You bust my chops (at least write very defensively/derisively), but write a new blog entry agreeing with my comments?!?&quot;1. You might notice, if you read closely, that the article to which you linked was posted a day before your first comment here -- and it was written even before that.  I'm not writing posts to agree with you; your characterization of events is misleading.2. You didn't just comment on a collision weakness in the MD5 algorithm.  You said I should rethink my recommendation of MD5.  I never made a specific recommendation that people should use MD5 -- I just explained how it's used, mentioned the fact it isn't as strong as some other algorithms, and explained why it's not a big problem to use it for verifying downloads.3. Speaking of why it's not a problem: Because the collision weakness is not a preimage weakness, the only way it's a problem for software download verification is if the person providing the download is untrustworthy.  If that person is untrustworthy, you're screwed anyway -- so it's an entirely superfluous weakness in that respect.  Even then, it would be extremely difficult for the person providing the download to come up with two working pieces of software, one innocuous and one malicious, that match the same MD5 hash.4. The newer article to which you linked is about password hashes, not download verification hashes.  The security landscape is somewhat different there, thus justifying giving a crap about the collision weakness in that context.  I even explained that in some detail in that article.5. 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.  You seem to have ignored that, however, and didn't bother to check the material until that same article appeared in your inbox in a TR newsletter (the URL you provided, ending in &quot;&amp;tag=nl.e036&quot;, indicates how you got to the article).  Additionally, when I quoted that article you decided that it somehow &quot;didn't count&quot; -- even though I was just using it to elucidate a point -- because it wasn't from the same article as the one to which you responded.  Somehow, though, it's okay for you to quote from my other articles -- from the same article, even.  What's up with that?6. I didn't write &quot;defensively&quot;.  I pointed out all the problems with your statements, starting with the one that suggested that I &quot;recommended&quot; MD5 over other algorithms.7. Even if I did write &quot;defensively&quot;, it's not entirely unwarranted considering the accusation implicit in the title of your first post in this discussion.edit: added some quotes]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-247349-2384115]]></guid>
        <dc:creator><![CDATA[apotheon]]></dc:creator>
        <pubDate>Fri, 14 Dec 2007 11:23:36 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[In your own words]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-247349-2383772]]></link>
        <description><![CDATA[@ChadIn your more recent blog entry:http://blogs.techrepublic.com.com/security/?p=377&amp;tag=nl.e036You seem to acknowledge the points I've made about the use of MD5:&quot;The problem with the MD5 hash algorithm is that it suffers from a collision weakness. This means that someone could generate two separate inputs that both produce the same hash output from the MD5 algorithm. There are some significant negative security implications for this. For instance, someone could create two files that produce the same cryptographic hash, one of which appears to be innocuous and the other of which matches the hash of the first but in some way defrauds or attacks someone who expects the innocuous message and uses the hash to verify it.&quot;====================So, what's going on here?  You bust my chops (at least write very defensively/derisively), but write a new blog entry agreeing with my comments?!?]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-247349-2383772]]></guid>
        <dc:creator><![CDATA[aikimark@...]]></dc:creator>
        <pubDate>Fri, 14 Dec 2007 05:46:17 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Windows MD5 tool]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-247349-2383462]]></link>
        <description><![CDATA[I use the free (looks like BSD-style license) software found here:http://www.fourmilab.ch/md5/Yeah, yeah... it's a CLI version.  It works, and it's tidy though.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-247349-2383462]]></guid>
        <dc:creator><![CDATA[chad.dailey@...]]></dc:creator>
        <pubDate>Thu, 13 Dec 2007 14:10:36 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Perhaps two hashes]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-247349-2383402]]></link>
        <description><![CDATA[If one is a software developer or cyber vendor, sharing files with others, it might be prudent to calculate and publish two different hash values.An example of this is:http://www.codeproject.com/KB/security/BlockCiphers.aspxWhile neither the MD5 nor SHA1 are considered cryptographically 'safe' at this point, using both is still sound.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-247349-2383402]]></guid>
        <dc:creator><![CDATA[aikimark@...]]></dc:creator>
        <pubDate>Thu, 13 Dec 2007 13:01:06 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Thanks for the info]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-247349-2382046]]></link>
        <description><![CDATA[That makes me feel a little warmer towards YUM.  And the discovery of YUM Extender has done much as well.  Why it is not installed by default I do not know, but the act of saving header information for each repository speeds up yum installs tremendously, this behavior should have been default, but at the same time, I can see why they chose to re-scan header info each time... irritating as that may be.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-247349-2382046]]></guid>
        <dc:creator><![CDATA[Dumphrey]]></dc:creator>
        <pubDate>Wed, 12 Dec 2007 07:08:48 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[yes]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-247349-2381311]]></link>
        <description><![CDATA[YUM, APT, and portupgrade all perform hash checking.  Fedora's YUM and Debian's APT each provide download verification using OpenPGP signatures.  FreeBSD's portupgrade double-checks itself, verifying by both MD5 and SHA256.The better automated software management systems are nice that way.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-247349-2381311]]></guid>
        <dc:creator><![CDATA[apotheon]]></dc:creator>
        <pubDate>Tue, 11 Dec 2007 09:46:23 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[If that's what you meant, it's not what you said.]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-247349-2381277]]></link>
        <description><![CDATA[&quot;What you might have written in an unlink/unreference article should not be used in your response. How are we to know that such articles exist and are relevant to this particular blog entry?&quot;I didn't realize this was a game with rules, and you wanted to win so badly.  I brought it up to point out that you seem to have misunderstood my point -- to reinforce the quote I provided from the article to which you directly responded, not as a point meant to stand alone.  Telling me that referencing other sources to demonstrate that is against the rules of your game is unlikely to convince me of anything other than that you have a petty need to prove people &quot;wrong&quot; about things.  Obviously, I hope that is not your motivation -- but I'm having a hard time coming up with a believable alternative interpretation right now.Also . . . I now realize that my presentation of my statements from the immediately preceding comment was not as clear as it could be.  Another reason for bringing up what was said in another article was to point out that you seemed to have mistaken my attempt to keep the article to which you responded on-topic (and the weaknesses of MD5 outside of verifying communications within a trust relationship are definitely off-topic for that article) for an implicit statement that the MD5 algorithm lacks weaknesses.&quot;My earlier comment in this thread should not be construed as a denigration of your original entry.&quot;Perhaps not the content of the comment -- but the title could be interpreted no other way, where you said &quot;You may want to rethink your MD5 recommendation&quot;.&quot;I think I read your blog entry 'closely' enough to understand it.&quot;I find that difficult to believe, considering I never recommended MD5 as a preferred cryptographic algorithm -- but you very clearly indicated that you thought I did so.Perhaps that wasn't your intent, but it's what you had accomplished.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-247349-2381277]]></guid>
        <dc:creator><![CDATA[apotheon]]></dc:creator>
        <pubDate>Tue, 11 Dec 2007 09:32:53 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[comment clarification]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-247349-2381031]]></link>
        <description><![CDATA[@apotheon&quot;Then, in my most recent article, I said:&quot;What you might have written in an unlink/unreference article should not be used in your response.  How are we to know that such articles exist and are relevant to this particular blog entry?===========I didn't disagree with your premise that MD5 is both ubiquitous and useful.  I thought that your blog entry readers should know that there has been some cryptographic research showing weaknesses in MD5.  Although it isn't broken, NIST has put it on their &quot;not for future use&quot; list and has a digest hash contest, similar to the crypto contest that gave use AES.===========My earlier comment in this thread should not be construed as a denigration of your original entry.  * &quot;generally useful&quot; is not in dispute.* MD5 status as de rigeur hash standard is not in dispute.  You use what is available.* Software downloads should ALWAYS be conducted in a trust relationship.  However, it would be advisable to scan for viruses after successful download prior to installation.===========I think I read your blog entry &quot;closely&quot; enough to understand it.  I had attempted to add valuable information to readers of this blog entry, not discount its content or denigrate its author.Thank you for allowing me to clarify my comments.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-247349-2381031]]></guid>
        <dc:creator><![CDATA[aikimark@...]]></dc:creator>
        <pubDate>Tue, 11 Dec 2007 06:07:50 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[RE: Use MD5 hashes to verify software downloads]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-247349-2381026]]></link>
        <description><![CDATA[Thanks for the blog, especially the link to digestIT, I have been using a similar product for while now called hash &amp;lt;nclick, which is only an md5 report for a given file, useful when moving large files etc to verify integrity, but no copy/paste which can be useful.One question, do you happen to know off the top of your head if the Fedora Yum manager performs hash checking?  I always assumed it did...]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-247349-2381026]]></guid>
        <dc:creator><![CDATA[Dumphrey]]></dc:creator>
        <pubDate>Tue, 11 Dec 2007 05:41:40 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[I think you're assuming something that wasn't said.]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-247349-2380657]]></link>
        <description><![CDATA[You may want to reread some of the article.  I said:&quot;While MD5 is not the strongest cryptographic hash tool in the world these days, it is still generally useful for verifying file integrity when downloading software.&quot;Then, in my most recent article, I said:&quot;Because downloading software involves an implicit trust in the provider of the software in the first place, the potential for abuse in file verification hashes is very slim. Because you do not get to choose the inputs that will match a given hash, you cannot simply generate two versions of a program ? one that is benign and one that is malign ? and use that to slip malware past someone?s defenses while providing an MD5 hash for verification that both software files match.&quot;On the other hand, because in authentication systems a password?s only function is to produce a given hash, and circumventing the security of the authentication system does not require tricking a human being into believing a second input to a given hash is the same as the first, the security implications of a hash algorithm?s collision weakness can be far greater than in the case of verifying a file download.&quot;You might also want to more closely read some of what you are citing.  From the Computerworld article:&quot;These results, while mathematically significant, aren't cause for alarm.&quot;. . . and, finally, I never specifically recommended using MD5 over other algorithms.  What I did is explain that the use of MD5 hashes for download verification is ubiquitous, and explain how to make use of it.  If you find a download with a verification hash provided by a better algorithm, have at it -- there are some that provide SHA-256 in addition to MD5, for instance.  Many, however, only use MD5.What are you going to do if a given download provides verification only via MD5?  You don't have many options.  On one hand, you can use it -- which is as safe as the place where you're downloading it.  On the other hand, you can choose to avoid it -- which is less safe, because now you aren't using anything to try to verify your download.Here's a key statement from today's article, to help you understand why this isn't the terrible security vulnerability you think it is:&quot;Because downloading software involves an implicit trust in the provider of the software in the first place, the potential for abuse in file verification hashes is very slim.&quot;. . . and, to wrap this up, here's my final sentence from this article about MD5 hash verification, with the part of the sentence that is actually relevant to the reason for what I do recommend bolded:&quot;Because so many open source software development projects use MD5 hashes for verification, it is a good idea to learn how to use it and keep an MD5 hash generating tool handy if you ever need to go outside of a secure software management system when installing software.&quot;Thanks for reading and commenting.  I wish you had read more closely.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-247349-2380657]]></guid>
        <dc:creator><![CDATA[apotheon]]></dc:creator>
        <pubDate>Mon, 10 Dec 2007 12:57:21 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[You may want to rethink your MD5 recommendation]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-247349-2380476]]></link>
        <description><![CDATA[While MD5 is convenient and pervasive, it may not be reliable.http://www.computerworld.com/printthis/2004/0,4814,95343,00.htmlhttp://www.schneier.com/blog/archives/2005/10/nist_hash_works_2.htmlNIST currently finds SHA-256 (and equivalents) to be reliable for a while.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-247349-2380476]]></guid>
        <dc:creator><![CDATA[aikimark@...]]></dc:creator>
        <pubDate>Mon, 10 Dec 2007 08:32:20 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[no such luck . . .]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-247349-2380425]]></link>
        <description><![CDATA[I'm not aware of any updated MD5 extensions for Firefox.  Try using the digestIT tool instead, if you need something for MS Windows.edit:  This might help, too.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-247349-2380425]]></guid>
        <dc:creator><![CDATA[apotheon]]></dc:creator>
        <pubDate>Mon, 10 Dec 2007 07:48:05 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Good idea only it's for old ver of Firefox]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-247349-2380315]]></link>
        <description><![CDATA[I like the idea. I went to the link, downloaded the windows version. It turns out that it only works with version 1.0. Oh well, lets try the other one noted as being for all platforms. Hmmm, only compatible with version 1.4.Is there a version somewhere that is compatible with 2.x?]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-247349-2380315]]></guid>
        <dc:creator><![CDATA[harrylal]]></dc:creator>
        <pubDate>Mon, 10 Dec 2007 06:44:47 -0800</pubDate>
    </item>
    </channel>
</rss>

