the "primes" file

[Niels Provos]

In message <Pine.LNX.4.30.0104041134530.12543-100000 at holly.crl.go.jp>, Tom Holr
oyd writes:
>On Tue, 3 Apr 2001, Niels Provos wrote:
>DH only requires the subgroup be of size q, but SRP requires that the
>subgroup be of size p - 1.  Now it turns out that the generators in the
>"primes" file all generate the full p - 1 group, and in fact the OpenSSL
>routine DH_generate_parameters() will always create parameters like this.
Ah.  I didn't remember that SRP required the whole group to be generated.
But you are right the program I use to generate the primes file
generates only primes with generators for the whole geoup.

>But it seems that it *is* allowed (according to the draft) that someday
>somebody will use a generator that generates the q subgroup but not the
>p - 1 subgroup.  (For example, the diffie-hellman-group1-sha1 prime uses a
>generator of 2, but this is unacceptable for SRP; libsrp uses this same
>prime with a generator of 5.)
That is true.  There is no reason to not allow a generator that generates
the large subgroup.  At least when you are looking at a DH key exchange.

>Thus SRP can't use the primes file directly -- although the embeded primes
>are built from it (but they are tested to make sure the subgroup is size
>p - 1 first).
You can probably use the primes file, and do some very quick filtering
along the lines of

  2   when p (mod 24) = 11.
  5   when p (mod 10) = 3 or 7.

That is the filter I use for the primes.

>The current SRP patch also reads from the system configuration file
>/etc/tpasswd.conf, both for compatibility with existing SRP installations
>and to address your concern.  So you can add new primes without
>recompiling.  However if you ever want to *retire* a prime, you must
>recompile.
That should not be a problem then.

>values).  Is retiring primes likely to be an issue?
Not really.  The only issue is one of variety.  Discourage precomputation
of any particular prime.

Niels.