matt at openssl.org
Mon Mar 2 10:11:26 UTC 2020
On 28/02/2020 09:11, Phani 2004 wrote:
> 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
> 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?
That cipher only does mte.
> 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.
If you want to support etm you have to implement aes-cbc and sha1
> One more query i have is, how do we pass the etm option to the openssl
> in conf file.
etm will be negotiated by default if it is available - there is no need
to configure this. You can disable etm using the "EncryptThenMac"
Options = -EncryptThenMac
> On Fri, Feb 28, 2020 at 8:53 AM Matt Caswell <matt at openssl.org
> <mailto: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
> > 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
> 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".
> > Regards
> > Phani
> > On Wed, 26 Feb, 2020, 6:03 PM Hubert Kario, <hkario at redhat.com
> <mailto:hkario at redhat.com>
> > <mailto: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
> > -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
> > 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
More information about the openssl-users