> -----Original Message----- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf > Of Andrey Jivsov > Sent: Monday, April 08, 2013 6:46 PM > To: ipsec@ietf.org > Subject: Re: [IPsec] NUDGE: WG Last Call for draft-ietf-ipsecme-dh-checks > > Sec 2.2: > > It MUST check both that the peer's public value is in range (1 < r > > < p-1) and that r**q = 1 mod p (where q is the size of the > > subgroup, as listed in the RFC). > > Would it make sense to specify a more economical test for strong prime > groups?
"Strong groups", that is, groups with (p-1)/2 prime, are listed in section 2.1; and yes, the test there is considerably cheaper. > > If q is meant to be p = q*2+1, there are only two possibilities for the value > < > p-1 received from the peer to be in the wrong subgroup. One of them is 1, > which is ruled out by the check above. Another one is g^q. > It's a fixed quantity for the given modp group. Seems like a memcmp with a > fixed quantity g^q is the best way to address the problem. Actually, g^q == 1; I don't think that's what you mean. Now, there is certainly the possibility of the value being in the wrong subgroup; but there are far more than two possibilities. Here's the entire list for strong groups: 1; that's rejected by the test in section 2.1 p-1; that's also rejected by the test in section 2.1 primitive elements; those are elements r which have order p-1. These are not rejected by the test. (in addition, there are KE values that don't correspond to actual group elements; 0 and values >= p; those are rejected too). Now, there are q-1 different primitive elements; that's more than we could reasonably list. We could specify a test to reject primitive elements; however, that test isn't cheap (it can be done cheaper than the full r**q==1 test, nevertheless, not cheaply. In addition, an attacker injecting a primitive element could use it to deduce the lsbit of the private exponent; however that cannot deduce any more than that. I don't believe that the expense of the full test is worth protecting one bit of the exponent. > > On 04/08/2013 02:46 PM, Paul Hoffman wrote: > > [[ So far, we have received only *one* review of this document, from > > Tero. If we don't receive more reviews, the document might not > > progress due to lack of interest. Please review this document within > > the next week and contribute your review to the list. ]] > > > > Greetings. This is the start of the WG Last Call for > > draft-ietf-ipsecme-dh-checks; the WG period will end in two weeks, on > > April 15. The current draft is available at > > http://tools.ietf.org/html/draft-ietf-ipsecme-dh-checks-01 > > > > Given that this will be a Standards Track document, it is important for it > > to > be reviewed by as many people as possible. Possible results of individual > reviewing the document are: > > > > - "Looks fine, please publish" > > > > - "Looks fine, here are some comments" > > > > - "Has some problems, here they are" > > > > - Other things of that sort > > > > Many people on this mailing list are IPsec implementers but are mostly or > completely silent on the mailing list. If you are one of those people, doing a > WG Last Call review is a good way to participate usefully in the WG. Please > strongly consider (a) reading the current draft and (b) sending a message to > the list with your short or long review. If there are too few reviews on this > document, we could get pushback from the IESG about the document. > > > > --Paul Hoffman > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
