Cannot share keys after re-login

[hitriyvalenok]

Steps to reproduce

I created a second account (wentel-test) and set up a test room. I logged out from wentel-test, sent a message to the room from my main account, then logged back as wentel-test (using the recovery key). The message expectedly couldn't be decrypted.

Outcome

The keys aren't being requested automatically (even though notifications are enabled in my main account's browser), and I can't request them manually (only have three options: Share, Report, View Source). Key storage is enabled, all settings are at default.

What did you expect?

wentel-test to be able to request sharing the keys OR keys to be shared automatically

What happened instead?

nothing

Operating system

MacOS (Catalinf)

Browser information

128.0.6613.138

URL for webapp

https://app.element.io/

Application version

1.11.97

Homeserver

No response

Will you send logs?

wentel (main).zip
wentel-test.zip

[t3chguy]

The keys aren't being requested automatically

Even if they were, the request would be rejected.

This is a feature called PFS https://www.vmware.com/topics/perfect-forward-secrecy

If a user has 0 devices logged in at the time a message is sent then no encryption keys are shared to that user for a given megolm session. The solution to this is something called device dehydration which is already supported in Labs but requires specific support from your server.

Closing in favour of device dehydration

[hitriyvalenok]

If a user has 0 devices logged in at the time a message is sent then no encryption keys are shared to that user for a given megolm session

Perhaps I wasn't clear enough. There were two users in the room: main and test. Only the test user logged out, while main remained in the room the entire time. So there was always at least one user (main) present in the room continuously. But when test returned, it still had no option to request keys from main.

[t3chguy]

@hitriyvalenok perhaps I wasn't clear, I said "devices" not "users".

A user has 0-N devices. If a user has 0 devices then PFS means they cannot decrypt anything that happens during the period of time when they have 0 devices. PFS allows you to protect against situations where devices are lost/stolen or passwords leaked so that impacted messages are minimised to just that which happened during the breach, any history before the breach, and any messages after the breach would be undecryptable.

they still had no option to request keys from main.

Because the Matrix protocol does not allow this. I mean you could request, but the other side would reject, due to PFS, which is a feature of the Megolm protocol.

[hitriyvalenok]

Thanks for your reply!

device dehydration which is already supported in Labs but requires specific support from your server.

Can I use this feature on the default matrix.org server?

[t3chguy]

I don't think so, matrix.org tends to not enable features until they are stable in the Matrix spec and matrix-org/matrix-spec-proposals#3814 is still in draft

[hitriyvalenok]

Is device dehydration safe to use?

[t3chguy]

I'm not involved with that project.
Fundamentally it is just another "device" that is uploaded encrypted to your account which you can recover (using recovery key) when you log back in from the state where you have 0 non-dehydrated devices.

So the worst case scenario would be that the dehydrated device becomes unrecoverable and it does not grant you access to history whilst you had 0 (other) devices.

Thus, depends on what you mean safe. I think the implementation may still have some bugs: https://github.com/element-hq/element-web/issues?q=sort%3Aupdated-desc%20is%3Aissue%20is%3Aopen%20%20label%3AA-E2EE-Dehydration%20