Thanks for the quick response Matt.
Is there any specific reason why it was designed that way in 1.1.1?
It looks little odd that we need a non-NULL EVP_cipher object even though we do not use it/need it.
I am looking for support for ARM architecture. I can't wait till 3.0.
Is there any chance we may get support for this on ARM any sooner?
Any patches available on 1.1.1a?
Thanks in advance.
Regards
Phani
On Mon, Jan 13, 2020 at 5:53 PM Matt Caswell <matt@xxxxxxxxxxx> wrote:
On 13/01/2020 06:20, Phani 2004 wrote:
> Hi Team,
>
> I am trying to add support on an hardware engine for aes-cbc-hmac-sha1.
> I have observed that currently aes-cbc-hmac-sha1 is supported only for
> x86 architecture.
> "EVP_aes_128_cbc_hmac_sha1" api returns NULL for non-x86 platforms. The
> openssl speed app calls the "EVP_get_cipherbyname" call when it tries to
> parse the given arguments.
> It calls the above API and it returns NULL for the non-x86 platforms.
> How do we enable/add support for aes-cbc-hmac-sha1 on non-x86 platforms.
> I mean in the release version and not some local changes in my copy.
> Is this on the roadmap? I am currently using openssl-1.1.1a version.
This is an interesting problem. In order use an ENGINE implementation of
a cipher, your application has to have a non-NULL EVP_CIPHER object to
start with. This particular cipher is a highly specialised one only used
by libssl. There are a handful of other similar ones.
I can't actually think of a way around this problem in 1.1.1. In 3.0 it
will be very different. You will be able to use the EVP_CIPHER_fetch()
API to ask for a cipher implementation even for ciphers that aren't
available from the built-in providers.
So, yes, in a way this is on the roadmap - although you will have to
implement your custom cipher via a provider rather than an engine.
Matt
