Rotating the current device keys will break encryption and cause UTDs

[BillCarsonFr]

When a new session (device) is created, the device keys for that session (device) are uploaded:

• Ed25519 fingerprint key
• Curve25519 identity key

These keys are then published to the homeserver, which is done by using the device_keys property of the /keys/upload endpoint.

As per implementation guide:

Theoretically we should rotate the Curve25519 identity key from time to time, but we haven't implemented this yet.

Currently matrix-sdk-crypto will reject updates of device keys if the signing key (fingerprint key) has changed.

There are some reports of clients re-uploading a new set of Ed25519/Curve25519 keys. This will break encryption for devices that already downloaded the previous set of keys, because the new keys will be ignored, and the old one will still be used as a target for Olm messages.

As a consequence future encrypted to-device messages for that device will encrypt for the old keys and will fail to decrypt with: Olm event doesn't contain a ciphertext for our key.

Future devices will be able to decrypt because they will only have download the new keys.

The problem is that Synapse lets you update a new set of the device keys without complaining, and we know that it will break encryption.

What we can do

• Modify the spec and synapse to do some sanity check on /keys/upload and rejects updates of the Ed25519 fingerprint key
• Could we get some synapse stats on such failures
• Given that no clients supports rotating the Curve25519 key, could we get rid of that in the spec?

[richvdh]

As per spec:

Theoretically we should rotate the Curve25519 identity key from time to time, but we haven't implemented this yet.

@BillCarsonFr: where is this quote from, please?

[richvdh]

Future devices will be able to decrypt because they will only have download the new keys.

@BillCarsonFr: should this be "encrypt"?

[BillCarsonFr]

As per spec:

Theoretically we should rotate the Curve25519 identity key from time to time, but we haven't implemented this yet.

@BillCarsonFr: where is this quote from, please?

https://matrix.org/docs/matrix-concepts/end-to-end-encryption/

[dkasak]

I'm all for ripping Curve25519 key rotation out of the spec and consider it nonsense. The only reason why we've historically opted for a pair of keys instead of just a single one was that we didn't know about or want to implement XEdDSA or equivalent, to be able to sign things with the Curve25519 key. Having a single key makes everything vastly simpler to reason about and also obviously cannot support key rotation without the device's identity changing.