Do temporary files store sensitive data?

If the passphrase file isn't wiped before deleting it, the passphrase stays written to the physical disk until the sectors it was using get allocated to another file and are overwritten. It would not be hard to write a program that would read through the entire hard disk and try every sequence of bytes as a passphrase with a length between 1 and 100, and it would probably only take a few hours to run depending on the size of the hard disk. I use gpg on my laptop and expect that if it's stolen no one is going to be able to scan the disk for pass-phrases to all my encrypted files and recover them, which would be possible if I used FireGPG on a daily basis and it left my passphrase laying around in unallocated sectors. For desktop computers, it's secure until you give it away to someone else or sell it. Unless you want to spend a lot of time securely wiping your disk. What happens if you have to send your computer in for repair and they swap the disk out? Half the time they'll try to refurbish it and give it to someone else with a new image which isn't large enough to overwrite all the personal data stored on the disk. Lots of places say they wipe old drives before they resell them but don't actually do it.

The proper way to call GnuPG from another program is to use pipes or fifos on gpg's standard input and output file descriptors and write the input data to gpg's stdin, and read its output from stdout directly from the calling program. Additionally, the --passphrase-fd flag tells GnuPG to read the passphrase from another open file descriptor so that nothing sensitive ever touches the disk. It's kind of a pain, and I haven't seen any functions for actually doing that from the Mozilla plugin interfaces, but I'll keep looking and offer a patch if I can write one. It might be possible to do it with named pipes, depending on how they're implemented on Windows and Linux. For instance, if it's not possible to just fork and run GnuPG (I haven't seen anything about forking in the documentation), then gpg would have to be run with input and output redirected to pipes that FireGPG created, and use --passphrase-file to access a named pipe that FireGPG can write to. It would depend on the named pipes not caching data to disk.

If nothing else, it would be good to securely wipe the files before deletion by writing random bytes over the entire length of the file, since that will stop everyone without special hardware or disk control software (and luck). It might be good to provide a notice about this to people who are in a situation where they can't allow any sensitive information to be leaked to the disk, too.

I tried writing some simple code to do the random overwriting, but for some reason Firefox doesn't overwrite the file, instead it creates "File-1" and writes the random data to it, but doesn't seem to overwrite the original file. Here's what I did:

function removeFile(path) {
    var fileobj = Components.classes[NS_LOCALEFILE_CONTRACTID].
                             createInstance(Components.interfaces.nsILocalFile);
    fileobj.initWithPath(path);

    var stream = Components.classes["@mozilla.org/network/safe-file-output-stream;1"]
                   .createInstance(Components.interfaces.nsIFileOutputStream);
    stream.init(fileobj, WRITE_MODE, WRITE_PERMISSION, 0); // write, no creation or truncation because it should overwrite the existing data

    var randombytes;
    // Create a string of 4096 bytes for speed, Math.random + multiply +
    // floor is almost certainly too slow for large files. Overwriting
    // with repeating random data is sufficient to prevent most data
    // recovery

    for(var i=0;i<4096;i++) randombytes += String.fromCharCode(Math.floor(Math.random()*256));

    var filesize = fileobj.fileSize;

    alert(fileobj.path);
    for(i=0;i<filesize;i+=4096) {
        stream.write(randombytes, randombytes.length);
    }

    stream.close();

    alert("wait");

    try {
        fileobj.remove(path);
    }
    catch (e) {
        alert(path);
        // If file dosen't exist
    }
}

I don't write javascript very much, and this is the first time I've done anything with the Mozilla file and stream libraries, so it may just be a problem with how I wrote it. The alert(fileobj.path) and alert("wait") are in there for debugging. When alert(fileobj.path) runs, it prints /tmp/1182238476247fgpg_tmpFile, but if I look in /tmp I also see /tmp/1182238476247fgpg_tmpFile-1 which actually gets the random bytes written to it, and the original file stays the same. At the alert("wait") line, the -1 file is gone but the original file still has the original data and is not random.

I've tried a couple combinations of values for WRITE_MODE including just 0x02 to open the file write only, since truncating it may deallocate the sectors and the random bytes might get allocated to different ones. I suppose I could write a shell script and batch file that do the secure wiping, but it would require a special utility for Windows and would rely on having dd and /dev/urandom on Linux, which isn't very cross platform. I could also write a C program that would compile on Windows and Linux to do a simple wipe, but I don't know if the project wants to start collecting stuff written in other languages.

blivengood -> It's beacause you init a tempory file (so FF use a unique name), see our 'getContent' function for a a stream of a existing file)

Sid77 -> Yes, we're do some scrach to fix the problem, and ipc.xpt is related. But Enigma use complicated functions...

We will secure this system, but the first priority is a standart system for gmail...

(No hstart.exe will needed with ipc, so we can say it's our second priority )

another option might be to use a use-agent

unfortunately, IPC is the only way to go: both using a temp file and --passphrase is insecure, as password can be easily read through the file or with "ps -aux | grep gpg"