On Thu, Oct 14, 1999 at 10:54:12AM +0100, Ben Laurie wrote:
> Lutz Jaenicke wrote:
> SSL_IS_EXPORT checks for either, so this isn't the problem.
Ok, spend some more hours walking through ssl_ciph.c and I think by now
I do know what is going on :-)
When assembling the list of ciphers, the default list is assembled using the
following rule:
#define SSL_DEFAULT_CIPHER_LIST "ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP"
Now, "+EXP" is expanded to
#define SSL_TXT_EXP40 "EXP"
the the 40 bit information, which is later applied together with SSL_EXP_MASK
in ssl_ciph.c. SSL_EXP_MASK however covers two bits:
#define SSL_EXP_MASK 0x00300000L
#define SSL_EXP40 0x00100000L
#define SSL_NOT_EXP 0x00200000L
#define SSL_EXP56 0x00300000L
, the "EXP40"-bit and the "NOT_EXP"-bit. EXP56 uses both bits at the same time,
meaning "EXPORT" and "NOT EXPORT" at the same time, what will be the cause
of the problem. (The macro SSL_IS_EXPORT is not the question here.
In ssl_ciph.c, at line 527, the bits are evaluated:
ma=mask & cp->algorithms;
As the result, for a 56bit cipher we get "ma=0x00300000L", for a 40bit cipher
we get "ma=0x00100000L".
In the next line, the test
if ((ma == 0) || ((ma & algorithms) != ma))
will sort out the 56bit cipher, because we test for "algorithms=0x00100000L"
and hence (0x00300000L & 0x00100000L) != 0x00300000L), such that the 56bit
cipher is not treated as an export cipher.
So far, so good, now the next problem arises:
If we use a rule like "+EXP56:+EXP", we will also fail, since the bit
0x00200000L is used for "NOT_EXPORT".
Using the same mathematics as before, a "NOT_EXPORT" algorithm will yield
ma=0x00200000L and the test will yield
(0x00200000L & 0x00300000L) == 0x00200000L,
so that a "NOT_EXPORT" cipher is handled like a 56bit cipher and both
types are mixed up during sorting.
Given the actual state of the source, I am not too sure on how to solve this
problem in a consistent manner, because of the use of the NOT_EXPORT bit.
It should be easy to handle the "export cipher"-recognition by using a
SSL_EXP40_MASK 0x00100000L, so that all those cyphers with this bit set
are moved to the end of the list.
Even better however would be to remove the "NOT_EXPORT" state of 0x00200000L
from the definitions. The logic would then be "if (!is_export) not_export."
What is your opinion?
Best regards,
Lutz
PS. While thinking about it: wasn't there a talk about a possible change of
US law with the possibility of exporting 64bit ciphers? How to code this
thing. It should at least be possible to sort by crypto strength: strongest
first.
--
Lutz Jaenicke [EMAIL PROTECTED]
BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
