Two questions:

1. Could you explain why we need backupID? The message to sign seems generic and wondering if we need a separate file for each backupID
2. Is there an easy way to somehow unify getSIWEBackupMessagePath with getBackupUserKeysFilePath which is basically doing the same?

Could you explain why we need backupID? The message to sign seems generic and wondering if we need a separate file for each backupID

For each backupID we specify backup message that was used to encrypt backup with backup id. Theoretically we can have distinct backup message for each backup id. However your suggestion would work. The reason for that is backup message stays the same as long as SIWE user is logged in. And when the user logs out we delete entire content of backup directory anyway. So for now it is not possible for the compaction files to be encrypted with different backup message. I am not suer however if this assumption could be broken in future. I will give it some thought.

Are we storing the backup message and its signature in an encrypted way?

In D11714#338794, @ashoat wrote:

Are we storing the backup message and its signature in an encrypted way?

The signature is kept in SQLite and never leaves SQLite so it is always stored in encrypted way. Backup messages resides in SQLite as well but in current design it is temporarily written to a flat file. The reason for that is the Rust thread that creates compaction is different thread than the one responsible for uploading and the system was designed in January in such a way that data necessary for upload are created and stored in files and then the other thread reads, uploads and deletes those files. Answering you question - backup message is not stored encrypted but is it data that are potentially sensitive? It is the signature that we use to encrypt backup so without the wallet this message isn't useful.

In D11714#338278, @marcin wrote:

Could you explain why we need backupID? The message to sign seems generic and wondering if we need a separate file for each backupID

For each backupID we specify backup message that was used to encrypt backup with backup id. Theoretically we can have distinct backup message for each backup id. However your suggestion would work. The reason for that is backup message stays the same as long as SIWE user is logged in. And when the user logs out we delete entire content of backup directory anyway. So for now it is not possible for the compaction files to be encrypted with different backup message. I am not suer however if this assumption could be broken in future. I will give it some thought.

Thinking about it I can't see a case where not using backupID to create a path would lead to errors but I think doing so is more future proof and consistent with the way we construct temporary files for other data that we upload to backup service.

Is there an easy way to somehow unify getSIWEBackupMessagePath with getBackupUserKeysFilePath which is basically doing the same?

Let's introduce a private method that constructs path from any two strings and us it in those public methods.