It is worse. crypt() encrypts only the first 8 characters, so that any (file)names with the same 8 starting chars encrypt to the same string (given the same seed). Also you don't get 13 chars out of it, but 11, because the first to characters are the preselected seed. You could use 2 characters of your filename as seed, but then you would give an attacker already two known characters of the filename for free

You might look at other hash algorithms, for example Digest::MD5 or Digest::SHA2. Base64 encoded you still get '/' in the hash, but you could afterwards use tr{/}{-} to change every / into a -

You do know that hash functions are one-way, right? You can't decrypt those filenames later on, not with crypt nor any of the hashes I mentioned. If you need to decrypt them again you have to use a symmetric chiffre like DES or AES

If you need a better answer, tell us more

You could use something like Crypt::CBC and pump all your filenames through it. This is particularly desirable if you'd like to be able to recover the filenames again later.

Thank you so much for telling me about Crypt::CBC. It looks like this module would work great for encrypting strings, files and other data.

However, the resulting encrypted strings are something like "Salted__8��u�,��Zr�Xf�6���9 �B#����". This would be fine if I was working with data, but this is not good for filenames.

Thanks again for your help. I'm sure Crypt::CBC will come in handy in the near future.

Why is it "not good?" Looks like you're not using encrypt_hex.

Hence the reason my example uses encrypt_hex() ... There are many other ways to move from the binary bits to something suitable to your filesystem, but encrypt_hex is built in and easy...

-Paul

I see little or no benefit from a security point of view. Once an attacker has gained access to your file-system, having the filenames encrypted will then buy you little or no extra protection. Or perhaps you might wish to save the encrypted filenames into a database and thus "break" the link between the data in the database and the physical files on disk? Again, you will be better served by having your database and the access to it well protected and secured.

Not knowing anything more detailed about what you are trying to achieve, it strikes me as "protection through obfuscation" which is always the wrong way to do it. But I may be mistaken and you are trying to do something totally different, so please enlighten us.

The absolutely best way to encrypt anything is of course the use of a "one time pad" with a key length longer than the message. There are no known ways, brute force or otherwise, to reliably decrypt such a message.

use Digest::MD5 qw(md5_hex);
my $digest = md5_hex($data);
[download]

A few points, though:

• Any crypto method which produces similar output for similar input is pretty poor crypto. As already mentioned, crypt() ignores anything after the first 8 characters, making it a pretty poor choice for dealing with inputs over 8 characters long.
• crypt() is a one-way hashing function, so using it (or MD5 or SHA*) would only be useful in this scenario for determining whether a filename entered by the user corresponds to an existing file or not. You cannot reverse the hashing process to get a list of plaintext filenames from the list of hashes, which makes it very easy to "lose" files.
• Hashing filenames would basically just turn the name of the file into a password needed to access its contents. Using a password-protected file format (with plaintext-named files) is the normal way to accomplish this.
• I've never heard of anyone wanting to encrypt/hash user names before. I'm kind of getting the impression here that you either work for an ultra-high-security organization (in which case you should already know these things) or you're just "encrypting" everything in sight without first stopping to consider what benefit may or may not be gained by obscuring each type of information.