Andrey Jivsov wrote:
Actually, this step is to generate a strong prime for DH exchange, which is a long-term parameter. The actual DH exchange will be completed in the order of few ms on modern CPU.
Can that program generate a set of DSS PQG params with 2k bit P ? And does it do so faster than generating a sophie-germane prime for DH?
If so, you safely can use the P ang G from DSS for DHE, with less prime generation time.
Well, I find the issue of time is insignificant here. Many applications hard-code the prime into the source code. Some standards, like IKE, pre-define these primes, i.e. modp groups, so that the generation is impossible by design. This particular application, "openssl dhparam", allows to generate a prime usable for TLS that was needed to force "openssl s_server" module to use 2048 EDH. The default in "openssl s_server" is 1024.
I wouldn't look for time optimization during the prime generation -- if it takes one day to generate if for many years to come, then let it be so long.
The parameters in dhparams are just a generator=2 and a good prime. the "openssl dsagen" actually uses parameters from "openssl dhparams", so this would not help.
You may be right about the high percentage of SSL servers using 1024 EDH, but I think it is time to support stronger EDH.
Given that EDH keys (er, "private values") are used only once, the reward from breaking an inidividual EDH exchange is rather small. Consequently, I think that 1024-bit EDH is plenty strong enough for PFS purposes. And it's clear that only a *tiny* minority of SSL/TLS servers that use EDH use larger than 1024-bit primes. So, the benefit to the overall mozilla community of this change is small - that is, only a very small minority of mozilla users will ever benefit from it.
But if the cost of increasing the size of P is small enough, I have no
problem is increasing it, and in fact have done so. Julien persuaded me
that the server is in control of its own destiny with respect to DHE primes.
I think I disagree on the value of this change, mostly for issues other than cryptographic strength (Julien is right). If some server chose to be more cautious and implemented a larger EDH size that is considered to be within the resonable range, Mozilla as a client must support this range, or it will fail to interoperate with the server. If we agreed that the range is resonable, it is then Mozilla's fault. I wish group size parameter were a part of negotiation, but it is not. That means that to be tolerant to other implementations, Mozilla needs to support some resonable set of crypto parameters which is as close to the superset as possible. We may debate what the acceptable superset is for a long time, but 2048 bit modp group is part of it IMO.
Nelson mentioned that NSS cares about the size of NSS params because of DoS concern. In this case, there are other ways to tackle this. For example, implementation could limit stronger EDH groups only to stronger symmetrical algorithm sizes. That's my suggestion for interfacing with DH code generation -- the caller should tell the NSS what the max DH size is, so that NSS code can support a range close to the "superset". That's as close as one can get in parametarizing said TLS limitation.
The increased P size is now checked into the NSS 3.9 branch, from which NSS 3.9.3 is scheduled to be released next week. Hopefully we can get
mozilla.org to accept NSS 3.9.3 for use in firefox 1.0.
I filed the bug, please check it for more information:
http://bugzilla.mozilla.org/show_bug.cgi?id=259229
Thanks very much, Andrey, for doing that, and for looking into the source code enough to determine exactly where the limit was, and what source needed to change to lift it. You went FAR BEYOND what most users do in reporting that "bug", and your work is appreciated. Your reward is the fast turnaround on the checkin for that fix. Hope that's a satisfactory reward.
I also greatly appreciate that you ran a test server with which I could test the "fix". That saved me a lot of time, and enabled the checkin to come that much sooner. I truly appreciate that contribution. Test resources are just as valuable as contributed code, IMO.
Please feel welcome and invited to make more contributions to NSS.
That you for the quick fix, I am convinced that it is beneficial to everyone. We have few years before I will log a similiar bug again ;-) _______________________________________________ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
