Safeguard from potential attacks against OCB2 #4227
Merged
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
Closed
3 tasks
OCB2 is known to be broken under certain conditions: https://eprint.iacr.org/2019/311 To execute the universal attacks described in the paper, an attacker needs access to an encryption oracle that allows it to perform encryption queries with attacker-chosen nonce. Luckily in Mumble the encryption nonce is a fixed counter which is far too restrictive for the universal attacks to be feasible against Mumble. The basic attacks do not require an attacker-chosen nonce and as such are more applicable to Mumble. They are however of limited use and do require an en- and a decryption oracle which Mumble seemingly does not provide at the same time. To be on the safe side, this commit implements the counter-cryptanalysis measure described in the paper in section 9 for the sender and receiver side. This way if either server of client are patched, their communication is almost certainly (merely lacking formal proof) not susceptible to the attacks described in the paper.
Krzmbrzl
force-pushed
the
ocb2-counter-cryptanalysis
branch
from
457a78f
to
be97594
Compare
|
I took the liberty of applying the style fixes myself (and squashing them into your original commit) in order for this to get merged ASAP ☝️ |
|
Thank you very much for this contribution :) |
Krzmbrzl
added a commit
that referenced
this pull request
Jun 6, 2020
…against OCB2" OCB2 is known to be broken under certain conditions: https://eprint.iacr.org/2019/311 To execute the universal attacks described in the paper, an attacker needs access to an encryption oracle that allows it to perform encryption queries with attacker-chosen nonce. Luckily in Mumble the encryption nonce is a fixed counter which is far too restrictive for the universal attacks to be feasible against Mumble. The basic attacks do not require an attacker-chosen nonce and as such are more applicable to Mumble. They are however of limited use and do require an en- and a decryption oracle which Mumble seemingly does not provide at the same time. To be on the safe side, this commit implements the counter-cryptanalysis measure described in the paper in section 9 for the sender and receiver side. This way if either server of client are patched, their communication is almost certainly (merely lacking formal proof) not susceptible to the attacks described in the paper. Backported from #4227
10 tasks
Johni0702
added a commit
to Johni0702/mumble
that referenced
this pull request
Jan 26, 2021
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
Johni0702
added a commit
to Johni0702/mumble
that referenced
this pull request
Jan 26, 2021
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
Johni0702
added a commit
to Johni0702/mumble
that referenced
this pull request
Feb 4, 2021
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
added a commit
that referenced
this pull request
Feb 5, 2021
…CB2 XEX* mitigation 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. Fixes #4719
Krzmbrzl
pushed a commit
to Krzmbrzl/mumble
that referenced
this pull request
Feb 6, 2021
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
pushed a commit
to Krzmbrzl/mumble
that referenced
this pull request
Feb 6, 2021
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
pushed a commit
to Krzmbrzl/mumble
that referenced
this pull request
Feb 6, 2021
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
added a commit
that referenced
this pull request
Feb 6, 2021
…s due to OCB2 XEX* mitigation" 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
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.
As explained in #4219 (comment):
The respective paper can be found at https://eprint.iacr.org/2019/311
The thing about 64-bit big-endian hosts turned out to already be handled in the definition of
SWAP64: https://github.com/mumble-voip/mumble/blob/dbac1b91922a06233edde20c46c90831422cdcba/src/ByteSwap.h