At a closer look,
the quantity g^k = g^(p-1)/2 is 1 or p-1, the values that are eliminated
by the check in section 2.1 for 1 < r < p-1. Given this, the check 1 < r
< p-1 is indeed a nice check for the small subgroup of the safe primes.
( This doesn't take care of a peer doing something silly and using small
exponents, but that's a generic problem. )
On 04/08/2013 05:17 PM, Andrey Jivsov wrote:
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: 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
