Tarsnap's security is built around the notion of a key file which is required by the Tarsnap client code in order to perform any operations. This allows Tarsnap to avoid several weaknesses inherent in the use of passwords:

• People aren't good at remembering strong passwords; so they tend to use weak passwords and/or reuse passwords between applications.
• Passwords can be observed when they are input, either directly (watching over someone's shoulder as they type) or via side channels (e.g., acoustic attacks, whereby a password is stolen by analysing the sounds emitted by a keyboard).
• While key derivation functions can be used to transform passwords into symmetric cryptographic keys, it is impossible to use passwords to derive asymmetric keys.

However, passphrases are still useful in certain situations — for example, if there is potential for a key file to be stolen. For this reason, Tarsnap key files can be passphrase-protected, via keys computed using the scrypt key derivation function.

Tarsnap key files contain two types of keys: Authentication keys, which are used to prove to the server that the holder is allowed to write, read, or delete data; and encryption keys, which are used to encrypt, sign, verify, and decrypt archives. This separation ensures that even if the Tarsnap service is compromised (say, if big guys with guns turn up with a search warrant), your data will be safe from disclosure and tampering. (For more information about how Tarsnap uses cryptographic keys, see the technical details about cryptography page).

When a system is registered with the Tarsnap service via the tarsnap-keygen utility, all of these keys are generated and stored in a single key file; but using the tarsnap-keymgmt utility, "restricted" key files can be created which can be used to do any subset of:

• Reading, verifying, and decrypting archives.
• Encrypting, signing, and writing archives.
• Reading and deleting individual archives. (It's impossible to delete one archive while leaving others intact without also being able to read archives.)
• Deleting all archives stored by a system.

For example, this makes it possible to set up a system to automatically store archives daily (e.g., via a cron job) while not being able to read those archives back or delete them — ensuring that even if someone breaks into the system and does his best to delete everything, your data will still be safe.

No matter how secure Tarsnap's design is, however, you don't run the design on your computer — you run the code. For this reason, all of the source code to the Tarsnap client is available. You don't need to simply trust that Tarsnap does things right (and that it isn't a trojan planted by the US government): You can read the source code and check for yourself (and there's even a bug bounty if you find anything wrong).