[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Decrypt, Edit and Encrypt a File



Douglas A. Tutty wrote:
> On Tue, Apr 07, 2009 at 06:17:56PM -0400, H.S. wrote:
>> Douglas A. Tutty wrote:
>>> On Tue, Apr 07, 2009 at 05:46:31PM -0400, H.S. wrote:
>>>> Douglas A. Tutty wrote:
>>>>> Where does it hold the decrypted data?  Does it stay in RAM, does it get
>>>>> swapped, does it go to a scratch file?
>>>> This might help:
>>>> http://www.easypg.org/
>>> yea, it looks like it can leak info.
>> I am just starting to play around with the two tools (gnupg.vim and
>> easypg). You appear to already know about vim and have pointed out a
>> possible problem with easypg. Does this problem not exist in the vim plugin?
> 
> I don't use the vim plugin.  I currently have encrypted swap, with /tmp
> on tmpfs (so /tmp is encrypted), and have /home encrypted too.  On boxes
> where /home isn't encrypted, I still have swap and /tmp encrypted.  
> 
> To decrypt a file without leaking info (other than that ram itself isn't
> encrypted, but that's another kettle of fish), I pipe the file through
> openssl and point the output to somewhere in $TMP.
> 
> Example:
> 
> In /etc/pam.d/common-session, I have:
> 
> 	session optional pam_tmpdir.so
> 
> which gives a $TMP of /tmp/user/1000
> 
> $ cat /proc/swaps:
> Filename			Type		Size	Used	Priority
> /dev/mapper/sda2_crypt		partition 	979956 	0 	-1
> 
> $ mount | grep -i /tmp
> /dev/mapper/sdb1_crypt on /var/tmp type ext3 (rw,data=journal)
> tmpfs on /tmp type tmpfs (rw,size=500m)
> 
> Encryption/decryption is done with OpenSSL's enc
> 
> To encrypt:
> 
> openssl aes-256-cbc -a -e -salt -in file -out file.aes
> 
> To decrypt:
> 
> openssl aes-256-cbc -a -d -salt -in file.aes -out file
> 
> All I need to do to keep unencrypted data off an unencrypted /home (or
> USB stick, whatever), is to ensure that the output of decrypt only goes
> to /tmp (or additionally in my case, /var/tmp).
> 
> I can then edit the file, do whatever I want (as long as the software
> doesn't itself leak info), then re-encrypt the file putting the
> encrypted file whereever I like.
> 
> There are a limited number of place where a piece of software can leak
> info:
> 
> 1.	to /tmp:		Its encrypted
> 2.	to /var/tmp:		Its encrypted
> 3.	to somewhere on ~/	I have /home encrypted
> 4.	left in swap		its encrypted
> 5.	in a core dump after a crash:	use ulimit (see man bash) to
> 					limit core dump size to 0
> 
> Of course, the uncrypted data is in memory, so anything that can read
> any memory segment can read your data.
> 
> I hope that this helps in your considerations.

Yes, that was helpful in understanding all this. Thanks for the explanation.

I am curious, what is the performance cost to have your ~/ and /tmp and
/swap encrypted? What kind of machine are you using?

Also, since you have to use mount, which requires root privileges, the
above method is not possible for a normal (non-root) user, is it?

Thanks.




-- 

Please reply to this list only. I read this list on its corresponding
newsgroup on gmane.org. Replies sent to my email address are just
filtered to a folder in my mailbox and get periodically deleted without
ever having been read.


Reply to: