Backport "FIX(ocb2): Work around packet loss due to OCB2 XEX* mitigation" #4738
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Krzmbrzl
changed the title
Krzmbrzl
force-pushed
the
backport-4720
branch
from
7e845db
to
5570804
Compare
The mitigation for vulnerabilities discovered in OCB2 (https://eprint.iacr.org/2019/311, called XEX* attack, or XEXStarAttack, in code) introduced in be97594 (mumble-voip#4227) willingly allowed for some packets with specific characteristics to be dropped during encryption to prevent the vulnerability from being exploited. It was assumed that the chance of such packets was sufficiently small (given we are dealing with compressed audio) that such loss was acceptable. It was however discovered that digital silence (as produced by e.g. a noise gate) will cause Opus to emit almost exclusively such packets, leading to strong artifacts on the receiving end. See mumble-voip#4385. This commit tries to work around the issue by modifying such packets in a way which will no longer require them to be dropped, and yet produce the expected output on the receiver side. As far as I understand [Opus] (specifically section 4.1, 4.3.0 and 4.3.3), the 0s are simply unused bits and are only there because we running Opus in constant bitrate mode. So, flipping one of them should have no effect on the resulting audio. [Opus]: https://tools.ietf.org/html/rfc6716 Fixes mumble-voip#4719
Krzmbrzl
force-pushed
the
backport-4720
branch
from
5570804
to
c1ceb59
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The mitigation for vulnerabilities discovered in
OCB2 (https://eprint.iacr.org/2019/311, called XEX* attack, or XEXStarAttack, in code)
introduced in be97594 (#4227) willingly allowed for some packets with specific
characteristics to be dropped during encryption to prevent the vulnerability
from being exploited.
It was assumed that the chance of such packets was sufficiently small (given
we are dealing with compressed audio) that such loss was acceptable.
It was however discovered that digital silence (as produced by e.g. a noise
gate) will cause Opus to emit almost exclusively such packets, leading to strong
artifacts on the receiving end. See #4385.
This commit tries to work around the issue by modifying such packets in a way
which will no longer require them to be dropped, and yet produce the expected
output on the receiver side.
As far as I understand Opus (specifically section 4.1, 4.3.0 and 4.3.3), the
0s are simply unused bits and are only there because we running Opus in constant
bitrate mode. So, flipping one of them should have no effect on the resulting
audio.
This is a backport of #4720