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