2.8 KiB
MSC2874: Single SSSS
Secure Secret Storage and Sharing (SSSS) was designed to allow the user to create multiple keys that would be able to decrypt different subsets of the secrets. However, the vast majority of users do not need this feature.
This proposal defines how clients should behave if they only wish to support a
single key, by defining which key clients should use if multiple keys are
present. It also makes the name field in the m.secret_storage.key.* events
optional, as this field was mainly added to allow a user to select between
different keys.
Proposal
If a client wants to present a simplified interface to users by not supporting
multiple SSSS keys, then the client should use the default key (the key listed
in the m.secret_storage.default_key account data event.) If there is no
default key the client may behave as if there is no SSSS key at all. When such
a client creates an SSSS key, it must mark that key as being the default key.
The name field in the m.secret_storage.key.* account data events is
optional, rather than required. If a client wishes to display multiple keys to
a user and a given key does not have a name field, the client may use a
default name as the key's name, such as "Unnamed key", or "Default key" if the
key is marked as default.
For example, when a client creates a key with ID abcdefg, it will create an
m.secret_storage.key.abcdefg account data event to store information about
the key. It will then mark it as the default key by setting the
m.secret_storage.default_key account data to {"key": "abcdefg"}. When
another client logs in after this, it will see that the default key has been
set, and will know to use that key as the SSSS key.
Potential issues
If secrets are encrypted using a key that is not marked as default, a client might not decrypt the secrets, even if it would otherwise be able to.
Alternatives
Rather than solely relying on the key marked as default, a client could guess at what key to use. For example, it could look at the secrets that it needs, see what keys they are encrypted with, and if there is only one common key, then it could use that. (This is what Element currently does.) Or if there are multiple keys, it could use some sort of heuristic to pick a key. However, this approach can be error-prone, and it is better to rely on an explicit marking.
Security considerations
None
Unstable prefix
An unstable prefix is not needed for a behaviour change in choosing the key to use as there are no event/endpoint changes.
Some clients already omit the name field (notably, matrix-js-sdk
unintentionally does this -- mea culpa), and this does not seem to be causing
issues, so an unstable prefix seems unnecessary for this.