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