Sorry, I was scanning too quickly.
I meant section 2.1 primes, the primes in the form (renaming my earlier
definition) p = k*2+1.
Wouldn't receiving g^k be as much of a problem as receiving 1 for the
public value? No matter what my private exponent is, the shared secret
will be either of the two values.
On 04/08/2013 04:15 PM, Scott Fluhrer (sfluhrer) wrote:
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Andrey Jivsov
Sent: Monday, April 08, 2013 6:46 PM
To: [email protected]
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
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
