When a system is first registered with the Tarsnap server, the tarsnap-keygen utility generates cryptographic keys for the system to use. These keys form the backbone of Tarsnap's security: Without them, it is (given the current state of the art of cryptography) infeasible for anyone to either decrypt or create archives which will be recognized as valid.

The cryptographic keys used by Tarsnap include:

• A 2048-bit RSA key used for signing archives. This is used in combination with SHA256 and a Merkle hash tree to verify the authenticity of stored archives.
• A 2048-bit RSA key used for encrypting session keys. All the data which the Tarsnap client sends to the server to store is encrypted with per-archive random AES-256 keys; those keys are encrypted with this RSA key and attached to the stored data.
• A 256-bit HMAC-SHA256 key used to protect each individual block of data from tampering. From a cryptographic perspective, this is unnecessary, since a Merkle hash tree protects each archive; but data is compressed using zlib before being stored, so this provides protection against a theoretical attacker who can tamper with stored data and has found a security flaw in zlib decoding.
• Two 256-bit HMAC-SHA256 keys used to generate names for blocks of data stored. Tarsnap uses the same reference-by-hash trick as the author's Portsnap and FreeBSD Update utilities; using HMACs instead of raw SHA256 hashes prevents any information from leaking via the hashes.
• Three 256-bit HMAC-SHA256 keys used to sign requests sent by the Tarsnap client to the Tarsnap server: One used for writes, one used for reads, and one used for deletes.

The Tarsnap client-server protocol avoids the complexity of SSL by using a streamlined protocol which:

• Doesn't use certificates.
• Only supports a single key exchange algorithm, equivalent to SSL using an RSA_DH certificate.
• Only supports a single set of cryptographic primitives.