search

saveoursecrets / sdk

High-level, cross-platform SDK for a local-first, distributed encrypted database that can be used to build password managers, cryptocurrency wallets or other applications that require storing secrets securely.
GNU Affero General Public License v3.0
0 stars 0 forks source link

Consider removing account signing key #324

Open tmpfs opened 7 months ago

tmpfs commented 7 months ago

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.

conduition commented 7 months ago

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 commented 7 months ago

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.