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
gnupg binaries too big? / OpenBSD Moving Towards Signed Packages — Based On D. J. Bernstein Crypto
Hi, Is there any possibility to create a minimal version of gnupg? http://bsd.slashdot.org/story/14/01/19/0124202/openbsd-moving-towards-signed-packages-based-on-d-j-bernstein-crypto # --- /It's official: 'we are moving towards signed packages http://marc.info/?l=openbsd-miscm=138992613426488w=2,' says Theo de Raadt on the misc@ mailing list. This is shortly after a new utility, signify http://bxr.su/OpenBSD/usr.bin/signify/signify.c, was committed into the base tree. The reason a new utility had to be written in the first place http://www.tedunangst.com/flak/post/signify is that gnupg is too big to fit on the floppy discs, which are still a supported installation medium for OpenBSD. Signatures are based on the Ed25519 http://ed25519.cr.yp.to/ public-key signature system from D. J. Bernstein and co., and his public domain code once again appears http://bxr.su/OpenBSD/usr.bin/signify/mod_ed25519.c in the base tree of OpenBSD, only a few weeks after some other DJB inventions made it into the nearby OpenSSH http://it.slashdot.org/story/13/12/11/173213/openssh-has-a-new-cipher-chacha20-poly1305-from-dj-bernstein as well./ Kind regards, Mark -- m...@it-infrastrukturen.org http://rsync.it-infrastrukturen.org ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Reusing signed user ID or attribute
Ok, so I have to conclude it's implementation specific? I'm using a custom user attribute to store something that can change quite often (privacy lists for a chat user). What do you suggest? On Fri, Jan 17, 2014 at 1:28 PM, Hauke Laging mailinglis...@hauke-laging.de wrote: Am Fr 17.01.2014, 11:44:55 schrieb Daniele Ricci: My question is the following: suppose I create a user ID or attribute. I sign it with my key and that's ok. One day I revoke that user ID or attribute and sign it again with a certification revocation. A few years later, I want to restore that user ID or attribute because, e.g. I restored an old e-mail address. Is it enough to sign the revoked user attribute once again with a valid signature (then timestamps will do the rest) or do I have to create a new user ID with the same data? I am afraid that depends on the implementation. The RfC isn't clear on that (if I understand it correctly). It says about self-signatures (a revocation is not a self-signature in this sense, though): An implementation that encounters multiple self-signatures on the same object may resolve the ambiguity in any way it sees fit, but it is RECOMMENDED that priority be given to the most recent self-signature. About revocations it says: 0x30: Certification revocation signature This signature revokes an earlier User ID certification signature (signature class 0x10 through 0x13) or direct-key signature (0x1F). It should be issued by the same key that issued the revoked signature or an authorized revocation key. The signature is computed over the same data as the certificate that it revokes, and should have a later creation date than that certificate. IIRC then GnuPG accepts a later self-signature (overriding the revocation). IMHO that makes most sense. As long as the mainkey isn't revoked or expired why shouldn't one change one's mind? I haven't tried now but IIRC you have to delete the revocation first before you can create a new signature. Hauke -- Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -- Daniele ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Reusing signed user ID or attribute
Am So 19.01.2014, 15:55:51 schrieb Daniele Ricci: Ok, so I have to conclude it's implementation specific? I'm using a custom user attribute to store something that can change quite often (privacy lists for a chat user). What do you suggest? My first thought is: Why should it make sense to put this data into a certificate? Use a simple file with a simple signature. Let the signature expire every few days (or hours, whatever you need). You may put the URL of the file into the certificate using a notation. Hauke -- Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Reusing signed user ID or attribute
On 01/19/2014 09:55 AM, Daniele Ricci wrote: Ok, so I have to conclude it's implementation specific? I'm using a custom user attribute to store something that can change quite often (privacy lists for a chat user). What do you suggest? I don't know what a privacy list for a chat user is. You should probably try to document what you are trying to achieve more clearly, and present it in a public forum where people can help you think through possible ways to achieve it. This thread started off by asking about user IDs or attributes, which seems to assume that this is the only way to provide the information you're looking for. But an OpenPGP notation (stored within the self-signature) could also provide that information directly. User IDs and User Attributes are for information that you need or want third parties to confirm and certify. Information in an OpenPGP notation does *not* need to be confirmed or certified by third parties. So if Alice wants to indicate something about her preferences about how to use chat, she can do so in a notation subpacket within her self-sig. does this make sense? --dkg 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: Reusing signed user ID or attribute
Thank you Daniel, it actually sounds very right. Now that I think about it, storing this kind of data in the public key block isn't so good afterall. I will investigate over this and ask to the right ML next time. Thank you everyone for your help. On Sun, Jan 19, 2014 at 5:21 PM, Daniel Kahn Gillmor d...@fifthhorseman.net wrote: On 01/19/2014 09:55 AM, Daniele Ricci wrote: Ok, so I have to conclude it's implementation specific? I'm using a custom user attribute to store something that can change quite often (privacy lists for a chat user). What do you suggest? I don't know what a privacy list for a chat user is. You should probably try to document what you are trying to achieve more clearly, and present it in a public forum where people can help you think through possible ways to achieve it. This thread started off by asking about user IDs or attributes, which seems to assume that this is the only way to provide the information you're looking for. But an OpenPGP notation (stored within the self-signature) could also provide that information directly. User IDs and User Attributes are for information that you need or want third parties to confirm and certify. Information in an OpenPGP notation does *not* need to be confirmed or certified by third parties. So if Alice wants to indicate something about her preferences about how to use chat, she can do so in a notation subpacket within her self-sig. does this make sense? --dkg -- Daniele ___ 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
