Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Keys are not uploaded to backup if the backup is not signed #4676

Open
ajbura opened this issue Feb 3, 2025 · 5 comments · May be fixed by #4677
Open

Keys are not uploaded to backup if the backup is not signed #4676

ajbura opened this issue Feb 3, 2025 · 5 comments · May be fixed by #4677
Labels
A-Element-R Issues affecting the port of Element's crypto layer to Rust T-Defect

Comments

@ajbura
Copy link
Contributor

ajbura commented Feb 3, 2025

Spec says https://spec.matrix.org/v1.10/client-server-api/#server-side-key-backups : trust can also be determined

by deriving the public key from a private key that it obtained from a trusted source. Trusted sources for the private key include the user entering the key, retrieving the key stored in secret storage, or obtaining the key via secret sharing from a verified device belonging to the same user.

link to problem area:

if (!trustInfo.trusted) {

should be (as both are part of BackupTrustInfo)

if (!trustInfo.matchesDecryptionKey && !trustInfo.trusted) {

alternative fix at

trusted: signatureVerification.trusted(),

trusted: signatureVerification.trusted() || backupMatchesSavedPrivateKey

related debugging:

more details:
one of my account only has device signatures(from logged out devices) in auth_data and missing master_key signature in that case the backup is stalled for forever. Not sure we can also add master_key signature using https://spec.matrix.org/v1.10/client-server-api/#put_matrixclientv3room_keysversionversion without resetting version?

@dosubot dosubot bot added A-Element-R Issues affecting the port of Element's crypto layer to Rust T-Defect labels Feb 3, 2025
@ajbura ajbura linked a pull request Feb 3, 2025 that will close this issue
4 tasks
@richvdh
Copy link
Member

richvdh commented Feb 3, 2025

I'm struggling to understand what the actual problem you're seeing is. Part of the problem is that there is no one meaning of "trusted": it is very much contextual.

As best I can understand:

  • You have a key backup which (for some reason?) has not been signed by your master cross-signing key
  • However, you also have the private decryption key for this backup and it has been imported (and can therefore successfully decrypt keys retrieved from the backup?)
  • Per the spec, the backup should then be "trusted" for the purpose of uploading received message keys to the backup
  • However, this is not working.

Is that correct?

@ajbura
Copy link
Contributor Author

ajbura commented Feb 3, 2025

Yes, you got it right, my keys are not uploading.

@richvdh
Copy link
Member

richvdh commented Feb 3, 2025

Ok. How did you get into the state where you have a key backup that you have the decryption key for, but which has not been signed by your cross-signing key?

Not saying it shouldn't work, it's just not something we've ever come across before and so haven't tested.

@richvdh richvdh changed the title Key backup not working with private key trust Keys are not uploaded to backup if the backup is not signed Feb 3, 2025
@ajbura
Copy link
Contributor Author

ajbura commented Feb 3, 2025

I am not sure, maybe from the client (Element Android probably) i enabled this feature 3-4 years ago have not signed it with master key? and since i never reset it or lost key it remains the same.

it was uploading keys initially but from last 2 years it has stopped (looking at restored keys in new login).

@richvdh
Copy link
Member

richvdh commented Feb 3, 2025

ok, thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Element-R Issues affecting the port of Element's crypto layer to Rust T-Defect
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants