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 <matt at openssl.org> 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 <matt at openssl.org
> > <mailto:matt at openssl.org>> 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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20191101/60ccb942/attachment-0001.html>