Jean-Marc Desperrier wrote:
> Congratulation ! You have found something that strongly looks like a > regression that is present on SSL connexion for all mozilla.org products > since the timeframe between the release of Mozilla 1.5 and of Mozilla > 1.6, ie mz 1.5 is able to connect using EDH-RSA-DES-CBC3-SHA, and mz 1.6 > gives the -8092 error.
NSS versions 3.1 (the first fully open source version) through 3.8.x did not impose upper limits on the sizes of certain types of keys and key parameters. Consequently, it was possible to send data to NSS that caused it to begin computations that it would never finish, a denial of service attack. This was especially undesirable for products that run unattended.
So, in NSS 3.9 (which was first used in mozilla 1.7, IIRC) size limits were intentionally imposed on ALL keys and other parameters. These limits would cause operations to fail, rather than run for unacceptably long times, when those operations used keys that exceeded the limits. Rather than being a regression (which implies being unplanned), the introduction of the failures due to those limits was deliberate.
> It seems likely this regression is inside NSS.
The limits were and are imposed inside NSS.
Since DH and DSA use the same parameters and rely on the same mathentical hard problem for security, we chose to impose the same limits on DH as were imposed on DSA (in the definition of DSS). Indeed, the NSS code that generates DH parameters has always used the limits for DSS. The change in NSS 3.9 was to impose those same limits on keys and parameters received from outside of NSS.
Andrey reminded me of Lenstra's paper (5 years old now) which gives
a table predicting the minimum effective key sizes of various types of
algorithms, including discrete logs, necessary to stay ahead of the
advancing cryptanalytic and computational capabilities. Based on that
table, and the assumptions it embodies, discrete logarithms would become compuationally feasible for 1024-bit fields by 2002, implying that DH
and DSS should start using larger prime fields before then.
Lenstra's paper predicted that 1024-bit prime fields would become too weak long before the 160-bit hash size used in DSS would become a weakness. But NIST is already phasing out SHA-1 (long before 2013), but the present DSS still limits P to 1024 bits, long after 2002 (unless I've missed a new revision to DSS). This suggests to me that NIST has a different idea of the relative strengths of the different parameters than did Lenstra.
In any case, I observe that the limits we imposed on DH were relatively much lower than the limits we imposed on RSA. We imposed limits that were effectively 1x currect practice for DH, and 4x current practice on RSA (IIRC). so I think it is not unreasonable to raise the limit for DH prime size.
According to Lenstra's table a prime size of 2236 bits matches the current discrete log size limit of 160 bits, so I would consider raising DH_MAX_P_BITS to perhaps as much as 2236, but not more.
/Nelson _______________________________________________ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
