in reply to Re-3: Encrypting a Filename
in thread Encrypting a Filename

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

Replies are listed 'Best First'.
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]

In Section Seekers of Perl Wisdom