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) */
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,
Grégory BELLIER.
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
