Thank you Matt. You have been very helpful.
On Tue, May 7, 2019 at 6:40 PM Matt Caswell <matt@xxxxxxxxxxx> wrote:
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@xxxxxxxxxxx
> <mailto:matt@xxxxxxxxxxx>> 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
>
