dsb - distributed secure backup

1. Goals

Use of backup servers which are not fully trusted.

Use of multiple backup servers, possibly a p2p network.

Allow backups and restores of arbitrary subsets of files.

2. Protocol

dsbsrv manages the backup repository. It is normally called from sshd (or directly from inetd, if you don't need encryption or access control). It reads 1-line commands on stdin and replies with 1-line responses. Some commands and responses are followed by binary content, in which case the length of the content is included in the command resp. response.

The repository is a collection of files, each identified by a key. The key should only contain the letters A-Z, a-z and 0-9, and not exceed 250 characters in length. It has no meaning to the server, except that it is expected to be unique for each file. A typical implementation would be an MD5 sum of the filename, modification date and file permissions, encoded in hex or base64.

The files themselves are also usually encrypted and signed. Thus, a compromised backup server cannot read or change the files. At worst, it can delete them.

QUERY key [0]

Enquires whether the server has a file with the given key.

Answers

HAVE key [0]

HAVENOT key [0]

FAILED key (human-readable error message) [0]

STORE key [length]

Asks the Server to store the file with the given key. The length specifies the number of bytes to follow. The server must read all of the data before responding, even if it determines that it cannot fulfill the request (e.g., due to a full disk). (Note: is this a good idea? Maybe a two phase protocol would be better, since a disk full condition (or a policy against long files) can usually be detected at the start of the command)

Answers

STORED key [0]

FAILED key (human-readable error message) [0]

RETRIEVE key [0]

RETRIEVING key [length]

FAILED key (human-readable error message) [0]

3. Prototype