Abigail-II is right. If your only goal is to make the data unintelligible to the layperson to discourage manual editing of a configuration file, there's probably no need to go to great lengths to encrypt it. And if that's the case, ROT-13 is a good solution.

ROT-13 (from what I recall) was a technique first made ubiquitously common on Usenet, particularly when consciencious adults posting "racey" text-based material (sex stories, etc.) to public Usenet groups (possibly viewed by children) applied a ROT-13 to their message before posting it so that innocent eyes wouldn't just happen across an F-word or a story about some X rated experience.

Many newsreaders still have a ROT-13 decode option built in. But the point was that you had to be able to recognize that it's ROT-13'ed, and you had to consciously apply the decoding.

Chances are your end users aren't going to bother with applying a ROT-13 decoding just on the off chance of finding that suddenly they're able to edit your configuration file.

Here's how it works. Take any letter of the english alphabet, and rotate rotate it 13 characters. The Perl way to do this is with transliteration, and I belive that Abigail-II already posted an example of that later in this thread.

If you're afraid that ROT-13 isn't secure enough, do this: Add a checksum to the end of the ROT-13'ed file. If someone tampers with the file they'll have to also adjust the checksum. But the point is that ROT-13 isn't secure, it's just a pain in the butt, which will probably either confuse or discourage would-be tinkerers. Kinda like car door locks. Anyone can still get in, but why bother when the car parked next to yours forgot to lock up altogether?