Re: [openssl.org #2352] PATCH: Add new extended key usage ipsecIKE
2010/9/29 Micah Anderson via RT r...@openssl.org
According to RFC 4945 § 5.1.3.12 section title ExtendedKeyUsage[0] the
following extended key usage has been added:
... this document defines an ExtendedKeyUsage keyPurposeID that MAY be
used to limit a certificate's use:
id-kp-ipsecIKE OBJECT IDENTIFIER ::= { id-kp 17 }
where id-kp is defined in RFC 3280 [5]. If a certificate is intended
to be used with both IKE and other applications, and one of the other
applications requires use of an EKU value, then such certificates
MUST contain either the keyPurposeID id-kp-ipsecIKE or
anyExtendedKeyUsage [5], as well as the keyPurposeID values
associated with the other applications. Similarly, if a CA issues
multiple otherwise-similar certificates for multiple applications
including IKE, and it is intended that the IKE certificate NOT be
used with another application, the IKE certificate MAY contain an EKU
extension listing a keyPurposeID of id-kp-ipsecIKE to discourage its
use with the other application. Recall, however, that EKU extensions
in certificates meant for use in IKE are NOT RECOMMENDED.
Conforming IKE implementations are not required to support EKU. If a
critical EKU extension appears in a certificate and EKU is not
supported by the implementation, then RFC 3280 requires that the
certificate be rejected. Implementations that do support EKU MUST
support the following logic for certificate validation:
o If no EKU extension, continue.
o If EKU present AND contains either id-kp-ipsecIKE or
anyExtendedKeyUsage, continue.
o Otherwise, reject cert.
I believe that the attached patch adds the ipsecIKE extended key usage
flag to openssl.
Micah
0. http://tools.ietf.org/html/rfc4945#section-5.1.3.12
Hi,
I took a look at your patch just by curiosity because I can't judge it.
However, there is a wrong copy/paste in obj_dat.h, even though this file is
generated automatically :
0x2B,0x06,0x01,0x05,0x05,0x07,0x03,0x08, /* *[682]* OBJ_time_stamp */
+0x2B,0x06,0x01,0x05,0x05,0x07,0x03,0x09, /* *[682]* OBJ_OSCPSigning */
+0x2B,0x06,0x01,0x05,0x05,0x07,0x03,0x17, /* [684] OBJ_ipsecIKE */
0x2B,0x06,0x01,0x04,0x01,0x82,0x37,0x02,0x01,0x15,/* [690] OBJ_ms_code_ind
*/
0x2B,0x06,0x01,0x04,0x01,0x82,0x37,0x02,0x01,0x16,/* [700] OBJ_ms_code_com
*/
0x2B,0x06,0x01,0x04,0x01,0x82,0x37,0x0A,0x03,0x01,/* [710] OBJ_ms_ctl_sign
*/
@@ -1091,6 +1090,8 @@ static const ASN1_OBJECT nid_objs[NUM_NID]={
{emailProtection,E-mail Protection,NID_email_protect,8,
(lvalues[674]),0},
{timeStamping,Time Stamping,NID_time_stamp,8,(lvalues[682]),0},
+{OSCPSigning, OSCP Signing,NID_OSCPSigning,8,(lvalues*[683]*),0},
+{ipsecIKE, ipsec Internet Key Exchange
(IKE),NID_ipsecIKE,8,(lvalues[684]),0},
Re: Already generated files are not generated a second time because they already exist
2010/9/22 Dr. Stephen Henson st...@openssl.org On Tue, Sep 21, 2010, Gregory Bellier wrote: Hi all ! I'm currently playing with openssl-0.9.8o to add a cipher in it (just for fun). I noticed in crypto/objects that 2 files (obj_dat.h and obj_mac.h) are automatically generated from scripts which read obj_mac.num and objects.txt. Therefore I did not update manually obj_dat.h and obj_mac.h. However, when I run make I get errors. Those errors are from obj_dat.h and obj_mac.h because they were not updated whereas it was supposed to be done automatically. The scripts didn't run. For ciphers already included, these errors are not triggered because the released tarball contains obj_dat.h and obj_mac.h already up-to-date. The question is, is this a normal behaviour ? In my opinion, it isn't. Those files aren't updated because they already exist. To build correctly OpenSSL, I have to rm -f obj_dat.h obj_mac.h. Then when I run make, the scripts are executed and those two files are correctly created. So, if I add a new symetric cipher, to be able to run a correct make test what would be the right thing to do : - add the cipher, update those 2 files manually and run config/make/make test. Therefore, whar's the point of automatically generated ? - add the cipher, run the scripts manually and config/make/make test - add the cipher, delete those files and config/make/make test. If it's not either one of those 3 possibilities, then I think there is a problem. I'd like to have your opinion on this matter. I hope I made myself clear. You should only have to modify objects.txt, the others are all updated from it. That's the point, the others are not updated if all the files have the same date. That's what I figured out and said in my last email (not the one you replied from) That said it isn't a good idea to modify objects.txt locally because the generated NIDs will clash with future OpenSSL additions in official releases resulting in binary incompatibility. Agreed. A better way is to create a NID dynamically using OBJ_create() and use that instead. Could you be more specific and give some more details ? Regards, Gregory.
Already generated files are not generated a second time because they already exist
Hi all ! I'm currently playing with openssl-0.9.8o to add a cipher in it (just for fun). I noticed in crypto/objects that 2 files (obj_dat.h and obj_mac.h) are automatically generated from scripts which read obj_mac.num and objects.txt. Therefore I did not update manually obj_dat.h and obj_mac.h. However, when I run make I get errors. Those errors are from obj_dat.h and obj_mac.h because they were not updated whereas it was supposed to be done automatically. The scripts didn't run. For ciphers already included, these errors are not triggered because the released tarball contains obj_dat.h and obj_mac.h already up-to-date. The question is, is this a normal behaviour ? In my opinion, it isn't. Those files aren't updated because they already exist. To build correctly OpenSSL, I have to rm -f obj_dat.h obj_mac.h. Then when I run make, the scripts are executed and those two files are correctly created. So, if I add a new symetric cipher, to be able to run a correct make test what would be the right thing to do : - add the cipher, update those 2 files manually and run config/make/make test. Therefore, whar's the point of automatically generated ? - add the cipher, run the scripts manually and config/make/make test - add the cipher, delete those files and config/make/make test. If it's not either one of those 3 possibilities, then I think there is a problem. I'd like to have your opinion on this matter. I hope I made myself clear. Regards, Gregory.
Re: Already generated files are not generated a second time because they already exist
Le 21/09/2010 17:57, Martin Kaiser a écrit : Thus wrote Gregory Bellier (gregory.bell...@gmail.com): I noticed in crypto/objects that 2 files (obj_dat.h and obj_mac.h) are automatically generated from scripts which read obj_mac.num and objects.txt. Therefore I did not update manually obj_dat.h and obj_mac.h. However, when I run make I get errors. Those errors are from obj_dat.h and obj_mac.h because they were not updated whereas it was supposed to be done automatically. The scripts didn't run. For ciphers already included, these errors are not triggered because the released tarball contains obj_dat.h and obj_mac.h already up-to-date. The question is, is this a normal behaviour ? In my opinion, it isn't. Those files aren't updated because they already exist. To build correctly OpenSSL, I have to rm -f obj_dat.h obj_mac.h. Then when I run make, the scripts are executed and those two files are correctly created. I've just had a quick look at 0.9.8k's crypto/objects/Makefile, there's a dependency between obj_mac.h and objects.txt obj_mac.h: objects.pl objects.txt obj_mac.num $(PERL) objects.pl objects.txt obj_mac.num obj_mac.h Changing one character in objects.txt and calling make in the top-level directory causes the perl script to run. What operating system are you using? I recall seeing a problem in this area on Windows with an mk1mf build where everything is copied into one large Makefile. I'm using GNU/Linux and I am totally confused ! You are right, I modified an OID from objects.txt from the tarball and obj_dat.h and obj_mac.h got updated. However, I added some stuff in this file, how come is it not taken into account ? Moreover, I got it to build with a objects.txt and I saved it in a corner with its hash. I copied this modified objects.txt into my clean working folder. Checked the hash one more time, committed my changes and then copied my whole directory to do try to build and rechecked the hash. Guess what, it still doesn't build because the script doesn't run. Let's test one more time. I copied my clean folder and then I copied objects.txt. Basically, the exact same file is overwritten. It built! Sorry, this email was written in several times but I left what I already typed in case it could be useful. I think I figured it out. I did 2 builds in parallel : - First test, as I said, I copied my clean working directory and I started to build. I expected it to fail and it did. - Second test, I copied my clean working directory and overwritten. I expected the build to succeed and it did. To put the whole matter in a nutshell, it's just a story of date. When I copied my working folder, all the files in the new folder had the same date. Therefore the script didn't run. A simple : cp objects.txt objects2.txt ls -l [wait a minute to see the time difference] cp objects2.txt objects.txt rm objects2.txt is enough to make it work. I think something is wrong here. Gregory. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: TLS and bad record mac
Tim Hudson a écrit : Gregory BELLIER wrote: I added a cipher in OpenSSL and NSS. I would like to send an email with SMTPs from a modified Thunderbird (because of NSS) to a postfix. The TLS negociation is between NSS and OpenSSL. [snip] Do you have any hint in what could be wrong? Use the -state -debug flags for s_client and s_server to trace each end when your modified NSS is at the other end. That will provide you with a lot more information to assist in figuring out what you've done wrong in the code. i.e. point modified thunderbird at a modified s_server with -state -debug enabled. Tim. Thanks for your comments, I'll look into that. Greg. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
TLS and bad record mac
Hello, I added a cipher in OpenSSL and NSS. I would like to send an email with SMTPs from a modified Thunderbird (because of NSS) to a postfix. The TLS negociation is between NSS and OpenSSL. However, I get the following error: Mar 18 19:40:15 pico postfix/smtpd[3842]: SSL3 alert write:fatal:bad record mac Mar 18 19:40:15 pico postfix/smtpd[3842]: SSL_accept:error in SSLv3 read certificate verify A Mar 18 19:40:15 pico postfix/smtpd[3842]: SSL_accept error from unknown[10.0.0.69]: -1 Mar 18 19:40:15 pico postfix/smtpd[3842]: warning: TLS library problem: 3842:error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac:s3_pkt.c:422: Mar 18 19:40:15 tcc postfix/smtpd[3842]: lost connection after STARTTLS from unknown[10.0.0.69] Google haven't been helpful. I manage to have a working TLS when I use openssl s_server, s_client. I believe part of the negociation works, I mean they do recognize the OID. In Thunderbird, I put a printf at the entrance of the cbc encryption and it gets printed, meaning it enters in the right cipher. I don't think it's a decryption failure because of the working tunnel and above all, the first line I copied here : bad record mac. What does it mean exactly? Do you have any hint in what could be wrong? Thanks in advance for your help, Gregory. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Ciphers and modes of operation
Thank you both,
it now works.
Thank you for your time, you've been helpful.
Grégory BELLIER.
Cheng, Weidong a écrit :
Hi Gregory:
Stephen already commented on your email. In your case, it may be
better to go through an engine implementation instead of the current
solution. In this case, you needn’t to worry about what you have
missed to fill up.
Weidong
*From:* owner-openssl-...@openssl.org
[mailto:owner-openssl-...@openssl.org] *On Behalf Of *Gregory BELLIER
*Sent:* Wednesday, February 24, 2010 3:07 AM
*To:* openssl-dev@openssl.org
*Subject:* Re: Ciphers and modes of operation
Hello Weidong and Stephen,
thank you for your attention. You're right, I should have given more
details.
Here we go.
I'm not trying to delete a standard cipher but to add one. At this
point, it builds correctly but the make tests fails at some point.
Therefore, I try to find where the problem could be.
There are 2 points, I would like to ask you.
_1°) Modes of operation
_I already asked you if it's mandatory to have all the modes of
operations for all the ciphers. Until now, I used a bunch of code
which is below in evp/e_myc.c otherwise, it doesn't build because
ecb/cfb/ofb declarations are missing.
I did this because the only operation mode I would need is CBC.
However, I'm not sure if what I did is correct. I started suspecting
this part because of the error I have at point n°2. I've spent a lot
of time to study the implementation of Camellia and SEED, and I feel
like the rest of the integration is correct. Even though I had a doubt
about the SSL_ENC_MASK as you can see in my last thread of discussion.
Which means, the only part where my implementation is different than
anything I've seen is in this evp file.
So please, if you have time, take a look at this code sample, maybe
you'll notice something in just a glance.
#define BLOCK_CIPHER_def_dyna(cname, nmode, mode, MODE, kstruct, nid,
block_size, \
key_len, iv_len, flags, init_key, cleanup, \
set_asn1, get_asn1, ctrl) \
static EVP_CIPHER cname##_##mode = { \
nid##_##nmode, block_size, key_len, iv_len, \
flags | EVP_CIPH_##MODE##_MODE, \
init_key, \
cname##_##mode##_cipher, \
cleanup, \
sizeof(kstruct), \
set_asn1, get_asn1,\
ctrl, \
NULL \
}; \
#define IMPLEMENT_BLOCK_CIPHER_CBC(cname, ksched, cprefix, kstruct, nid, \
block_size, key_len, iv_len, cbits, \
flags, init_key, \
cleanup, set_asn1, get_asn1, ctrl) \
BLOCK_CIPHER_func_cbc(cname, cprefix, kstruct, ksched) \
BLOCK_CIPHER_def_dyna(cname, cbc, cbc, CBC, kstruct, nid, 0, 0, 0, \
flags, init_key, cleanup, set_asn1, get_asn1, ctrl)
IMPLEMENT_BLOCK_CIPHER_CBC(myc, ks, MYC, EVP_MYC_KEY,
NID_myc, 16, MYC_KEY_LENGTH,16, 128,
EVP_CIPH_VARIABLE_LENGTH, myc_init_key, NULL,
EVP_CIPHER_set_asn1_iv, EVP_CIPHER_get_asn1_iv, NULL)
const EVP_CIPHER *EVP_myc_cbc(void)
{
myc_cbc.block_size = 16;
myc_cbc.iv_len = 16;
myc_cbc.key_len = 32;
return myc_cbc;
}
_2°) The make tests errors
_This is the whole deal and the errors I get :
t1_enc.c:661 - 1 - BAD because i=90 rec-length=48
s3_pkt.c:350 - 1 - BAD
t1_enc.c - md_size = 20
s3_pkt.c - 4 - BAD
ERROR in SERVER
28934:error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or
bad record mac:s3_pkt.c:429:
ERROR in SERVER
28934:error:140A4044:SSL routines:SSL_clear:internal error:ssl_lib.c:183:
28934:error:1408A044:SSL routines:SSL3_GET_CLIENT_HELLO:internal
error:s3_srvr.c:725:
And it goes on like this for a couple of times.
I left some fprintf I did so it can help you to understand.
- This is from t1_enc.c:661 :
/* TLS 1.0 does not bound the number of padding bytes by the block size.
* All of them must have value 'padding_length'. */
if (i (int)rec-length)
{
/* Incorrect padding. SSLerr() and ssl3_alert are done
* by caller: we don't want to reveal whether this is
* a decryption error or a MAC verification failure
* (see http://www.openssl.org/~bodo/tls-cbc.txt
http://www.openssl.org/%7Ebodo/tls-cbc.txt) */
fprintf(stderr, t1_enc.c - 1 - BAD because i=%d rec-length=%d\n,
i, (int)rec-length );
return -1;
}
- This is from s3_pkt.c:350
if (enc_err = 0)
{
if (enc_err == 0)
/* SSLerr() and ssl3_send_alert() have been called */
goto err;
/* Otherwise enc_err == -1, which indicates bad padding
* (rec-length has not been changed in this case).
* To minimize information leaked via timing, we will perform
* the MAC computation anyway. */
fprintf(stderr,s3_pkt.c - 1 - BAD \n);
decryption_failed_or_bad_record_mac = 1;
}
- This is from s3_pkt.c:411
if (mac == NULL || memcmp(md, mac, mac_size) != 0)
{
fprintf(stderr,s3_pkt.c - 4 - BAD);
if (mac == NULL)
fprintf(stderr, - Mac is NULL);
fprintf(stderr, \n);
decryption_failed_or_bad_record_mac = 1;
}
}
As you can see, this last printf Mac is NULL is not printed.
I hope you won't be drowned by this flaw of information but I also
hope I gave you enough information so you could be able to give me a hand.
Regards
Re: Ciphers and modes of operation
: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Gregory BELLIER Sent: Tuesday, February 23, 2010 8:48 AM To: openssl-dev@openssl.org Subject: Re: Ciphers and modes of operation I did some tests and it failed to build if I don't declare all the operation modes. Do you have any ideas how I could proceed ? Thanks. Cheng, Weidong a écrit : Hi, Gregory; Yes. You could implement some of them. Regards, Weidong -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Gregory BELLIER Sent: Tuesday, February 23, 2010 7:45 AM To: openssl-dev@openssl.org Subject: Ciphers and modes of operation Hello. Simple question, is it mandatory to declare the cbc, ecb, cfb, ofb for each cipher or is it possible to only declare and implement some of them (let's say ecb and cbc) ? Regards, Grégory BELLIER. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Ciphers and modes of operation
I forgot to mention that what I do is based on OpenSSL-0.9.8l Grégory. Cheng, Weidong a écrit : Please give more information as Stephen suggested. -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Gregory BELLIER Sent: Tuesday, February 23, 2010 8:48 AM To: openssl-dev@openssl.org Subject: Re: Ciphers and modes of operation I did some tests and it failed to build if I don't declare all the operation modes. Do you have any ideas how I could proceed ? Thanks. Cheng, Weidong a écrit : Hi, Gregory; Yes. You could implement some of them. Regards, Weidong -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Gregory BELLIER Sent: Tuesday, February 23, 2010 7:45 AM To: openssl-dev@openssl.org Subject: Ciphers and modes of operation Hello. Simple question, is it mandatory to declare the cbc, ecb, cfb, ofb for each cipher or is it possible to only declare and implement some of them (let's say ecb and cbc) ? Regards, Grégory BELLIER. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Ciphers and modes of operation
Dr. Stephen Henson a écrit :
On Wed, Feb 24, 2010, Gregory BELLIER wrote:
Hello Weidong and Stephen,
So please, if you have time, take a look at this code sample, maybe you'll
notice something in just a glance.
#define BLOCK_CIPHER_def_dyna(cname, nmode, mode, MODE, kstruct, nid,
block_size, \
key_len, iv_len, flags, init_key, cleanup, \
set_asn1, get_asn1, ctrl) \
static EVP_CIPHER cname##_##mode = { \
nid##_##nmode, block_size, key_len, iv_len, \
flags | EVP_CIPH_##MODE##_MODE, \
init_key, \
cname##_##mode##_cipher, \
cleanup, \
sizeof(kstruct), \
set_asn1, get_asn1,\
ctrl, \
NULL \
}; \
#define IMPLEMENT_BLOCK_CIPHER_CBC(cname, ksched, cprefix, kstruct, nid, \
block_size, key_len, iv_len, cbits, \
flags, init_key, \
cleanup, set_asn1, get_asn1, ctrl) \
BLOCK_CIPHER_func_cbc(cname, cprefix, kstruct, ksched) \
BLOCK_CIPHER_def_dyna(cname, cbc, cbc, CBC, kstruct, nid, 0, 0, 0, \
flags, init_key, cleanup, set_asn1, get_asn1, ctrl)
IMPLEMENT_BLOCK_CIPHER_CBC(myc, ks, MYC, EVP_MYC_KEY,
NID_myc, 16, MYC_KEY_LENGTH,16, 128,
EVP_CIPH_VARIABLE_LENGTH, myc_init_key, NULL,
EVP_CIPHER_set_asn1_iv, EVP_CIPHER_get_asn1_iv,
NULL)
const EVP_CIPHER *EVP_myc_cbc(void)
{
myc_cbc.block_size = 16;
myc_cbc.iv_len = 16;
myc_cbc.key_len = 32;
return myc_cbc;
}
Just a comment about that and a point of reference for anyone who might also
want to implement a cipher. All this IMPLEMENT/DECLARE business is done
internally so we can defined many cipher structures which are almost identical
and any changes to them need only a macro change and not having to manually
update over a hundred definitions as well.
If you define your own cipher you don't and arguably shouldn't do that because
it can be difficult to see what is going on. You can just define the
EVP_CIPHER structure manually. There is an example of this manual cipher
definition in crypto/evp/e_xcbc_d.c
One thing to note is that OpenSSL expects a cipher to function correctly if
the input and output buffers are the same (i.e. to cipher in place).
I'd suggest testing with something like the 'enc' utility at first to see if
you can encrypt/decrypt data sensibly. If you have any test vectors then try
those too.
In fact, I don't need to redefine it but I can't find a way to do
otherwise. If I don't do so, I get an error about the modes of operation
I didn't declare.
The testenc runs fine :
sh ./testenc
[...]
myc
myc base64
myc-cbc
myc-cbc base64
Therefore, because I don't implement/declare all the modes of operation,
I guess I have to define the EVP_CIPHER structure manually.
But, I know I don't do it well but it works. At least, from the
beginning of the make tests to the error.
I'll try however what you suggest.
Do you think what I've done could be the cause of the bug ?
Ciphers and modes of operation
Hello. Simple question, is it mandatory to declare the cbc, ecb, cfb, ofb for each cipher or is it possible to only declare and implement some of them (let's say ecb and cbc) ? Regards, Grégory BELLIER. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Ciphers and modes of operation
I did some tests and it failed to build if I don't declare all the operation modes. Do you have any ideas how I could proceed ? Thanks. Cheng, Weidong a écrit : Hi, Gregory; Yes. You could implement some of them. Regards, Weidong -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Gregory BELLIER Sent: Tuesday, February 23, 2010 7:45 AM To: openssl-dev@openssl.org Subject: Ciphers and modes of operation Hello. Simple question, is it mandatory to declare the cbc, ecb, cfb, ofb for each cipher or is it possible to only declare and implement some of them (let's say ecb and cbc) ? Regards, Grégory BELLIER. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
SSL_ENC_MASK since SEED
Hello. I'm studying some parts of the OpenSSL code and I now have a question. In ssl/ssl_locl.h, I'm wandering if the #define SSL_ENC_MASK is right. Before the Camellia was added (0.9.8b), we had : #define SSL_ENC_MASK 0x0*4*3F8000L In 0.9.8c: #define SSL_ENC_MASK 0x0*C*3F8000L From 4 to C - +8 I guess, that each time you add a new cipher, the SSL_ENC_MASK is +8. I may guess wrong, please correct me so I can learn. However, the SSL_ENC_MASK in 0.9.8f is 0x1C3F8000L because of the new cipher which is SEED. - I would have thought the new mask should have been 0x143F8000L since SEED. - In the case I misunderstand and that the current mask is the good one, what should the next one be ? 0x253F8000L or 0x2C3F8000L ? Regards, Grégory BELLIER.
Re: SSL_ENC_MASK since SEED
Thanks Mounir but you didn't exactly answer my question. I noticed Camellia and SEED. My question was about how to define the mask according to a new cipher. That's why I've already taken a look at the last 2 entries. However, if a new algorithm makes it in OpenSSL, what would the mask be ? I guess it would be 0x2C3F8000L because the new algorithm would be declared with 0x2000. But I'm not sure and wondering if I miss something. Mounir IDRASSI a écrit : Hi, SSL_ENC_MASK is a bit mask. Each time a new algorithm is added, a new bit est positioned. If you look in the file ssl_locl.h just under the define of SSL_ENC_MASK, you'll find the definitions of the bits associated with each algorithm. For example, for Camellia it's 0x0800 (bit number 27) and for SEED it's 0x1000 (bit number 28). Cheers, __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: SSL_ENC_MASK since SEED
understood. Thanks. Mounir IDRASSI a écrit : The bit flag for a new algorithm would logically be 0x2000 and the next 0x4000. Thus, the value of the mask would be 0x3C3F8000L and 0x7C3F8000L respectively. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
