( just jumped onto the list ) nash <[EMAIL PROTECTED]> wrote: > How do you feel this differs from a participant simply pre-agreeing on his keys with the "passive attacker?"
There is not much difference, you are right. What we described is also a lot easier to detect ( are there actually ips signatures for this? ), but easier to implement and coordinate. > How does the threat differ from the participant simply forwarding the plaintext on a separate channel? The separate channel isn't necessary, that's the difference. > I mean, no key exchange protocol is magical. If one of the parties is a bad guy, then he can subvert the security objectives of the protocol every time. What are you really expecting DH to do, here? We are expecting the vendors who claim to sell highly secure equipment to follow extremely simple sanitation procedures as recommended by the NIST , ANSI , and various RFCs. > Blake-Wilson, et al., set out the authenticated key agreement problem > in this way: ... entity i wishes to agree on secret keying information with entity j. Each party desires an assurance that no party other than i and j can possibly compute the keying information agreed. > Your attack assumes that j is the "bad guy." That's not what Blake-Wilson seem to be talking about. I disagree. They're supposed to protect themselves. There is no assurance that no other party can compute the keying information if the keys aren't validated. Buggy software can send invalid keys, for instance. > This strikes me as sloppy academics at best, or deliberately misleading, at worst. I hope you were merely excited and in a rush, but either way you've thrown several red flags. This characterization is unnecessary. We are not a research organization and I am not an academic. We are simply pointing out that nobody is following the recommendations. I admit that the title of the blog post could have been less inflammatory. You also did not address the fact that DoS/MitM implementations don't need to compute the secret, so the processing power required to run them is a lot lower. -Adam Bozanch
_______________________________________________ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________