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/20
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
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:
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-en
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
