Slashdot Mirror
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."
I have explicitly asked my web host provider for either SFTP or FTPS. They basically said that it wasn't possible to provide that on a shared host. This seems untrue to me, I just can't state it as a fact since I haven't attempted it myself. But to get what the OP wants, one would essentially need a secure file system implementation on top of FTP. Ie. only the client can see the unencrypted file, not the in between transport over FTP, or the server side disk drive.
"Thanks for all the money you paid to us. We've used it to buy off ISO among other things" -Microsoft
See http://www.truecrypt.org/ for cross platform encryption...you can throw your files in there.
Obligatory blog plug: http://www.caseybanner.ca/
Well, it's feature list is exactly what you want and some more :). Here's the project description:
Manent is an algorithmically strong backup and archival program. It features efficient backup to anything that looks like storage. Currently it supports plain filesystems ("directories"), FTP, and SFTP. Planned are Amazon S3, optical disks, and email (SMTP and IMAP). It can work (making progress towards finishing a backup) over a slow and unreliable network. It can offer online access to the contents of the backup. Backed up storage is completely encrypted. Backup is incremental, including changed parts of large files. Moved, renamed, and duplicate files will not require additional storage. Several computers can use the same storage for backup, automatically sharing data. Both very large and very small files are supported efficiently. Manent does not rely on timestamps of the remote system to detect changes.
Check it out: http://freshmeat.net/projects/manent. It's under active development (the UI and the setup are currently in fetal stage) but the basic functionality is there and is well tested.
Disclaimer: I am the author.
What about Portable Python?
If I understand your problem, you want the remote image encrypted, right? In which case SFTP/FTPS is redundant overhead (and whatever data is sent is stored in its plaintext). This is something that might be possible with FUSE (e.g., use the Python-FUSE bindings to construct an FTP client that passes stuff through GnuPG first).
Heh, you'd be surprised how many people around here lack a sense of humour.
So I wrote it myself. http://freshmeat.net/projects/manent
It appears that there are options for rsync encrypting files on the far end. rsyncrypto might be just one of these. I have not used them but I remember them coming across my 'radar screen' in the past.
Rsyncrypto is insecure. By resetting to the IV, it opens an information leak similar to the one with ECB mode (see the picture of the penguin on that page).
To see why CBC with occasional reset-to-IV is insecure (regardless of trigger function), consider a long repeating pattern of the same bytes (e.g. the white spaces in the penguin picture). CBC won't encrypt them to the same value (like ECB does), but every time the IV resets the same sequence of encrypted bytes will appear. This pattern is detectable and further the places where this pattern is disrupted is detectable. So going back to the penguin picture, the non-background portions will have a shadow that disrupts the repeating background pattern and revealing the content of the file.
Note - I'm the one who designed and wrote rsyncrypto.
Well, no. Two files will likely be encrypted using different session (read - AES) keys, and therefor will not be even remotely similar. One file having two significantly similar areas will show up, however. This case was deemed somewhat remote in my analysis. You are free to perform your own, of course. If you do, please feel free to email me.
The only place where actual data leakage may happen are due to the fact that a persistent attacker can compare cipher texts, and know where the decision function triggered. This is a good point to ask "how much information is gleaned about the file".
I think current rsyncrypto is ok on that front, and future plans include improvements. These improvements, alas, will cost in performance.
Shachar