Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Explain in docs how and why Shelter Protocol has better TOFU than other protocols #6

Open
taoeffect opened this issue Sep 17, 2024 · 1 comment
Assignees
Labels
documentation Improvements or additions to documentation enhancement New feature or request

Comments

@taoeffect
Copy link
Member

Problem

The docs don't mention something important that people might want to know about SP:

Fun fact: with Shelter Protocol, unlike Signal, your "fingerprint" doesn't change for your contacts when you get a new phone.

It's really TOFU, not TOFU, and TOFU again, and again, and again.

Solution

Explain why this is and how it works.

@taoeffect taoeffect added documentation Improvements or additions to documentation enhancement New feature or request labels Sep 17, 2024
@corrideat
Copy link
Member

corrideat commented Sep 17, 2024

I'd rather focus on development at the moment, but briefly:

The reason this is so is because identities are tied to long-term keys that are generated at contract creation. These keys can be rotated, but there always is a chain of trust that ultimately can be linked to these initial keys. In GI, when one uses a password, the account is 'recovered' and these main keys are recovered.

Drawing a parallel to Signal, these keys are local to the device, and so, installing Signal again (or getting a new device) involves re-registration, with the effect that the account is essentially 'fresh'. I'm not sure if the folks at Signal have addressed this with cloud or other backups, but theoretically they could handle it this way.

Whether this is desirable or not (referring both to Chelonia and Signal) is debatable and depends on the trust model and underlying assumptions made. However, I think Chelonia is superior because:

  • Re-registration can happen if desirable
  • Nothing stops an implementation from making device-local keys only
  • Nothing stops an implementation from showing key rotations, even without re-registration. This would help maintain a long-term identity with device-local keys while still showing counterparties that a new device is in use.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants