Query regarding adding support aes-cbc-hmac-sha1 on non x86 platform through engine

[Matt Caswell]

On 14/01/2020 07:42, Phani 2004 wrote:
> Thanks for the quick response Matt.
> Is there any specific reason why it was designed that way in 1.1.1?

These ciphers are really quite unusual. Normally we have an
implementation of ciphers on all platforms. These are the exception and
were added much later than when the ENGINE code went in. I suspect
no-one considered the scenario when ENGINEs was developed that we might
have a cipher that is NULL on some platforms.


> 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?

I don't see a way around this for 1.1.1 unfortunately. Maybe other
people might have suggestions.

Matt


> 
> Thanks in advance.
> 
> Regards
> Phani
> 
> On Mon, Jan 13, 2020 at 5:53 PM Matt Caswell <matt at openssl.org
> <mailto:matt at openssl.org>> 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
>