Looking for simple wrapper for symmetric key file encryption

[Mr. Clif]

Hi Ryan,

Yes that is exactly the kind of front end I was looking for, and it 
looks very nice. Thanks for writing it. :-) Though now I have finished 
the stab I took at solving the problem myself, which is a much simpler 
command line script. You can find the two versions of it here:

https://www.eugenemakerspace.com/wiki/Sites/Cryptsym

If folks have the time, I would appreciate any feed back on how they 
like it.

     Ciao!
     Clif

On 01/21/2014 09:28 AM, Ryan Sawhill wrote:
> 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