aes_cbc_hmac_sha1 implementation

[Phani 2004]

Hi Team,

Can anyone help me with the below queries.
Thanks in Advance.

Regards
Phani

On Fri, Feb 28, 2020 at 2:41 PM Phani 2004 <phani2004 at gmail.com> 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
> 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/20200302/d51f4f27/attachment.html>