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

Consider removing account signing key #324

Open
tmpfs opened this issue Feb 6, 2024 · 2 comments
Open

Consider removing account signing key #324

tmpfs opened this issue Feb 6, 2024 · 2 comments
Assignees

Comments

@tmpfs
Copy link
Collaborator

tmpfs commented Feb 6, 2024

Now that we have device signing keys working it's worth considering removing the account signing key.

Instead use a random identifier, the current address is 20 bytes and we should maintain backwards compatibility so possibly a 16 byte UUID prepended with a fixed 4 byte identifier.

@tmpfs tmpfs self-assigned this Feb 6, 2024
@conduition
Copy link
Contributor

conduition commented Feb 6, 2024

At any point in time, a device key can be either trusted or untrusted on a per-device basis, and device signing keys we trust today might be revoked tomorrow.

Contrastingly, the account signing key is long-lived and irrevocable. If a device is revoked, its device is key is no longer useful, but the account signing key might be useful depending on what its signatures can do. If the user has any revoked devices in their account history, there's a good chance the account signing key might be compromised, and so its signatures can't be trusted.

To head off any accidental dependence on the potentially-exposed account signing key, removing it from the code might be the most hygienic option. However this isn't urgent, as long as nothing currently verifies signatures from the account signing key in any meaningful context.

@tmpfs
Copy link
Collaborator Author

tmpfs commented Feb 11, 2024

Just want to note here that if/when this is done the pairing protocol would no longer require E2EE as the trusted device information is public to the server(s) but really no harm in keeping the encrypted tunnel.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants