Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

EVP_CIPHER_CTX_set_key_length and EVP_CIPHER_key_length

70 views
Skip to first unread message

la...@angry-red-pla.net

unread,
Aug 28, 2012, 8:37:30 AM8/28/12
to
Hi all

I created a shared key based on a DH exchange and want to use that key
with a symmetric encryption algorithm. This key has a length of 16 Bytes
(128 bit). Here is what I do to initialize AES:

char *key,*iv;

// DH exchange which ends with a 16B value in key


RAND_pseudo_bytes(iv,16);

EVP_EncryptInit(&enc_ctx,EVP_aes_128_cbc(),NULL,NULL);
EVP_CIPHER_CTX_set_key_length(&enc_ctx,16);
EVP_EncryptInit(&enc_ctx,NULL,skey,iv);

None of the functions seems to generate an error. I checked that by
calling ERR_print_errors_fp. However when I check the key length

printf("key len: %d\n",EVP_CIPHER_key_length(&enc_ctx));

It returns 1. Shouldn't it return 16? I guess I make a mistake when
setting the key, but where?

best regards
Carolin

______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openss...@openssl.org
Automated List Manager majo...@openssl.org

Dr. Stephen Henson

unread,
Aug 28, 2012, 7:37:42 PM8/28/12
to
On Tue, Aug 28, 2012, la...@angry-red-pla.net wrote:

> Hi all
>
> I created a shared key based on a DH exchange and want to use that key
> with a symmetric encryption algorithm. This key has a length of 16 Bytes
> (128 bit). Here is what I do to initialize AES:
>
> char *key,*iv;
>
> // DH exchange which ends with a 16B value in key
>
>
> RAND_pseudo_bytes(iv,16);
>
> EVP_EncryptInit(&enc_ctx,EVP_aes_128_cbc(),NULL,NULL);
> EVP_CIPHER_CTX_set_key_length(&enc_ctx,16);
> EVP_EncryptInit(&enc_ctx,NULL,skey,iv);
>
> None of the functions seems to generate an error. I checked that by
> calling ERR_print_errors_fp. However when I check the key length
>
> printf("key len: %d\n",EVP_CIPHER_key_length(&enc_ctx));
>
> It returns 1. Shouldn't it return 16? I guess I make a mistake when
> setting the key, but where?
>

The cipher EVP_aes_128_cbc() has a fixed key length so there is no need to set
it, though it is harmless to do so.

The function EVP_CIPHER_key_length works on an EVP_CIPHER structure not an
EVP_CIPHER_CTX. You need to call EVP_CIPHER_CTX_key_length instead.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

la...@angry-red-pla.net

unread,
Aug 29, 2012, 4:20:33 AM8/29/12
to
Yup, using the correct function helps :-)

Thanks!

Erik Tkal

unread,
Aug 29, 2012, 1:47:03 PM8/29/12
to
I have a client that I want to attempt to negotiate TLS 1.2 but will accept TLS 1.0. What is the magic incantation (e.g. TLSv1_client_method() vs TLSv1_2_client_method() in conjunction with what options)?

Specifying TLSv1_client_method() seems to only offer TLS 1.0 {3,1}. Specifying TLSv1_2_client_method() offers TLS 1.2 {3,3}, but then when the server returns a TLS 1.0 {3,1} ServerHello, the client generates a Protocol Version alert.

How do I tell the client that this is acceptable? Appendix E of RFC 5246 indicates this should be possible.

I am using OpenSSL 1.0.1c.


....................................
Erik Tkal
Juniper OAC/UAC/Pulse Development

Abhiram Shandilya

unread,
Aug 29, 2012, 2:37:49 PM8/29/12
to
Hi Erik:
If you only want to allow TLSv1.2 and TLSv1.0 handshakes you will need to try a connection with the TLSv1_2_client_method and then by TLSv1_client_method. You can also use SSLv23_client_method to negotiate only TLSv1.2 and TLSv1.0 using an SSLv2 handshake by explicitly disabling SSLv2, SSLv3 and TLSv1.1 using SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2|SSL_OP_NO_SSLv3|SSL_OP_NO_TLSv1_1). At least that's my understanding.
Regards
Abhi

Erik Tkal

unread,
Aug 29, 2012, 2:48:28 PM8/29/12
to
TLS 1.1 would be acceptable, but the server is 1.0 (we don't have any implementing 1.1). The server sends a TLS 1.0 ServerHello, which per the RFC should work:

A TLS 1.2 client who wishes to negotiate with such older servers will
send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS 1.2) in
ClientHello.client_version. If the server does not support this
version, it will respond with a ServerHello containing an older
version number. If the client agrees to use this version, the
negotiation will proceed as appropriate for the negotiated protocol.

What I'm trying to figure out is how to tell OpenSSL that the client agrees to use this version, whereas now it generates a fatal alert. I cannot use an SSLv2 handshake, as this is inside EAP-TLS.


....................................
Erik Tkal
Juniper OAC/UAC/Pulse Development



0 new messages