aes_cbc_hmac_sha1 implementation

[Phani 2004]

OK. I understood that "AES-128-CBC-HMAC-SHA1"(aesni_cbc_hmac_sha1) always
does mte.
I am trying to implement engine implementation of combined mode cipher
aes_cbc_hmac_sha1.
So in my aes_cbc_hmac_sha1_cipher implementation should i do mte only?

If hardware engine can do both operations in a single request and save
time. Also, say there is a flag which indicates whether its mte or etm.
How should my aes_cbc_hmac_sha1 implementation look like?
Should it do only mte always? Should i have two ciphers, one for etm and
other for mte.
But how to i tell openssl to use this cipher for etm and other for mte
without changing the openssl code.

One more query i have is, how do we pass the etm option to the openssl in
conf file.

Regards
Phani

On Fri, Feb 28, 2020 at 8:53 AM Matt Caswell <matt at openssl.org> wrote:

>
>
> On 27/02/2020 18:30, Phani 2004 wrote:
> > Thanks for the reply.
> >
> > In ssl_get_evp_cipher api when etm flag is enabled the
> > aesni_cbc_hmac_sha1_cipher is not used. In this cipher only it
> > implements mte. This part is not clear to me? Support I implement one
> > cipher func which needs to handle both etm as well as mte, at the cipher
> > api level how do I know if we have etm extension enabled or not.
>
> At the engine level all it knows about are ciphers and hashes. Engines
> know nothing about TLS ciphersuites or TLS extensions. Your engine will
> not know whether etm or mte is in use. libssl makes the decision about
> what cipher it is going to ask the engine for based on what has been
> negotiated.
>
> If mte is in use then it will first look to see if it has an
> implementation of "AES-128-CBC-HMAC-SHA1" (of which
> aesni_cbc_hmac_sha1_cipher is the built-in implementation).
>
> If that is not available it will look for individual implementations of
> "AES-128" and "SHA1".
>
> If etm is in use it will just look for individual implementations of
> "AES-128" and "SHA1".
>
> Matt
>
>
>
> >
> > Regards
> > Phani
> >
> > On Wed, 26 Feb, 2020, 6:03 PM Hubert Kario, <hkario at redhat.com
> > <mailto:hkario at redhat.com>> wrote:
> >
> >     On Wednesday, 26 February 2020 08:59:01 CET, Phani 2004 wrote:
> >     > Thanks for the quick response Matt.
> >     >
> >     > My command was :
> >     > openssl s_client -connect 10.29.20.26 -cipher ECDHE-RSA-AES128-SHA
> >     -tls1_2.
> >     > I did not realise that "2" was not copied.
> >     >
> >     > I am trying to implement combined algo support on our engine.
> >     > I am using the openssl s_server and s_client apps to validate my
> >     > implementation.
> >     > The combined algo that i am looking to implement is AES128/256 and
> >     SHA1.
> >     > Its clear that i should always use tls version less than 1.3
> >     otherwise GCM
> >     > ciphers are used.
> >     >
> >     > What cipher suites can i use to validate the above combination of
> >     combined
> >     > algo?
> >
> >     OpenSSL internally treats key exchange and symmetric cipher
> >     separately, so
> >     all "*AES128-SHA" ciphers use the same cipher backend
> >
> >     you should also test AES256-SHA, AES128-SHA256, AES256-SHA256 and
> >     AES256-SHA384
> >
> >     > Which tls versions support which cipher suites?
> >
> >     *-SHA1 and *MD5 is supported by everything between SSL3 and TLS 1.2
> >     *-SHA256 and *-SHA384 (if they are not TLS1.3 cipher suites) are
> >     supported
> >     by TLS 1.2 only
> >
> >     > Should i be doing "encrypt-then-mac" or "mac-then-encrypt" in my
> >     > implementation?
> >     > Does the cipher suite decide this?
> >     > If yes, what are the ciphers which do "encrypt-then-mac" and what
> >     ciphers
> >     > to "mac-then-encrypt"?
> >
> >     etm vs mte happens based on negotiated extension, not cipher suite
> >
> >     --
> >     Regards,
> >     Hubert Kario
> >     Senior Quality Engineer, QE BaseOS Security team
> >     Web: www.cz.redhat.com <http://www.cz.redhat.com>
> >     Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20200228/0c594a60/attachment-0001.html>