Support multiple encrypted channels for a single event #386
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
To encrypt a message against multiple channels, two things are needed:
1. A method of encoding _which_ channels are included in the key derivation that's order-independent.
2. A method of deriving a shared secret for multiple channels.
This implements both and integrates it into the pusher workflow.
A message encrypted to multiple recipients encodes the channel metadata into an encrypted header.
For example:
```
private-encrypted-multi-00000000000000207b2263223a5b22626172222c22626c61222c22666f6f225d2c2272223a22227d:{"nonce":"MyNLvxXvz3nJ\/lMv+oRtK991TXW\/00Kx","ciphertext":"+nkcgt+SUDY42NqKCsxB5DgfGz1uhbNgx\/DJkHeL4ffH0JAkbUGgSpd+AzXGx9C6uQ=="}
```
This hex string is encoded as strlen(data) + data. It encodes two pieces of information:
1. A list of suffixes for the encrypted channel names.
2. Optional additional randomness for key derivation.
The suffixes can be used at runtime to re-assemble the channel names.
Given a list of channel names, one can additionally derive a shared secret for the message that all channels should be able to decrypt.
The algorithm it uses is HMAC-SHA256 with an input that consists of lengths of segments followed by the segments' raw data. This design was inspired by PAE from PASETO and TupleHash from the NIST standard.
https://www.nist.gov/publications/sha-3-derived-functions-cshake-kmac-tuplehash-and-parallelhash
Each segment in calculating the shared secret is that channel's shared secret.
This commit does not update the documentation or guidance around limitations. A congruent change would need to land in every other Pusher implementation before it could be updated.
| $pos = strlen(self::ENCRYPTED_PREFIX); | ||
| foreach ($sorted as $ch) { | ||
| if (!self::is_encrypted_channel($ch)) { | ||
| continue; |
There was a problem hiding this comment.
We may want to throw here instead. The intent for this method is to only allow encrypted channels.
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.
Note: This assumes all channels have the same master secret.
If you're interested in an E2EE design that doesn't have this requirement, crypto_box_seal only requires the recipient's public key.
To encrypt a message against multiple channels, two things are needed:
This implements both and integrates it into the pusher workflow.
A message encrypted to multiple recipients encodes the channel metadata into an encrypted header.
For example:
This hex string is encoded as strlen(data) + data. It encodes two pieces of information:
The suffixes can be used at runtime to re-assemble the channel names.
Given a list of channel names, one can additionally derive a shared secret for the message that all channels should be able to decrypt.
The algorithm it uses is HMAC-SHA256 with an input that consists of lengths of segments followed by the segments' raw data. This design was inspired by PAE from PASETO and TupleHash from the NIST standard.
https://www.nist.gov/publications/sha-3-derived-functions-cshake-kmac-tuplehash-and-parallelhash
Each segment in calculating the shared secret is that channel's shared secret.
The first commit does not update the documentation or guidance around limitations. A congruent change would need to land in every other Pusher implementation before it could be updated.
Description
Fixes #383