Stitched aes-128 and hmac-sha1 (encrypt-then-mac)

[pablo platt]

Hi,

Stitching aes-cbc with sha1 can result with x2 performance [1].
Is there support for stitched aes-128-hmac-sha1 encrypt-then-mac? This
issue [2] says that only mac-then-encrypt is supported in OpenSSL.

Does this implement mac-then-encrypt and relevant [3]?
Is it possible to use the same code with just changing the order to achieve
encrypt-then-mac?
How can I compile the Perl file to be used from a C program?

[1] https://software.intel.com/en-us/articles/improving-openssl-performance
[2] https://github.com/openssl/openssl/issues/8785
[3]
https://github.com/openssl/openssl/blob/master/crypto/aes/asm/aesni-sha1-x86_64.pl

Thanks

Re: Stitched aes-128 and hmac-sha1 (encrypt-then-mac)

[Matt Caswell]

On 01/11/2019 07:56, pablo platt wrote:
> Hi,
> 
> Stitching aes-cbc with sha1 can result with x2 performance [1].
> Is there support for stitched aes-128-hmac-sha1 encrypt-then-mac? This
> issue [2] says that only mac-then-encrypt is supported in OpenSSL.

The issue is correct. Only mac-then-encrypt is supported. Furthermore
these stitched ciphers are specifically targeted at use by libssl and
are designed for use in SSL/TLS only. They are not general purpose
ciphers and should not be used directly unless you *really* know what
you are doing.

Note that more modern TLS ciphersuites use AEAD modes such as GCM or CCM
so that mac-then-encrypt vs encrypt-then-mac and "stitched" ciphers are
irrelevant anyway.

> 
> Does this implement mac-then-encrypt and relevant [3]?

[3] is the aesni assembler implementation used behind the
EVP_aes_128_cbc_hmac_sha1() and EVP_aes_256_cbc_hmac_sha1() ciphers,
i.e. all the same comments I made above apply here. It's
mac-then-encrypt, and specifically targeted for use in SSL/TLS by
libssl. It's not intended for general purpose use.

The documentation says this about these ciphers:

"EVP_aes_128_cbc_hmac_sha1(),
EVP_aes_256_cbc_hmac_sha1()

Authenticated encryption with AES in CBC mode using SHA-1 as HMAC, with
keys of 128 and 256 bits length respectively. The authentication tag is
160 bits long.

WARNING: this is not intended for usage outside of TLS and requires
calling of some undocumented ctrl functions. These ciphers do not
conform to the EVP AEAD interface."

https://www.openssl.org/docs/man1.1.1/man3/EVP_aes_128_cbc_hmac_sha1.html



> Is it possible to use the same code with just changing the order to
> achieve encrypt-then-mac?

No.

> How can I compile the Perl file to be used from a C program?

This is an internal file not intended for use outside of OpenSSL and not
intended to be compiled separately. You might be able to extract it -
but if so, you're on your own.


Matt

Re: Stitched aes-128 and hmac-sha1 (encrypt-then-mac)

[pablo platt]

Thank you for the explanation.

The use case is a WebRTC server (SFU) that encrypts and authenticate SRTP
packets.
Encryption is a major part of CPU load on SFU servers. Reducing it by 50%
will have a large impact.

Is it planned to add aes-128-hmac-sha1 encrypt-then-mac?

On Fri, Nov 1, 2019 at 1:32 PM Matt Caswell  wrote:

>
>
> On 01/11/2019 07:56, pablo platt wrote:
> > Hi,
> >
> > Stitching aes-cbc with sha1 can result with x2 performance [1].
> > Is there support for stitched aes-128-hmac-sha1 encrypt-then-mac? This
> > issue [2] says that only mac-then-encrypt is supported in OpenSSL.
>
> The issue is correct. Only mac-then-encrypt is supported. Furthermore
> these stitched ciphers are specifically targeted at use by libssl and
> are designed for use in SSL/TLS only. They are not general purpose
> ciphers and should not be used directly unless you *really* know what
> you are doing.
>
> Note that more modern TLS ciphersuites use AEAD modes such as GCM or CCM
> so that mac-then-encrypt vs encrypt-then-mac and "stitched" ciphers are
> irrelevant anyway.
>
> >
> > Does this implement mac-then-encrypt and relevant [3]?
>
> [3] is the aesni assembler implementation used behind the
> EVP_aes_128_cbc_hmac_sha1() and EVP_aes_256_cbc_hmac_sha1() ciphers,
> i.e. all the same comments I made above apply here. It's
> mac-then-encrypt, and specifically targeted for use in SSL/TLS by
> libssl. It's not intended for general purpose use.
>
> The documentation says this about these ciphers:
>
> "EVP_aes_128_cbc_hmac_sha1(),
> EVP_aes_256_cbc_hmac_sha1()
>
> Authenticated encryption with AES in CBC mode using SHA-1 as HMAC, with
> keys of 128 and 256 bits length respectively. The authentication tag is
> 160 bits long.
>
> WARNING: this is not intended for usage outside of TLS and requires
> calling of some undocumented ctrl functions. These ciphers do not
> conform to the EVP AEAD interface."
>
> https://www.openssl.org/docs/man1.1.1/man3/EVP_aes_128_cbc_hmac_sha1.html
>
>
>
> > Is it possible to use the same code with just changing the order to
> > achieve encrypt-then-mac?
>
> No.
>
> > How can I compile the Perl file to be used from a C program?
>
> This is an internal file not intended for use outside of OpenSSL and not
> intended to be compiled separately. You might be able to extract it -
> but if so, you're on your own.
>
>
> Matt
>

Re: Stitched aes-128 and hmac-sha1 (encrypt-then-mac)

[Matt Caswell]

On 01/11/2019 11:59, pablo platt wrote:
> Thank you for the explanation.
> 
> The use case is a WebRTC server (SFU) that encrypts and authenticate
> SRTP packets.
> Encryption is a major part of CPU load on SFU servers. Reducing it by
> 50% will have a large impact.
> 
> Is it planned to add aes-128-hmac-sha1 encrypt-then-mac?

There are no current plans. You might investigate the impact of using
AEAD ciphers instead.

Matt

> 
> On Fri, Nov 1, 2019 at 1:32 PM Matt Caswell  > wrote:
> 
> 
> 
> On 01/11/2019 07:56, pablo platt wrote:
> > Hi,
> >
> > Stitching aes-cbc with sha1 can result with x2 performance [1].
> > Is there support for stitched aes-128-hmac-sha1 encrypt-then-mac? This
> > issue [2] says that only mac-then-encrypt is supported in OpenSSL.
> 
> The issue is correct. Only mac-then-encrypt is supported. Furthermore
> these stitched ciphers are specifically targeted at use by libssl and
> are designed for use in SSL/TLS only. They are not general purpose
> ciphers and should not be used directly unless you *really* know what
> you are doing.
> 
> Note that more modern TLS ciphersuites use AEAD modes such as GCM or CCM
> so that mac-then-encrypt vs encrypt-then-mac and "stitched" ciphers are
> irrelevant anyway.
> 
> >
> > Does this implement mac-then-encrypt and relevant [3]?
> 
> [3] is the aesni assembler implementation used behind the
> EVP_aes_128_cbc_hmac_sha1() and EVP_aes_256_cbc_hmac_sha1() ciphers,
> i.e. all the same comments I made above apply here. It's
> mac-then-encrypt, and specifically targeted for use in SSL/TLS by
> libssl. It's not intended for general purpose use.
> 
> The documentation says this about these ciphers:
> 
> "EVP_aes_128_cbc_hmac_sha1(),
> EVP_aes_256_cbc_hmac_sha1()
> 
> Authenticated encryption with AES in CBC mode using SHA-1 as HMAC, with
> keys of 128 and 256 bits length respectively. The authentication tag is
> 160 bits long.
> 
> WARNING: this is not intended for usage outside of TLS and requires
> calling of some undocumented ctrl functions. These ciphers do not
> conform to the EVP AEAD interface."
> 
> https://www.openssl.org/docs/man1.1.1/man3/EVP_aes_128_cbc_hmac_sha1.html
> 
> 
> 
> > Is it possible to use the same code with just changing the order to
> > achieve encrypt-then-mac?
> 
> No.
> 
> > How can I compile the Perl file to be used from a C program?
> 
> This is an internal file not intended for use outside of OpenSSL and not
> intended to be compiled separately. You might be able to extract it -
> but if so, you're on your own.
> 
> 
> Matt
> 

Re: Stitched aes-128 and hmac-sha1 (encrypt-then-mac)

[pablo platt]

AES-GCM will be supported in WebRTC in the future.
It has great performance and I think better security.
The only downside is that packets will be 6 bytes larger and it'll take few
months/years most browsers support it.

Thanks

On Fri, Nov 1, 2019 at 2:01 PM Matt Caswell  wrote:

>
>
> On 01/11/2019 11:59, pablo platt wrote:
> > Thank you for the explanation.
> >
> > The use case is a WebRTC server (SFU) that encrypts and authenticate
> > SRTP packets.
> > Encryption is a major part of CPU load on SFU servers. Reducing it by
> > 50% will have a large impact.
> >
> > Is it planned to add aes-128-hmac-sha1 encrypt-then-mac?
>
> There are no current plans. You might investigate the impact of using
> AEAD ciphers instead.
>
> Matt
>
> >
> > On Fri, Nov 1, 2019 at 1:32 PM Matt Caswell  > > wrote:
> >
> >
> >
> > On 01/11/2019 07:56, pablo platt wrote:
> > > Hi,
> > >
> > > Stitching aes-cbc with sha1 can result with x2 performance [1].
> > > Is there support for stitched aes-128-hmac-sha1 encrypt-then-mac?
> This
> > > issue [2] says that only mac-then-encrypt is supported in OpenSSL.
> >
> > The issue is correct. Only mac-then-encrypt is supported. Furthermore
> > these stitched ciphers are specifically targeted at use by libssl and
> > are designed for use in SSL/TLS only. They are not general purpose
> > ciphers and should not be used directly unless you *really* know what
> > you are doing.
> >
> > Note that more modern TLS ciphersuites use AEAD modes such as GCM or
> CCM
> > so that mac-then-encrypt vs encrypt-then-mac and "stitched" ciphers
> are
> > irrelevant anyway.
> >
> > >
> > > Does this implement mac-then-encrypt and relevant [3]?
> >
> > [3] is the aesni assembler implementation used behind the
> > EVP_aes_128_cbc_hmac_sha1() and EVP_aes_256_cbc_hmac_sha1() ciphers,
> > i.e. all the same comments I made above apply here. It's
> > mac-then-encrypt, and specifically targeted for use in SSL/TLS by
> > libssl. It's not intended for general purpose use.
> >
> > The documentation says this about these ciphers:
> >
> > "EVP_aes_128_cbc_hmac_sha1(),
> > EVP_aes_256_cbc_hmac_sha1()
> >
> > Authenticated encryption with AES in CBC mode using SHA-1 as HMAC,
> with
> > keys of 128 and 256 bits length respectively. The authentication tag
> is
> > 160 bits long.
> >
> > WARNING: this is not intended for usage outside of TLS and requires
> > calling of some undocumented ctrl functions. These ciphers do not
> > conform to the EVP AEAD interface."
> >
> >
> https://www.openssl.org/docs/man1.1.1/man3/EVP_aes_128_cbc_hmac_sha1.html
> >
> >
> >
> > > Is it possible to use the same code with just changing the order to
> > > achieve encrypt-then-mac?
> >
> > No.
> >
> > > How can I compile the Perl file to be used from a C program?
> >
> > This is an internal file not intended for use outside of OpenSSL and
> not
> > intended to be compiled separately. You might be able to extract it -
> > but if so, you're on your own.
> >
> >
> > Matt
> >
>

RE: OpenSSL compilation errors in Windows

[Nagalakshmi V J]

Hi Matt,

Thanks for your help. I am able to proceed now.

Thanks and regards,
Nagalakshmi

-Original Message-
From: Matt Caswell 
Sent: Wednesday, October 30, 2019 7:55 PM
To: Nagalakshmi V J ; openssl-users@openssl.org
Subject: Re: OpenSSL compilation errors in Windows

** This mail has been sent from an external source **


On 29/10/2019 11:55, Nagalakshmi V J wrote:
> Hi Matt,
>
> Thank you so much for your response. Those mentioned APIs resolved my
> errors.
>
> For the below code,
>
>  return  SSL_get_session(pConnection) != NULL &&
> pConnection->session->session_id_length != 0;
>
> Any reference for accessing session_id_length?
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openssl.org_d
> ocs_man1.1.0_man3_SSL-5FCTX-5Fset-5Fgenerate-5Fsession-5Fid.html&d=DwI
> D-g&c=cxWN2QSDopt5SklNfbjIjg&r=zbjUR56YPF3jaTRTjX4KZlHM9-LmYAuR5atSqEG
> OnpA&m=mgmrDa8wrs1zaAUL-PLOcRGKsCoFwXg9ZmrJMt56Yso&s=GW6E7NE-6ODy28APY
> gBz7MYCKAuXh9wULiPQjZ-AMR0&e=

You should use SSL_SESSION_get_id() to get hold of the length:

https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openssl.org_docs_man1.1.1_man3_SSL-5FSESSION-5Fget-5Fid.html&d=DwID-g&c=cxWN2QSDopt5SklNfbjIjg&r=zbjUR56YPF3jaTRTjX4KZlHM9-LmYAuR5atSqEGOnpA&m=mgmrDa8wrs1zaAUL-PLOcRGKsCoFwXg9ZmrJMt56Yso&s=rGqb0VAIAgD_dzrh6Cpv2AyI6wzAaog-HYn_OY_0mMU&e=

Matt

>
> Not sure if I can use the above link.
>
>
> /Thanks & Regards,/
> /Nagalakshmi V J/
> --
> --
> *From:* Matt Caswell 
> *Sent:* 29 October 2019 10:47
> *To:* Nagalakshmi V J ;
> openssl-users@openssl.org 
> *Subject:* Re: OpenSSL compilation errors in Windows
>
> ** This mail has been sent from an external source **
>
>
> On 29/10/2019 10:34, Nagalakshmi V J wrote:
>>
>> tls1_PRF(s->ctx->md5,s->ctx->sha1,buf,(int)(p-buf),
>>
>>  pGenerator->master_secret,sizeof(pGenerator->master_secret),
>>
>>  km,tmp,num);
>
> It seems your code is replicating parts of libssl - which seems like a
> strange (and possibly dangerous) thing to do!
>
>> Struct ssl_ctx_st {
>>
>> ...
>>
>> constEVP_MD *md5;  /* For SSLv3/TLSv1 'ssl3-md5' */
>>
>> constEVP_MD *sha1; /* For SSLv3/TLSv1 'ssl3->sha1' */
>>
>> ...
>>
>> }
>
> You really don't need to access these things. They're just cached
> references to the value returned by EVP_get_digestbyname("ssl3-md5")
> and EVP_get_digestbyname("ssl3-sha1"). So you can call those functions
> directly anyway.
>
> Matt
>
> =
> Please refer to https://northamerica.altran.com/email-disclaimer
> for important disclosures regarding this electronic communication.
> =
=
Please refer to https://northamerica.altran.com/email-disclaimer
for important disclosures regarding this electronic communication.
=

Re: Digest algorithms for Ruby

[Jordan Brown]

On 10/31/2019 7:35 AM, Viktor Dukhovni wrote:
> My advice would be to avoid specific support for any *particular*
> digest algorithm. Instead, provide bindings to:
>   - EVP_get_digestbyname(),
>   - EVP_MD_CTX_create(3),
>   - EVP_DigestInit_ex(3),
>   - EVP_DigestUpdate(3),
>   - EVP_DigestFinal_ex(3),
>   - EVP_MD_CTX_destroy(3)
>
> which can they use *any* available digest algorithm (by name).
>

That avoids having *your* software be dependent on the digest
algorithms, but it does so by exporting the dependency out to your caller.

The bottom line for somebody trying to maintain compatibility is that
when you remove some algorithm X, there's always a risk that something
in the stack - be it software or user configuration - explicitly depends
on X and so will fail on upgrade.

-- 
Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris