EVP_aes_128_cbc_hmac_sha256() not working on arm64 architecture

[Matt Caswell]

On 07/05/2019 20:47, Mirko J. Ploch wrote:
> Thank you for your response. You answered my question. It is not available on my
> target platform architecture (arm64).
> 
> I do have a specific need for that cipher, and it does not have anything to do
> with TLS. An app that I am working on requires it for JSON Web Encryption (JWE)
> as the required encryption algorithm.
> 
> https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-31#appendix-B

Then (in spite of the name) this is not the cipher you want to use. This cipher
can *only* do the AAD specified for TLS - it is not a general purpose cipher and
so will not be capable of doing the AAD specified in that draft.

You can probably achieve what you want using EVP_aes_128_cbc() and then using
HMAC-SHA256 separately.

Matt

> 
> Best Regards,
> Mirko
> 
> On Tue, May 7, 2019 at 11:45 AM Matt Caswell <matt at openssl.org
> <mailto:matt at openssl.org>> wrote:
> 
> 
> 
>     On 06/05/2019 16:41, Mirko J. Ploch wrote:
>     > Hello,
>     >
>     > I'm trying to use EVP_aes_128_cbc_hmac_sha256() for encryption on an iOS
>     device
>     > with arm64 architecture. I was able to get it working with the x86_64
>     > architecture when running the iOS device simulator on an iMac. Is this
>     just not
>     > capable of working on an arm64 platform?
>     >
>     > Looking at the code for EVP_aes_128_cbc_hmac_sha256, it does not look like it.
>     > I'm hoping that there is a way to get it working.
>     >
>     https://github.com/openssl/openssl/blob/OpenSSL_1_1_1b/crypto/evp/e_aes_cbc_hmac_sha256.c
> 
>     This cipher is a special purpose cipher not intended for general use. It is
>     specifically targeted at usage in TLS. Unless you're writing a TLS stack you
>     probably don't want to use this. It is only available on some platforms and does
>     runtime detection to check whether the platform is suitable or not. Most
>     importantly the platform must have AES-NI support.
> 
>     It's usefulness even in a TLS stack is somewhat limited these days since it is
>     not relevant for TLSv1.3 and does not get used if encrypt-then-mac is negotiated
>     (which recent versions of OpenSSL will try to negotiate by default).
> 
>     Matt
>