Re: Remove SHOULD for elliptic curve groups in IKEv2

["The Purple Streak (Hilarie Orman)" <ho@alum.mit.edu>]

The co-factor should not affect interoperability.  What is it about the
IKE state that caused a failure?

For the modp case, you do not need to do any cofactor checks with IKE.
Assuming you use a good random number generator, the probability of
choosing a value in the tiny subgroup is negligable.
It is less likely than choosing a DES weak key.  Furthermore, the
IKE generator will always be a square, thus protecting low order bits.

Hilarie

Andrey Jivsov wrote:

>>Your explanation of co-factors with ECC sheds no light on the matter
>>for me.
>>
> 
> Here is how I understand IKE implementing ECC DH should work.
> 
>     Initiator generates secret scalar x, calculates x*G and sends it to the
> responder in KE.
>     Responder generates secret scalar y, calculates y*G and sends it to the
> initiator in KE.
>     Both peers calculate x*y*G and use it in place of "g^xy" for SKEYID_xxx
> generation.
> 
>     '*' here is a scalar multiplication.
> 
> As it turns out, one well-known vendor interpreted "g^xy" as x*y*c*G. In
> this case cofactor multiplication changes the IKE state so that two
> implementations cannot interoperate. In addition, I mentioned before my
> concerns about patent(s) for cofactor multiplication.
> 
> 
>> I'll note as an aside that because IKE requires Sophie-Germain
>>primes, this is note an issue for modexp groups, either.
>>
> 
> This is a good analogy. I would like to see g^xy is interpreted the same way
> as it is interpreted for MODP groups, i.e. without cofactor multiplication
> in g^xy.
> 
> For MODP cofactor is always 2. This allows implementation to store constant
> value 2^(MOPD_prime-1)/2 for each MOPD_prime and then memcmp() received g^x
> with this value. If implementation checks for small g^x and g^xy, this
> covers the small subgroup attack for any MODP group.
> 
> For ECC Koblitz groups cofactor is 4, but similar checks can be performed.
> 
> 
> 
>