The fact that fSekrit doesn't write temp files is a definite plus - f0dder, I wonder if you have looked at the VirtualLock() API to see if you can prevent inadvertant writing of the data to the pagefile. That would be a nice improvement to the paranoia/worry factor - particularly if using it on a machine that's not yours - in which case the paranoia factor of keyloggers, etc., kicks in - nothing fSekrit can do about that).
As for a nice encryption utility for non-txt files (.doc, .xls, etc.) I use AxCrypt (
http://axcrypt.axantum.com/) and open source utility that integrates into the shell. To encrypt, just right click and select encrypt.
When you want to open the file, just double click on it and AxCrypt prompts for the passphrase, decrypts the file to the temp folder in the user profile then launches the application for the original filetype. When the application closes, the temp file is re-encrypted back to the file you double-clicked on. It's all very seemless.
However, you do run into the issues that f0dder mentions, so you need to be aware that:
1) the file is decrypted to the temp folder - AxCrypt does wipe and delete delete it when the application is done, but if something goes wrong (machine crash or whatever) the data can be left in the clear;
2) AxCrypt has no control over what the application that's editing the decrypted copy does - most apps will leave traces of the data in various places and Windows can also send the data in memory to the pagefile. there's pretty much nothing that AxCrypt can do about either of these.
You can reduce exposure of the decrypted data by setting up XP's EFS on the user profile's temporary folder - that way the working copy is transparently encrypted.
The author gives clear and comprehensive advice on how AxCrypt works and how to deal with some of inherent limitations such as those given above. As long as you're aware of these issues and take the proper steps it's a prettty nice little utility.
