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.