MSC3270: Symmetric megolm backup

[uhoreg]

Rendered

Implementations

• JS SDK
• Polyjuice Client Test

[deepbluev7]

This stays as v1, because it uses the same API, only the algorithm is different? (I would have expected a v2, but it doesn't really seem necessary, just surprising!)

[uhoreg]

My rationale is that it's v1 of the aes-hmac-sha2 algorithm. We probably should have put the version number after the name originally (so that we would end up with m.megolm_backup.aes-hmac-sha2.v1), but we did it this way to begin with.

I'm open to being persuaded that it should be different.

[deepbluev7]

I don't really see a reason for v2, apart from being able to distinguish the backup format the key name. (See other thread)

[poljar]

I see a couple of reasons:

1. Newcomers can quickly know how many versions there were in total.
2. It's not ambiguous which backup algorithm I mean if I just say the version number N.
3. Since it's unlikely that the algorithm won't change when the version number changes we're going to have only v1 algorithms, which renders the version number pointless.
4. Since the key itself didn't change but only the way we use it has, we can have a RecoveryKey struct that now has a decrypt_v1() and decrypt_v2() method.

[uhoreg]

Soru commented:

Fair point, calling it v2 will be trivial

(It's too bad GitHub doesn't automatically put email replies in the right thread.)

[uhoreg]

I'm not sure that it's that important that people can easily tell how many versions there are. Especially since the old algorithm will eventually be deprecated and (hopefully eventually) will be able to be ignored. So in practice we'll end up with just one version in use.

Also, I don't think that we would refer to backup algorithms by number -- I think that it would be more common to refer to them by name, or as "symmetric" versus "asymmetric". And I think it would be confusing to have two different ways (number and name) to distinguish the two algorithms embedded in the same string.

If people don't like the m.megolm_backup.v1.aes-hmac-sha2, my current first preference would be switching to m.megolm_backup.aes-hmac-sha2.v1 (so that it's clearer that we're talking about version 1 of the aes-hmac-sha2 method, rather than version 1 of megolm backup) and my second preference would be to drop the number altogether (m.megolm_backup.aes-hmac-sha2) so that we avoid the confusion altogether.

[dkasak]

I think that it would be more common to refer to them by name, or as "symmetric" versus "asymmetric".

I agree with this and I think it does have merit to name things in a way that makes it easy to refer to them, both from code (in the form of method names) and in casual conversation.

So I'm wondering if it's even important to include the crypto construct name in the version at all? It's clunky to spell out so it's unlikely to ever get used in conversation, and then you have to mentally translate between symmetric and aes-hmac-sha2. Would it perhaps make more sense to name it m.megolm_backup.symmetric.v1?

Barring that, I would prefer moving the version number to the end.

[uhoreg]

We generally try to include the algorithm names, as explained in https://spec.matrix.org/unstable/client-server-api/#messaging-algorithm-names

[deepbluev7]

Can the old encryption key be reused, that is already stored under this key? Or should a new one be generated? How does a client tell in that case, that this key is for the new or old backup?

[uhoreg]

Yes, this is the same issue that we have when you create a new backup version -- you can't tell if the thing stored in SSSS is for the new backup or the old backup. The best we can say right now is that the key stored in SSSS should be for the current backup, which means that there is a race when you're migrating from one backup to the other.

We could fix this by saying that we should store it using the name m.megolm_backup.v1.<backup version>, but it's unclear if we should fix this as part of this MSC, or as a separate MSC.

[deepbluev7]

In this special instance, we could also name the key v2, which would make it obvious, but we may want to reserve v2 for proper naming of the keys? Although I would prefer to only migrate all key backups once, in which case a new naming scheme may make sense being introduced in this as well.

[deepbluev7]

Until https://github.com/uhoreg/matrix-js-sdk/tree/symmetric_backup is ready, I think you need to also add the need-implementation label.

[cbarrete]

The implementation details of some clients don't make "the original factor for choosing asymmetric
encryption obsolete" at the spec level. As long as a user doesn't use such a client, this doesn't affect them at all.

[Sorunome]

The thought behind this paragraph was probably that some x-signing keys typically need to be cached anyways so it is trivial to toss the megolm key into said cache. online megolm backup outdates x-signing.

[cbarrete]

While I don't disagree with this, I don't think that current implementation practices should legitimize increasing the impact of a client being compromised at the spec level.

[Sorunome]

The current (unstable) spec with asymmetric megolm backup introduces a security issue (not because of the specific asymmetric implementation, but because of using asymmetric cryptography in a place where symmetric one is more appropriate), which lead to this MSC, as outlined in the first paragraph.

So, we are closing one bigger security issue with this. Clients who don't want to cache the key could always have the user manually input it for a one-shot sync or similar.

[ara4n]

i think the risks here depend on your threat model. if you trust your server admin not to inject malicious history (but you want the legit history to be as secure as possible), then using a client with assymetric crypto which doesn’t cache the megolm key may be most appropriate. The use case here might be a govt server or something where you assume the server is generally trusted but you still don’t want your messages to be exposed if the server was compromised - and are happy for msgs whose keys came from msg backup to say “untrusted”.

Conversely, if you are a random user on a relatively untrusted server (eg using a public hosting solution), you might be very worried about the server sending you faked history when you log in on a new device (eg some malware attachment which appears to come from a verified user but was actually inserted by the server admin). In which case risks of an endpoint attack stealing your symmetric backup key might be less than the risk of a malicious server admin attack, making this MSC worthwhile.

I feel pretty uncomfortable that after all the effort the double ratchet takes to mitigate the risk of key exfiltration by having a self healing ratchet, we end up a) storing all our megolm keys locally anyway, b) storing our megolm backup key locally too. That said, given the megolm keys are stored locally anyway… perhaps storing the backup key is okay. (At which point, why are we even using the double ratchet in the first place?)

[deepbluev7]

If you are storing the backup key and all sessions you know about locally, I think symmetric backup is fine. If you don't want past messages to get compromised, wouldn't you rather just not use any backup at all and as soon as you log out, all your history is burned and lost? That gives you the best forward secrecy.

Asymmetric backup is somewhere in between, where only the device with the decryption key can decrypt the past messages, while other devices can only upload keys into the backup. But that backup can still get compromised, you could just theoretically require the client to always prompt for a password to decrypt past messages. That is however weakened by other clients readily sharing the backup key, if a verified device asks for it. So really, I think the best approach here is to disable the online key backup and rely on key gossiping instead to access past messages. Because then at least you always have the control of burning old decryption keys. Once you upload a backup, that is always there and once someone gets access to the key, those messages are all forever compromised.

[uhoreg]

As I discovered when writing matrix-org/matrix-spec#1294, the spec uses the term "trusted" to mean different things is different contexts, so we may want to consider using a different term. Suggestions welcome.

[deepbluev7]

Could we maybe store what the session was signed by?

[richvdh]

@uhoreg I gather we are planning to do something different to this? (#4048) Should this MSC be closed?

[uhoreg]

Closed in favour of #4048