2 ms·

Encryption can be implemented flexibly on systems you control. When it come to encrypting backups, the toughest issue is doing it safely on target systems you d

by wampus 12y ago

Encryption can be implemented flexibly on systems you control. When it come to encrypting backups, the toughest issue is doing it safely on target systems you don't control (duplicity attacks this problem well). I'd recommend starting there. Encrypted replication is a very interesting idea, and actually helps with the problem of maintaining local & remote backups. I usually stagger them, but being able to replicate to arbitrary targets would be very convenient (I don't like to rsync backups after the fact, because you risk corrupting the target if there is a local failure).

derekp7 12y ago
One of the items I struggle with is that I want to keep the current client-side simplicity of Snebu -- on the client, the only thing that is required is bash, find, and tar (although GNU find is required, and older versions of find don't support enough options). However, I think I have a potential solution, which I'll work on this weekend. The solution is: on the client side, include an optional encrypting tar filter, which takes a tar file as input, and encrypts the file contents of each file within the archive, delivering a tar file output with regular headers, but compressed encrypted files. I'll probably have to take some liberties with the tar file format, but as long as the snebu backend is similarly modified (to recognize a pre-compressed and encrypted file segment), then I should be able to get it to work without any major compromises. The only issues with my current plan are: 1) Multiple files with the same contents will still be de-duplicated, which may leak some information (if an attacker already knows file A's contents, and B is marked as being a copy of A, then the attacker will know what file B is). 2) The metadata (file name, size, owner, possibly SHA1) will still be visible. Although I may just use the SHA1 of the encrypted version as the file reference. 3) Sparse files will still show where the "holes" in the files are, unless you tell it not to preserve file sparseness.

by wampus 12y ago

derekp7 12y ago

One of the items I struggle with is that I want to keep the current client-side simplicity of Snebu -- on the client, the only thing that is required is bash, find, and tar (although GNU find is required, and older versions of find don't support enough options). However, I think I have a potential solution, which I'll work on this weekend. The solution is: on the client side, include an optional encrypting tar filter, which takes a tar file as input, and encrypts the file contents of each file within the archive, delivering a tar file output with regular headers, but compressed encrypted files. I'll probably have to take some liberties with the tar file format, but as long as the snebu backend is similarly modified (to recognize a pre-compressed and encrypted file segment), then I should be able to get it to work without any major compromises. The only issues with my current plan are: 1) Multiple files with the same contents will still be de-duplicated, which may leak some information (if an attacker already knows file A's contents, and B is marked as being a copy of A, then the attacker will know what file B is). 2) The metadata (file name, size, owner, possibly SHA1) will still be visible. Although I may just use the SHA1 of the encrypted version as the file reference. 3) Sparse files will still show where the "holes" in the files are, unless you tell it not to preserve file sparseness.