Re: Card readers supported by GPG's internal drivers
On Tue, 11 Jul 2006 20:16, Tony Whitmore said: Is there a compatibility list of drivers supported by GPG's internal card reader driver, other than the relevant part of the HOWTO? Do No there is no such list. This is becuase the driver implements the CCID specification with a few limitations (only T-1, auto-negoations required). It only a matter of the reader. $ gpg --card-status gpg: pcsc_establish_context failed: no service (0x8010001d) gpg: card reader not available gpg: OpenPGP card not available: general error Using --debug-ccid-driver will give more information. Shalom-Salam, Werner ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
How to verify the file was successfully encrypted...
Hi folks. I've read the man page. I've read the FAQ's. I'm not seeing what I'm looking for. Using something like zip, you can use a -T to test the integrity of the file. Note: this is not testing that nobody has altered it, or that it came from a specific user; it is only testing whether it is a good gpg file and whether it can be decrypted. All I can find in gpg is a way to verify the integrity vs. a signature file. I'm looking for a way to gpg encrypt a file, test that the encryption was good and that the file can be extracted, and then to delete the original file. Even better would be a way to automatically remove the original when the encrypted version has been successfully created, if such a parameter exists. At the very least, though, a way of testing that the file encryption was successful without having to sit at my desk at 3AM running 'gpg --decrypt filename' to test it would be very helpful. Is this something I'm just not seeing on the man page and in the FAQ's? Thanks! Benny Helms ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Card readers supported by GPG's internal drivers
On Wed, Jul 12, 2006 at 09:05:58AM +0200, Werner Koch wrote: On Tue, 11 Jul 2006 20:16, Tony Whitmore said: Is there a compatibility list of drivers supported by GPG's internal card reader driver, other than the relevant part of the HOWTO? Do No there is no such list. This is becuase the driver implements the CCID specification with a few limitations (only T-1, auto-negoations required). It only a matter of the reader. Ah OK. It's not entirely clear from the spec of my reader whether it supports the CCID specification, although it does say it supports the T=1 protocol. $ gpg --card-status gpg: pcsc_establish_context failed: no service (0x8010001d) gpg: card reader not available gpg: OpenPGP card not available: general error Using --debug-ccid-driver will give more information. Not all that much more, I'm afraid. :) $ gpg --debug-ccid-driver --card-status gpg: DBG: ccid-driver: no CCID reader with number 0 gpg: pcsc_establish_context failed: no service (0x8010001d) gpg: card reader not available gpg: OpenPGP card not available: general error Running the command through an strace shows gpg trying to access device nodes directly (e.g. /dev/bus/usb/002/022) rather than entries in /proc/bus/usb as the HOWTO talks about. The device nodes are, by default, writeable only by root. But even with tweaked permissions and group ownership on the device node, the same error occurs. The difference is that instead of reporting Permission denied on the device node, strace shows: open(/dev/bus/usb/002/022, O_RDWR)= 3 ioctl(3, USBDEVFS_IOCTL, 0xbfe8ad20)= -1 ENOTTY (Inappropriate ioctl for device) If there are any more suggestions of what I can try, I'm all ears. :) Thanks, Tony signature.asc Description: Digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How to verify the file was successfully encrypted...
Benny Helms wrote: I'm looking for a way to gpg encrypt a file, test that the encryption was good and that the file can be extracted, and then to delete the original file. Forgive a silly question, but what's wrong with decrypting the file as a way of verifying the encryption worked? At the very least, though, a way of testing that the file encryption was successful without having to sit at my desk at 3AM running 'gpg --decrypt filename' to test it would be very helpful. If you're already sitting at your desk at 3AM doing encryptions, then doing a decryption shouldn't be a terrible additional step. If you've got a Perl script that's doing the encryptions, then have your Perl script do the verification step, too. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Card readers supported by GPG's internal drivers
On Tue, Jul 11, 2006 at 10:03:20PM +0100, Tony Whitmore wrote: I'm running Ubuntu Dapper. Am I right in thinking the entries in /proc/bus/usb/XXX/XXX should be modified to match the rules (i.e. group scard, mode 644)? Because they don't seem to be: Current systems with udev should use somewhere obviously named in /dev by default, with libusb preferring them. It's those that get their permissions changed. There are unresolvable races with using /proc. -- You grabbed my hand and we fell into it, like a daydream - or a fever. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How to verify the file was successfully encrypted...
On Tue, Jul 11, 2006 at 01:38:23PM -0600, Benny Helms wrote: Hi folks. I've read the man page. I've read the FAQ's. I'm not seeing what I'm looking for. Using something like zip, you can use a -T to test the integrity of the file. Note: this is not testing that nobody has altered it, or that it came from a specific user; it is only testing whether it is a good gpg file and whether it can be decrypted. All I can find in gpg is a way to verify the integrity vs. a signature file. I'm looking for a way to gpg encrypt a file, test that the encryption was good and that the file can be extracted, and then to delete the original file. What is your actual threat model here? The simplest answer is to check gpg's rc after the encryption run. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Card readers supported by GPG's internal drivers
On Wed, Jul 12, 2006 at 12:02:12PM +0100, Mark Brown wrote: On Tue, Jul 11, 2006 at 10:03:20PM +0100, Tony Whitmore wrote: I'm running Ubuntu Dapper. Am I right in thinking the entries in /proc/bus/usb/XXX/XXX should be modified to match the rules (i.e. group scard, mode 644)? Because they don't seem to be: Current systems with udev should use somewhere obviously named in /dev by default, with libusb preferring them. It's those that get their permissions changed. There are unresolvable races with using /proc. Thanks for confirming this Mark. It's what I had suspected from the strace output [1]. gpg is certainly looking at entires in /dev/bus/usb when it runs, and doesn't seem to reference /proc at all. Having changed the permissions on the relevant device node, it hasn't changed the situation. Thanks, Tony [1] http://lists.gnupg.org/pipermail/gnupg-users/2006-July/028983.html signature.asc Description: Digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How to verify the file was successfully encrypted...
On Wed, 2006-07-12 at 12:25 +0200, Janusz A. Urbanowicz wrote: On Tue, Jul 11, 2006 at 01:38:23PM -0600, Benny Helms wrote: snip What is your actual threat model here? The simplest answer is to check gpg's rc after the encryption run. Before deleting original file, I must make certain encrypted version is in good shape so I can open it at a later date and obtain data. If it is broken, I'm in deep monkey muffins. That's the threat model. Can you please explain what you mean by check the gpg's rc after the encryption run? I'm unfamilar with the meaning of rc in this case. Thanks! Benny ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How to verify the file was successfully encrypted...
On Wed, 2006-07-12 at 05:14 -0500, Robert J. Hansen wrote: Benny Helms wrote: I'm looking for a way to gpg encrypt a file, test that the encryption was good and that the file can be extracted, and then to delete the original file. Forgive a silly question, but what's wrong with decrypting the file as a way of verifying the encryption worked? Sorry. I guess I should have given more details. I was just hoping the bare minimum info would be enough because somebody would say, Oh, that's easy! All you do is... I have a server with files that are created on a daily basis. Many files. I've reached a point where I want to have those files encrypted each night to prevent security breaches. My intent is to encrypt the file and delete the original. However, if I do that, and then go back a week later to obtain some data from that file, and it says, Whoa, dude! This gpg file seems to be hosed. I can't open it!, I'm absolutely screwed because our contract requires eternal data retention on some if this stuff. Losing data is unacceptable. But at the same time, having an encrypted version and an unencryted version is equally unacceptable. Basically, I'm looking for a *scripted* way to verify that the newly created gpg file is in good condition and I'll be able to open it at a later date if needed, BEFORE I delete the original file. Frankly, I'm surprised that's not a standard built-in function in gpg. Bzip2 will bzip a file, and only after successfully completing the task, it will automatically delete the original and leave only the bz2 version in place. That's the basic functionality I'm looking for. And I definitely want it to be able to do the job in a script because I don't have a life as it is, let alone sitting here manually decrypting file after file to test their usability in the wee hours of the morning when I should be home with my family. Make sense? If you've got a Perl script that's doing the encryptions, then have your Perl script do the verification step, too. I'm doing this with a plain old bash script. Basically... for file in list of files do gpg -r username -z 9 --encrypt $file pseudo code here; if the encryption went well, and the file is a \ good one, delete the original; otherwise email the the hosed file\ name so I can manually encrypt it when I get to work in the morning done Benny ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How to verify the file was successfully encrypted...
On Wed, 2006-07-12 at 13:23 -0400, Mark Hardman wrote: If you're using bash, can't you just script it like this... 1. encrypt to gpg 2. decrypt to text (or whatever it was originally) with altered file name (filename.test_decrypt) 3. do a diff between the original file and the newly decrypted file (versions of diff I've used work on binary files, too, but you might want to test this) 4. if there are no differences, delete original file and test decrypt file, leaving only the encrypted gpg file Would that get what you're looking for? Take care. mark Thank you for the reply, Mark. Yes, that would definitely do the trick. I guess I need to go to the FAQ to discover how to safely put a password into a scripted activity since each decryption requires a password. Check me on this, though. Is there any error checking in gnupg when creating a file? Is it safe to assume that if the job completes, the file is usable? This method you've described will definitely work, but it seems like a lot more CPU cycles and a lot more time involved in the script than should be necessary. Should I be submitting a wish to the developer list? Benny ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How to verify the file was successfully encrypted...
On Wed, Jul 12, 2006 at 11:57:21AM -0600, Benny Helms wrote: On Wed, 2006-07-12 at 13:23 -0400, Mark Hardman wrote: If you're using bash, can't you just script it like this... 1. encrypt to gpg 2. decrypt to text (or whatever it was originally) with altered file name (filename.test_decrypt) 3. do a diff between the original file and the newly decrypted file (versions of diff I've used work on binary files, too, but you might want to test this) 4. if there are no differences, delete original file and test decrypt file, leaving only the encrypted gpg file Would that get what you're looking for? Take care. mark Thank you for the reply, Mark. Yes, that would definitely do the trick. I guess I need to go to the FAQ to discover how to safely put a password into a scripted activity since each decryption requires a password. Check me on this, though. Is there any error checking in gnupg when creating a file? Is it safe to assume that if the job completes, the file is usable? This method you've described will definitely work, but it seems like a lot more CPU cycles and a lot more time involved in the script than should be necessary. Should I be submitting a wish to the developer list? There is no way to design such a self-check. This isn't a lack in GnuPG, but a design impossibility for any program. Think about it: a check mode would try and account for a bug in GnuPG and warn you that the file was not encrypted properly. However, if you're presuming a bug, then who says you should trust the check mode? If GnuPG completes successfully, that means it succeeded. If you want more assurance than that, the only way to do it is to decrypt the file and compare. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How to verify the file was successfully encrypted...
There is no way to design such a self-check. This isn't a lack in GnuPG, but a design impossibility for any program. Think about it: a check mode would try and account for a bug in GnuPG and warn you that the file was not encrypted properly. However, if you're presuming a bug, then who says you should trust the check mode? If GnuPG completes successfully, that means it succeeded. If you want more assurance than that, the only way to do it is to decrypt the file and compare. If you wanted to be really sure that GPG didn't mess something else, try decrypting it with some other OpenPGP implementation. If you're using perl, use Crypt::OpenPGP. (And Text::Diff to do your diff, and File::Slurp to read in the files for Text::Diff :) BTW, why are you encrypting these files anyway? If someone broke into your computer they could just steal the crypto key too. Regards, Jonathan Rockway ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How to verify the file was successfully encrypted...
Benny Helms wrote: snippage First off, I hope you've considered that gpg is doing what it's suppose to do and you're really trying to break it. If your encrypted files are corrupt at a later date, maybe you have another problem and don't *want* to make it just go away. IOW, be cautious that a solution doesn't weaken your security. ;) Thank you for the reply, Mark. Yes, that would definitely do the trick. I guess I need to go to the FAQ to discover how to safely put a password into a scripted activity since each decryption requires a password. Don't know if this will help or not, but I just did a quick test with GnuPG 1.4.4 and the --dry-run command line switch seem to work fine. Outputs to stdout rather than writing a file to disk. I changed a single bit in an encrypted (armored) file and tried it, and got a CRC error without entering any pass phrase at all. That's with -vv set in my options file, FWIW. And bleeding edge hash/cypher algorithms. Additionally, you can enter a pass phrase on the command line with the --passphrase switch. I tested it with both known good and known bad encrypted files, and if you enter a bogus/incorrect pass phrase for a known good file you get a bad passphrase error. With a known bad encrypted file you get the same CRC error. Neither one requires any user input, which is what you want. IOW, if you... gpg -d --dry-run --passphrase boguspassphrase bad-file.asc You get the CRC error, but if you... gpg -d --dry-run --passphrase boguspassphrase good-file.asc You get the bad passphrase. The down side is, both are exit code '2', so you'd have to grep for the verbal response to tell the difference. But that's not a major hurdle and it should be trivial to if $? grep return codes into something useful. The other down side is this doesn't explicitly tell you if you have a *good* encrypted file, it only picks out a couple errors. To do that you'd have to either be sitting there entering pass phrases, or include them in your script. Probably not where you'd want to go with this. :( -- Hand crafted on 12 July, 2006 at 14:36:55 EDT Outside of a dog, a book is a man's best friend. Inside of a dog, it's too dark to read. -Groucho Marx signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How to verify the file was successfully encrypted...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jonathan Rockway wrote: BTW, why are you encrypting these files anyway? If someone broke into your computer they could just steal the crypto key too. True, unless the private key isn't kept on the same machine. Which also would negate the ability to decrypt the file on the server to verify that the encryption was successful. :) - -- ToddOpenPGP - KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp == Those who have been intoxicated with power... can never willingly abandon it. -- Edmund Burke -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) Comment: When crypto is outlawed bayl bhgynjf jvyy unir cevinpl. iG0EARECAC0FAkS1SQQmGGh0dHA6Ly93d3cucG9ib3guY29tL350bXovcGdwL3Rt ei5hc2MACgkQuv+09NZUB1otkgCgnP7KTsByYiIOddJmAG7HNyB+JA4AniX2DvJw d0uPX2K0oA+DO8iZ5K4x =YnXM -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How to verify the file was successfully encrypted...
On Wed, 2006-07-12 at 13:11 -0500, Jonathan Rockway wrote: snip BTW, why are you encrypting these files anyway? If someone broke into your computer they could just steal the crypto key too. Excellent question! Truth be told, as soon as they are encrypted, they're being moved to another server in another location, and then are being burned to CD and moved to a safety deposit box. Benny ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How to verify the file was successfully encrypted...
On Wed, 2006-07-12 at 15:13 -0400, Jeffrey F. Bloss wrote: Benny Helms wrote: snippage Don't know if this will help or not, but I just did a quick test with GnuPG 1.4.4 and the --dry-run command line switch seem to work fine. Outputs to stdout rather than writing a file to disk. I changed a single bit in an encrypted (armored) file and tried it, and got a CRC error without entering any pass phrase at all. That's with -vv set in my options file, FWIW. And bleeding edge hash/cypher algorithms. Additionally, you can enter a pass phrase on the command line with the --passphrase switch. I tested it with both known good and known bad encrypted files, and if you enter a bogus/incorrect pass phrase for a known good file you get a bad passphrase error. With a known bad encrypted file you get the same CRC error. Neither one requires any user input, which is what you want. IOW, if you... gpg -d --dry-run --passphrase boguspassphrase bad-file.asc You get the CRC error, but if you... gpg -d --dry-run --passphrase boguspassphrase good-file.asc You get the bad passphrase. The down side is, both are exit code '2', so you'd have to grep for the verbal response to tell the difference. But that's not a major hurdle and it should be trivial to if $? grep return codes into something useful. The other down side is this doesn't explicitly tell you if you have a *good* encrypted file, it only picks out a couple errors. To do that you'd have to either be sitting there entering pass phrases, or include them in your script. Probably not where you'd want to go with this. :( Thanks Jeffrey. Excellent suggestion. This worked well with a .asc file, but not with a .gpg file. Does anyone on the list have a preference for .asc vs .gpg output? Pros? Cons? The size is almost twice as big as a .gpg at this time, which is a definite con. But there are probably some serious pros as well. Input? Benny ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How to verify the file was successfully encrypted...
This might be a hard one. When you encrypt to a public key, there is no way gpg can decrypt it, to verify that it can be decrypted, unless it can unlock the private key with your password. The only way i see, is that gpg would have to encrypt 2 times and compare the results. But then again, the same error might happen twice. Does this make any sense? i don't know, this was just what im thinking. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How to verify the file was successfully encrypted...
Benny Helms wrote: On Wed, 2006-07-12 at 15:13 -0400, Jeffrey F. Bloss wrote: Benny Helms wrote: snippage Don't know if this will help or not, but I just did a quick test with GnuPG 1.4.4 and the --dry-run command line switch seem to work fine. Outputs to stdout rather than writing a file to disk. I changed a single bit in an encrypted (armored) file and tried it, and got a CRC error without entering any pass phrase at all. That's with -vv set in my options file, FWIW. And bleeding edge hash/cypher algorithms. Additionally, you can enter a pass phrase on the command line with the --passphrase switch. I tested it with both known good and known bad encrypted files, and if you enter a bogus/incorrect pass phrase for a known good file you get a bad passphrase error. With a known bad encrypted file you get the same CRC error. Neither one requires any user input, which is what you want. IOW, if you... gpg -d --dry-run --passphrase boguspassphrase bad-file.asc You get the CRC error, but if you... gpg -d --dry-run --passphrase boguspassphrase good-file.asc You get the bad passphrase. The down side is, both are exit code '2', so you'd have to grep for the verbal response to tell the difference. But that's not a major hurdle and it should be trivial to if $? grep return codes into something useful. The other down side is this doesn't explicitly tell you if you have a *good* encrypted file, it only picks out a couple errors. To do that you'd have to either be sitting there entering pass phrases, or include them in your script. Probably not where you'd want to go with this. :( Thanks Jeffrey. Excellent suggestion. This worked well with a .asc file, but not with a .gpg file. Does anyone on the list have a preference for .asc vs .gpg output? Pros? Cons? The size is almost twice as big as a .gpg at this time, which is a definite con. But there are probably some serious pros as well. Input? .asc files are immune to mangling of CR/LF characters which may be present in binary data, which often happens when you transfer via email or FTP. -- Alphax Death to all fanatics! Down with categorical imperative! OpenPGP key: http://tinyurl.com/lvq4g signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
