In message <Pine.LNX.4.30.0104031615270.8678-100000 at holly.crl.go.jp>, Tom Holro yd writes:>SRP has different requirements from Diffie-Hellman. In particular, >for SRP the generator must be primitive. It turns out that the "primes" >file contains only safe primes with primitive generators, and is thus >ideal for SRP, but so far in OpenSSH it has only been used for DH, >which doesn't require this.The primes file is used for the Diffie-Hellman group exchange. If you read the draft, you will see that safe primes are required and that the generators all generate the full sub-group size q.>As a side issue, the SRP patch compiles the primes into libssh, and >provides a function srp_get_param() which could be used to replace the >file-reading code that is currently in dh.c, as well as an is_safe_group() >function that can be used to check DH parameters*. This removes >the requirement of having to install an extra configuration file.I do not see that as a benefit. The purpose of having an extra file is that you can use new groups without recompiling the binaries.>* This is not currently done in OpenSSH -- in fact as far as I can tell, >using the DH_GEX_SHA1 key exchange method, an attacker can send a modulus >that is not prime (only the length is checked). Is this not a problem?No. It is not a problem. You have to trust the server already for everything that you do. If you do not trust your server, I suggest that you do not connect to it. niels.
On Tue, 3 Apr 2001, Niels Provos wrote:> The primes file is used for the Diffie-Hellman group exchange. If > you read the draft, you will see that safe primes are required and > that the generators all generate the full sub-group size q.The draft says, for p = 2q + 1, the order has to be _either_ q or p - 1. 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. 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.) 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).> >As a side issue, the SRP patch compiles the primes into libssh ... > >This removes the requirement of having to install an extra > >configuration file. > I do not see that as a benefit. The purpose of having an extra file > is that you can use new groups without recompiling the binaries.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. It is not necessary to embed the primes in the binary, but some people like to have as few configuration files as possible. Since SRP can't use the primes file directly, we'd need to have another file (likely ETCDIR/verifier.conf) that contains all the same values (plus the libsrp values). Is retiring primes likely to be an issue? Dr. Tom Holroyd "I am, as I said, inspired by the biological phenomena in which chemical forces are used in repetitious fashion to produce all kinds of weird effects (one of which is the author)." -- Richard Feynman, _There's Plenty of Room at the Bottom_
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.