auth: ENCRYPTION_FAILURE during key negotiation after key rotation #135
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
…evices of the same user (or one device and the server) try to connect and negotiate a shared key, but one device does not know about a user key rotation yet which happened previously
…lure (and the newly added test case)
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.
Hi Herb!
I recently encountered an ENCRYPTION_FAILURE when I tried to connect my device with the server.
I realized that the server had encrypted the seed for negotiating a shared key with a newer generation of user keys that my device was not yet aware of. As a result, the device was unable to connect and therefore could not synchronize the team graph to receive the new keys and remained locked out.
So I wrote a test that reproduces the problem. It occurs when a user has at least three devices in the team graph, let's say a laptop, a phone and a tablet. If he uses the laptop to remove the phone, the user keys are rotated, but the tablet won't receive the new keys if it's offline during the removal. Since the laptop and the server have the latest user keys, but the tablet doesn't, it becomes unable to connect to the server because the server uses a newer generation of user keys for key negotiation than the tablet.
I am wondering if the problem could be solved by using device keys for key negotiation as device keys never rotate. I have tried it and it solves the problem, passes all tests and I assume it is equally secure. But I'm uneasy about what I don't know, such as your reasons for favoring user keys for shared key negotiation, or security issues or side effects that I'm unaware of.
What do you think?