program linked with lcrypto is many times slower than openssl command

Question

I have a simple C program for aes256 encryption. It is linked with openssl library (-lcrypto). The core of the program are following few lines:

AES_set_encrypt_key(key32 ,256 ,&aes_ks3); while( len = fread( buf ,1 ,4096, fp) ){ if( 4096 != len ) break; AES_cbc_encrypt(buf ,buf ,len ,&aes_ks3 ,iv ,AES_ENCRYPT); fwrite(buf ,1 ,len ,wfp); } AES_cbc_encrypt(buf ,buf ,len+padding_len ,&aes_ks3, iv,AES_ENCRYPT); fwrite(buf ,1 ,len+padding_len ,wfp);

I am only using standard openssl library functions for encryption (ie. I am not using my own functions). I can encrypt same file, using same key and IV with openssl command:

openssl enc -aes-256-cbc -in FILE.in -out FILE.out -K $key -iv $iv

And I get identical output file (thus verifying that my program works correctly).

However, my program consistently runs is 4-5 times slower than the openssl command. They are both using the same routines, abd are both linked with the same library.

How is that possible?

How can I investigate why?

UPDATE:

Here are the actual numbers for encrypting same file with 1) openssl, 2) my program:

1) openssl:

real 0m0.238s user 0m0.196s sys 0m0.040s

2) my program:

real 0m1.006s user 0m0.964s sys 0m0.040s

what's RW_SIZE and FREAD_COUNT? Without any more information I would probably bet that's where your bottleneck is. — Art
– Art, Commented Jan 25, 2016 at 13:23
@Art - I have replaced RW_SIZE and FREAD_COUNT by their corresponding numbers. — Martin Vegter
– Martin Vegter, Commented Jan 25, 2016 at 13:32
I guess my bet wasn't that great. 4096 sounds like it's plenty of buffer to not cause a lot of overhead. What are the actual performance numbers of your program vs. the openssl command? — Art
– Art, Commented Jan 25, 2016 at 13:48
How often does the program enter the loop? Maybe the performance issue is with the file operations and not crypto functions. Try reading only at the beginning and writing only at the end of the program. Anyway, be aware that you're using deprecated API - you should use EVP suite and not such primitives. — Leśny Rumcajs
– Leśny Rumcajs, Commented Jan 25, 2016 at 13:49

Community · Accepted Answer · 2017-03-17 13:14:46Z

3

By calling the AES functions directly, you lose all the optimizations provided by the EVP layer. In particular, the EVP layer supports AES intrinsics, which makes a huge difference on CPUs that support them.

edited Mar 17, 2017 at 13:14

CommunityBot

11 silver badge

answered Jan 25, 2016 at 15:15

David Schwartz

184k18 gold badges229 silver badges293 bronze badges

Sign up to request clarification or add additional context in comments.

5 Comments

Maarten Bodewes Over a year ago

Well, 2 to 7 times depending on how fast the CPU is itself last time I checked. Quite a difference, but the window is shrinking. Note that AES-NI still has advantages with regards to e.g. side channel attacks, so there is more to that instruction than just speed (just additional info after +1).

Martin Vegter Over a year ago

@David Schwartz - is it possible to use the AES-NI cpu instructions directly (without using EVP) ? ie is there some parameter to set when using AES_cbc_encrypt ?

Thomas M. DuBuisson Over a year ago

It's almost certainly going to be a compile-time parameter. Have you tried -O3 and -maes?

David Schwartz Over a year ago

@MartinVegter I wouldn't suggest it, but you can look at the source code in crypto/evp/e_aes.c to see the functions that the EVP layer uses to decide which AES functions to call.

Martin Vegter Over a year ago

@David Schwartz - I have solved the problem by using the AES-NI functions, instead of the previous general AES functions. Thanks for the help.

Collectives™ on Stack Overflow

program linked with lcrypto is many times slower than openssl command

1 Answer 1

5 Comments

Linked

Hot Network Questions

Collectives™ on Stack Overflow

1 Answer 1

5 Comments

Linked

Related