Re: [SC-L] DH exchange: conspiracy or ignorance?
( 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. ___
Re: [SC-L] DH exchange: conspiracy or ignorance?
Since most, if not all implementations of DH key exchange are set to choose p and q from primes with several hundreds of digits, the chance of getting a zero or one is extremely small to non-existent. That aside the finding is, of course, an implementation weakness. Bjarne --- Bjarne Carlsen CTO I/S Mail2Net Denmark ons, 19 09 2007 kl. 11:31 -0400, skrev Evgeny Lebanidze: > Yes, this is certainly bad and a very interesting finding. These checks > should clearly be present. Are there serious practical ramifications of this > problem though? In other words, how likely is it that the generated public > key in the DH key exchange will actually be 0 or 1? It can certainly happen, > but our passive attacker would have to be passive for a very long time and > there is no guarantee that the secret key they might eventually get will be > of interest to them (since the attacker cannot control when a weak public key > is produced). Just a thought. > > Evgeny > > - > Evgeny Lebanidze > Senior Security Consultant, Cigital > 703-585-5047, http://www.cigital.com > Software Confidence. Achieved. > > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kowsik > Sent: Wednesday, September 19, 2007 1:24 AM > To: SC-L@securecoding.org > Subject: [SC-L] DH exchange: conspiracy or ignorance? > > http://labs.musecurity.com/2007/09/18/widespread-dh-implementation-weakness/ > > K. > > ps: I work for Mu. > ___ > 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. > ___ > > ___ > 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. > ___ ___ 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. ___
Re: [SC-L] DH exchange: conspiracy or ignorance?
| Yes, this is certainly bad and a very interesting finding. These | checks should clearly be present. Are there serious practical | ramifications of this problem though? In other words, how likely is | it that the generated public key in the DH key exchange will actually | be 0 or 1? It can certainly happen, but our passive attacker would | have to be passive for a very long time and there is no guarantee that | the secret key they might eventually get will be of interest to them | (since the attacker cannot control when a weak public key is | produced). Just a thought. What's special about an computed local value of 1 is that anyone can easily compute the log of 1: It's 0. (Note that a public key value of 0 is impossible - 0 isn't in the group. The same goes for any value greater than p-1. Checking for these isn't so much checking for security as checking for the sanity of the sender - if he sends such a value, he's buggy and shouldn't be trusted!) In typical implementations of DH, both the group and the generator are assumed to be public. In that case, anyone can generate a table of x, g^x pairs for as many x's as they resources to cover. Given such a table, a passive attacker can find log of the secret whenever the secret happens to be in the table. Of course, the group is chosen large enough that any conceivable table will only cover a tiny proportion of the possible values, so in practical terms this attack is uninteresting. The fact that two entries in the table (for x=0 and x=p-2) can be computed "in your head" (well, you might need a pencil and paper for the second) doesn't make the table any more of an viable attack mechanism. So the passive observer attack doesn't make much sense to me. Is there some other attack specific to these values that I'm missing? BTW, the paper suggest a second test, (K_a)^g = 1 (mod p). This test makes sense if you're working over a subgroup of Z* mod p (as is often, but not always, done). If you're working over the full group, any K_a between 1 and p-1 is "legal", so this can only test the common parameter g, which is fixed. That hardly seems worth doing - if the public parameters are bad, you're completely screwed anyway. -- Jerry | Evgeny | | - | Evgeny Lebanidze | Senior Security Consultant, Cigital | 703-585-5047, http://www.cigital.com | Software Confidence. Achieved. | | | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kowsik | Sent: Wednesday, September 19, 2007 1:24 AM | To: SC-L@securecoding.org | Subject: [SC-L] DH exchange: conspiracy or ignorance? | | http://labs.musecurity.com/2007/09/18/widespread-dh-implementation-weakness/ | | K. | | ps: I work for Mu. | ___ | 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. | ___ | | ___ | 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. | ___ | | ___ 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. ___
Re: [SC-L] DH exchange: conspiracy or ignorance?
Yes, this is certainly bad and a very interesting finding. These checks should clearly be present. Are there serious practical ramifications of this problem though? In other words, how likely is it that the generated public key in the DH key exchange will actually be 0 or 1? It can certainly happen, but our passive attacker would have to be passive for a very long time and there is no guarantee that the secret key they might eventually get will be of interest to them (since the attacker cannot control when a weak public key is produced). Just a thought. Evgeny - Evgeny Lebanidze Senior Security Consultant, Cigital 703-585-5047, http://www.cigital.com Software Confidence. Achieved. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kowsik Sent: Wednesday, September 19, 2007 1:24 AM To: SC-L@securecoding.org Subject: [SC-L] DH exchange: conspiracy or ignorance? http://labs.musecurity.com/2007/09/18/widespread-dh-implementation-weakness/ K. ps: I work for Mu. ___ 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. ___ ___ 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. ___
[SC-L] DH exchange: conspiracy or ignorance?
http://labs.musecurity.com/2007/09/18/widespread-dh-implementation-weakness/ K. ps: I work for Mu. ___ 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. ___
