<p dir="ltr">One way to mitigate risk from my experience is this flow:</p>
<p dir="ltr">Turn swap off.<br>
Mount a tpmfs volume.<br>
Do all work on tmpfs including gpg steps.<br>
Shred contents of tmpfs.<br>
Unmount tmpfs.<br></p>
<p dir="ltr">-jacob<br>
</p>
<div class="gmail_quote">On Aug 26, 2012 6:40 AM, "Stephen Queen" <<a href="mailto:svqueen@gmail.com">svqueen@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 8/25/12, Michael Fierro <<a href="mailto:miguelito@biffster.org">miguelito@biffster.org</a>> wrote:<br>
> On Sat, Aug 25, 2012 at 11:41 AM, Yaverot <<a href="mailto:Yaverot@computermail.net">Yaverot@computermail.net</a>> wrote:<br>
>><br>
>> --- <a href="mailto:miguelito@biffster.org">miguelito@biffster.org</a> wrote:<br>
>><br>
>> >> Why not just use an encrypted file system?<br>
>><br>
>> >Sometimes you need a hammer instead of a sledgehammer.<br>
>><br>
>> "Cover your tracks" is a sledgehammer requirement. GPG shouldn't care<br>
>> about what filesystem it is on. Is it a FAT variant, so you can "just"<br>
>> ovewrite the data from a random source? Is it ext3 or 4 where you have to<br>
>> worry about journaling? Is it a CoW setup, a SSD, ZFS or btrfs -> can you<br>
>> even overwrite the "plaintext" data?<br>
><br>
> I think we got off-track from the original question: how can you get<br>
> gnupg to delete a file after it encrypts it.<br>
><br>
>> If you're worrying about this then you definitely don't want GPG to "do it<br>
>> wrong" by just issuing a rm.<br>
><br>
> The best idea is to have gnupg to not have an option to delete, but to<br>
> be able to pass this functionality on to the OS. You can then use<br>
> OS-specific utilities to delete the file at whatever security level<br>
> you need. (e.g. using shred or srm to overwrite the file.<br>
><br>
> gpg --batch ---armor --encrypt $1 --outfile secure.gpg<br>
><br>
> if [ $@ ] then<br>
> shred --remove<br>
><br>
>From the man page for shred<br>
" CAUTION: Note that shred relies on a very important assumption: that<br>
the file system overwrites data in place. This is the traditional way<br>
to do things, but many modern file sys‐<br>
tem designs do not satisfy this assumption. The following are<br>
examples of file systems on which shred is not effective, or is not<br>
guaranteed to be effective in all file system<br>
modes:<br>
<br>
* log-structured or journaled file systems, such as those<br>
supplied with AIX and Solaris (and JFS, ReiserFS, XFS, Ext3, etc.)<br>
<br>
* file systems that write redundant data and carry on even if<br>
some writes fail, such as RAID-based file systems<br>
<br>
* file systems that make snapshots, such as Network Appliance's<br>
NFS server<br>
<br>
* file systems that cache in temporary locations, such as NFS<br>
version 3 clients<br>
<br>
* compressed file systems"<br>
<br>
So shred has to be used with caution.<br>
_______________________________________________<br>
clue mailing list: <a href="mailto:clue@cluedenver.org">clue@cluedenver.org</a><br>
For information, account preferences, or to unsubscribe see:<br>
<a href="http://cluedenver.org/mailman/listinfo/clue" target="_blank">http://cluedenver.org/mailman/listinfo/clue</a></blockquote></div>