You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
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.
The text was updated successfully, but these errors were encountered: