None of the old messages are decrypted.

[0xorial]

Steps to reproduce

1. I logged in in browser.
2. I sent a few messages to a friend in a private chat
3. I logged in in a desktop and passed did one of the 2:
   • did the cross-verification
   • entered the security key I copied from the browser.

Outcome

What did you expect?

To see my messages

What happened instead?

Every single message is "unable to decrypt message"

Operating system

No response

Application version

No response

How did you install the app?

No response

Homeserver

No response

Will you send logs?

Yes

[t3chguy]

Will you send logs?
Yes

Not seeing any logs from you

[0xorial]

@t3chguy thanks for the heads-up! I am revewing the logs and a bit concerned as they seem to include quite some user information. in particular, the keys seem to be included. I am assuming since you are encouraging users to share that info, there is a good explanation of why it is not an issue to share it. Is there a quick info on that, or would I have to read and understand the protocol? I am especially triggered by seeing a text master_key=Some("(redacted_here_but_present_in_logs)"), and backup_key=MegolmV1BackupKey { key: "(redacted_here_but_present_in_logs)", version: Some("3") }.

Aside from that, I attach the log with manually redacted keys below, if that is of any help.

element-log.log

[0xorial]

And another thing, I am not sure what changed, but now messages started appearing, but all of them have a warning that authenticity of this encrypted message cannot be guaranteed on this device. There is no such warning on web or mobile (android).

[BillCarsonFr]

@t3chguy thanks for the heads-up! I am revewing the logs and a bit concerned as they seem to include quite some user information. in particular, the keys seem to be included. I am assuming since you are encouraging users to share that info, there is a good explanation of why it is not an issue to share it. Is there a quick info on that, or would I have to read and understand the protocol? I am especially triggered by seeing a text master_key=Some("(redacted_here_but_present_in_logs)"), and backup_key=MegolmV1BackupKey { key: "(redacted_here_but_present_in_logs)", version: Some("3") }.

Aside from that, I attach the log with manually redacted keys below, if that is of any help.

element-log.log

These are the public part
pub fn master_key(&self) -> &MasterPubkey MasterPubKey here

And same for MegolmV1BackupKey key: Curve25519PublicKey

[BillCarsonFr]

And another thing, I am not sure what changed, but now messages started appearing, but all of them have a warning that authenticity of this encrypted message cannot be guaranteed on this device. There is no such warning on web or mobile (android).

You are getting the keys from your backup that's why you are seeing the authenticity warning. Keys downloaded from backup are not similar to keys received directly from the sender in regards of the cryptographic binding to the sender.

Your web and mobile received the key directly from the sender so there is no authenticity warning.

To be complete there is a proposal for a new backup algorithm that would maintain authenticity

[0xorial]

@BillCarsonFr, so, did I understand correctly that at the moment backup is somewhat different on desktop vs mobile and web, and a side effect of that is the issues with decoding messages from other platforms? But this is not useful to fix because a new backup algorithm is upcoming?

[andybalaam]

@0xorial I don't think it's a fundamental difference between desktop and mobile + web - it's just that in this case, your desktop device didn't receive the key directly - it had to fetch it from key storage ("backup"), meaning it doesn't know for sure that the message is exactly as it should be. The mobile and web devices received the key directly from the sender so they know it's correct.

So the main question here is why did it take a long time for your messages to appear on desktop? They should have been saved to key storage by web or mobile and downloaded quite quickly to desktop after you logged in.

[andybalaam]

Without a full "rageshake" ("Send Debug Logs" in the UI) I can't investigate further. I suspect one of the other devices is not properly connected to key storage, meaning it didn't upload keys, and then the problem fixed itself when the other device came online and did upload keys, but this is guesswork.

[andybalaam]

Closing, but if you have more info please feel free to re-open.