Re: Looking for simple wrapper for symmetric key file encryption
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 c...@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@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Looking for simple wrapper for symmetric key file encryption
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 c...@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@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Looking for simple wrapper for symmetric key file encryption
On 19-1-2014 7:50, Mr. Clif wrote: Does anyone use symmetric file encryption? Yes, but only for encrypting files for personal use. Not in communication with others. What is the best practice here? As always, that depends on your use case and threat model. I heard of another solution which was to mount an encrypted directory with fuser to drop files into. Possible, I use TrueCryot containers for that but that's similar (although more portable and usable on that other OS). I think I would wounder how safe the passphrase was for mounted filesystems, Are you asking how long it would take to brute-force the pasword, how difficult it is to snoop it or if there are known vulnarabilities in the symmetric encryption used by gnupg, fuser or others? though I know of some techniques for protecting them. Remember the weakest link in all encryption: https://xkcd.com/538/ -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Looking for simple wrapper for symmetric key file encryption
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
Re: Looking for simple wrapper for symmetric key file encryption
On 19-1-2014 12:12, Andy Ruddock wrote: 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. Although trust in that approach has gotten some drawback since the actions of RSA Inc. became public knowledge. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Looking for simple wrapper for symmetric key file encryption
On 01/19/2014 03:53 AM, Johan Wevers wrote: On 19-1-2014 7:50, Mr. Clif wrote: Does anyone use symmetric file encryption? Yes, but only for encrypting files for personal use. Not in communication with others. Same here. This is why I wrote that perl script, so I wouldn't have to remember to delete the plaintext file after I encrypted it. Are there other front ends or wrappers that help the work flow in this way? What is the best practice here? As always, that depends on your use case and threat model. I heard of another solution which was to mount an encrypted directory with fuser to drop files into. Possible, I use TrueCryot containers for that but that's similar (although more portable and usable on that other OS). I think I would wounder how safe the passphrase was for mounted filesystems, Are you asking how long it would take to brute-force the pasword, how difficult it is to snoop it or if there are known vulnarabilities in the symmetric encryption used by gnupg, fuser or others? though I know of some techniques for protecting them. Remember the weakest link in all encryption: https://xkcd.com/538/ Yes I suppose that's true. Though I was just thinking about ways I heard of to hide the key material in RAM. As I mentioned below, I'd rather not have to resort to an encrypted filesystem just to handle the occasional private file unless the conventional wisdom says that it's the only good way to do it. 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. Thanks, Clif ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Looking for simple wrapper for symmetric key file encryption
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@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Looking for simple wrapper for symmetric key file encryption
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
Looking for simple wrapper for symmetric key file encryption
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
