[prev in list] [next in list] [prev in thread] [next in thread]
List: openssl-dev
Subject: Re: Ciphers and modes of operation
From: Gregory BELLIER <gregory.bellier () gmail ! com>
Date: 2010-02-26 16:13:02
Message-ID: 4B87F30E.4070707 () gmail ! com
[Download RAW message or body]
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-dev@openssl.org
> [mailto:owner-openssl-dev@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,
> Grégory BELLIER.
>
>
>
>
> Cheng, Weidong a écrit :
>
> Please give more information as Stephen suggested.
>
>
>
> -----Original Message-----
> From: owner-openssl-dev@openssl.org <mailto:owner-openssl-dev@openssl.org> \
> [mailto:owner-openssl-dev@openssl.org] On Behalf Of Gregory BELLIER
> Sent: Tuesday, February 23, 2010 8:48 AM
> To: openssl-dev@openssl.org <mailto: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-dev@openssl.org <mailto:owner-openssl-dev@openssl.org> \
> > [mailto:owner-openssl-dev@openssl.org] On Behalf Of Gregory \
> > BELLIER
> > Sent: Tuesday, February 23, 2010 7:45 AM
> > To: openssl-dev@openssl.org <mailto: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 \
> > <mailto:openssl-dev@openssl.org> Automated List Manager \
> > majordomo@openssl.org <mailto:majordomo@openssl.org> \
> > ______________________________________________________________________ OpenSSL \
> > Project http://www.openssl.org Development \
> > Mailing List openssl-dev@openssl.org \
> > <mailto:openssl-dev@openssl.org> Automated List Manager \
> > majordomo@openssl.org <mailto:majordomo@openssl.org>
> >
>
>
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> Development Mailing List openssl-dev@openssl.org \
> <mailto:openssl-dev@openssl.org> Automated List Manager \
> majordomo@openssl.org <mailto:majordomo@openssl.org> \
> ______________________________________________________________________ OpenSSL \
> Project http://www.openssl.org Development Mailing \
> List openssl-dev@openssl.org <mailto:openssl-dev@openssl.org> \
> Automated List Manager majordomo@openssl.org \
> <mailto:majordomo@openssl.org>
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majordomo@openssl.org
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic