In reply to @daedric:aguiarvieira.pt
It makes no sense. :/

In reply to @cvwright:futo.org
There is a spec change proposal MSC3061 that provides a way to share older historical room keys with new users, more in line with the room's history visibility setting.

In reply to @ity:itycodes.org
Only if you are cross-signed and their client sends them, iirc.

In reply to @bluescreenoff:matrix.org
Why not? I don't think I said anything wrong?

In reply to @dkasak:termina.org.uk
No, you can never re-receive old keys from other people, only from other cross signed devices of your own.

Hmm according to this (https://blog.neko.dev/posts/unable-to-decrypt-matrix.html) article it is possible to receive them from the sender
So I couldn't decrypt my own messages from the past but from my chat partner as long as they still have the keys for their sent messages (which is the case in my example) so I should be able to get the keys or not? But I seem to not get them even when the other person is online at the same time as I am. So is there anything I have to do in addition to initiate the request for the sender's keys?

From the article: "Now comes the real magic. Clients can request keys from each other by sending a key request. That way you can request the keys to all unreadable messages either from one of your devices or the original sender. This however has limitations. What if your other clients don't exist or are offline? Or the original sender isn't online? Well, then none can send you keys, so you will never receive them. Sorry, make sure to keep a backup next time!"

In reply to @brayd:chat.braydmedia.de

Hmm according to this (https://blog.neko.dev/posts/unable-to-decrypt-matrix.html) article it is possible to receive them from the sender
So I couldn't decrypt my own messages from the past but from my chat partner as long as they still have the keys for their sent messages (which is the case in my example) so I should be able to get the keys or not? But I seem to not get them even when the other person is online at the same time as I am. So is there anything I have to do in addition to initiate the request for the sender's keys?

From the article: "Now comes the real magic. Clients can request keys from each other by sending a key request. That way you can request the keys to all unreadable messages either from one of your devices or the original sender. This however has limitations. What if your other clients don't exist or are offline? Or the original sender isn't online? Well, then none can send you keys, so you will never receive them. Sorry, make sure to keep a backup next time!"

These behaviours were further restricted as part of remediations of https://matrix.org/blog/2022/09/28/upgrade-now-to-address-encryption-vulns-in-matrix-sdks-and-clients/. Nico's blog post predates that so it's outdated in this respect.

Using the mechanisms available today, it's impossible to safely accept keys re-shared after the fact from other people's devices. You can only safely accept keys re-shared from your own verified devices. So the former behaviour was removed, for example in the Rust SDK crypto crate.

In reply to @dkasak:termina.org.uk

These behaviours were further restricted as part of remediations of https://matrix.org/blog/2022/09/28/upgrade-now-to-address-encryption-vulns-in-matrix-sdks-and-clients/. Nico's blog post predates that so it's outdated in this respect.

Using the mechanisms available today, it's impossible to safely accept keys re-shared after the fact from other people's devices. You can only safely accept keys re-shared from your own verified devices. So the former behaviour was removed, for example in the Rust SDK crypto crate.

Ahh that explains
Thank you
On the other hand it somehow makes sense that a chat partner doesn't count as "trusted" since they could maybe manipulate the old messages and send matching keys

Sure that wouldn't be easy to do but I think it could be possible...maybe a reason why it was changed?

In reply to @brenbarn:matrix.org
that's completely nuts

In reply to @brayd:chat.braydmedia.de

Ahh that explains
Thank you
On the other hand it somehow makes sense that a chat partner doesn't count as "trusted" since they could maybe manipulate the old messages and send matching keys

Sure that wouldn't be easy to do but I think it could be possible...maybe a reason why it was changed?

In reply to @dkasak:termina.org.uk
It's not fundamentally impossible to have the original author of the message securely re-share the key that was initially lost on its way to you. However, there is no current mechanism for the author's client to do so. The mechanism that was being used for this suffers from lesser guarantees, allowing a malicious server to inject messages (and keys), pretending they were authored by someone else. This is why it had to be removed.

In reply to @brayd:chat.braydmedia.de

Ahh that explains
Thank you
On the other hand it somehow makes sense that a chat partner doesn't count as "trusted" since they could maybe manipulate the old messages and send matching keys

Sure that wouldn't be easy to do but I think it could be possible...maybe a reason why it was changed?

In reply to @cvwright:futo.org
It's unfortunate for sure but it makes sense given the reality of the situation. If we can get something like MSC3917 working and merged into the spec, then a lot of things will be better.

In reply to @brenbarn:matrix.org
what makes sense given the reality is to just disable e2ee (at least by default) until all such issues are resolved

In reply to @brayd:chat.braydmedia.de
Well I'd rather loose access to sensitive information in 1:1 chats rather than not having those information encrypted from third parties

In reply to @brenbarn:matrix.org
(i.e., "grandma" type users)

Tbh those kind of users would probably also loose access their access to their signal messages
At least as soon as they'd have to migrate to a new phone. They'd probably be able to migrate the phone number but they would not understand that they'd have to actively have signal on the old and new phone open and have to start a migration process for the data and the keys even though Signal makes it very simple while not compromising encryption

I don't think it's even easier than that

Of course it is important to improve how all of this is handled on Matrix to make it as easy and as fail-proof for non-technical users as possible, but disabling encryption per default until that is ready is a bit drastic IMO (even though afaik you can do that just fine when you're administrating your own Synapse server)

In reply to @brayd:chat.braydmedia.de
Well I'd rather loose access to sensitive information in 1:1 chats rather than not having those information encrypted from third parties