On Dec 3, 2007 11:07 AM, Per Hedeland <<a href="mailto:per@hedeland.org">per@hedeland.org</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Yes, this is basically what the originally referenced paper discusses.<br>The point is, as I described in the part of my message that you snipped,<br>that this is not how you use md5 (or any other hash) for integrity<br>checking. Both you and earlier Michael Regen (about the "funny"

<br>application invented by the guys that wrote the paper) use the word<br>"example" - and I have to wonder, example of what? Can either of you<br>point to any real-world application where the possibiliy to modify two

<br>inputs such that they produce the same hash actually is a problem *per<br>se*?<br></blockquote><div><br>I tried to point out that there are several applications for the use of hashes. For md5 (and others) some are broken (whenever the initial message was created by a source you cannot trust) and some are still fine (initial message was created by a trustworthy source). 

<br>In the case of md5 in Erlang's distribution mechanism I assume this falls into the second category: Fine and not broken.<br><br>Regarding your question<font size="-1"> - if I understood it correctly: Take a look at NIST and their FIPS 140-2 

</font><font size="-1">(</font>Security Requirements for Cryptographic Modules) <font size="-1">certification process</font><font size="-1">. Now assume I want to get certification for my OpenSSL version. Simplified: I prepare an innocent version of OpenSSL and the security policy (

<a href="http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp642.pdf">http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp642.pdf</a>) including hashes for my source code files (=initial message). Then NIST reviews and certifies it (

<a href="http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140crt/140crt642.pdf">http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140crt/140crt642.pdf</a>). Security is based on the assumption that I cannot create another (evil) version of OpenSSL source code with the same hash codes as provided in the security policy. Later you download my in the meanwhile changed OpenSSL version, check the hashes and assume everything is fine.

<br><br>I am puzzled that they are using HMAC-SHA1 in 2006 and even in 2007. </font><font size="-1">Did I miss anything? However, you get the point.</font><br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<br>By the way, this discussion really doesn't have much to do with Erlang,<br>I'm not sure why Joe posted here in the first place - except for one<br>thing that hasn't even been mentioned yet: The Erlang distribution

mechanism uses md5 in the authentication process. Of course it isn't "broken" (yet) either, but changing to a "better" hash function is obviously a good idea.</blockquote><div> I totally agree.

<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Then again, everyone seems to think that the<br>Erlang distribution is inherently unsafe anyway (for reasons that aren't

obvious to me at least)... <font color="#888888"> --Per Hedeland </blockquote></div> I can just talk about myself. And I simply do not know whether it is safe or not. I have not seen any reviews of it, neither bad nor good ones and I assume that its ability to withstand attacks is not tested much because I assume that most Erlang nodes are operated in a safe environment. Remember, even OpenSSH had it's troubles. One of the design goals of OpenSSH was to operate it in the wild. I do not know whether this was also one of the design goals of Erlang distribution. I tend to deny this since I read distribution_handshake.txt ("This is not entirelly safe, as it is vulnerable against takeover attacks, but it is a tradeoff between fair safety and performance.").

Erlang SSL distribution is currently broken. You cannot control which IP address epmd binds to... I think in the area of IT security you have to choose the defensive approach. You need a proof or very good hints that something is secure before you can assume it to be secure. Therefore I handle Erlang distribution as if it were unsafe.

<br><br>By the way I am only referring to open source Erlang. I cannot say anything about the commercial version of Erlang.<br><br>Cheers,<br>Michael<br><br><br>