Replace OCB-AES128 encryption with free alternative #445

New issue

Closed

opened 2026-02-20 19:25:40 -05:00 by deekerman · 3 comments

deekerman commented

2026-02-20 19:25:40 -05:00

Owner

Originally created by @ghost on GitHub (Jan 23, 2015).

Mumble currently uses the OCB algorithm for the encryption of UDP. Unfortunately, this algorithm is patented in the United States and requires a license when used in commercial software.

The licensing does not pose a problem to Mumble directly, but rather to those who implement the Mumble protocol. The restriction means Mumble-related software cannot (a) be compatible with the official Mumble server software and implement UDP audio, and (b) be sold inside the U.S. without purchasing an OCB license.

I propose that an algorithm that does not have these restrictions be used (or at least be supported by murmur) for UDP encryption. While I have not researched such an algorithm, this link contains the names of several alternatives: Why is OCB-AES mode not becoming a standard for authenticated encryption?

I can appreciate that this issue will probably only be solved by someone developing 3rd-party Mumble clients, but I thought I would bring it to attention anyway.

Any thoughts on this?

Originally created by @ghost on GitHub (Jan 23, 2015). Mumble currently uses the [OCB](http://web.cs.ucdavis.edu/~rogaway/ocb/) algorithm for the encryption of UDP. Unfortunately, this algorithm is patented in the United States and requires a [license](http://web.cs.ucdavis.edu/~rogaway/ocb/license.htm) when used in commercial software. The licensing does not pose a problem to Mumble directly, but rather to those who implement the Mumble protocol. The restriction means Mumble-related software cannot (a) be compatible with the official Mumble server software and implement UDP audio, and (b) be sold inside the U.S. without purchasing an OCB license. I propose that an algorithm that does not have these restrictions be used (or at least be supported by murmur) for UDP encryption. While I have not researched such an algorithm, this link contains the names of several alternatives: [Why is OCB-AES mode not becoming a standard for authenticated encryption?](https://crypto.stackexchange.com/questions/5639/why-is-ocb-aes-mode-not-becoming-a-standard-for-authenticated-encryption) I can appreciate that this issue will probably only be solved by someone developing 3rd-party Mumble clients, but I thought I would bring it to attention anyway. Any thoughts on this?

deekerman closed this issue

2026-02-20 19:25:43 -05:00

deekerman commented

2026-02-20 19:25:45 -05:00

Author

Owner

@mkrautz commented on GitHub (Jan 23, 2015):

The OCB license was actually made quite a bit less strict a couple of years ago, so it is not as bad as you portray.

However, I agree with the sentiment.

Some time ago, I implemented XSalsa20-Poly1305 support in Grumble (the server, not your Grumble!)

See https://github.com/mumble-voip/grumble/tree/master/pkg/cryptstate

It also includes some negotiation logic for selecting the supported crypto modes.

I know @hacst is not fond of implementing an additional mode. I've previously voiced my support of doing it, though.

@mkrautz commented on GitHub (Jan 23, 2015): The OCB license was actually made quite a bit less strict a couple of years ago, so it is not as bad as you portray. However, I agree with the sentiment. Some time ago, I implemented XSalsa20-Poly1305 support in Grumble (the server, not your Grumble!) See https://github.com/mumble-voip/grumble/tree/master/pkg/cryptstate It also includes some negotiation logic for selecting the supported crypto modes. I know @hacst is not fond of implementing an additional mode. I've previously voiced my support of doing it, though.

deekerman commented

2026-02-20 19:25:47 -05:00

Author

Owner

@mkrautz commented on GitHub (Jan 23, 2015):

~~Actually, I take my comment back. I see that the #2 OCB license does not allow commercial use.~~

Edit: Only hardware implementations require a separate license. Software implementations are free to use OCB in any way they wish (as long as they're not military).

@mkrautz commented on GitHub (Jan 23, 2015): ~~Actually, I take my comment back. I see that the #2 OCB license does not allow commercial use.~~ Edit: Only hardware implementations require a separate license. Software implementations are free to use OCB in any way they wish (as long as they're not military).

deekerman commented

2026-02-20 19:25:47 -05:00

Author

Owner

@ghost commented on GitHub (Jan 23, 2015):

~~Actually, I take my comment back. I see that the #2 OCB license does not allow commercial use.~~

I'm glad I wasn't the only one who misread the license wording. Thanks for the clarification.

Software implementations are free to use OCB in any way they wish (as long as they're not military).

That's probably permissive enough not to change the implementation.

@ghost commented on GitHub (Jan 23, 2015): > <strike>Actually, I take my comment back. I see that the #2 OCB license does not allow commercial use.</strike> I'm glad I wasn't the only one who misread the license wording. Thanks for the clarification. > Software implementations are free to use OCB in any way they wish (as long as they're not military). That's probably permissive enough not to change the implementation.