To address the question in your edit: When the key file is created, you are prompted for a password to encrypted the private key. That password is used (along

To address the question in your edit: When the key file is created, you are prompted for a password to encrypted the private key. That password is used (along with the public key) to generate the HMAC key which gets recorded in the keyfile and is used to sign each file in the backup. The encrypted private key is sent to the server, and gets sent back when you do the restore, but the HMAC secret key stays on the client. Since you need to type in the password to restore the data, the HMAC key gets re-generated at restore time. The reason the passphrase is hashed with the public key (again using an HMAC-SHA-256 hash) is so that if the same passphrase is used on different hosts with unique encryption keys, the HMAC key still ends up being unique. So a compromised key file on the client will compromise the secret HMAC key, but it won't compromise the encrypted data. Which is better than having a single symmetric encryption key laying around for both encryption and authentication (encryption being the more important item). And the key is tied to the backup snapshot, not to the repository so each client can have their own keys. Further information is at https://www.snebu.com/tarcrypt.html https://www.snebu.com/tarcrypt.html which gives the inner workings of tarcrypt (some of the description of the tar file extensions are dependent on a working knowledge of the basic tar format and the PAX extensions, which are documented in the GNU tar documentation).