See also DBM::Deep - pay attention to the DBM::Deep FILTERS section. There is even an encryption example (mind you, encryption on smaller chunks of data may make it easier to break - something with padding of some sort may help).

As mentioned above, encryption on smallish chunks of data can make things easier (for some definition of easier) to break, as the search space is smaller. If you don't need record level encryption, and just want to keep the cleartext off from the disk (the user would still possibly be able to access the data however), try http://www.truecrypt.org. I use it frequently for my thumbdrives, as well as anything else on my "anchored" machines that I would have problems with walking away. I mount it when needed, and unmount it when done.

As is my typical advice - when rolling your own encryption method, even if using someone else's algorithm, be very careful. There have been some spectacular failures due to misusing an algorithm or setting up prerequisites incorrectly.

Thanks this is good stuff. However the only issue I can see as a problem is the caveat in the synopsis about using this on NFS which is something I possibly want to do.

Do you have a file structure in mind or are you just at the planning stage? What about using DBD::CSV to perform SQL (select,insert,update and delete) on your data. You could encrypt/decrypt using one of the many encryption modules. Perhaps if you elaborate on what you want to do others may have more concrete advice.

This is in the planning stage and doesn't involve SQL. Perhaps I should have said read/write operations on a text file instead. Apologies.

The file would look something like this, where the first column is an id column which would be used when updating or removing the relevant record from the file

id col1 col2 col3 col4 username email.address status
[download]

I'd envisage around 3000 records being present in the file to start with. Growing over time to a much larger number (50,000 records). So performance will play a part as the file grows.