Provider vs engine

[RobinGeffroy]

Hello,

I tried to use the provider for linux s390x, and I am wondering if it's the same as the engine. When I run the test suite for the provider, I see only a few hardware usage with icastats (ECDH, ECDSA Sign, ECDSA Verify, EC Keygen, RSA-ME, RSA-CRT). When I run the test suite for the engine, I see a lot of them (SHA256, SHA512, DRBG-SHA-512, RSA-ME, RSA-CRT, and the 3DES and AES ones).

I'm kinda surprised, as I expected the provider to get the same crypto acceleration than the engine. Even when using the provider to do some TLS tests, I can see that the AES counters are not incremented, and thus the crypto acceleration is not there.

Is that normal ? Is it because OpenSSL now handle this and libica is not needed ?

Regards,

Robin Geffroy

[ifranzki]

Hi Robin, the provider intentionally accelerates only RSA, ECC and DH.

The reason for this is that pretty much all symmetric ciphers and digests are already accelerated by OpenSSL code by using CPACF since long time. So routing them to a provider will not do any good, it will just make it slower.

The engine was developed at a time where OpenSSL did not accelerate those algorithm yet, so back then it made sense to pass them to the engine.

Please see the table here for the HW acceleration of OpenSSL out-of-the-box: https://www.ibm.com/docs/en/linux-on-systems?topic=linuxone-openssl-ibmz

So this actually leaves only the asymmetric algorithms such as RSA, ECC, and DH to be accelerated by the provider (or engine). For ECC, the mostly used curves are actually also accelerated by CPACF in OpenSSL out-of-the-box.

Please see the following decision tree abut how we recommend to configure the provider and/or engine nowadays: https://www.ibm.com/docs/en/linux-on-systems?topic=linuxone-quick-decision

So even for the engine, we recommend to use default_algorithms = RSA,DH,DSA to only enable those algorithms for the engine, and leave all others for the out-of-the-box acceleration by OpenSSL.

[RobinGeffroy]

Hello,

thanks for your answer. That's what I understood after looking at OpenSSL changelog and found that acceleration was added. I was asking because I saw the statistics with icastats for the engine, but not for the provider. If it's done with OpenSSL, it's logical. But I'm working on IBM z/OS and trying to have acceleration for OpenSSL as well. And, in this case, the engine/provider is the easy way -- because it's easier to add this than to change OpenSSL itself. I worked on libica to modify it and was able to add some code for z/OS, but I did not see any improvement with the provider. With the engine - which also accelerate AES and others - it worked fine.

Guess I'll have to add some code to the provider to handle AES as well. I'll take a look at OpenSSL CPACF implementation to see what can be done.

Thanks for your answer, you can close this issue.

Regards,

Robin

[ifranzki]

I wonder why the CPACF acceleration done in OpenSSL code for Linux on IBM Z should not also work for z/OS ? It is probably enclosed with #ifdefs and thus is not used when compiling on z/OS, but maybe this can be adjusted accordingly ? Why reinvent the wheel again ?

[RobinGeffroy]

Because there are LOTS of code that needs ifdef. Some code with assembly that won't work out of the box, some code for s390 or s390x, etc. Using the engine as-is with just replacement of some parts (that we already had) was easier. We were able to make it work with the engine, but still have some issues with interoperability with older OpenSSL version, seems to be an issue with RSA-PSS padding. I guess we'll have to take a look at the CPACF work done in OpenSSL anyway, it would be indeed better.