Sharing keys between Element on Android and Web does not work, encrypted messages not showing up

[greve]

Description

Filed as new as requested by element-hq/element-web#16184 (comment)

It is impossible to verify another device - messages are showing up on BOTH devices as

** Unable to decrypt: The sender has disabled encrypting to unverified devices. **
Re-request encryption keys from your other sessions.?

Re-requesting also does not work, likely due to similar issues.

Would love to verify the sessions, but whichever way I choose, I cannot. Verification by Text and Emoji both start on both devices normally. Upon confirmation on the older, authenticated device I am at the final step being asked

Security Phrase
Enter your Security Phrase or Use your Security Key to continue.
But when I enter the security phrase I once entered, it tells me that it is invalid. No idea which other phrase it wants from where.

So I try to verify with Security Key, which from other tickets I have understood to be the Recovery Key?

If I enter that, or upload it, it tells me that it is invalid.

Tried resetting it and downloading it again. Worked perfectly to restore everything in one session, was happily backing up.

Still keeps claiming it is wrong for verification.

So where is that magic Security Key, and most importantly: Why does it even ask this when I am already signed in, fully authenticated, with access to all keys?

Steps to reproduce

• Start verification
• Follow the steps
• Be asked for key
• Watch it fail

Logs being sent: yes/no

Version information

• Platform: web (in-browser) or desktop?

For the web app:

• Browser:Google Chrome (latest versions over the past weeks)

• OS: Fedora

• URL: Private version of Element Web

• Element on Android, up to date

[ManDay]

Cf element-hq/element-android#2889

[ManDay]

@jryans How is this not a defect? This is a reproducible by chance issue.

Log in to Element Web, cross-verify the session, find that all your encrypted rooms are unreadable and no way to retrieve the encryption keys.

Log out, log in, randomly it's either working or not. I don't have any question of the "how do I" sort. This feels very much like a bug.

[greve]

We moved our chat to another URL.

Now I also have the exact same issue between web and web.

[elsiehupp]

I'm having this exact same issue. Incoming messages in a new one-to-one room are rendering as ** Unable to decrypt: The sender has disabled encrypting to unverified devices. ** on all four of my devices (Element Desktop macOS, Element Desktop Linux, Element Web, and Element Mobile iOS), with other conversations working fine.

I just left the conversation and tried starting a fresh one, so I'll see if that works.

[t3chguy]

@elsiehupp

The sender has disabled encrypting to unverified devices.

This means exactly what it says, whatever client you use will not change their settings.

Either verify with them (in person) or get them to turn that setting off.

[elsiehupp]

@t3chguy yes, I figured that out. (The sender forgot that they had it turned on.)

Regardless, the error messages were rather confusing, especially due to the fact that I got different error messages on my iPhone and on my Mac:

[t3chguy]

@elsiehupp that is an iOS bug for not supporting the more detailed message.

[elsiehupp]

Also, clicking “Re-request encryption keys” seemed to do literally nothing. I think ultimately the situation was only resolved when the sender initiated the process rather than me. The entire process was extremely janky, with the iPhone client freezing after receiving the request, so I was only able to complete it on my Mac.

But, yes, this is getting a bit off-topic for this issue. 😬

[t3chguy]

Re-request encryption keys

It sends a request to your own other devices for the keys if they received them (due to being verified or otherwise)

[elsiehupp]

Part of why it’s confusing is that my devices were all verified with my account, but the issue was that my account wasn’t verified with the sender’s account. The usual interface for verifying devices showed my devices as all verified and didn’t show anything wrong. This is more an issue with the error messages being ambiguous (regarding device-account verification versus contact verification) and the contact-verification user interface being somewhat hidden and somewhat buggy than it is with contact-verification in general.

Again, I should probably open an issue or a pull request with a better version of the error message.

[elsiehupp]

For comparison: element-hq/element-ios#5458

[ManDay]

element-hq/element-android#5305

[jittygitty]

@t3chguy Why can't re-request encryption keys ask the other chat participant? I mean if I'm in a "direct-message" 2person private chat and I get this Unable to decrypt error, why can't we request that the other person resend the decryption keys if somehow this didn't work during initial creation of room when they accepted the invitation? Otherwise seems impossible to fix if decryption was not already working on some other device. Or do you know of a way to fix this?
(see my post at: element-hq/element-web#19748 )

@ManDay @elsiehupp Yea too many E2EE issues, I was hoping for some 3-way triangulation and self-healing of such issues via simple wizard type guiding of chat participants to resend keys etc:
element-hq/element-web#20685

[t3chguy]

@jittygitty it already does, but their device will only send you keys if they already sent you keys and they got lost in transit. #647 is the issue for allowing users to request keys they weren't in the room for/lost

[greve]

I'm also continuing to struggle with this. Have one session left that's fully trusted, but there seems to be no way to transfer trust to another device. After confirming there is no man in the middle, it wants an additional password/key, but the one I am sure is correct isn't accepted. And there is no recovery process that I was able to identify. So, I'm staying with untrusted devices, as that's the only way to keep using it. Otherwise, I'd have to restart from scratch, at which point I'd rather switch to something else. The trusted device obviously has full access to all keys. Why can't it just transfer them to other devices? It's really frustrating....

…

________________________________ From: Michael Telatynski ***@***.***> Sent: Wednesday, July 27, 2022 11:01:30 AM To: vector-im/element-web ***@***.***> Cc: Georg Greve ***@***.***>; Author ***@***.***> Subject: Re: [vector-im/element-web] Sharing keys between Element on Android and Web does not work, encrypted messages not showing up (#16413) @jittygitty<https://github.com/jittygitty> it already does, but their device will only send you keys if they already sent you keys and they got lost in transit. element-hq/element-meta#647<#647> is the issue for allowing users to request keys they weren't in the room for/lost — Reply to this email directly, view it on GitHub<https://github.com/vector-im/element-web/issues/16413#issuecomment-1196456409>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAF2QMVLFMGTN4IKZ2YDSKTVWD3GTANCNFSM4XKJ47UA>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[jittygitty]

@t3chguy So are you saying that in reality the device of the other person whom I invited to the 2person "direct-message" private chat, never actually sent me the encryption keys to begin with? And that is why the "re-request" did not result in their device trying to "resend" me their keys?

If so, is there a ticket working on fixing this type of situation?

When someone sends their keys, do they sit on the server waiting for pickup by the other user/users, or if the network connection breaks for any reason during that sending, keys are lost?

[wtogami]

I experienced this problem where Element Desktop claimed Element Android did not support encryption and it would fail to verify the other client. My friend told me to switch to matrix.org instead of fedora.im as he hasn't seen self-hosted or smaller servers succeed at this. I created a new account on matrix.org and cross-signing worked for me for the first time.

[jittygitty]

@wtogami Then maybe it's a server issue, many self-hosting (like myself) are using Dendrite ( See: matrix-org/dendrite#2184 matrix-org/dendrite#2471 matrix-org/dendrite#2436 etc etc.. )

I think the various Matrix/Element teams need to really make these decryption issues a priority since it really hurts the "entire" MATRIX ecosphere/community and fixing them will make it much easier to bring new people on board to MATRIX. :)
(It's embarrassing when we invite someone, and we can't see each other's text messages due to "decryption errors" complaining of missing keys to decrypt.)

Because we have a "SERVER" in-between, if a client has an "issue", the SERVER should be able to step in and help fix any such problem reported by any client.

On the PLUS side, seems they are listening and have started working on these issues, see good posts by @BillCarsonFr like: element-hq/element-web#20685 (comment)

[TLATER]

Because we have a "SERVER" in-between, if a client has an "issue", the SERVER should be able to step in and help fix any such problem reported by any client.

That would break the trust model. Users need to verify each other's sessions, you don't want a situation in which you can claim to be anyone, and potentially trick others into sending you messages that weren't meant for them.

That said, the server doesn't even have to step in here. The problem is that devices from one user do not share which other devices they trust. I.e., I can have my Android phone perfectly set up to talk to someone, with all their keys and sessions trusted, but then when I go to my desktop I need to re-verify everything.

Having to go through the full verification process with 3+ devices (and potentially new clients when I want to try one) is incredibly tedious, and actually not exactly feasible - I may be able to go visit my family abroad once, and then keep their session verified on one device, but if one of us gets a new device I do not want to have to immediately fly over to go check whatever emoji they have on their screen. I also can't take my desktop computer over (though that can be remedied by sharing a screenshot via the one working device, at the expense of being extremely annoying).

I don't think this adds any security either; if I verify my session from another existing session, I am effectively verifying that I trust that session (or, rather, that that is my device). By extension, whoever I'm talking to should be able to trust that this is in fact my device, because I verified it is, and they have previously verified that they trust me.

If anything, this worsens security. All but one of my sessions currently simply accept that I'm talking to unverified sessions. Whenever someone gets tired of the red symbol, we just verify the sessions without ever checking the emoji. Poor UX always results in poor security.

Why don't devices share the keys of other users' devices they trust today? Can we help? Is there a tracking issue for these kinds of problems?

[AmyNicole8715]

How is this still a problem?

[BenBE]

It simply (still) does not work …

If you need for some reason to close your browser session and your only device with keys for messages on is your mobile, you end up loosing access to those messages on the desktop, because even after verifying the desktop session with the session on the mobile you don't get the keys for past messages … On the other hand, for two desktop sessions running on different computers, requesting session keys works (although only for chats that have been opened on the new computer too).

[iDmple]

I'm facing the same issue on Android vs Desktop. It's like they have different keys and no idea how to fix it.

[novirium]

Currently trying to deal with (what I think) is the same issue. Have several old clients (both Web and Android) that can successfully show an encrypted conversation with another contact. Trying to add a new device (web) consistently fails to decrypt any existing messages in that conversation - sent by either me or the third-party contact. Have tried cross verifying, manually verifying with emojis, even manually exporting and importing keys. All sessions show as verified, and "Connect this session to key backup" successfully shows keys being imported.

Viewing the source on the failed messages shows Unable to decrypt: DecryptionError: The sender's device has not sent us the keys for this message. for all messages, including my own ones.

I still don't actually know how to resolve this, but the situation as it stands is very frustrating - if there's a technical reason why doing this isn't possible, fair enough, but I feel like the UI should at least communicate that in some way rather than insisting that everything is verified and working fine.

[JokerGermany]

Same like @novirium here:

(yes there are older messages from the user which can be decrypted)
Element Desktop session crashed and i cross signed it with another devices.
Since then there a some messages in the "middle" which can't be decrypted.
I looked on another device (schildichat) and the messages can be read there.
I don't get any message to request the keys from another device

Source:

{
  "type": "m.room.message",
  "content": {
    "msgtype": "m.bad.encrypted",
    "body": "** Unable to decrypt: DecryptionError: The sender's device has not sent us the keys for this message. **"
  }
}