Secure File Storage Over Non-Trusted FTP?

hmckee writes "Does any software exist that enables me to store/backup/sync files from my local computer to a non-trusted FTP site? To accomplish this, I'm using a script to check timestamps, encrypt and sign the files individually, then copy each file to an offsite FTP directory. I've looked over many different tools (Duplicity, Amanda, Bacula, WinSCP, FileZilla) but none of them seem to do exactly what I want: (1) multi-platform (Windows and Linux), stand-alone client (can be run from a portable drive). (2) Secure backup (encrypted and signed) to non-trusted FTP site. (3) Sync individual files without saving to a giant tar file. (4) Securely store timestamps and file names on the FTP server. Any help or info on alternative solutions appreciated."

Comments

Working On Something Similar

[RAMMS EIN]

I'm working on a backup solution that allows people to back up their data to a remote server securely and efficiently. For "efficiently", think rsync: only the differences are sent (and some information necessary to identify what the differences are). For "securely", think assymetric cryptography: your backup is stored in encrypted form, so that only someone who possesses your private key can use it.

All this is currently in very early stages of design. I'd welcome any suggestions for protocols or software I could use. Currently, I am thinking to implement a transactional network block device protocol, and implement the backup protocol on top of that. I still need to decide on a programming language I can use for parts I need to write myself, too (something safe (no buffer overflows, please), yet with byte level access...and no Java or .NET, please).

By the way, this is going to be a commercial product, but the code and the protocols will be open. I'll charge for the storage and bandwidth. :-D

duplicity + ftplicity

[Horus107]

duplicity combined with ftplicity:

"Anyone storing data on an unfamiliar FTP server needs to encrypt and sign it to ensure reliable protection against prying eyes and external manipulation. duplicity is just the tool for this, and the ftplicity script from c't magazine makes working with it child's play."

http://www.heise-online.co.uk/security/Backups-on-non-trusted-FTP-servers--/features/79882
http://duplicity.nongnu.org/

Re:I knew a guy who always had headaches

[hairyfeet]

Like pretty much every SMB I have ever worked on. It is really a shame there isn't an easy native way to run VB code in Linux,because every single SMB I walk into has some damned VB3-6 app that holds that place together. Worse is it always seems to be written by a guy named Chuck that worked there ages ago and didn't know WTF he was doing. I swear I opened up the last VB4 one to convert it to VB6 and try to fix the crashing and was like "OMFG! Tap dancing Christ what was this guy thinking! Was he high?".

The ENTIRE first page was nothing but a giant mess of GOTO calls. I'll admit I'll throw in about one GOTO per app just to do a quick function call,but DAMN. The entire first page was GOTO here,then GOTO there,then GOTO somewhere else. Luckily like a good 75% of VB apps out there it was a GUI connecting to a database so I was able to whip off a replacement. But it would be nice if just once they brought in an actual coder to write a program instead of clueless chuck. But as always this is my 02c,YMMV

Re:I knew a guy who always had headaches

[Anonymous Coward]

Here's a review of rsyncrypto that also says it isn't really secure:

For an example of an information leak, suppose you have an XML file and you use rsyncrypto to copy the file to a remote host. Then you change a single XML attribute and use rsyncrypto to copy the updates across. Now suppose an attacker captured the encrypted versions in transit, and thus has copies of both the encrypted file before the change and after the change. The first thing they learn is that only the first 8KB of the file changed, because that is all that was sent the second time. If they can speculate what sort of file the unencrypted file was (for example, an XML file) then they can try to use that guess in an attempt to recover information.

Rsyncrypto encrypts parts of the file independently, thus keeping any changes you make to a single block of the file local to that block in the encrypted version. If you're protecting a collection of personal files from a possible remote system compromise, such a tradeoff in security might be acceptable. On the other hand, if you cannot allow any information leaks, then you'll have to accept that the whole encrypted file will change radically each time you change the unencrypted file.