Encryption

Backup encryption is used for two purposes:

transport encryption

Encryption of data in transit between the server and client to prevent eavesdropping on the network.

data encryption

Encryption of the dumped data on tape (or other backup medium) provides protection in case the tape falls into the wrong hands.

It is becoming routine to hear of companies losing control of massive amounts of critical data when backup tapes stray from the company's control; for example

• http://www.washingtonpost.com/wp-dyn/content/article/2005/12/27/AR2005122700959.html

Comparison

Transport	Data	Tag
No	No	A
Yes	No	B
No	Yes	C
Yes	Yes	D
Yes	No	E (public-key)

In scenarios A and C, and eavesdropper on the network can observe the data. In B D and E, an eavesdropper cannot.

In secenarios A and B, one can retrieve the data from backup tapes without any need for keys. This is perhaps obvious, but very important for backups.

In C, D, and E, the backup tapes are encrypted. Thus, one could store them someplace where you trust people not to destroy them but you don't trust them to read them. This can make some sense for particularly sensitive data.

In E, the backup data doesn't appear on the server in plaintext. This can be useful for backing up clients with particularly sensitive data. To really make sense, the client should be configured so that it will only honor dump requests to a preconfigured set of public keys.

Symmetric vs. Public-key encryption

Symmetric encryption is also known as single-key (or secret-key) encryption. The same key is used for encryption as well as decryption. Pros:

1. just one key to manage
2. faster

Cons:

1. need to share the key between two parties through a secured channel
2. to do automatic backup, passphrase needs to store somewhere in this case.

Public/private key encryption is also known as asymmetric encryption. A public key is used for encryption while a distinct private key is used for decryption. The systems doing the encryption do not need the private key, so the private key can be stored e.g., in a lockbox until a restore (with the attendant decryption) is required. Pros:

1. no secret (i.e. public key) needed for encrypting.
2. if public key is lost, it can be revised from the private key
3. no need to use passphrase during encryption

Cons:

1. computationally expensive, thus slower[**]
2. data is encrypted for a specific person/group. Only the specific person with the right private key can decrypt the data.
3. potential man-in-the-middle attack

[**] it has been pointed out that computational resources don't matter that much: most systems generate a symmetric session key, which is encrypted using the public key. Hence the slow part is limited to the encryption of the session key, while the actual data is encrypted using the fast symmetric algorithm.

Transport Encryption Support

To set up transport encryption between UNIX hosts, the simplest solution is to set up SSH authentication (How To:Set up transport encryption with SSH). The SSH authentication driver multiplexes all of its communication over a single SSH channel, with the result that all data is encrypted.

Alternately, Kerberos authentication can optionally support encryption, although this is not a well-supported option and consumes a significant amount of computing power on both ends of the connection.

Data Encryption Support

Amanda 2.5.0 and later support encryption in a fashion similar to compression. It can be performed either on the server or the client, and is controlled in dumptype definitions by the encrypt client or encrypt server directives. See How To:Set up data encryption for more details.

---

Other languages: [[::Encryption|English]] {{#ifexist: {{#if: | | {{#if: | :}}Encryption}}/Fr |  • {{#if: |français| [[::Encryption/Fr|français]]}}|}}

{{#ifexist: {{#if: | | {{#if: | :}}Encryption}}/Zh-cn |  • {{#if: |中文（中国大陆）| [[::Encryption/Zh-cn|中文（中国大陆）]]}}|}}