6

I need to use GPG on a folder with a lot of files and subfolders. I can use "find" + "gpg" for that and I can encrypt all the files but my issue is GPG does not delete the original file after successful encryption.

What is the best and the most secure way to delete the original file(s) after GPG does it encryption properly? I do not want to delete my files prematurely and I do not want remove unencrypted files (due to error, permission etc issues with GPG operation) improperly.

thanks

1 Answer 1

4

shred sounds like your weapon of choice, for securely deleting files, but see below for filesystem limitations.

And if you're using the terminal, some bash/sh scripting might be useful. If you want to use an error-checking one line? Like this to move a file if it's encrypted correctly, and print a message if it wasn't?

gpg --encrypt <options> "$file" && mv "$file" todel-folder || echo "Error, $file did not encrypt"

Or you could put together some multi-line "if success" & "if fail" items for logging, using some curly brackets:

gpg --encrypt <options> "$file" && {
  echo "gpg on $file successful" >> logfile
  mv "$file" todel-folder
  } || {
  echo "Error, $file did not encrypt" >> logfile
}

And then after, you can securely delete/wipe/shred the files in todel-folder, or just shred them immediately instead of using mv:

gpg --encrypt <options> "$file" && {
    echo "gpg on $file successful" >> logfile
    shred "$file" && { 
        echo "shred on $file successful" >> logfile
        } ||  {
        echo "shred on $file successful" >> logfile
        }
    } || {
    echo "Error, $file did not encrypt" >> logfile
}

See man shred for some options and warnings:

shred - overwrite a file to hide its contents, and optionally delete it

CAUTION: Note that shred relies on a very important assumption: that the file system overwrites data in place. This is the traditional way to do things, but many modern file system designs do not satisfy this assumption. The following are examples of file systems on which shred is not effective, or is not guaranteed to be effective in all file system modes:

  • log-structured or journaled file systems, such as those supplied with AIX and Solaris (and JFS, ReiserFS, XFS, Ext3, etc.)

  • file systems that write redundant data and carry on even if some writes fail, such as RAID-based file systems

  • file systems that make snapshots, such as Network Appliance's NFS server

  • file systems that cache in temporary locations, such as NFS version 3 clients

  • compressed file systems

In the case of ext3 file systems, the above disclaimer applies (and shred is thus of limited effectiveness) only in data=journal mode, which journals file data in addition to just metadata. In both the data=ordered (default) and data=writeback modes, shred works as usual. Ext3 journaling modes can be changed by adding the data=something option to the mount options for a particular file system in the
/etc/fstab file, as documented in the mount man page (man mount).

2
  • well the thing is that I do not want to move files around because it can get very complicated if something goes wrong, like restructuring it back in the case of a problem. No ?
    – yarun can
    Feb 18, 2015 at 0:02
  • The move there is only executed if gpg was successful, and as a precaution before the irreversible shred. But you could do shred instead of mv and get it gone right then? I'll add some possibly useful multi-line stuff for logging
    – Xen2050
    Feb 18, 2015 at 0:39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .