New crypto discussion

[davidebeatrici]

We're currently using AES-128-OCB as cipher for the UDP channel (the TCP channel uses TLS, handled by Qt).

While there aren't known security issues, we believe it's time to switch to a better cipher.

We initially planned to switch from OCB to OCB3, but the patents issues would have remained.
AES-256-AEGIS, AES-256-GCM and ChaCha20-Poly1305 are the proposed alternatives.

@jedisct1 (libsodium's maintainer) recommended AES-256-AEGIS for better performance and ChaCha20-Poly1305 for better compatibility.

Our baseline for Mumble 1.4 is Ubuntu 18.04, which provides:

• OpenSSL 1.1.1
• libsodium 1.0.16
• NSS 3.35
• mbed TLS 2.8.0
• wolfCrypt 3.13.0

Benchmarks

https://github.com/mumble-voip/crypto-benchmark is the tool we used to measure performance.

AMD Ryzen 7-3800X

[NSS] AES-256-GCM took 3.267660 seconds for 1000000 iterations, 4096 bytes message
[NSS] ChaCha20-Poly1305 took 26.553126 seconds for 1000000 iterations, 4096 bytes message
[OpenSSL] AES-256-GCM took 1.921156 seconds for 1000000 iterations, 4096 bytes message
[OpenSSL] AES-256-OCB took 1.440563 seconds for 1000000 iterations, 4096 bytes message
[OpenSSL] ChaCha20-Poly1305 took 3.722622 seconds for 1000000 iterations, 4096 bytes message
[libsodium] AES-256-GCM took 3.553536 seconds for 1000000 iterations, 4096 bytes message
[libsodium] ChaCha20-Poly1305 took 5.054257 seconds for 1000000 iterations, 4096 bytes message
[wolfCrypt] AES-256-GCM took 90.733242 seconds for 1000000 iterations, 4096 bytes message
[wolfCrypt] ChaCha20-Poly1305 took 21.632958 seconds for 1000000 iterations, 4096 bytes message

Intel Core i5-4690

[NSS] AES-256-GCM took 4.752897 seconds for 1000000 iterations, 4096 bytes message
[NSS] ChaCha20-Poly1305 took 30.735785 seconds for 1000000 iterations, 4096 bytes message
[OpenSSL] AES-256-GCM took 2.975262 seconds for 1000000 iterations, 4096 bytes message
[OpenSSL] AES-256-OCB took 2.436486 seconds for 1000000 iterations, 4096 bytes message
[OpenSSL] ChaCha20-Poly1305 took 4.410388 seconds for 1000000 iterations, 4096 bytes message
[libsodium] AES-256-GCM took 5.262651 seconds for 1000000 iterations, 4096 bytes message
[libsodium] ChaCha20-Poly1305 took 6.276619 seconds for 1000000 iterations, 4096 bytes message
[wolfCrypt] AES-256-GCM took 129.391199 seconds for 1000000 iterations, 4096 bytes message
[wolfCrypt] ChaCha20-Poly1305 took 28.194343 seconds for 1000000 iterations, 4096 bytes message

AMD FX-6300

[NSS] AES-256-GCM took 8.369304 seconds for 1000000 iterations, 4096 bytes message
[NSS] ChaCha20-Poly1305 took 47.978501 seconds for 1000000 iterations, 4096 bytes message
[OpenSSL] AES-256-GCM took 5.444225 seconds for 1000000 iterations, 4096 bytes message
[OpenSSL] AES-256-OCB took 3.194741 seconds for 1000000 iterations, 4096 bytes message
[OpenSSL] ChaCha20-Poly1305 took 7.658956 seconds for 1000000 iterations, 4096 bytes message
[libsodium] AES-256-GCM took 7.680904 seconds for 1000000 iterations, 4096 bytes message
[libsodium] ChaCha20-Poly1305 took 13.378307 seconds for 1000000 iterations, 4096 bytes message
[wolfCrypt] AES-256-GCM took 223.153596 seconds for 1000000 iterations, 4096 bytes message
[wolfCrypt] ChaCha20-Poly1305 took 41.273524 seconds for 1000000 iterations, 4096 bytes message

x86_64 CPU on Travis CI

[NSS] AES-256-GCM took 4.078755 seconds for 1000000 iterations, 4096 bytes message
[NSS] ChaCha20-Poly1305 took 15.603647 seconds for 1000000 iterations, 4096 bytes message
[OpenSSL] AES-256-GCM took 2.390765 seconds for 1000000 iterations, 4096 bytes message
[OpenSSL] AES-256-OCB took 2.436504 seconds for 1000000 iterations, 4096 bytes message
[OpenSSL] ChaCha20-Poly1305 took 4.282076 seconds for 1000000 iterations, 4096 bytes message
[libsodium] AES-256-GCM took 4.746877 seconds for 1000000 iterations, 4096 bytes message
[libsodium] ChaCha20-Poly1305 took 7.879056 seconds for 1000000 iterations, 4096 bytes message
[wolfCrypt] AES-256-GCM took 125.962188 seconds for 1000000 iterations, 4096 bytes message
[wolfCrypt] ChaCha20-Poly1305 took 27.405068 seconds for 1000000 iterations, 4096 bytes message

ARM64 CPU on Travis CI

[NSS] AES-256-GCM took 154.621518 seconds for 1000000 iterations, 4096 bytes message
[NSS] ChaCha20-Poly1305 took 43.217945 seconds for 1000000 iterations, 4096 bytes message
[OpenSSL] AES-256-GCM took 18.301692 seconds for 1000000 iterations, 4096 bytes message
[OpenSSL] AES-256-OCB took 24.131057 seconds for 1000000 iterations, 4096 bytes message
[OpenSSL] ChaCha20-Poly1305 took 29.108860 seconds for 1000000 iterations, 4096 bytes message
[libsodium] skipping AES-256-GCM benchmark due to missing requirements. SSSE3 extensions, "aesni" and "pclmul" instructions are required.
[libsodium] ChaCha20-Poly1305 took 32.916597 seconds for 1000000 iterations, 4096 bytes message
[wolfCrypt] AES-256-GCM took 247.166981 seconds for 1000000 iterations, 4096 bytes message
[wolfCrypt] ChaCha20-Poly1305 took 44.717989 seconds for 1000000 iterations, 4096 bytes message

Thoughts

Please note that when talking about performance I'm only referring to ChaCha20-Poly1305, which is the cipher we're going to use.

NSS

Advantages

• Permissive license (MPL 2.0).
• FIPS-140 and FIPS-140-2 validated.

Disadvantages

• Low performance. The benchmark's code is based on the tests (https://github.com/nss-dev/nss/blob/master/gtests/pk11_gtest/pk11_aes_gcm_unittest.cc and https://github.com/nss-dev/nss/blob/master/gtests/pk11_gtest/pk11_chacha20poly1305_unittest.cc), thus the API usage should be correct.
• Scarce documentation (https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Reference), but it seems that it's being rewritten.

libsodium

Advantages

• Permissive license (ISC).
• Good performance.
• Simple API and good documentation.

Disadvantages

• Not FIPS-140 validated.

wolfCrypt

Advantages

• FIPS-140 and FIPS-140-2 validated.
• Best performance, even better than OpenSSL, but only when optimizations are enabled...

Disadvantages

• ... and they aren't by default. The official Debian and Ubuntu packages don't enable them, resulting in the very low performance shown in the benchmarks. See [wolfCrypt] Much slower performance compared to other libraries wolfSSL/wolfssl#2691 for further info.
• Restrictive license (GPLv2). May be problematic for a closed-source project based on Mumble.

[trudnorx]

The first question should be: When is Mumble 1.4 going to be released?

It took 10 years to go from Mumble 1.2 to Mumble 1.3. Maybe in 10 years there will be a lot better crypto technology and it's better to decide when Mumble 1.4 release is nearby. In 10 years, assuming OpenSSL is still relevant even very old Ubuntus are going to ship with a new version of it.

Is there any issue with any other OS?

I say:
Keep OpenSSL.

• Old, most widely used and tested.
• Don't have to change code much.
• Best performance.
• Who cares about some old Ubuntu version which is for sure going to be nearing EOL whenever Mumble is released?

[trudnorx]

OpenSSL changelog 1.1.0:

Support for ChaCha20 and Poly1305 added to libcrypto and libssl.

Ubuntu 18.04 LTS has a libssl1.1 package in its repo, so it looks like it supports it to me. Just gotta install it in case it's not installed by default, what's wrong with that?

[Krzmbrzl]

Ubuntu 16.04 will have it's end of life in april 2021. So that's almost another 1,5 years. THough apparently it is not even listed on Ubuntu's website for download anymore...

Can't we statically link to OpenSSL and thus don't care what packages are available on the user's OS?

[davidebeatrici]

@trudnorx Mumble 1.4 is possibly going to be released in 2020.

Changing the code is not an issue, even with OpenSSL we would have to rewrite it, because we're not using the EVP interface right now.

As for the performance and testing, I agree. wolfCrypt would've been a perfect replacement if it wasn't for the optimizations issue and maybe also the license.

@Krzmbrzl That's a valid option, yes. The issue is that also Qt uses OpenSSL, meaning that we would have to link to two different versions of the same library...

[Krzmbrzl]

And Qt also links statically? Why do we need different versions then? Does Qt use a version that is too old?

[davidebeatrici]

Qt uses the version provided by the distribution (unless we link to our own Qt).

[Krzmbrzl]

Ah and I assume this would make things complicated once we start statically linking to another version of OpenSSL 💡

[trudnorx]

Problem with statically linking OpenSSL is that it wouldn't get security updates.

[davidebeatrici]

Indeed.

One thing we could do is write an implementation for OpenSSL and one for libsodium, using the latter only when EVP_chacha20_poly1305() is not available.

https://cmake.org/cmake/help/latest/module/CheckFunctionExists.html

[trudnorx]

1. Keeping OpenSSL still sounds like the best option. No need to implement libsodium or anything else at all. Seems to me like that just adds more complexity and more problems for no good reason.

2. These benchmarks aren't really telling us much. Will it add any latency to voice communication and if so how much vs. the current AES-128-OCB mode? In my any more latency would be unacceptable. How would it affect the average CPU usage of the program in the average situation?

3. What is the problem with patents?
   OCB is licensed free to use for OpenSSL and any programs using OpenSSL.
   OCB is licensed free to use for any programs releasing source code and allowing free copying, modification, and re-distribution of that source code.
   OCB is also licensed free to use for any non-commercial and non-military software.

And as far as I understand these things are OR. So it's (uses OpenSSL) OR (free source) OR (noncommercial AND nonmilitary).

So what's the problem with just using OCB3?

4. How about keep OpenSSL but switch to DTLS with AES-256-GCM? Does this solve how it is "harder" to use without TLS? What is the problem with that? Any platforms is it incompatible with?

[Krzmbrzl]

The point about patents is that Mumble uses a BSD license which grants rights that are incompatible with those patents. Thus for people using mumble commercially, this would be a problem

Using libsodium as a backup solution sounds good to me. Though I don't know how much effort this would be

[trudnorx]

The point about patents is that Mumble uses a BSD license which grants rights that are incompatible with those patents. Thus for people using mumble commercially, this would be a problem

As far as I understand that wouldn't be a problem because there is a patent grant for programs using OpenSSL. So even if they make commercial software based on Mumble and don't release the source, there is still no patent problem.

https://web.cs.ucdavis.edu/~rogaway/ocb/license3.pdf

[Krzmbrzl]

Hm I'm far from being an lawyer but I guess you could be correct. I don't know though if this license allows OpenSSL to implement it and does not grant further permission to the party using OpenSSL...

[davidebeatrici]

Also, OCB was introduced in OpenSSL 1.1 (https://www.openssl.org/docs/manmaster/man3/EVP_aes_256_ocb.html), meaning that the compatibility issue would remain.

2. These benchmarks aren't really telling us much. Will it add any latency to voice communication and if so how much vs. the current AES-128-OCB mode? In my any more latency would be unacceptable. How would it affect the average CPU usage of the program in the average situation?

Our current implementation doesn't make use of AES-NI, meaning that only the higher bits (256 instead of 128) can lower the performance.

[trudnorx]

Hm I'm far from being an lawyer but I guess you could be correct. I don't know though if this license allows OpenSSL to implement it and does not grant further permission to the party using OpenSSL...

It allows all those permissions to the party using OpenSSL. Just read it. Read points 1.3, 1.4 and 2.1. There is no patent problem.

[Krzmbrzl]

From reading Mumble.proto it is not clear to me, if there is a recommended way of negotiating capabilites.

Afaik there is not

Is it only about the cipher? Maybe the AudioTransport should be negotiated instead (which could imply the cipher or another method of negotiation like TLS)?

That way you'd still be stuck on a specific cipher for a given transport protocol. If you need to change the cipher (because it is deemed un-secure), you'd be out of luck.
Instead I think the audio transport protocol negotiation could be added in addition to the cipher negotiation.

Imo that belongs into a separate issue though ☝️

[streaps]

That way you'd still be stuck on a specific cipher for a given transport protocol

You just negotiate a name that defines the transport and the cipher, like:

udp-aes128-ocb
udp-chacha20-poly1305
udp-aegis-256
webrtc
quic

[TerryGeng]

@streaps I'm tracing the opus flag inside Authenticate message.

It looks like only few places referred to this field.
Set:

1. murmur/Server.cpp, inside Server::recheckCodecVersions, tell clients the codecs the server supported. Interestingly, I believe the server doesn't decode audio packets.
2. mumble/ServerHandler.cpp, inside ServerHandler::serverConnectionConnected, tell the server if the client support Opus. But there's already a flag doing the same thing inside CodecVersion.

Read:

1. murmur/Message.cpp, inside Server::msgAuthenticate, set a flag to indicate the user support opus. But this field seems to be not very useful since codec information is included in voice packets.

Therefore, I believe it can be deleted without much to worry about.

What bothers me is

mumble/src/murmur/Server.cpp

Lines 2020 to 2021 in e6f9883

	// Enable Opus if the number of users with Opus is higher than the threshold
	bool enableOpus = ((opus * 100 / users) >= iOpusThreshold);

I think this part is certainly deprecated and need to be removed in the next version.

Also, I discovered there're also many places in our proto has Opus field. Like UserStats and CodecVersion. I think we only need to keep the one inside CodecVersion. Other duplicated Opus fields should be removed.

I will open another issue regarding this.

[TerryGeng]

@streaps However, UDP ping packets is also encrypted, so it does not entirely belong to audio.

Currently, I still decide that I will go with adding a supported_cipher field in CryptoModes CryptSetup.

[streaps]

@TerryGeng,
the UDP ping packet is only relevant if UDP is used for audio. It's part of the UDP audio transport.

I don't like the name CryptoModes as it suggest a "mode of operation" in crypto speak (IMO). I also feel that CryptoModes in the Version packet is the equivalent of "celt_versions" and "opus" fields the in Authenticate packet. More like a patchwork of stuff lacking any deliberate design.

[yuhong]

Keep in mind that OCB patents are about to expire as well.

[streaps]

There are no real problems with the OCB patents anyway. It's only FUD (yes, some libre software fanatics can spread that too).

[Krzmbrzl]

There are no real problems with the OCB patents anyway. It's only FUD (yes, some libre software fanatics can spread that too).

According to https://en.wikipedia.org/wiki/OCB_mode#Patents it is only allowed to use OCB in software licensed under GPL (which Mumble is not) or in a non-commercial setting. There's the problem: Right now it is currently not possible to legally use Mumble commercially without fiddling with those patents.
That's at least how I understand it 🤷

[streaps]

According to the same Wikipedia page:
"By January 2013, the author has granted a free license for any open source license certified by the Open Source Initiative."

and according to the linked license page:
"License 2 — General License for Non-Military Software Implementations OCB (Jan 10, 2013).
This license does not authorize any military use of OCB. Aside from military uses, you are authorized to make, use, and distribute (1) any software implementation of OCB"

also:
"License 3 — Patent License for OpenSSL (Nov 13, 2013).
This license was provided at the request of the OpenSSL Software Foundation to specifically authorize use of OCB in OpenSSL."

https://www.cs.ucdavis.edu/~rogaway/ocb/license.htm

[elch01]

Why not LibreSSL?

[ghost]

Why not LibreSSL?

It appears to be in vcpkg:

https://github.com/microsoft/vcpkg/tree/master/ports/libressl

If their licensing is compatible it might be worth a discussion.

[thorvald]

To provide a bit of historical context: When we first implemented the crypt layer, we reached out to the inventor of OCB about the licensing. As a result, Mumble has an explicit permission, direct from the inventor, to include OCB under BSD (as well as GPL) on a royalty-free basis.

[EP-u-NW]

Just for the records: I think that the patent on OCB was dropped, so it's also free for non-open-source projects: https://mailarchive.ietf.org/arch/msg/cfrg/qLTveWOdTJcLn4HP3ev-vrj05Vg/

[andreygursky]

Why not LibreSSL?

It appears to be in vcpkg: ...

But it is missing in Debian GNU/Linux and perhaps all derivatives.

[Krzmbrzl]

Okay let's open the DTLS box again.

@jedisct1 and @streaps you voiced concerns about DTLS being slow, insecure and too much overhead. Could you perhaps elaborate on that (preferably with some sources linked)?

When I read the DTLS specs it did not appear as if it was doing something very different than what we are doing right now except that it does not require a separate TCP channel to get things done 👀

[TerryGeng]

Not familiar with DTLS... but I think one purpose of #4824 is to keep the backward compatibility. If we use DTLS for control messages, it doesn't sound like a simple crypto enhancement anymore but a full-blown protocol rework.

[Krzmbrzl]

Indeed. But imo Mumble would benefit from a protocol rework that makes the protocol itself more flexible. And backwards compatibility could be maintained (for a while) by keeping the current mechanism available for communication with older Mumble clients/servers.

[Johni0702]

I feel like DTLS should live one layer below the negotiation implemented by #4824 precisely because that keeps us more flexible.
That is, even if we do end up deciding to use DTLS as the new preferred option, that does not affect the PR because the voice transport negotiation in it was specifically designed to give us that flexibility.

And it doesn't limit us to just DTLS, if it turns out to be too slow or just not feasible for certain clients, they can use AES-256-GCM instead. And if we ever want to get rid of DTLS for whatever reason like we do with OCB2 now, then we likely end up with #4824 anyway but now with another layer of backwards compatibility code for DTLS on top.

Some examples of things the voice transport negotiation can do which are difficult/impossible with a pure DTLS solution (there's probably more reasons in #4248):

• QUIC, which already handles encryption for us
• Browser-based clients, which cannot freely do DTLS, only WebRTC
• Custom transports in a way that doesn't break when the official protobuf file is changed
• Awesome cipher X which is not supported by DTLS
• Changes to the voice packet encoding (e.g. Change UDP protocol #4284)

[Krzmbrzl]

@Johni0702 excellent point. In my mind DTLS and the negotiation protocol were an "either-or" decision whereas these are actually orthogonal features 👍

I assume the only adaption that is needed for #4824 is that depending on the agreed-upon method there will be no CryptSetup message (e.g. because for instance for DTLS all of that is done via the UDP channel anyway). Though I think this is not even really part of that PR, only its description.
@TerryGeng thoughts?

[andreasstieger]

The OCB patent issue is now resolved, see #6403 / #6404