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
No, it's more like someone running around naked outside holding a frosted pane of glass in front of them wondering if maybe they should also build a tool to hold a second pane of frosted glass behind them.
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.
I should have stated that the data wasn't THAT important since it's already backed up in two other places.
I was initially using Amazon S3 to do the backups, but since I had 20 GB of spare storage on my hosting site, I figured someone else must have tried doing the exact same thing because it's the cheapest solution. It didn't take me long to write a small script to encrypt files and send them to the FTP server, another reason I figured someone else may have done this. So, rather than extending the script, I thought I'd "Ask Slashdot" to see if anyone else had completed the exercise.
If it were REALLY important for me to have this storage, I'd go back to using S3 or spring an extra $10 a month to get my account upgraded to use SSH/SFTP.
As it stands now, I may just get a kick out of implementing the project for fun.
You are correct, the access from Windows is really of secondary concern. Still, it would be nice to access the data from work or the wife's computer.
I should have also added that I asked the question to see how much flaming and ridicule I could draw by asking about such a cheap-ass, overly complex solution that is simply solved by SSH/SFTP. :)
So I wrote it myself. http://freshmeat.net/projects/manent
The real problem is not knowing about rsync since it's designed for exactly his problem.
Rsyncrypto
http://rsyncrypto.lingnu.com/
Encrypts while making the above sentence untrue - a small change in the file results in a (relatively) small change in the cypher text.
It's stable, been around a while, and is written by me :-)
Shachar
P.s.
It is, in fact, written by me for the purpose of a commercial backup service. The software itself, however, is free.
The problem is FTP. It is an old deprecated protocol that is inherently insecure and even FTP w/ SSL is simply a work around to a broken problem. As long as you are using insecure FTP then you are officially screwed and I seriously doubt any company is making product when they know FTP has the SSL option (which is a work around but it works). The real answer to your problem is use a secure protocol like SSH which does everything you just asked for natively. Now because I just posted two easy answers to your dilemma, tell me why my company would write and sell complex time stamping encrypting whatchyamacallit software for FTP transfers? This question was already answered a decade or two ago.
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