See https://lamp1-sesa.citic74.net. The weak key check passes (length >= 512 bits) but SSL_GetChannelInfo reports the key length is 504 bits. I also found an instance of this at https://www.avinetmail.com last night but I can't reproduce it now. I have also noticed that SSL_GetChannelInfo sometimes reports key lengths 8 bits shorter for a variety of key lengths: 504 2 512 305 760 19 768 3577 1008 8 1016 2083 1024 457115 2040 2 2048 276 Also, should we be checking for only a single leading zero in ephemeral keys or do we need to strip all leading zeroes?

We should strip all leading zeroes in the dh_p parameter (the prime modulus).

Brian, I don't understand your table in comment 0. Is this frequency by key size? There are numerous interfaces that pass key lengths in BYTES, so when we need key lengths in bits, we multiply by 8, and do not subtract the number of leading 0 bits. This should account for up to 7 extra bits being falsely reported, but not 8. Note that there's a long story about the stripped leading bits in DHE results. PKCS#3 requires that the DHE result have exactly the same length (in bit) as prime P. Stripping it down by removing all leading zero bits, as done for SSL 3.{0,1,2}, was theoretically a mistake. The specification for ECDH and ECDHE explicitly requires that the result have the proper length without excessive stripping of leading zeros. During the production of the TLS 1.2 RFC, there was discussion about requiring PKCS#3 compliance for integer finite field (not EC) DHE, but I don't recall if that suggested change made it into the final RFC or not.

(In reply to comment #2) > Brian, > I don't understand your table in comment 0. Is this frequency by key size? Those are the frequencies of reported key sizes out of ~500,000 sites that negotiate DHE cipher suites. > Note that there's a long story about the stripped > leading bits in DHE results. I vaguely remember that. But, this isn't about leading zeros of the result; it is about leading zeros for P itself.