Make KeyProvider and ParticipantKeyHandler work consistently for shared key and sender key scenarios (e2ee) #850
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
🦋 Changeset detectedLatest commit: ff4e6a5 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
size-limit report 📦
|
lukasIO
changed the title
davidzhao
approved these changes
Aug 23, 2023
| this.e2eeManager.setParticipantCryptorEnabled(enabled), | ||
| ]); | ||
| await Promise.all([this.localParticipant.setE2EEEnabled(enabled)]); | ||
| if (this.localParticipant.identity !== '') { |
There was a problem hiding this comment.
good to be safe here. could this this be true?
There was a problem hiding this comment.
localParticipant.identity gets initialized with an empty string on room creation. As long as we don't know the actual identity, it doesn't make sense to enable the cryptor with a wrong/dummy identity. We do however use the most recent setting for localParticipant.isE2EEEnabled on SignalConnected now to enable the cryptor once we know the local participant's identity.
lukasIO
changed the title
Merged
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.
main motivation for these fixes was an inconsistency in setting the local participant's keys, which expected the participantId to be
undefined. This caused a bug when trying to set individual sender keys instead of using a shared-key provider.Initially this was done because when
setKeyon a KeyProvider was called, we had no way of figuring out whether or not that participant is actually the local participant, until we're connected to the server and have the participant identity info.This PR
enabledEncryptionMapthat tracks whether or not encryption is enabled for a specific participant (previously this was handled as part of theParticipantKeyHandler)SignalConnected(the earliest we know the identity without manually parsing the token)initAckworker message in order not to have to mis-use the existingenablemessage for that purposesharedKeyHandlerthat handles all key interactions whensharedKeyis set to true. Previously an instance was created for each participant, but in the shared key scenario that makes less sense. the only downside is that ratcheting doesn't work independently now, but I don't really see a reason in the shared key scenario for ratcheting anyways.