Re: Encrypting a Filename

Shameless plug, yes, but how about using Net::SFTP? SFTP runs as a subsystem over a standard SSH connection, so automatically everything you send over the network is encrypted, including both filename and file contents.

This way you can just do something like this:

    use Net::SFTP;
    my $sftp = Net::SFTP->new("backup_host");
    $sftp->put("local_file", "remote_file");
[download]

Or, what about rsync, using ssh as the rsh replacement? I don't know enough about that to know whether it encrypts filenames going over the network, but I would *guess* that it does, because I believe it just runs over ssh.

If you want to stick w/ the method you're talking about, I think your best option is to do what you suggested: encrypt the filename, then base64-encode it. Considering that you're going to be sending the entire contents of files over the network, adding a couple of bytes per filename isn't going to be the deciding factor in terms of efficiency. :)

Comment on Re: Encrypting a Filename Download Code

Replies are listed 'Best First'.
Re-3: Encrypting a Filename by John M. Dlugosz (Monsignor) on Jun 15, 2001 at 03:26 UTC
Re SSH: Since I don't have that, I'm really looking for a self-contained solution. This script backs up to another part of the file system, which can be a different spindle or could be a "backup buddy" over the network, but it doesn't require a network. I will check it out, though. As for efficiency, that's not my worry. I'm more concerned with file name limitations of the receiving system. Burn to a standard CDR for example, limits the length and character set. I can punt on that if I just say "ZIP the files, then burn that" because ZIP doesn't have a length limit and pretty much likes any 8-bit character string as a name. However, what if your source is case-sensitive and the dest is case sensitive? In my situation at home, the source is NTFS with full Unicode names, but the dest is FAT32. So, I'm thinking of URL-encoding the names and sticking to a small destination character repertoire. Preserves case. BUT, what about case clashing if the dest is case-insensitive? I suppose I need to encode that too, and assume the dest is case smashing!! Any thoughts, on any of that? Don't you hate contradictory requirements? —John	[reply]
Re: Re-3: Encrypting a Filename by marcink (Monk) on Jun 15, 2001 at 03:47 UTC
I'm more concerned with file name limitations of the receiving system. One more suggestion, then: calculate the encrypted file name with some kind of digesting algorithm (with numeric suffix to make it unique), while encrypting the original name together with file contents (by prepending or appending it to the original file)? Pro: you can make the filename generator use very small character set. Cons: 1) file name decoding requires more work (and the encrypted version is not sufficient), 2) finding encrypted file might require proximity searching, -mk	[reply]
Re-6: Encrypting a Filename by John M. Dlugosz (Monsignor) on Jun 15, 2001 at 05:24 UTC
If I make the source=>dest one-way, such as by truncating, I can store the real filename inside the file. That provides the other way. However, next time it goes the first way, it may not be unique, if suffixes are added to disambiguate. It may have to check several candidates to see which matches. Perhaps that will be rare, especially if I set the limits to match the real destination filesystem (so it doesn't fold more than it has to). Not as elegant as 1:1, but probably not over-burdened. Hmm, but it would mean it always has to open the file to check the real name, not just compare dates to see if the backup needs freshening. —John	[reply]