Looking for simple wrapper for symmetric key file encryption

[Ryan Sawhill]

As already mentioned, you could decrypt the file to a ram disk -- the
/dev/shm directory should already be there, but if you're trying to
bypass creating an unnecessary file altogether, you need something
else.

I actually wrote a GUI frontend for this purpose (among others) a
while back. It's called pyrite and available at:
https://github.com/ryran/pyrite

It's extremely versatile and can do everything but manage keys --
basically you can do any kind of signing & verifying with or without
any kind of encryption/decryption (including symmetric).

Your workflow with it could look like this:

1.)  Run pyrite /path/to/encrypted/file
      [GUI opens up with text-input populated by encrypted text]

2.) Decrypt text
      [Cipher-text is replaced with decrypted version; never saved to disk]

3.) Make your edits/changes

4.) Re-encrypt

5.) Click save-to-disk button


On Sun, Jan 19, 2014 at 4:48 PM, Mr. Clif <clif at eugeneweb.com> wrote:
> Hi Doug,
>
> Thanks for the comments. Yes the threat model is mostly the worry of having
> old temp files or even the original cleartext files left behind on the HD,
> or even worse having them backed up. ;-) At the very least I want something
> that tries to protect me from stupid mistakes. Yep the RAM disk idea was
> part of the solution I'm heading towards.
>
> So do you or does anyone know of a nice front end that helps with that? An
> example of behavior that doesn't seem helpful is that when I use GPA to
> decrypt a file it defaults to saving it on the HD. I'm not trying to knock
> GPA here but wouldn't it be better to display the contents in a window? Well
> I realize that might be just what I want, and others have use cases that it
> works fine for. ;-)
>
>     Clif
>
>
> On 01/19/2014 01:23 PM, Doug Barton wrote:
>>
>> On 01/19/2014 08:56 AM, Mr. Clif wrote:
>>>
>>> So I'm trying to get a sense from the users here if they feel that the
>>> process of using gpg for symmetric encryption is safe enough, and they
>>> are not worried about leaving clear text behind.
>>
>>
>> I think you're misunderstanding a few things. First, the problem of the
>> plain text file is not exclusive to symmetric encryption. In fact there is
>> no difference between that, and the plain text file that's left behind after
>> public key encryption.
>>
>> Second, you haven't defined your threat model. You have given us a vague
>> sense of wanting to have a "secure" system, but you haven't said what you're
>> trying to secure it against. Thus it's hard to respond intelligently to your
>> query.
>>
>> That said, I would suggest that you consider using a RAM disk to do your
>> work on. It can be created to do the work, then deleted after you're done,
>> with no risk of leaving a file behind on disk. Of course you'd want to make
>> sure your RAM disk was not swap-backed.
>>
>> hope this helps,
>>
>> Doug
>>
>
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users