All my DMs say the authenticity can't be verified (on old messages)

[turt2live]

I don't know why, and as a user I want to click a button to make the warning go away/be fixed

[turt2live]

this was on a new signin, so probably key backup?

[aljoscha]

This happens to me too, along with a black shield. Hovering over the shield reveals the "authenticity can't be verified" message.

[geraldwuhoo]

Can confirm, this happened to me this morning as well. Opened an existing session to see the "authenticity can't be guaranteed" message.

[532910]

Both contacts have Cross-Signing and Key Backup configured on all devices.
All sessions are shown as verified with a green shield, that is shown on the top too: Everyone in this room is verified.
Both contacts are on the same HS.

Despite this, I see The authenticity of this encrypted message can't be guaranteed on this device for some of my and his new messages.

[jryans]

@uhoreg Hmm, is it expected to see this message for new messages as well, or just those restored from key backup?

[532910]

And I see this with different contacts for all criteria above.

[uhoreg]

@uhoreg Hmm, is it expected to see this message for new messages as well, or just those restored from key backup?

It could happen for new messages that use the same megolm session as old messages. New megolm sessions should not show the message.

[dylangerdaly]

I can confirm I'm seeing this as well.

[uhoreg]

I thought that this issue contained an explanation for why this happens, but it doesn't ☹️ .

So, for everyone confused by why it's saying this: Normally, in encrypted rooms, messages are authenticated using the decryption key, based on the fact that the decryption key was received directly from the sender. When you sign into a new device (or under some other situations), you may get the decryption key from key backup (keys stored encrypted on the server), or from key sharing (keys sent from your other devices). When that happens, we lose the link to the original sender, and we don't currently store the fact that it was trusted in the first place, which is why it now says that the authenticity can't be verified.

So the message is completely expected in certain situations (particularly for old messages when you log in a new device)

[Avamander]

When that happens, we lose the link to the original sender, and we don't currently store the fact that it was trusted in the first place, which is why it now says that the authenticity can't be verified.

How do I re-establish that link using Element?

So the message is completely expected in certain situations (particularly for old messages when you log in a new device)

I get it for each message I send from my second device. They both have key backup set up and restored and are cross-signed.

[Avamander]

In general this message seems useless - it's undocumented and unactionable.

[jryans]

How do I re-establish that link using Element?

There is no way to do so currently.

[jryans]

In general this message seems useless - it's undocumented and unactionable.

I understand this frustration. I'll try raising this issue with our Product team internally.

[ara4n]

So the fact is that you only know for sure that your megolm keys are actually sent by the person who claimed to send them at the point you receive them directly for them. If you receive them subsequently from your online backup, or re-shared by another party, then it's possible that they might be faked by an attacker who is colluding with your server to feed you fake messages. There is work in progress to improve the trustworthiness of data of online backups, but the risk still applies to keyshared keys.

To improve the UX:

1. We could display a dialog when you restore keys from backup saying "encrypted history restored! (warning: we cannot prove your history has not been tampered with)" or words to that effect.

2. We could display an inline cell in the timeline saying "we cannot prove that history before this point has not been tampered with"

3. We could ignore the warning entirely, but this feels a bit irresponsible even though it's an edge case that you have an attacker trying to fake your past history to you. For instance, an attacker on the server might deliberately inject compromising material into your history in order to frame you, and this warning confirms that currently you can't trust your history 100% to be free from that, when keys are restored from backup.

Whatever, keyshared msgs would still have the individual shield warning.

[croemheld]

Until recently I was using the element-desktop application on Ubuntu, along with the Element iOS app. All sessions have been verified. Yesterday I switched to the web version via Riot in Franz, where my iOS app messages are all marked with the aforementioned shield. This is only happening for all messages written from my iOS app, if I write a message from the desktop app, the message in the web client is not marked with a shield.

[kittykat]

To reproduce, I deleted my secure backup & logged out of all but one session, then logged into a new session & verified via my Security Key. My two sessions trust each other; a DM with another user shows full trust between both users (in both directions), but any messages sent by the other user in the DM appear with gray shields in the new session only. (Messages sent from my own account, from either session, appear with no shield.)

[kittykat]

I'm going to close this issue for now:

Duplicate of #16318

[uhoreg]

This is actually different from #16318. 16318 is about new messages (messages sent after the device logged in), while this issue is about old messages.

[foresto]

Suggestions:

• How about adding an explanation to the warning on those shields? Something like, "This is normal for old messages if you've signed in with a new device." That would have saved my friends a day of frustrating and fruitless troubleshooting.
• If the ultimate goal is to store and recover enough info to avoid this problem, but that can't be implemented soon, perhaps a user's other sessions that do still have the missing info could gossip it to the new session? It seems silly that I have one session that can verify old messages and another that can't, given that they already trust and talk to each other.

In any case, thanks very much for explaining what's going on, @uhoreg and @ara4n. For the record, I think the info they represent is important; just presented in a way that needlessly causes alarm.

[UmbraChimera]

Is there still not a way to get the "the authenticity of this message can't be confirmed on this device" to go away? I don't know why it's showing up this time but not on any other of my installs I verify.

[Loc-t-h]

also noticed this happened when I logged in to a new device

[BrenBarn]

So, for everyone confused by why it's saying this: Normally, in encrypted rooms, messages are authenticated using the decryption key, based on the fact that the decryption key was received directly from the sender. When you sign into a new device (or under some other situations), you may get the decryption key from key backup (keys stored encrypted on the server), or from key sharing (keys sent from your other devices). When that happens, we lose the link to the original sender, and we don't currently store the fact that it was trusted in the first place, which is why it now says that the authenticity can't be verified.

It doesn't have to be verified. I verified it when I verified the other session. What it means for me to verify the session is to say "I am stating by fiat that everything this session tells me is true."

So the message is completely expected in certain situations (particularly for old messages when you log in a new device)

It's not expected. What is expected is that when I verify a session there is no daylight between what that other session thinks is verified and what my new session think is verified. Their notions of what is verified and trusted should be completely fused.

[Avamander]

Even if Element doesn't dare fuse the two together automatically, there should be an option to do it manually.

[foresto]

So the message is completely expected in certain situations

It's not expected.

I think @uhoreg means it's "expected" in the sense that the code is behaving as originally intended, not that the result is good.

This bit of context is important:

we don't currently store the fact that it was trusted in the first place, which is why it now says that the authenticity can't be verified.

I think (I hope) we can all agree that, although the current behavior makes sense once you understand what's going on behind the scenes, the presentation is misleading, annoying, distracting, and generally makes Element look broken. Fixing it is apparently gated on a design change to store the missing information.

[BrenBarn]

Fixing it is apparently gated on a design change to store the missing information.

Was breaking it in the first place gated on a design change? It is frustrating to see constantly this "oh we have to deliberate about what to do". Broken e2ee features have been released, causing problems for users. Why was the same level of deliberation not given before pushing these things out?

[BloodyIron]

Yeah I thought this whole "nice UX for e2ee" was solved like two+ years ago? I hear from my family members with regularity they have a really bad UX because they are being "repeatedly" prompted to verify devices (and I think this is just because they are dismissing them, not because they are under threat). And now I see this aspect of e2ee is UX-incomplete?

I agree with @BrenBarn that this feels like it was broken earlier in a way that was avoidable through the rigorous planning that was supposed to have been done (and while I trust was done, this is an area that it fell short).

I want e2ee in Element/Matrix to be "easy" and good for users, and while it is better than before, we're not quite there yet. And this is actually impacting me, someone who is more savvy on such things than my family members, and the "not quite trusted" silver shield has me thinking each time "am I actually secure right now with e2ee or is there something I missed?" and then I discover, no, this is a "bug" of sorts... :/

[ekg]

I'd like to echo what others are saying. Basically, if we've authenticated the sessions, we've said trust these keys, and then we've done all these steps to verify the setup, it shouldn't be that you show some special signal attached to messages that says that authenticity can't be verified. It is not possible. How can I have verified things but yet not verified them enough? Something isn't working.

[DemiMarie]

There is work in progress to improve the trustworthiness of data of online backups, but the risk still applies to keyshared keys.

What is the status of this?

[networkException]

Perhaps the brand new MSC 4048 is part of that work?

[uhoreg]

Yes, MSC4048 should fix this issue. I'm currently working on an implementation in the Rust SDK. This, combined with the effort to move the crypto portion of the js-sdk to use the Rust implementation means that this will eventually be solved in Element Web/Desktop. We're not sure how long it be before it's all ready, but both of those tasks (implementing authenticated backups and getting the Rust integration production-ready) are currently high priority tasks and are being actively worked on by the crypto team.

[OdinVex]

How about a simple effing button: "I know what I'm doing, trust that I did this." -_- Managing patch files to just disable the icon is rather annoying, especially since Element loves randomly signing users out, especially if they use Secret Service APIs like KeePassXC. Not unlocked while attempting to access? "Losing your crap, good luck." Gotten to the point I actually archive my ~/.config/Element folder daily to completely restore it. Edit: Sorry, very frustrated with all this. I trust my server, I trust my devices, I just want to override this behavior.

Edit: Curious how this'll play out when you get rid of a device but you know and trusted what you sent at the time from it...

[networkException]

The secret service bug you're describing is a regression introduced in version 1.11.46, see element-hq/element-desktop#1429. I've commented the workaround I've been using to get around the issue, maybe thats helpful to you as well

[OdinVex]

The secret service bug you're describing is a regression introduced in version 1.11.46, see element-hq/element-desktop#1429. I've commented the workaround I've been using to get around the issue, maybe thats helpful to you as well

That unfortunately does not loop, making autostart useless and giving you no feedback of why it won't run. I chose this instead: Exec=/bin/sh -c 'while secret-tool lookup service element.io | xargs test -z; do sleep 1; done; element-desktop --hidden' Granted, this causes it to loop until success but it sleeps, so no CPU issues at all.

[NOP4]

Hello,
Any update on this? I got the problem on all new messages on my new phone.
Is there a way to sign out or reconnect to remove this grey shield?