[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Regrouping for IPSEC WORKING GROUP LAST CALL



Hilarie,

>It's a big performance hit to take in response to a
>"*may* have flaws".

It is better to error on the side of better security.  I assume that some
of the same characteristics that allow you to factor the exponent to
improve computation speed may also provide better attacks.  I'm also not
sure that it is that big of a performance hit since there are many
interesting tricks to speed up elliptic curve computations.

It is difficult to argue the topic of what algorithm is "strong enough"
since stronger often means slower computations.

The specification currently has field sizes of  155 and 185 exponents.
ANSI has 163, 191, 239, 359 and 431.  ANSI strongly reccomends against
using field sizes less than 160!

So, I propose that in the current IKE draft that:

1) The current Oakley Group 3 (2^^155) be removed.

2) Two additional groups be added from the existing ANSI definitions (163
and 239).

3) The exisitng and new field descriptions should be tweeked to match
   the ANSI and IEEE format for describing the information (replacement
    text soon).

4) The 185 (group 4) should be removed, or if it remains, a
   security warning on the fears associated with non-prime groups
   should be included.

5) If the group feels that an exportable EC exchange is required that
   is akin to RSA 512 this could also be added (Perry, please no flames
   on export issues).




Regards,

Paul







ho@earth.hpc.org on 02/19/98 05:22:49 PM

To:   Paul Lambert/Certicom
cc:   ipsec@tis.com
Subject:  Re: Regrouping for IPSEC WORKING GROUP LAST CALL




The Oakley groups were chosen to optimize computation time; the
techniques don't work with prime exponents for the Galois field.
It's a big performance hit to take in response to a
"*may* have flaws".

Hilarie



Hilarie








Follow-Ups: