John Gardiner Myers wrote:
>
> "Nelson B. Bolyard" wrote:
> > Inadequacies of SSL_SecurityStatus:
> 12. It reports 3DES as having 168 bits of effective strength when it has
> only 112.
Sadly there is more than one definition of effective key size.
More on this below.
> Would it be reasonable to combine authKeyBits and keaKeyBits, with the
> function returning the lesser value? I'm concerned about confusion
> similar to that about the difference between key size versus secret key
> size. What does it matter that key exchange used 1024 bits if the peer
> only authenticated with 512 bits?
I think a decision to display the lesser of the two values (or something
different) ought to be made by the application, not the NSS library.
I think the NSS API should make the raw data (which is not available by
other means) available to the application. The application might have a
simplified "dumbed down" display for the average user, and a more detailed
display for the "advanced" user. If the application chooses to reduce the
amount of data it passes on to the user, that's fine, but the NSS API
shouldn't prevent the application from having access to the facts.
That reasoning argues for increasing, rather than decreasing, the number of
values returned for the symmetric crypto algorithm key size.
The old API returns: (this is pedantic for the benefit of other readers)
keysize - the total number of bits in the symmetric cipher's key.
It's the log (base 2) of the number of keys in the cipher's
entire key space.
secretkeysize - for SSL2, the number of bits in the master secret that
are transmitted encrypted (the rest are sent in the clear).
For both SSL2 and SSL3, secretkeysize is the log (base 2) of the number of
different symmetric encryption keys that can be derived from the (secret
portion of the) master secret, given that the clearly transmitted client and
server "random" values (and clear master secret bits for SSL2) are known.
The space occupied by all those keys is a subspace of the full symmetric
cipher's key space. This logarithm is one definition of "effective key size".
Another definition of effective key size is a measure of the "work effort"
required to determine a key for a known plaintext/ciphertext pair. It is a
log to the base 2 of the number of keys that must be tried (worse case) to
find the right key, given the best available cryptanalytic techniques (which
change over time). This number is always, in some sense, an estimate because
someone may have better cryptanalytic techniques than are publicly known.
For 3DES, these 3 values are 168, 168, and 112 (or less) respectively.
For RC4-40 they are 128, 40, and 40 .
For RC4-128 they are 128, 128, and 128 (as far as we know).
Perhaps we should return all 3 numbers. Any suggestions for better names?
> Perhaps separate numbers might make sense for DHE/RSA or RSA/DSA
> handshakes.
I think you're saying here that it might make sense when the algorithms
are different, as opposed to merely when the keys are different but the
algorithms are the same (e.g. RSA/RSA, as in export cipher suites). Yes?
It occurs to me that the same distinction between log2 of keyspace and
log2 of the subspace that can be derived also applies to some asymmetric
algorithms. For example, it is common for DH implementations to limit
themselves to only 160-bit private exponents. So, while the prime modulus
may be much longer than 320 bits, the number of actual secret keys that
can be derived from it may be only 2^320.
--
Nelson Bolyard Sun / Netscape Alliance
Disclaimer: I speak for myself, not for Netscape
