I use ecryptfs, as packages are available for my distro (Debian) which make it easy to install and use.
I wouldn't like to make any claims about "best practice", for the most
part I rely on defaults provided by more knowledgeable folks than myself.
Mr. Clif wrote:
> So no one got back to me.
>
> Does anyone use symmetric file encryption? What is the best practice
> here? I heard of another solution which was to mount an encrypted
> directory with fuser to drop files into. I think I would wounder how
> safe the passphrase was for mounted filesystems, though I know of some
> techniques for protecting them.
>
> Any pointers regarding best practices for symmetric file encryption
> would be much appreciated.
>
> Thanks,
> Clif
>
> On 01/17/2014 01:15 PM, Mr. Clif wrote:
>> Greetings!
>>
>> I've been happily using pgp and gpg off and on for decades. One thing
>> I never quite figured out was what the best way to use it for
>> encrypting sensitive files on disk. After doing that one has to
>> remember to cleanup after themselves and delete all the leftover
>> plaintext versions of the file, or it kind of defeats the whole
>> purpose, and its pretty easy to make a mistake when doing it manually.
>> I always felt that GPG should help you a bit more in that regard. Now
>> I know that full disk encryption might be a way around this, but it
>> seems like overkill if you just have a couple of files to protect.
>>
>> I have searched high and low and checked out GnuPG Shell, GPA,
>> Seahorse, XAP, and some other misc wrappers but nothing seemed to fit
>> my use case. So I wrote a simple wrapper in perl. Basically it just
>> lets you toggle a file between plaintext and encrypted forms without
>> letting the plaintext version touch/remain on the disk, unless that is
>> what you want.
>>
>> #! /usr/bin/perl -U
>> # This Perl script is a wrapper around GPG to decrypt or encrypt
>> a file.
>> # It's goal is to try to prevent plaintext from touching, or remaining
>> # on the disk, something GPG fails to do. If there is a new file
>> created
>> # It will be in the same directory as the original unless you
>> specify a new
>> # path in a second arg.
>> #
>> # By Clif 12/05/13
>> #
>>
>> # External utilities
>> $GPG = "/usr/bin/gpg"; # GnuPG 1.4.15
>> $SHRED = "/usr/bin/shred"; # secure file deleter
>> (GNU coreutils) 8.13
>>
>> # Arguments
>> ($arg, $dest) = @ARGV;
>>
>> # Break down the pathname
>> $path = $1 if $arg =~ /^(.*?)(\/[^\/]*)$/;
>> $file = $1 if $arg =~ /([^\/]+)\/?$/;
>> $base = $1 if $file =~ /^(.+?)(\.[^.]*)?$/;
>> $ext = $1 if $file =~ /\.([^. ]*)\s*$/;
>>
>> # Get destination
>> if ($dest) {
>> $destp = 1;
>> $dest .= "/$base" if (-d $dest);
>> $dest =~ s/\.asc\s*$//;
>> } else { $dest = $path ? "$path/$base" : $base }
>>
>> # Is this a planetext or an encrypted file?
>>
>> if (-r $arg) {
>> if ($ext eq "asc") { # Encrypted
>> if ($destp) { system("$GPG -o $dest $arg") }
>> else { system("$GPG -o - $arg") }
>> } else { # Plaintext
>> unlink "${dest}.asc";
>> $err = system("$GPG -o ${dest}.asc -ca --cipher-algo AES256
>> $arg");
>> if ($err) { print "ERROR = $err\n" }
>> else { system("$SHRED -un9 $arg") }
>> }
>> } else { warn "No such file: $arg\n" }
>> # All done
>>
>>
>> Obviously it could be much more thorough but I just wanted to get the
>> idea across. I was also thinking about adding a RAM based editing
>> feature but I didn't want to reinvent the wheel if someone knows of a
>> similar project.
>>
>> Thanks for any comments you might have,
>> Clif
>>
>>
>
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
--
Andy Ruddock
------------
andy.rudd...@rainydayz.org (OpenPGP Key ID 0xB0324245)
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
