From jbruni at mac.com Fri Jun 1 20:01:02 2007 From: jbruni at mac.com (Joseph Oreste Bruni) Date: Fri, 1 Jun 2007 11:01:02 -0700 Subject: setting expiration dates Message-ID: <83C02188-51D6-44E4-9F5E-59CC25125396@mac.com> When creating a new subkey, I'm given the option of setting an expiration. The prompt allows me to specify a duration for the new subkey. Please specify how long the key should be valid. 0 = key does not expire = key expires in n days w = key expires in n weeks m = key expires in n months y = key expires in n years Key is valid for? (0) Is it possible to set an explicit date (e.g. 31 Dec) rather than a duration? I suppose I could compute the number of days, but that's annoying. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2508 bytes Desc: not available Url : /pipermail/attachments/20070601/7ed2fada/attachment.bin From dshaw at jabberwocky.com Fri Jun 1 20:31:26 2007 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 1 Jun 2007 14:31:26 -0400 Subject: setting expiration dates In-Reply-To: <83C02188-51D6-44E4-9F5E-59CC25125396@mac.com> References: <83C02188-51D6-44E4-9F5E-59CC25125396@mac.com> Message-ID: <20070601183126.GC8685@jabberwocky.com> On Fri, Jun 01, 2007 at 11:01:02AM -0700, Joseph Oreste Bruni wrote: > When creating a new subkey, I'm given the option of setting an expiration. > The prompt allows me to specify a duration for the new subkey. > > Please specify how long the key should be valid. > 0 = key does not expire > = key expires in n days > w = key expires in n weeks > m = key expires in n months > y = key expires in n years > Key is valid for? (0) > > Is it possible to set an explicit date (e.g. 31 Dec) rather than a > duration? I suppose I could compute the number of days, but that's > annoying. Yes, it is possible. At the prompt, enter the date in YYYY-MM-DD format. David From jbruni at mac.com Fri Jun 1 22:01:34 2007 From: jbruni at mac.com (Joseph Oreste Bruni) Date: Fri, 1 Jun 2007 13:01:34 -0700 Subject: setting expiration dates In-Reply-To: <20070601183126.GC8685@jabberwocky.com> References: <83C02188-51D6-44E4-9F5E-59CC25125396@mac.com> <20070601183126.GC8685@jabberwocky.com> Message-ID: On Jun 1, 2007, at 11:31 AM, David Shaw wrote: > On Fri, Jun 01, 2007 at 11:01:02AM -0700, Joseph Oreste Bruni wrote: >> When creating a new subkey, I'm given the option of setting an >> expiration. >> The prompt allows me to specify a duration for the new subkey. >> >> Please specify how long the key should be valid. >> 0 = key does not expire >> = key expires in n days >> w = key expires in n weeks >> m = key expires in n months >> y = key expires in n years >> Key is valid for? (0) >> >> Is it possible to set an explicit date (e.g. 31 Dec) rather than a >> duration? I suppose I could compute the number of days, but that's >> annoying. > > Yes, it is possible. At the prompt, enter the date in YYYY-MM-DD > format. > > David Awesome. Would you consider updating the prompt reflecting that capability? Thanks for the tip. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2508 bytes Desc: not available Url : /pipermail/attachments/20070601/f331ff29/attachment-0001.bin From jbruni at mac.com Sat Jun 2 03:16:09 2007 From: jbruni at mac.com (Joseph Oreste Bruni) Date: Fri, 1 Jun 2007 18:16:09 -0700 Subject: setting expiration dates In-Reply-To: <20070601183126.GC8685@jabberwocky.com> References: <83C02188-51D6-44E4-9F5E-59CC25125396@mac.com> <20070601183126.GC8685@jabberwocky.com> Message-ID: On Jun 1, 2007, at 11:31 AM, David Shaw wrote: > On Fri, Jun 01, 2007 at 11:01:02AM -0700, Joseph Oreste Bruni wrote: >> When creating a new subkey, I'm given the option of setting an >> expiration. >> The prompt allows me to specify a duration for the new subkey. >> >> Please specify how long the key should be valid. >> 0 = key does not expire >> = key expires in n days >> w = key expires in n weeks >> m = key expires in n months >> y = key expires in n years >> Key is valid for? (0) >> >> Is it possible to set an explicit date (e.g. 31 Dec) rather than a >> duration? I suppose I could compute the number of days, but that's >> annoying. > > Yes, it is possible. At the prompt, enter the date in YYYY-MM-DD > format. > I have another question about key expirations. Suppose I have a key that was originally created without an expiration, and I distribute that key. Later, I add an expiration date to the original key. Does the new expiration have any effect if someone has my key without the expiration? In other words, is the expiration date considered a discretionary control or a mandatory control? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2508 bytes Desc: not available Url : /pipermail/attachments/20070601/7040fe23/attachment.bin From dshaw at jabberwocky.com Sat Jun 2 04:20:04 2007 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 1 Jun 2007 22:20:04 -0400 Subject: setting expiration dates In-Reply-To: References: <83C02188-51D6-44E4-9F5E-59CC25125396@mac.com> <20070601183126.GC8685@jabberwocky.com> Message-ID: <20070602022004.GA10179@jabberwocky.com> On Fri, Jun 01, 2007 at 06:16:09PM -0700, Joseph Oreste Bruni wrote: > I have another question about key expirations. Suppose I have a key > that was originally created without an expiration, and I distribute > that key. Later, I add an expiration date to the original key. Does > the new expiration have any effect if someone has my key without the > expiration? In other words, is the expiration date considered a > discretionary control or a mandatory control? The expiration does not apply to someone who has the key without the expiration. It's not really a question of mandatory or discretionary, but just an out-of-date key. If and when they update their copy of your key, they will get the expiration. David From henry.bremridge at xobie.com Sat Jun 2 17:42:33 2007 From: henry.bremridge at xobie.com (Henry Bremridge) Date: Sat, 2 Jun 2007 16:42:33 +0100 Subject: SmartCards and Debian Lenny Message-ID: <200706021544.l52Fi2fZ027318@rs26.luxsci.com> Last night my system was updated cron-apt: Setting up libccid (1.3.0-1) ... cron-apt: Installing new version of config file /etc/reader.conf.d/libccidtwin ... cron-apt: Installing new version of config file /etc/libccid_Info.plist ... cron-apt: Installing new version of config file /etc/udev/pcscd_ccid.rules ... cron-apt: Restarting PCSC Lite resource manager: pcscd. Since then on trying to access my smart card (SCR335) I get the following $ gpg --card-status winscard_msg.c:97:SHMClientSetupSession() Error: connect to client socket: No such file or directory gpg: pcsc_establish_context failed: no service (0x8010001d) gpg: card reader not available gpg: OpenPGP card not available: general error I have removed and added all the files specified in http://www.fsfe.org/en/card/howto/card_reader_howto_udev and in particular - libpcsclite-dev - libpcsclite1 - pcscd Can anyone suggest any solutions? -- Henry Sat Jun 2 16:42:19 BST 2007 From henry.bremridge at xobie.com Sat Jun 2 19:49:12 2007 From: henry.bremridge at xobie.com (Henry Bremridge) Date: Sat, 2 Jun 2007 18:49:12 +0100 Subject: SmartCards and Debian Lenny In-Reply-To: <200706021544.l52Fi2fZ027318@rs26.luxsci.com> References: <200706021544.l52Fi2fZ027318@rs26.luxsci.com> Message-ID: <200706021750.l52Ho2Tr000395@rs26.luxsci.com> On Sat, Jun 02, 2007 at 04:42:33PM +0100, Henry Bremridge wrote: Many apologies: the solution as highlighted in my syslog was to delete /var/run/pcscd.pid -- Henry Sat Jun 2 18:48:49 BST 2007 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: Digital signature Url : /pipermail/attachments/20070602/7e421a5b/attachment.pgp From jharris at widomaker.com Sun Jun 3 23:25:43 2007 From: jharris at widomaker.com (Jason Harris) Date: Sun, 3 Jun 2007 17:25:43 -0400 Subject: new (2007-05-27) keyanalyze results (+sigcheck) Message-ID: <20070603212543.GA4324@wilma.widomaker.com> New keyanalyze results are available at: http://keyserver.kjsl.com/~jharris/ka/2007-05-27/ Signatures are now being checked using keyanalyze+sigcheck: http://dtype.org/~aaronl/ Earlier reports are also available, for comparison: http://keyserver.kjsl.com/~jharris/ka/ Even earlier monthly reports are at: http://dtype.org/keyanalyze/ SHA-1 hashes and sizes for all the "permanent" files: 6484659effbda4ce7a1da75569a09c1d5d4bce92 14829318 preprocess.keys 2e93f9a98200260202983ac16ce0613ea772010e 8623499 othersets.txt e4956d5b215f4d9dd77f0f972f5abcff1265e310 3552252 msd-sorted.txt f38aeff391fc2b8ed07f6d62620992fbea1fe9fb 2278 keyring_stats f37b6a7973cec8e39a13b2d8ae7a6f79f1af64bc 1397141 msd-sorted.txt.bz2 15c97abcbcd6b13e82a8d95330d0a5d08a303b7d 26 other.txt f742c2f21896b4e07d9fede9e1c4ded8fe3cd88b 1873083 othersets.txt.bz2 92568db2c700760127a373ed2fc98adfeb7edbf1 6047516 preprocess.keys.bz2 9ba4d9b29ecf8c424fbd8c054621c70171e2d1d0 15205 status.txt 6bbb0681e9d48b08777635234ab15b83207b5ec8 194432 top1000table.html ca90144b3158b5789011e0741687286c10c2921e 29612 top1000table.html.gz 543753bdb2fee73548f6b8e3a2bc993159894621 9763 top50table.html 846209e98a82e5003577bdea5643041fc9219f09 2529 D3/D39DA0E3 -- Jason Harris | NIC: JH329, PGP: This _is_ PGP-signed, isn't it? jharris at widomaker.com _|_ web: http://keyserver.kjsl.com/~jharris/ Got photons? (TM), (C) 2004 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 313 bytes Desc: not available Url : /pipermail/attachments/20070603/94560957/attachment.pgp From sunblaster5 at gmail.com Mon Jun 4 00:40:55 2007 From: sunblaster5 at gmail.com (rocko) Date: Sun, 03 Jun 2007 15:40:55 -0700 Subject: Can't generate new keys Message-ID: <1180910455.5793.3.camel@starshatter> When i try to make a new key i get the following error: gpg: no writable public keyring found: eof Key generation failed: eof I'm using Ubuntu 7.04 and logged on as regular user. I've generated a key before but i used: sudo gpg --gen-key that works fine. I just can't seem to do it as regular user. Do i have to be root to gen a new key pair? From tmz at pobox.com Mon Jun 4 01:36:55 2007 From: tmz at pobox.com (Todd Zullinger) Date: Sun, 3 Jun 2007 19:36:55 -0400 Subject: Can't generate new keys In-Reply-To: <1180910455.5793.3.camel@starshatter> References: <1180910455.5793.3.camel@starshatter> Message-ID: <20070603233655.GE5027@psilocybe.teonanacatl.org> rocko wrote: > When i try to make a new key i get the following error: > gpg: no writable public keyring found: eof > Key generation failed: eof > I'm using Ubuntu 7.04 and logged on as regular user. > I've generated a key before but i used: sudo gpg --gen-key > that works fine. > I just can't seem to do it as regular user. I'd guess that the ownership/permissions on your ~/.gnupg dir and/or keyring files are not correct. Check that you own the directory and the files in ~/.gnupg using "ls -la ~/.gnupg" (as a regular user). It should look something like this: $ ls -la .gnupg/ total 88K drwx------ 2 user user 4.0K Apr 3 15:18 . drwx------ 43 user user 4.0K Jun 3 20:34 .. -rw------- 1 user user 9.0K Dec 8 15:51 gpg.conf -rw------- 1 user user 11K Dec 8 16:02 pubring.gpg -rw------- 1 user user 9.7K Dec 8 15:56 pubring.gpg~ -rw------- 1 user user 600 Dec 8 15:57 random_seed -rw------- 1 user user 1.3K Dec 8 15:52 secring.gpg -rw------- 1 user user 1.3K Dec 8 15:56 trustdb.gpg -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Subtlety is the art of saying what you think and getting out of the way before it is understood. -- Anonymous -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available Url : /pipermail/attachments/20070603/62081cc4/attachment.pgp From breen.mullins at gmail.com Mon Jun 4 02:23:16 2007 From: breen.mullins at gmail.com (Breen Mullins) Date: Sun, 3 Jun 2007 17:23:16 -0700 Subject: Can't generate new keys In-Reply-To: <1180910455.5793.3.camel@starshatter> References: <1180910455.5793.3.camel@starshatter> Message-ID: <20070604002316.GB29299@Breens-Computer.local> * rocko [2007-06-03 15:40 -0700]: >I just can't seem to do it as regular user. >Do i have to be root to gen a new key pair? You shouldn't have to be. What are the permissions on ~/.gnupg ? Breen -- Breen Mullins Menlo Park, California From tmz at pobox.com Mon Jun 4 03:00:35 2007 From: tmz at pobox.com (Todd Zullinger) Date: Sun, 3 Jun 2007 21:00:35 -0400 Subject: Can't generate new keys In-Reply-To: <1180919328.5793.6.camel@starshatter> References: <1180910455.5793.3.camel@starshatter> <20070603233655.GE5027@psilocybe.teonanacatl.org> <1180919328.5793.6.camel@starshatter> Message-ID: <20070604010035.GF5027@psilocybe.teonanacatl.org> rocko wrote: > Your right it seems my permissions are wrong: > acidblue at starshatter:~$ ls -la .gnupg/ > total 40 > drwx------ 2 acidblue acidblue 4096 2007-06-03 15:42 . > drwxr-xr-x 72 acidblue acidblue 4096 2007-06-03 17:59 .. > -rw------- 1 acidblue acidblue 28 2007-05-19 11:47 gpg.conf > -rw------- 1 root root 4203 2007-05-19 11:54 pubring.gpg > -rw------- 1 root root 4203 2007-05-19 11:54 pubring.gpg~ > -rw------- 1 acidblue acidblue 600 2007-06-03 15:36 random_seed > -rw------- 1 root root 1313 2007-05-19 11:54 secring.gpg > -rw------- 1 root root 1280 2007-05-19 11:54 trustdb.gpg > > How do i change this? > Can i simply 'sudo chmod' the files > or do i have to reinstall gpg? chown is what you want. Something like this should do the trick: $ sudo chown -R acidblue. ~/.gnupg -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ If the world didn't suck, we'd all fall off. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available Url : /pipermail/attachments/20070603/83dafe82/attachment-0001.pgp From rjh at sixdemonbag.org Mon Jun 4 04:12:50 2007 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 3 Jun 2007 22:12:50 -0400 Subject: Can't generate new keys In-Reply-To: <20070603233655.GE5027@psilocybe.teonanacatl.org> References: <1180910455.5793.3.camel@starshatter> <20070603233655.GE5027@psilocybe.teonanacatl.org> Message-ID: <6CACFA41-9104-45AD-861B-F1DB50CA21FC@sixdemonbag.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > I'd guess that the ownership/permissions on your ~/.gnupg dir and/or > keyring files are not correct. Check that you own the directory and Additionally, the command 'chown -R my_user_name:my_user_name .gnupg' can do magic to fix these problems. - -- Robert J. Hansen "Most people are never thought about after they're gone. 'I wonder where Rob got the plutonium?' is better than most get." -- Phil Munson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iFYEAREIAAYFAkZjdSIACgkQf2XByo0Cu7MNsQDbBigv89TAx/EOOzU3T1I43Cw9 0sSNO6NXZdTwpQDeLbT/1dK/D5+YJ8Eck0U1bp1Jcw/odNOWfyB804kBHAQBAQgA BgUCRmN1IgAKCRC3APSC/q+BCesRB/4+a/B1Zr+B8rpDylI5EaMBhgg6s1HrIHoc pxiHx4Qo47Ef2JL/tNOT8HUCCwYqCgvRWeL5BpmivvWMcSRKbRnSQR/xeFk0hDK3 p1o/UpCW6HD5DKpm8AR0EPfdnLV7UcD6DOE7akR6K3Oc7DDaX02pKzZ8z/hYN+WW XEvE/e1M1C9JKmmJfE6ao+FLrwHDnKvG0L/meUPXtIUFsa7tIb2m7C9gbINY6k/j ieRYScqN0NDXSUMZiCzzPSrCh/nBxLxFtnw0EPDKt9S324NlTbbZDV4LyzVElFFQ MnZUung9ciGmVnoakiNfDSEEErlByAZsJ9v8xCxKZrL5qNpAWhBP =dpXF -----END PGP SIGNATURE----- From sunblaster5 at gmail.com Mon Jun 4 05:49:20 2007 From: sunblaster5 at gmail.com (rocko) Date: Sun, 03 Jun 2007 20:49:20 -0700 Subject: Can't generate new keys In-Reply-To: <20070604010035.GF5027@psilocybe.teonanacatl.org> References: <1180910455.5793.3.camel@starshatter> <20070603233655.GE5027@psilocybe.teonanacatl.org> <1180919328.5793.6.camel@starshatter> <20070604010035.GF5027@psilocybe.teonanacatl.org> Message-ID: <1180928960.27953.1.camel@starshatter> 'chown -R user' worked! thanks everyone On Sun, 2007-06-03 at 21:00 -0400, Todd Zullinger wrote: > rocko wrote: > > Your right it seems my permissions are wrong: > > acidblue at starshatter:~$ ls -la .gnupg/ > > total 40 > > drwx------ 2 acidblue acidblue 4096 2007-06-03 15:42 . > > drwxr-xr-x 72 acidblue acidblue 4096 2007-06-03 17:59 .. > > -rw------- 1 acidblue acidblue 28 2007-05-19 11:47 gpg.conf > > -rw------- 1 root root 4203 2007-05-19 11:54 pubring.gpg > > -rw------- 1 root root 4203 2007-05-19 11:54 pubring.gpg~ > > -rw------- 1 acidblue acidblue 600 2007-06-03 15:36 random_seed > > -rw------- 1 root root 1313 2007-05-19 11:54 secring.gpg > > -rw------- 1 root root 1280 2007-05-19 11:54 trustdb.gpg > > > > How do i change this? > > Can i simply 'sudo chmod' the files > > or do i have to reinstall gpg? > > chown is what you want. Something like this should do the trick: > > $ sudo chown -R acidblue. ~/.gnupg > From daneshwar.mishra at wipro.com Mon Jun 4 08:49:06 2007 From: daneshwar.mishra at wipro.com (daneshwar.mishra at wipro.com) Date: Mon, 4 Jun 2007 12:19:06 +0530 Subject: PLEASE UNSUSCRIBE ME In-Reply-To: Message-ID: Thanks & Regards, Danesh Mishra -----Original Message----- From: gnupg-users-bounces at gnupg.org [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of daneshwar.mishra at wipro.com Sent: Friday, May 18, 2007 2:52 PM To: vesely at tana.it; gnupg-users at gnupg.org Subject: RE: Secure text editor? Hi all, We are planning to use GPG tool in our application which is JAVA Based. Could you please let me know that, how can i use GPG encryption and decryption using JAVA. below is criteria on which i have to evaluate GPG Evaluate GPG tool -- i.Invoking this tool from Java. If this is not supported some other tool ii.Storage of keys/certificated in keystore iii.Using the keys/certificates for encryption & decryption. Note: Encryption and decryption will be of a given file name at any location. Means I gon't want to pass input as string but a file name. I have already gone through GNUPG.java file which does e/d of passed string. I am looking for some API which I can directly use. iv.Encrypt and decrypt for compressed as well as other files like text, pdf, excel etc. any help will be appritiable. regards, Danesh -----Original Message----- From: gnupg-users-bounces at gnupg.org [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of Alessandro Vesely Sent: Friday, May 18, 2007 12:58 PM To: gnupg Subject: Re: Secure text editor? Ryan Malayter wrote: > On 5/17/07, Alessandro Vesely wrote: >> Not quite. That may happen as an undocumented side effect on some (or >> all) OS versions, and is not what the function is meant to do. > > The documentation clearly states: > "These pages are guaranteed not to be written to the pagefile while > they are locked." Ooops, I hadn't noticed that. Yes, then VirtualAlloc and VirtualLock can be used to avoid leaving traces of sensitive data on the swap file in the way you described (i.e. lock before fill and sweep before unlock.) I still think that's not the kind of task that the function has been designed for. The authorization constrain you mentioned and other possible side effect tend to make it unpractical for naive usage. However, a background console app that allocates a few memory pages for storing sensitive data (e.g. a gpg agent?) should use it to increase data security. _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com From wk at gnupg.org Mon Jun 4 10:42:19 2007 From: wk at gnupg.org (Werner Koch) Date: Mon, 04 Jun 2007 10:42:19 +0200 Subject: setting expiration dates In-Reply-To: (Joseph Oreste Bruni's message of "Fri, 1 Jun 2007 13:01:34 -0700") References: <83C02188-51D6-44E4-9F5E-59CC25125396@mac.com> <20070601183126.GC8685@jabberwocky.com> Message-ID: <87hcpoxg9g.fsf@wheatstone.g10code.de> On Fri, 1 Jun 2007 22:01, jbruni at mac.com said: > Awesome. Would you consider updating the prompt reflecting that > capability? Enter a question mark at the prompt to see a help text. Shalom-Salam, Werner From shavital at mac.com Mon Jun 4 11:19:48 2007 From: shavital at mac.com (Charly Avital) Date: Mon, 04 Jun 2007 12:19:48 +0300 Subject: PLEASE UNSUSCRIBE ME In-Reply-To: References: Message-ID: <4663D934.1030902@mac.com> daneshwar.mishra at wipro.com wrote the following on 6/4/07 9:49 AM: > > > > Thanks & Regards, > > Danesh Mishra To unsubscribe, please open Scroll down to: To unsubscribe from Gnupg-users, get a password reminder, or change your subscription options enter your subscription email address: If you leave the field blank, you will be prompted for your email address Regards, From hs2412 at gmail.com Mon Jun 4 17:26:23 2007 From: hs2412 at gmail.com (hs2412 at gmail.com) Date: Mon, 04 Jun 2007 20:56:23 +0530 Subject: Question about check command Message-ID: <1180970783.12442.1193338545@webmail.messagingengine.com> Hi All When I run the check command in edit-key mode, it shows me something like sig! or sig!1 or sig!3 What does this mean? Regards Hardeep Hardeep Singh h.singh at seeingwithc.org OpenPGP KeyID: 0x39B8B23B Key: http://tinyurl.com/yghqcg From pubmb01 at skynet.be Mon Jun 4 18:09:29 2007 From: pubmb01 at skynet.be (Bruno Costacurta) Date: Mon, 4 Jun 2007 18:09:29 +0200 Subject: decrypt and secret key location Message-ID: <200706041809.29624.pubmb01@skynet.be> Hello, I received an encrypted file called 'test.asc' (recipient is correct, hereafter it is truncated) but trying to decrypt it I have following error : gpg --decrypt test.asc gpg: encrypted with 2048-bit ELG-E key, ID 0CC897B5, created 2006-06-11 "Bruno Costacurta " gpg: decryption failed: secret key not available Is it only key location? If so, how / where can I indicate my private key location ? If not, what type of problem ? Many thanks for help, Bruno Costacurta -- PGP key ID: 0x2e604d51 Key : http://www.costacurta.org/keys/bruno_costacurta_pgp_key.html Key fingerprint = 713F 7956 9441 7DEF 58ED 1951 7E07 569B 2E60 4D51 -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20070604/d4a20b78/attachment.pgp From michael at vorlon.ping.de Mon Jun 4 19:00:05 2007 From: michael at vorlon.ping.de (Michael Bienia) Date: Mon, 4 Jun 2007 19:00:05 +0200 Subject: Problem decrypting a mail with an OpenPGP card Message-ID: <20070604170005.GA8633@vorlon.ping.de> Hello, I've got three mails (from the same person) with my signed key (one for each uid). I can decrypt two of the three mails but not the third: $ gpg broken-gpg.mail gpg: sending command `SCD PKDECRYPT' to agent failed: ec=6.131 gpg: encrypted with 1024-bit RSA key, ID AF58F2B4, created 2006-03-13 "Michael Bienia " gpg: public key decryption failed: general error gpg: decryption failed: secret key not available $ gpg2 broken-gpg.mail gpg: encrypted with 1024-bit RSA key, ID AF58F2B4, created 2006-03-13 "Michael Bienia " gpg: public key decryption failed: Conditions of use not satisfied gpg: decryption failed: No secret key gpg is version 1.4.6, gpg2 is version 2.0.4 and I'm running Ubuntu feisty. I'm using the gpg-agent but I've also tried without the agent but it failed also. What could be the problem? Here is the output for one of the working mails: $ gpg2 -vv good-gpg.mail gpg: armor: BEGIN PGP MESSAGE Version: GnuPG v1.4.6 (GNU/Linux) :pubkey enc packet: version 3, algo 1, keyid FB50DDA4AF58F2B4 data: [1024 bits] gpg: armor header: gpg: public key is AF58F2B4 gpg: using subkey AF58F2B4 instead of primary key 968BD587 gpg: public key encrypted data: good DEK :encrypted data packet: length: unknown mdc_method: 2 gpg: using subkey AF58F2B4 instead of primary key 968BD587 gpg: encrypted with 1024-bit RSA key, ID AF58F2B4, created 2006-03-13 "Michael Bienia " gpg: AES256 encrypted data :compressed packet: algo=3 :literal data packet: mode b (62), created 1180971809, name="", raw data: unknown length gpg: original file name='' gpg: good-gpg.mail: unknown suffix and here for the non-working mail: $ gpg2 -vv broken-gpg.mail gpg: armor: BEGIN PGP MESSAGE Version: GnuPG v1.4.6 (GNU/Linux) :pubkey enc packet: version 3, algo 1, keyid FB50DDA4AF58F2B4 data: [1013 bits] gpg: armor header: gpg: public key is AF58F2B4 gpg: using subkey AF58F2B4 instead of primary key 968BD587 :encrypted data packet: length: unknown mdc_method: 2 gpg: using subkey AF58F2B4 instead of primary key 968BD587 gpg: encrypted with 1024-bit RSA key, ID AF58F2B4, created 2006-03-13 "Michael Bienia " gpg: public key decryption failed: Conditions of use not satisfied gpg: decryption failed: No secret key Michael From bahamut at digital-signal.net Mon Jun 4 21:38:30 2007 From: bahamut at digital-signal.net (Andrew Berg) Date: Mon, 04 Jun 2007 14:38:30 -0500 Subject: [Fwd: Re: decrypt and secret key location] Message-ID: <46646A36.4050402@digital-signal.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Bruno Costacurta wrote: > Hello, I received an encrypted file called 'test.asc' (recipient is > correct, hereafter it is truncated) but trying to decrypt it I have > following error : > > gpg --decrypt test.asc gpg: encrypted with 2048-bit ELG-E key, ID > 0CC897B5, created 2006-06-11 "Bruno Costacurta > " gpg: decryption failed: secret key not > available > > Is it only key location? If so, how / where can I indicate my > private key location ? If not, what type of problem ? Your secret key should be in ~./gnupg/secring.gpg. If you ran GPG from the command line and don't have homedir explicitly overwritten, that's where it is created when you generate a new key pair. If you run gpg --help, what does it say is the home directory? If you run gpg -K, are any keys listed? If you run gpg --list-keys, is your public key listed? [forgot to change the address again :p] - -- Windows NT 5.1.2600.2180 | Thunderbird 2.0.0.0 | Enigmail 0.95.0 | GPG 1.4.7 Key ID: 0x60A78FCB - available on major keyservers and upon request Fingerprint: 4A84 CAE2 A0D3 2AEB 71F6 07FD F88E 0340 60A7 8FCB -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEVAwUBRmRqNviOA0Bgp4/LAQN2kwf+PyPszDM1wFNhn+GrPB4fWTUn8FIlFEQH nrtjbSoUOoKLbWzkrWqJqit7XZ2W6xfJMhZYSeaunLGyRPQ9bm1RgJlgUCfuR8kM I1qwT5bCmDY6QcVuM0aw869DyJQJT6HdUI7fiBQeIOmPpujBJeT5+oi/jihaA34P +j5ZLitgHLhycyQLy5Ryw1iaxmwMFLNZRGlwsLATHgO2j8BFxYQYuiXbV1Hcx5Cc VJ4bGXrD/Frd7syMWGN3iG5MsRHnnGDfzhwJ6w0z6XQyg4rG4ClKas2gOQHnc8GK lzjSYtDu/e3KtNlEq0jQxgmXTWvuuY6H5r+h5j9nt+1RdY4OCxYi8Q== =2Yn8 -----END PGP SIGNATURE----- From pubmb01 at skynet.be Mon Jun 4 22:41:06 2007 From: pubmb01 at skynet.be (Bruno Costacurta) Date: Mon, 4 Jun 2007 22:41:06 +0200 Subject: [Fwd: Re: decrypt and secret key location] In-Reply-To: <46646A36.4050402@digital-signal.net> References: <46646A36.4050402@digital-signal.net> Message-ID: <200706042241.06517.pubmb01@skynet.be> On Monday 04 June 2007 21:38, Andrew Berg wrote: > Bruno Costacurta wrote: > > Hello, I received an encrypted file called 'test.asc' (recipient is > > correct, hereafter it is truncated) but trying to decrypt it I have > > following error : > > > > gpg --decrypt test.asc gpg: encrypted with 2048-bit ELG-E key, ID > > 0CC897B5, created 2006-06-11 "Bruno Costacurta > > " gpg: decryption failed: secret key not > > available > > > > Is it only key location? If so, how / where can I indicate my > > private key location ? If not, what type of problem ? > > Your secret key should be in ~./gnupg/secring.gpg. If you ran GPG from > the command line and don't have homedir explicitly overwritten, that's > where it is created when you generate a new key pair. > > If you run gpg --help, what does it say is the home directory? > If you run gpg -K, are any keys listed? > If you run gpg --list-keys, is your public key listed? > > > Thanks for your attention. However my GPG setup looks fine: /home/bruno: gpg -K /home/bruno/.gnupg/secring.gpg ------------------------------ sec 1024D/2E604D51 2006-06-11 uid Bruno Costacurta uid Bruno Costacurta /home/bruno: gpg --list-keys 0x2e604d51 pub 1024D/2E604D51 2006-06-11 uid Bruno Costacurta uid Bruno Costacurta uid Bruno Costacurta uid Bruno Costacurta sub 2048g/0CC897B5 2006-06-11 Thanks for any clue. Bye, Bruno Costacurta From jbruni at mac.com Tue Jun 5 00:17:21 2007 From: jbruni at mac.com (Joseph Oreste Bruni) Date: Mon, 4 Jun 2007 15:17:21 -0700 Subject: setting expiration dates In-Reply-To: <87hcpoxg9g.fsf@wheatstone.g10code.de> References: <83C02188-51D6-44E4-9F5E-59CC25125396@mac.com> <20070601183126.GC8685@jabberwocky.com> <87hcpoxg9g.fsf@wheatstone.g10code.de> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Jun 4, 2007, at 1:42 AM, Werner Koch wrote: > On Fri, 1 Jun 2007 22:01, jbruni at mac.com said: > >> Awesome. Would you consider updating the prompt reflecting that >> capability? > > Enter a question mark at the prompt to see a help text. This is interesting: After changing my encryption subkey's expiration by a few days (from 2008-02-07 to 2008-01-01), I tried to upload the updated key to the PGP Global Directory (http://keyserver.pgp.com). It complained that my key had expired, but it hasn't. Submitting the key to the SKS key servers (hkp://pool.sks-keyservers.net) didn't have a problem. My key ID is CD5518C7 if you want to look at it. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQEVAwUBRmSPcVGV1jrNVRjHAQhiUQf/dZ8K+X/7XnmOooDRfiDaEzTixUk5PQMb 23omFxrzwF7spckQILuxapGPh55RAKL9NlCXfRIRR+HJOLbTNjLeEfPDIgU3IWHr x3jd4lC7lqbcbNRHisF1K4bF1GUzSg0cOHRI8oqgx6OWa3pIGhR0VGvuF7AJq/XY rXvkwbL+U4BBiIHwR92dZmUpATvAs8twBdRv7/0BP2pZBhCubL19kIuUiMJPJMfK CcnD1VVSUMOce2PhTMzhBCZBb33rkw73aokTFxoJulA29ZST/aR2wcC5od8GbTJO 05RVrPDko2DOE8gdL6WCoWkAfFpbRRbhPGYDOmkn7SHTbsvFe4wFqg== =/BQI -----END PGP SIGNATURE----- From hhhobbit at securemecca.net Tue Jun 5 02:59:24 2007 From: hhhobbit at securemecca.net (Henry Hertz Hobbit) Date: Mon, 04 Jun 2007 18:59:24 -0600 Subject: gpg and cron In-Reply-To: References: Message-ID: <4664B56C.6010605@securemecca.net> Peter S. May wrote: > > Arsha Bertie wrote: >> i have been trying to run a script which encrypts and transfers files >> between 2 branches, i am using gpg for encryption, i have written a bash >> script and the script is working perfectly fine, but when i run it off a >> cron it doesnt want to work. > > Are you also testing the command manually as root? If not, you'll > probably want to run the task from your own user instead (you can edit > your own user's cron tasks by doing "crontab -e"). > >> 30 * * * * root /backup/encrypt.sh > /tmp/ab.log >> ~ >> >> >> Thr log file /tmp/ab.log is created after the cron executes but it is an > > If you're trying to get the errors, you need to redirect stderr (i.e. > "2>"), not stdout (i.e., ">"). Try: > > /backup/encrypt.sh 2> /tmp/ab.log > > Good fortune > PSM I am sorry I didn't see this earlier. I would have answered it individually. cron frequently gives your shell script a very abbreviated PATH since almost nothing is sourced. In fact it is so abbreviated that on some systems it is only /bin and /usr/bin. It varies depending on the system you are on and which shell you are using. First try a testgpgpath.sh script via cron: #!/bin/bash SAVEHISTSIZE=${HISTSIZE} HISTSIZE=0 export HISTSIZE rm -f /tmp/cron.log touch /tmp/cron.kog echo default cron PATH is >> /tmp/cron.log 2>&1 echo $PATH >> /tmp/cron.log 2>&1 echo >> /tmp/cron.log 2>&1 # just make sure the gpg version you are using is in the PATH first PATH=/usr/local/bin:${PATH}:/usr/local/sbin ; export PATH echo enhanced cron PATH is >> /tmp/cron.log 2>&1 echo $PATH >> /tmp/cron.log 2>&1 echo >> /tmp/cron.log 2>&1 echo GPG version >> /tmp/cron.log 2>&1 gpg --version >> /tmp/cron.log 2>&1 HISTSIZE=${SAVEHISTSIZE} export HISTSIZE exit The BASH you have may or may not do the history in the way I mentioned but you probably don't want a history of the encryption taking place even if you are encrypting to secret key and thus don't need a password (the history MAY not be advisable, but the password NOT being in the script IS advisable). You can get a good idea of what to put where with a: $ echo $PATH Rather than adding as I did above, I SET the path in the script so I know exactly what I have. I also frequently specify the path of the shell (in case you forget to give the file the proper perms): 30 * * * * /bin/sh < /backup/encrypt.sh > /tmp/ab.log 2>&1 I don't know what the "root" is doing there. If you want it to be run by root, then login as root and do a "crontab -e" to enter the information (be sure to set EDITOR to the editor of your choice). Are you sure you want this done every 30 minutes? It seems like something you would want done every 24 hours, and if that was done at 3:30 every morning the line would be: 30 3 * * * /bin/sh < /backup/encrypt.sh > /tmp/ab.log 2>&1 0,15,30,45 * * * * /bin/sh < /backup/testgpgpath.sh > \ /tmp/testgpgpath.log 2>&1 Don't forget to remove the testgpgpath. The other thing is that root usually doesn't have keys, but just copying the ones you want to /root/.gnupg makes that possible. HHH From ivalladt at punkass.com Tue Jun 5 10:04:13 2007 From: ivalladt at punkass.com (Ismael Valladolid Torres) Date: Tue, 05 Jun 2007 10:04:13 +0200 Subject: decrypt and secret key location In-Reply-To: <200706041809.29624.pubmb01@skynet.be> References: <200706041809.29624.pubmb01@skynet.be> Message-ID: <20070605080413.GC3712@punkass.com> Bruno Costacurta escribe: > If so, how / where can I indicate my private key location ? Of course so it seems. Where's your private key located? Cordially, Ismael -- Ismael Valladolid Torres m. +34679156321 La media hostia j. ivalladt at gmail.com http://lamediahostia.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : /pipermail/attachments/20070605/ef804218/attachment.pgp From claude at poliakoff.org Sun Jun 3 09:05:56 2007 From: claude at poliakoff.org (Claude Poliakoff, MD FACS) Date: Sun, 03 Jun 2007 00:05:56 -0700 Subject: initial GnuPG install? Message-ID: <46626854.30004@poliakoff.org> Your posted instructions were quite clear. I checked for prior instances of gpg.exe and found none. downloaded and installed the Windows XP binary, tried entering gpg.exe in a DOS cmd window, and command not recognized, so off to Control Panel>System>advanced tab & added ;C:\Program Files\GNU\GnuPG with no improvement. So checked again for instance of gpg.exe in search of entire system, again finding no instance thereof. Help appreciated as I am very intrigued by the prospect of pluggin in OpenPGP for both authentication and encryption. Thanks in advance. Claude From pubmb01 at skynet.be Tue Jun 5 11:16:08 2007 From: pubmb01 at skynet.be (Bruno Costacurta) Date: Tue, 5 Jun 2007 11:16:08 +0200 Subject: decrypt and secret key location In-Reply-To: <20070605080413.GC3712@punkass.com> References: <200706041809.29624.pubmb01@skynet.be> <20070605080413.GC3712@punkass.com> Message-ID: <200706051116.08316.pubmb01@skynet.be> On Tuesday 05 June 2007 10:04:13 Ismael Valladolid Torres wrote: > Bruno Costacurta escribe: > > If so, how / where can I indicate my private key location ? > > Of course so it seems. Where's your private key located? > > Cordially, Ismael Thanks for attention. Private key is located in ~/.gnupg (as reflected hereafter) which is the standard location. gpg -K /home/bruno/.gnupg/secring.gpg ------------------------------ sec 1024D/2E604D51 2006-06-11 uid Bruno Costacurta uid pubmb01 uid Bruno Costacurta /home/bruno: gpg --list-secret-keys 0x2e604D51 sec 1024D/2E604D51 2006-06-11 uid Bruno Costacurta uid Bruno Costacurta uid [ revoked] pubmb01 uid [ revoked] Bruno Costacurta uid [ revoked] pubmb02 uid Bruno Costacurta Thanks for any clue or idea. Bye, Bruno -- PGP key ID: 0x2e604d51 Key : http://www._anti_spam_here.org/keys/bruno_costacurta_pgp_key.html Key fingerprint = 713F 7956 9441 7DEF 58ED 1951 7E07 569B 2E60 4D51 -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20070605/4292410d/attachment.pgp From stefan at mail.swiftos.de Tue Jun 5 10:20:30 2007 From: stefan at mail.swiftos.de (Stefan Grote) Date: Tue, 05 Jun 2007 10:20:30 +0200 Subject: Unerwartetes IPC Kommando Message-ID: <46651CCE.8050006@mail.swiftos.de> Hallo *, ich habe gpg agent mit Smartcard und Openssh Support installiert, und moechte nun mich via SSH an einem entfernten Rechner anmelden, dabei soll der Key von der Smartcard genutzt werden. Hier meine config Files: .gnupg/gpg-agent.conf pinentry-programm /usr/bin/pinentry-qt enable-ssh-support scdaemon-program /usr/bin/scdaemon default cache-ttl-ssh 7200 default-cache-ttl 7200 max-cache-ttl-ssh 7200 max-cache-ttl 7200 default-cache-ttl 200 allow-preset-passphrase no-grab .gnupg/scdaemon.conf verbose debug 2048 log-file /home/stefan/scdaemon.log ssh-add -l und ssh-add -L geben den Korrekten Fingerprint und Public Key der Karte aus, versuche ich nun mich via SSH anzumelden bekomme ich folgende Fehlermeldung: Agent admitted failure to sign using the key. aus fruheren postings wei? ich das dies meist etwas mit dem Pinentry bzw mit dem PIN callback. tail -f scdaemon.log: scdaemon[2171] DBG: asking for PIN 'PIN' scdaemon[2171] PIN callback returned error: Unerwartetes IPC Kommando scdaemon[2171] operation auth result: Unerwartetes IPC Kommando scdaemon[2171] app_auth_sign failed: Unterwartetes IPC Kommando Das Pinentry Programm erscheint auch nicht. Wenn ich pinentry eingebe erscheint es allerdings. Jemand eine idee woran das liegen kann? Danke! Stefan From bahamut at digital-signal.net Wed Jun 6 14:56:44 2007 From: bahamut at digital-signal.net (Andrew Berg) Date: Wed, 06 Jun 2007 07:56:44 -0500 Subject: initial GnuPG install? In-Reply-To: <46626854.30004@poliakoff.org> References: <46626854.30004@poliakoff.org> Message-ID: <4666AF0C.1030608@digital-signal.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Claude Poliakoff, MD FACS wrote: > downloaded and installed the Windows XP binary, tried entering > gpg.exe in a DOS cmd window, and command not recognized, so off to > Control Panel>System>advanced tab & added ;C:\Program > Files\GNU\GnuPG with no improvement. So checked again for > instance of gpg.exe in search of entire system, again finding no > instance thereof. So you ran the installer, but no copy of gpg.exe was on the drive afterward. Is that correct? - -- Windows NT 5.1.2600.2180 | Thunderbird 2.0.0.0 | Enigmail 0.95.0 | GPG 1.4.7 Key ID: 0x60A78FCB - available on major keyservers and upon request Fingerprint: 4A84 CAE2 A0D3 2AEB 71F6 07FD F88E 0340 60A7 8FCB -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEVAwUBRmavC/iOA0Bgp4/LAQNXnAgAzAUuGMbcCA+gb8Wqkbo+/MPFDt4dHbmo 7ev+5CPzzXDKjNeVfR8nuRHv2oaj1s27bNh0BWDklkIFwiUWK+tPzimNjMdaoO1Q wB3i+JUPHFJ9QMwVWB9oRcKTLkar+ardQLeA690fkj47JL+OHjWcNzc9ONxFi8On hRuXepRVYb1TRlWD4F09T3KW2MoV+En1OJPdnXHjbbGdvssY9L0AdmwRZdulQmSU +VjR3iXp1PHyBJ2vj1S+OyyX64zczCg7ygHMfv0h6P7Iem9soqnpBAOqMsKRdxnI cHcO8QSIvuNGua7EO9O8A9+GjnVTu/xIltU0PoPPvN5qnVG9XxLXOg== =h3gi -----END PGP SIGNATURE----- From bahamut at digital-signal.net Wed Jun 6 16:09:18 2007 From: bahamut at digital-signal.net (Andrew Berg) Date: Wed, 06 Jun 2007 09:09:18 -0500 Subject: decrypt and secret key location In-Reply-To: <200706061504.43712.pubmb01@skynet.be> References: <200706041809.29624.pubmb01@skynet.be> <200706042208.26422.pubmb01@skynet.be> <4666AD2B.9030306@digital-signal.net> <200706061504.43712.pubmb01@skynet.be> Message-ID: <4666C00E.5070708@digital-signal.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Bruno Costacurta wrote: > I received an email from you with an ecrypted message. When I tried > to decrypt : > > gpg -v -v --decrypt test01.asc gpg: armor: BEGIN PGP MESSAGE gpg: > armor header: Charset: UTF-8 gpg: armor header: Version: GnuPG > v1.4.7 (MingW32) gpg: armor header: Comment: Using GnuPG with > Mozilla - http://enigmail.mozdev.org :pubkey enc packet: version 3, > algo 16, keyid 42531C9A0CC897B5 data: [2048 bits] data: [2047 bits] > gpg: public key is 0CC897B5 :pubkey enc packet: version 3, algo 1, > keyid BBC3C45BBBC5C9CF data: [2046 bits] gpg: public key is > BBC5C9CF :encrypted data packet: length: unknown mdc_method: 2 gpg: > using subkey BBC5C9CF instead of primary key 60A78FCB gpg: > encrypted with 2048-bit RSA key, ID BBC5C9CF, created 2007-04-20 > "Andrew Berg " gpg: using subkey > 0CC897B5 instead of primary key 2E604D51 gpg: encrypted with > 2048-bit ELG-E key, ID 0CC897B5, created 2006-06-11 "Bruno > Costacurta " gpg: decryption failed: secret > key not available > > > So I'm still having the problem about my secret key not > available... Looks like a subkey problem. I used the public key I got from a keyserver, which verifies that signed message. The lines that say it's using a subkey instead of the primary key seem to be the problem. Unfortunately, I know almost nothing about subkeys. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEVAwUBRmbADfiOA0Bgp4/LAQN/QQf+IGqq1rs+aLBe+Xy4ZjbD4Za2wjnMGeoB D9akrHJw+Tf7J/m+cqIYFrG/9lhm9Jf6sAdQRSYiUmuQ7qMl1fdaBkhnjrvOPw1o NUWp2SBay0HPZGC9eCU36Lj+/wtuQZN9OR/2Y9YvEL92r/t9oT0poYtE0DSvxH4U Md9orLNgBHwbi8N1Yp5jD2P6CtlkRKkLEDSg4QEh4f5LOP6GZRc90046ceJ4a+UH xZviIsf5Zk8XdcJBb5xjVVOpGPvwftCZ2+D7QrFUu7a0rjNpjCVnlrmOe3w/+E4x dQ8aAgL0V4DTkTS2ZSMtmH2f2A8xK9bZoaoymtTpTwuWCJIhgAOeHQ== =kIIj -----END PGP SIGNATURE----- From pubmb01 at skynet.be Wed Jun 6 16:23:58 2007 From: pubmb01 at skynet.be (Bruno Costacurta) Date: Wed, 6 Jun 2007 16:23:58 +0200 Subject: decrypt : primary key or subkey ? Message-ID: <200706061623.59065.pubmb01@skynet.be> Hello, I'm not able to decrpyt message as I received hereafter message about using subkey instead of primary key. Is this correct ? Could it be the problem relies on the usage of this subkey ? If yes, how to manage my keyring regarding this subkey (which is obviously used for en/decrypting not for signing) to be able to decrypt ? gpg -v -v --decrypt msg.asc gpg: armor: BEGIN PGP MESSAGE gpg: armor header: Version: GnuPG v1.4.6 (GNU/Linux) :pubkey enc packet: version 3, algo 16, keyid 42531C9A0CC897B5 data: [2048 bits] data: [2048 bits] gpg: public key is 0CC897B5 :encrypted data packet: length: unknown mdc_method: 2 gpg: using subkey 0CC897B5 instead of primary key 2E604D51 gpg: encrypted with 2048-bit ELG-E key, ID 0CC897B5, created 2006-06-11 "Bruno Costacurta " gpg: decryption failed: secret key not available Bye, Bruno -- PGP key ID: 0x2e604d51 Key : http://www.costacurta.org/keys/bruno_costacurta_pgp_key.html Key fingerprint = 713F 7956 9441 7DEF 58ED 1951 7E07 569B 2E60 4D51 -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20070606/12d93be6/attachment.pgp From dave.smith at st.com Wed Jun 6 16:48:45 2007 From: dave.smith at st.com (David SMITH) Date: Wed, 6 Jun 2007 15:48:45 +0100 Subject: decrypt : primary key or subkey ? In-Reply-To: <200706061623.59065.pubmb01@skynet.be> References: <200706061623.59065.pubmb01@skynet.be> Message-ID: <20070606144845.GH10506@bristol.st.com> On Wed, Jun 06, 2007 at 04:23:58PM +0200, Bruno Costacurta wrote: > Hello, > I'm not able to decrpyt message as I received hereafter message about using > subkey instead of primary key. > > Is this correct ? Could it be the problem relies on the usage of this subkey ? > If yes, how to manage my keyring regarding this > subkey (which is obviously used for en/decrypting not for signing) to be able > to decrypt ? IME it is normal to get this message when using subkeys. If you do 'gpg --list-keys --verbose', does it list the subkey 0CC897B5? What about when you do 'gpg --list-secret-keys'? -- David Smith | Tel: +44 (0)1454 462380 Home: +44 (0)1454 616963 STMicroelectronics | Fax: +44 (0)1454 462305 Mobile: +44 (0)7932 642724 1000 Aztec West | TINA: 065 2380 GPG Key: 0xF13192F2 Almondsbury | Work Email: Dave.Smith at st.com BRISTOL, BS32 4SQ | Home Email: David.Smith at ds-electronics.co.uk From hhhobbit at securemecca.net Wed Jun 6 17:20:48 2007 From: hhhobbit at securemecca.net (Henry Hertz Hobbit) Date: Wed, 06 Jun 2007 09:20:48 -0600 Subject: initial GnuPG install? In-Reply-To: References: Message-ID: <4666D0D0.9020301@securemecca.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Andrew Berg wrote: > > Claude Poliakoff, MD FACS wrote: >> downloaded and installed the Windows XP binary, tried entering >> gpg.exe in a DOS cmd window, and command not recognized, so off >> to Control Panel -> System -> advanced tab & added >> ;C:\Program Files\GNU\GnuPG with no improvement. So checked >> again for instance of gpg.exe in search of entire system, again >> finding no instance thereof. > So you ran the installer, but no copy of gpg.exe was on the > drive afterward. Is that correct? Yes, in which case nothing got installed. BUT type the following in case you have both 2003 Server installed first and XP second (or some other dual Microsoft OS arrangement) on the same machine: C:\> set Search for your %SystemDrive% variable in XP and make sure it is C:, since in the scenario I just gave, your %SystemDrive% for the XP OS will be E: (one CD/DVD drive) or F: (two CD/DVD drives). A good installer actually uses the %ProgramFiles% environment variable to do a proper install. Don't feel bad if that is what you did - I do it frequently myself. You get used to C: be the %SystemDrive%. Another way you can end up with there not being a C: %SystemDrive% is a reinstall of an OS. The other thing is that after you made the change to the %Path% environment variable, did you close the Command Prompt and open a new one up? The change doesn't take affect until you do that on XP or 2003 Server. With W2K you actually have to log out and log back in to get the new path. The output of the "set" command should reflect the addition in the %Path% list. HHH -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGZtDQr3QZv1upb6wRClxQAKCBdzRc4xdxyA5rZwKOUzZAZL/tjwCdEjME dQAhGQOzd5kt4upJ/DbVKYc= =ev/r -----END PGP SIGNATURE----- From pubmb01 at skynet.be Wed Jun 6 17:14:18 2007 From: pubmb01 at skynet.be (Bruno Costacurta) Date: Wed, 6 Jun 2007 17:14:18 +0200 Subject: decrypt : primary key or subkey ? In-Reply-To: <20070606144845.GH10506@bristol.st.com> References: <200706061623.59065.pubmb01@skynet.be> <20070606144845.GH10506@bristol.st.com> Message-ID: <200706061714.18438.pubmb01@skynet.be> On Wednesday 06 June 2007 16:48:45 David SMITH wrote: > On Wed, Jun 06, 2007 at 04:23:58PM +0200, Bruno Costacurta wrote: > > Hello, > > I'm not able to decrpyt message as I received hereafter message about > > using subkey instead of primary key. > > > > Is this correct ? Could it be the problem relies on the usage of this > > subkey ? If yes, how to manage my keyring regarding this > > subkey (which is obviously used for en/decrypting not for signing) to be > > able to decrypt ? > > IME it is normal to get this message when using subkeys. > > If you do 'gpg --list-keys --verbose', does it list the subkey 0CC897B5? > What about when you do 'gpg --list-secret-keys'? It seems the problem is here... gpg --list-secret-keys -v 0x2E604D51 gpg: using PGP trust model gpg: no secret subkey for public subkey 0CC897B5 - ignoring sec 1024D/2E604D51 2006-06-11 uid Bruno Costacurta uid Bruno Costacurta uid [ revoked] pubmb01 uid [ revoked] Bruno Costacurta uid [ revoked] pubmb02 uid Bruno Costacurta So I simply do not have a secret for my subkey. How can I add one ? Thanks for your attention. Bye, Bruno -- PGP key ID: 0x2e604d51 Key : http://www.costacurta.org/keys/bruno_costacurta_pgp_key.html Key fingerprint = 713F 7956 9441 7DEF 58ED 1951 7E07 569B 2E60 4D51 -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20070606/8f2cb312/attachment.pgp From dave.smith at st.com Wed Jun 6 18:01:21 2007 From: dave.smith at st.com (David SMITH) Date: Wed, 6 Jun 2007 17:01:21 +0100 Subject: decrypt : primary key or subkey ? In-Reply-To: <200706061714.18438.pubmb01@skynet.be> References: <200706061623.59065.pubmb01@skynet.be> <20070606144845.GH10506@bristol.st.com> <200706061714.18438.pubmb01@skynet.be> Message-ID: <20070606160121.GI10506@bristol.st.com> On Wed, Jun 06, 2007 at 05:14:18PM +0200, Bruno Costacurta wrote: > gpg --list-secret-keys -v 0x2E604D51 > gpg: using PGP trust model > gpg: no secret subkey for public subkey 0CC897B5 - ignoring > sec 1024D/2E604D51 2006-06-11 > uid Bruno Costacurta > uid Bruno Costacurta > uid [ revoked] pubmb01 > uid [ revoked] Bruno Costacurta > uid [ revoked] pubmb02 > uid Bruno Costacurta > > So I simply do not have a secret for my subkey. > How can I add one ? You can't "add" a secret key to a public one - otherwise, there wouldn't be much point to public key cryptography... You will have generated a secret key when you generated the public key - they're generated together. Somehow you've managed to lose the secret key. You need to look around in the places where you generated/stored the key to see if you can find it. If you can't find it, then I'm afraid that you're stuffed - you won't be able to decrypt your encrypted information (short of brute-force cracking it). Sorry for being the bearer of bad news... -- David Smith | Tel: +44 (0)1454 462380 Home: +44 (0)1454 616963 STMicroelectronics | Fax: +44 (0)1454 462305 Mobile: +44 (0)7932 642724 1000 Aztec West | TINA: 065 2380 GPG Key: 0xF13192F2 Almondsbury | Work Email: Dave.Smith at st.com BRISTOL, BS32 4SQ | Home Email: David.Smith at ds-electronics.co.uk From pubmb01 at skynet.be Wed Jun 6 18:53:48 2007 From: pubmb01 at skynet.be (Bruno Costacurta) Date: Wed, 6 Jun 2007 18:53:48 +0200 Subject: decrypt : primary key or subkey ? In-Reply-To: <20070606160121.GI10506@bristol.st.com> References: <200706061623.59065.pubmb01@skynet.be> <200706061714.18438.pubmb01@skynet.be> <20070606160121.GI10506@bristol.st.com> Message-ID: <200706061853.56601.pubmb01@skynet.be> On Wednesday 06 June 2007 18:01, David SMITH wrote: > On Wed, Jun 06, 2007 at 05:14:18PM +0200, Bruno Costacurta wrote: > > gpg --list-secret-keys -v 0x2E604D51 > > gpg: using PGP trust model > > gpg: no secret subkey for public subkey 0CC897B5 - ignoring > > sec 1024D/2E604D51 2006-06-11 > > uid Bruno Costacurta > > uid Bruno Costacurta > > uid [ revoked] pubmb01 > > uid [ revoked] Bruno Costacurta > > uid [ revoked] pubmb02 > > uid Bruno Costacurta > > > > So I simply do not have a secret for my subkey. > > How can I add one ? > > You can't "add" a secret key to a public one - otherwise, there wouldn't > be much point to public key cryptography... > > You will have generated a secret key when you generated the public key - > they're generated together. Somehow you've managed to lose the secret > key. You need to look around in the places where you generated/stored > the key to see if you can find it. If you can't find it, then I'm > afraid that you're stuffed - you won't be able to decrypt your encrypted > information (short of brute-force cracking it). > > Sorry for being the bearer of bad news... Sorry but indeed I have the secret key for 0x2E604D51 and it's valid (I just installed my gpg keyrings on a new computer and use it for signing). The 0CC897B5 is a subkey and was created automatically with 0x2E604D5 creation and never ask specific password. Bye, Bruno -- PGP key ID: 0x2e604d51 Key : http://www.costacurta.org/keys/bruno_costacurta_pgp_key.html Key fingerprint = 713F 7956 9441 7DEF 58ED ?1951 7E07 569B 2E60 4D51 -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20070606/fdd62d82/attachment.pgp From shavital at mac.com Wed Jun 6 18:56:20 2007 From: shavital at mac.com (Charly Avital) Date: Wed, 06 Jun 2007 19:56:20 +0300 Subject: decrypt : primary key or subkey ? In-Reply-To: <200706061623.59065.pubmb01@skynet.be> References: <200706061623.59065.pubmb01@skynet.be> Message-ID: <4666E734.8020305@mac.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Bruno Costacurta wrote the following on 6/6/07 5:23 PM: > Hello, > I'm not able to decrpyt message as I received hereafter message about using > subkey instead of primary key. This is your public key, as I have just downloaded it from the servers: - ---------- pub 1024D/2E604D51 created: 2006-06-11 expires: never usage: SC trust: unknown validity: unknown sub 2048g/0CC897B5 created: 2006-06-11 expires: never usage: E [ unknown] (1). Bruno Costacurta [ revoked] (2) pubmb01 [ revoked] (3) pubmb02 [ revoked] (4) Bruno Costacurta [ unknown] (5) Bruno Costacurta [ unknown] (6) Bruno Costacurta - ---------- > > Is this correct ? Could it be the problem relies on the usage of this subkey ? > If yes, how to manage my keyring regarding this > subkey (which is obviously used for en/decrypting not for signing) to be able > to decrypt ? As you can see, your primary key 1024D/2E604D51 is used for SC (Sign, Certify). The subkey 2048g/0CC897B5 is used for E encrypting *to you*. Not for decrypting. For decrypting you use your secret key (copy/paste of your own prompt/output): /home/bruno: gpg --list-secret-keys 0x2e604D51 sec 1024D/2E604D51 2006-06-11 The message "...using subkey...instead of primary key..." is exactly as it should be, as pointed out by dave.smith at st.com in this forum. The secret key required for decryption is reported to be where it should be. The problem might be with the encryption process used by the sender of that message. > > gpg -v -v --decrypt msg.asc > gpg: armor: BEGIN PGP MESSAGE > gpg: armor header: Version: GnuPG v1.4.6 (GNU/Linux) > :pubkey enc packet: version 3, algo 16, keyid 42531C9A0CC897B5 > data: [2048 bits] > data: [2048 bits] > gpg: public key is 0CC897B5 > :encrypted data packet: > length: unknown I am not sure this 'length: unknown' is as it should be. I have carried out a few tests with encrypted messages, and there is always a value after 'length: ..... As I pointed out above, *maybe* there is some problem with the encryption process used by the sender of the message you have not been able to decrypt. > mdc_method: 2 > gpg: using subkey 0CC897B5 instead of primary key 2E604D51 > gpg: encrypted with 2048-bit ELG-E key, ID 0CC897B5, created 2006-06-11 > "Bruno Costacurta " > gpg: decryption failed: secret key not available I am sending you, separately, a encrypted test message, please let me know if you can decrypt it. Charly MacOS 10.4.9 - MacBook Intel C2Duo - GnuPG 1.4.7 - GPG2 2.0.4 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (Darwin) Comment: GnuPG for Privacy Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEVAwUBRmbnCM3GMi2FW4PvAQhdAQgAg/qYzSf1pUlKt93QFArARWB3gW/BEsGT 2INSNIKbbYpeUGXMo19F5PMTFm1kxasxKUPt6GlKQKuS79qgZccqo2MHKMDRJlRi LBvhKo73rXBOmFPXWNEAgjyMzMV2+UdO2JJSMTLKEaGihxhvx6QjnWk/p0NXTw+M Ag1/gM++saMS6KozXortRJMzQnv14LNsG7S6tbIk7PZ76nOk2LGzwPyGPZxej5CI FVG98pC2te8CH34ZyWO/EpZjnIMo0bGCKU6XCm71MYRkIw8ZXJTuJHqki9xQk2Oz WiHgE/2Lms45IbtXKPro+sVbBzfJ4VII8T1K/t6AVBUmAB35ANaLwQ== =loXj -----END PGP SIGNATURE----- From hhhobbit at securemecca.net Thu Jun 7 03:57:44 2007 From: hhhobbit at securemecca.net (Henry Hertz Hobbit) Date: Wed, 06 Jun 2007 19:57:44 -0600 Subject: setting expiration dates In-Reply-To: References: Message-ID: <46676618.60200@securemecca.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Joseph Oreste Bruni wrote: > This is interesting: After changing my encryption subkey's expiration > by a few days (from 2008-02-07 to 2008-01-01), I tried to upload the > updated key to the PGP Global Directory (http://keyserver.pgp.com). > It complained that my key had expired, but it hasn't. Submitting the > key to the SKS key servers (hkp://pool.sks-keyservers.net) didn't > have a problem. My key ID is CD5518C7 if you want to look at it. I think PGP Global Directory is complaining that the pub key your sub key is attached to is expired. If it is working by allowing people to encrypt to you, maybe these are those new changes WK said have been made. Here is the key I got from PGP Global Directory for your KEYID after I imported it: pub 2048R/CD5518C7 2005-02-17 uid Joseph Oreste Bruni uid Joseph Oreste Bruni uid Joseph Oreste Bruni uid Joseph Oreste Bruni uid [jpeg image of size 1173] sub 2048R/EEA4EC97 2007-01-31 [expires: 2008-01-31] Well, the email addresses were changed by moe, but you get the idea. Your pub key IS expired! Assuming you still have the same email address you used when you gave them (PGP) the key, you can just have them remove your key with the following page: http://keyserver.pgp.com/vkd/GetRemoveKeyScreen.event PGP Global Directory doesn't work like the other key servers by giving you the ability to delete your keys (breaks WOT, but ...). Having just said the foregoing, here is how your key came down from pgp.mit.edu (HKP): pub 2048R/CD5518C7 2005-02-17 uid Joseph Oreste Bruni uid Joseph Oreste Bruni uid Joseph Oreste Bruni uid Joseph Oreste Bruni uid [jpeg image of size 1173] Hmm, where is the sub key? And here is how it comes down from the Penguin (X-HKP) in Germany: pub 2048R/CD5518C7 2005-02-17 uid Joseph Oreste Bruni uid Joseph Oreste Bruni uid Joseph Oreste Bruni uid Joseph Oreste Bruni uid [jpeg image of size 1173] sub 2048R/EEA4EC97 2007-01-31 [expires: 2008-01-01] Please do the following as a test for me with the key you have now (a # indicates a comment): $ gpg --edit-key CD5518C7 Command> expire # change the expire date of your pub key to match your # sub key or at least so it is NOT expired $ gpg --keyserver hkp://pgp.mit.edu --send-keys CD5518C7 $ gpg --keyserver x-hkp://random.sks.keyserver.penguin.de \ --send-keys CD5518C7 If desired, after you have deleted your key from the PGP Global Directory, you can also submit it to them again. Let me know if you do any of this and I will do the tests again. Next time I will be FAR shorter in my reply (will just show any changes from what I have here depending on what you have done). You will have to ask the others if having a pub key that is expired on the key servers is a good idea or even if it is possible - I don't think it is possible but don't know for sure. I was able to sign your key but have NO idea what that means. What good does it do to sign an expired key? My OPINION is to either say goodbye to the pub key and all the sub-keys, or keep them ALL freshened up on their expire date so people know that the key is still good. I normally interpret a pub key that is expired as having an implicit meaning that it is no longer used and the person has replaced that key with a newer key. So if I intend to keep using a key, I change the expire dates for the pub key and all sub-keys at least one month before any of them expire for the desired period I want to keep them - lots of options to consider, like revoking your present sub-key and adding a new sub-key, when the expire date for each key is, etc. Then I upload my pub key to at least two keyservers again if if was on the keyservers. No reply from you means you don't want me to do the tests and didn't make any changes. If you do the changes, let me know when you have done it with a Bcc: to me. I only read the Digest. Sometimes it goes days before I get a new bundle of messages. Sometimes I don't seem to get them at all, but maybe they fell through the cracks. HHH -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGZ2YYr3QZv1upb6wRCjMSAJ9A/qWNgeQofviDpKpEAat0pMZWLwCgst9+ 0U8xKtWRX2r/1Ch+FhAjFho= =9OYY -----END PGP SIGNATURE----- From dshaw at jabberwocky.com Thu Jun 7 04:20:39 2007 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 6 Jun 2007 22:20:39 -0400 Subject: setting expiration dates In-Reply-To: References: <83C02188-51D6-44E4-9F5E-59CC25125396@mac.com> <20070601183126.GC8685@jabberwocky.com> <87hcpoxg9g.fsf@wheatstone.g10code.de> Message-ID: <20070607022039.GB16676@jabberwocky.com> On Mon, Jun 04, 2007 at 03:17:21PM -0700, Joseph Oreste Bruni wrote: > > On Jun 4, 2007, at 1:42 AM, Werner Koch wrote: > > > On Fri, 1 Jun 2007 22:01, jbruni at mac.com said: > > > >> Awesome. Would you consider updating the prompt reflecting that > >> capability? > > > > Enter a question mark at the prompt to see a help text. > > > This is interesting: After changing my encryption subkey's expiration > by a few days (from 2008-02-07 to 2008-01-01), I tried to upload the > updated key to the PGP Global Directory (http://keyserver.pgp.com). > It complained that my key had expired, but it hasn't. Submitting the > key to the SKS key servers (hkp://pool.sks-keyservers.net) didn't > have a problem. My key ID is CD5518C7 if you want to look at it. Your key looks fine to me. Possibly the GD was complaining that you have two expired subkeys, though this should not matter as you also have an unexpired one. Perhaps try deleting the expired subkeys before submitting the key to the GD. If that works, you might submit a bug report on the GD, since an expired subkey should not prevent uploading the whole key. David From jbruni at mac.com Thu Jun 7 06:17:31 2007 From: jbruni at mac.com (Joseph Oreste Bruni) Date: Wed, 6 Jun 2007 21:17:31 -0700 Subject: setting expiration dates In-Reply-To: <20070607022039.GB16676@jabberwocky.com> References: <83C02188-51D6-44E4-9F5E-59CC25125396@mac.com> <20070601183126.GC8685@jabberwocky.com> <87hcpoxg9g.fsf@wheatstone.g10code.de> <20070607022039.GB16676@jabberwocky.com> Message-ID: <29DE25BB-D9B1-4EAB-999C-09704C133EF4@mac.com> On Jun 6, 2007, at 7:20 PM, David Shaw wrote: > On Mon, Jun 04, 2007 at 03:17:21PM -0700, Joseph Oreste Bruni wrote: >> >> This is interesting: After changing my encryption subkey's expiration >> by a few days (from 2008-01-31 to 2008-01-01), I tried to upload the >> updated key to the PGP Global Directory (http://keyserver.pgp.com). >> It complained that my key had expired, but it hasn't. Submitting the >> key to the SKS key servers (hkp://pool.sks-keyservers.net) didn't >> have a problem. My key ID is CD5518C7 if you want to look at it. > > Your key looks fine to me. Possibly the GD was complaining that you > have two expired subkeys, though this should not matter as you also > have an unexpired one. > > Perhaps try deleting the expired subkeys before submitting the key to > the GD. If that works, you might submit a bug report on the GD, since > an expired subkey should not prevent uploading the whole key. > > David The key as you see it in GD has expirations on all three subkey; two expired, but one currently unexpired. The change I performed was to move the expiration of the third subkey (EEA4EC97) to 2008-01-01. It is this changed key that was rejected by GD. Would it be helpful to send you the key as it currently exists in my keyring (which was rejected) for comparison with what was previous acceptable? Also, the expiration date on the subkey as it exists in GD was set at the time the subkey was created, whereas the expiration on the subkey in my keyring was changed post creation. Would that make a difference in the representation? I'm not familiar enough with the details of the spec. to know if this even makes sense. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2508 bytes Desc: not available Url : /pipermail/attachments/20070606/a98ed1dc/attachment.bin From pubmb01 at skynet.be Thu Jun 7 08:44:51 2007 From: pubmb01 at skynet.be (Bruno Costacurta) Date: Thu, 7 Jun 2007 08:44:51 +0200 Subject: decrypt : primary key or subkey ? In-Reply-To: <4666E734.8020305@mac.com> References: <200706061623.59065.pubmb01@skynet.be> <4666E734.8020305@mac.com> Message-ID: <200706070844.58702.pubmb01@skynet.be> On Wednesday 06 June 2007 18:56:20 Charly Avital wrote: > Bruno Costacurta wrote the following on 6/6/07 5:23 PM: > > Hello, > > I'm not able to decrpyt message as I received hereafter message about > > using subkey instead of primary key. > > This is your public key, as I have just downloaded it from the servers: > ---------- > pub 1024D/2E604D51 created: 2006-06-11 expires: never usage: SC > trust: unknown validity: unknown > sub 2048g/0CC897B5 created: 2006-06-11 expires: never usage: E > [ unknown] (1). Bruno Costacurta > [ revoked] (2) pubmb01 > [ revoked] (3) pubmb02 > [ revoked] (4) Bruno Costacurta > [ unknown] (5) Bruno Costacurta > [ unknown] (6) Bruno Costacurta > ---------- > > > Is this correct ? Could it be the problem relies on the usage of this > > subkey ? If yes, how to manage my keyring regarding this > > subkey (which is obviously used for en/decrypting not for signing) to be > > able to decrypt ? > > As you can see, your primary key 1024D/2E604D51 is used for SC (Sign, > Certify). > The subkey 2048g/0CC897B5 is used for E encrypting *to you*. Not for > decrypting. > > For decrypting you use your secret key (copy/paste of your own > prompt/output): > /home/bruno: gpg --list-secret-keys 0x2e604D51 > sec 1024D/2E604D51 2006-06-11 > > The message "...using subkey...instead of primary key..." is exactly as > it should be, as pointed out by dave.smith at st.com in this forum. > > The secret key required for decryption is reported to be where it should > be. > > The problem might be with the encryption process used by the sender of > that message. > > > gpg -v -v --decrypt msg.asc > > gpg: armor: BEGIN PGP MESSAGE > > gpg: armor header: Version: GnuPG v1.4.6 (GNU/Linux) > > > > :pubkey enc packet: version 3, algo 16, keyid 42531C9A0CC897B5 > > > > data: [2048 bits] > > data: [2048 bits] > > gpg: public key is 0CC897B5 > > > > :encrypted data packet: > > > > length: unknown > > I am not sure this 'length: unknown' is as it should be. I have carried > out a few tests with encrypted messages, and there is always a value > after 'length: ..... As I pointed out above, *maybe* there is some > problem with the encryption process used by the sender of the message > you have not been able to decrypt. > > > mdc_method: 2 > > gpg: using subkey 0CC897B5 instead of primary key 2E604D51 > > gpg: encrypted with 2048-bit ELG-E key, ID 0CC897B5, created 2006-06-11 > > "Bruno Costacurta " > > gpg: decryption failed: secret key not available > > I am sending you, separately, a encrypted test message, please let me > know if you can decrypt it. Hello Charly, thanks for your attention and help Unfortunately I cannot decrypt your test message : gpg --decrypt charly.asc gpg: encrypted with 2048-bit ELG-E key, ID CE3A0945, created 2002-02-11 "Charly Avital (GnuPG) " gpg: encrypted with 2048-bit ELG-E key, ID 0CC897B5, created 2006-06-11 "Bruno Costacurta " gpg: decryption failed: secret key not available Is there a way to modify subkey attributes, eg. adding decryption capabilities. If not, can I'll create a new subket with correct attributes. Considering I (probably) already lost (mean: cannot decypt) received encrypted message but will be able to use future messages encrypted with the new correct subkey. Bye, Bruno > > Charly > MacOS 10.4.9 - MacBook Intel C2Duo - GnuPG 1.4.7 - GPG2 2.0.4 > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -- PGP key ID: 0x2e604d51 Key : http://www.costacurta.org/keys/bruno_costacurta_pgp_key.html Key fingerprint = 713F 7956 9441 7DEF 58ED 1951 7E07 569B 2E60 4D51 -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20070607/275fd59e/attachment.pgp From dave.smith at st.com Thu Jun 7 10:27:08 2007 From: dave.smith at st.com (David SMITH) Date: Thu, 7 Jun 2007 09:27:08 +0100 Subject: decrypt : primary key or subkey ? In-Reply-To: <200706061853.56601.pubmb01@skynet.be> References: <200706061623.59065.pubmb01@skynet.be> <200706061714.18438.pubmb01@skynet.be> <20070606160121.GI10506@bristol.st.com> <200706061853.56601.pubmb01@skynet.be> Message-ID: <20070607082708.GJ10506@bristol.st.com> On Wed, Jun 06, 2007 at 06:53:48PM +0200, Bruno Costacurta wrote: > Sorry but indeed I have the secret key for 0x2E604D51 and it's valid (I just > installed my gpg keyrings on a new computer and use it for signing). > The 0CC897B5 is a subkey and was created automatically with 0x2E604D5 creation > and never ask specific password. No, you should have a subkey for both 0x2E604D51 /and/ 0x0CC897B5. Here are the details of my keys: bris0085(23)% gpg --list-keys --verbose /home/damia/users/dsmith/.gnupg/pubring.gpg ------------------------------------------- pub 1024D/F13192F2 2002-02-12 uid David Smith (STMicroelectronics) uid David Smith (Home) sub 1024g/FA5EA4A2 2002-02-12 [expired: 2002-08-11] sub 1024g/BE299CC1 2002-07-20 [expired: 2003-01-16] sub 1024g/C8D6DAB9 2003-01-18 [expired: 2003-07-17] sub 1024g/B643FF36 2003-11-09 [expired: 2004-05-07] sub 1024g/80454033 2004-05-17 [expired: 2004-11-13] sub 1024g/F5FE6DF8 2004-12-07 [expired: 2005-06-05] sub 1024g/0DD8A13F 2005-09-05 [expired: 2006-03-04] sub 1024g/9249F278 2006-06-20 [expired: 2006-12-17] sub 1024g/3712DE29 2006-12-22 [expired: 2006-12-24] sub 4096g/42F250C4 2007-01-13 [expires: 2007-07-12] bris0085(22)% gpg --list-secret-keys /home/damia/users/dsmith/.gnupg/secring.gpg ------------------------------------------- sec 1024D/F13192F2 2002-02-12 uid David Smith (Home) uid David Smith (STMicroelectronics) ssb 1024g/FA5EA4A2 2002-02-12 ssb 1024g/BE299CC1 2002-07-20 ssb 1024g/C8D6DAB9 2003-01-18 ssb 1024g/B643FF36 2003-11-09 ssb 1024g/80454033 2004-05-17 ssb 1024g/F5FE6DF8 2004-12-07 ssb 1024g/0DD8A13F 2005-09-05 ssb 1024g/9249F278 2006-06-20 Note that my main (signing) key has both public (pub) and secret (sec) parts, and each of my subkeys have public (sub) and secret (ssb) parts. Compare this with yours: % gpg --list-secret-keys -v 0x2E604D51 gpg: no secret subkey for public subkey 0CC897B5 - ignoring sec 1024D/2E604D51 2006-06-11 uid Bruno Costacurta uid Bruno Costacurta uid [ revoked] pubmb01 uid [ revoked] Bruno Costacurta uid [ revoked] pubmb02 uid Bruno Costacurta You seem to have managed to lose the secret part of your subkey, either through a bug or data corruption, or through human error. Unless you can find the secret part of your subkey again, the public part is worthless, and should be revoked by publishing a revocation certificate. This does, of course, assume that you generated a revocation certificate before you lost the secret part.... -- David Smith | Tel: +44 (0)1454 462380 Home: +44 (0)1454 616963 STMicroelectronics | Fax: +44 (0)1454 462305 Mobile: +44 (0)7932 642724 1000 Aztec West | TINA: 065 2380 GPG Key: 0xF13192F2 Almondsbury | Work Email: Dave.Smith at st.com BRISTOL, BS32 4SQ | Home Email: David.Smith at ds-electronics.co.uk From pubmb01 at skynet.be Thu Jun 7 12:31:19 2007 From: pubmb01 at skynet.be (Bruno Costacurta) Date: Thu, 7 Jun 2007 12:31:19 +0200 Subject: decrypt : primary key or subkey ? In-Reply-To: <20070607082708.GJ10506@bristol.st.com> References: <200706061623.59065.pubmb01@skynet.be> <200706061853.56601.pubmb01@skynet.be> <20070607082708.GJ10506@bristol.st.com> Message-ID: <200706071231.19630.pubmb01@skynet.be> On Thursday 07 June 2007 10:27:08 David SMITH wrote: > On Wed, Jun 06, 2007 at 06:53:48PM +0200, Bruno Costacurta wrote: > > Sorry but indeed I have the secret key for 0x2E604D51 and it's valid (I > > just installed my gpg keyrings on a new computer and use it for signing). > > The 0CC897B5 is a subkey and was created automatically with 0x2E604D5 > > creation and never ask specific password. > > No, you should have a subkey for both 0x2E604D51 /and/ 0x0CC897B5. > > Here are the details of my keys: > > bris0085(23)% gpg --list-keys --verbose > /home/damia/users/dsmith/.gnupg/pubring.gpg > ------------------------------------------- > pub 1024D/F13192F2 2002-02-12 > uid David Smith (STMicroelectronics) > uid David Smith (Home) > sub 1024g/FA5EA4A2 2002-02-12 [expired: 2002-08-11] > sub 1024g/BE299CC1 2002-07-20 [expired: 2003-01-16] > sub 1024g/C8D6DAB9 2003-01-18 [expired: 2003-07-17] > sub 1024g/B643FF36 2003-11-09 [expired: 2004-05-07] > sub 1024g/80454033 2004-05-17 [expired: 2004-11-13] > sub 1024g/F5FE6DF8 2004-12-07 [expired: 2005-06-05] > sub 1024g/0DD8A13F 2005-09-05 [expired: 2006-03-04] > sub 1024g/9249F278 2006-06-20 [expired: 2006-12-17] > sub 1024g/3712DE29 2006-12-22 [expired: 2006-12-24] > sub 4096g/42F250C4 2007-01-13 [expires: 2007-07-12] > > bris0085(22)% gpg --list-secret-keys > /home/damia/users/dsmith/.gnupg/secring.gpg > ------------------------------------------- > sec 1024D/F13192F2 2002-02-12 > uid David Smith (Home) > uid David Smith (STMicroelectronics) > ssb 1024g/FA5EA4A2 2002-02-12 > ssb 1024g/BE299CC1 2002-07-20 > ssb 1024g/C8D6DAB9 2003-01-18 > ssb 1024g/B643FF36 2003-11-09 > ssb 1024g/80454033 2004-05-17 > ssb 1024g/F5FE6DF8 2004-12-07 > ssb 1024g/0DD8A13F 2005-09-05 > ssb 1024g/9249F278 2006-06-20 > > Note that my main (signing) key has both public (pub) and secret (sec) > parts, and each of my subkeys have public (sub) and secret (ssb) parts. > > Compare this with yours: > > % gpg --list-secret-keys -v 0x2E604D51 > gpg: no secret subkey for public subkey 0CC897B5 - ignoring > sec 1024D/2E604D51 2006-06-11 > uid Bruno Costacurta > uid Bruno Costacurta > uid [ revoked] pubmb01 > uid [ revoked] Bruno Costacurta > uid [ revoked] pubmb02 > uid Bruno Costacurta > > > You seem to have managed to lose the secret part of your subkey, either > through a bug or data corruption, or through human error. > > Unless you can find the secret part of your subkey again, the public > part is worthless, and should be revoked by publishing a revocation > certificate. This does, of course, assume that you generated a > revocation certificate before you lost the secret part.... Hello David, (note: I'm able to revoke this subkey (done but not sent to keyserver yet)). The problem is that subkey comes alone and automatically when keypair is generated (and related keyring created). During creation there is only one password required which is linked to the primary key. My secret key and related password are OK. Where in this process is the secret part (and related password) of subkey specified ? How to specify correct attributes for subkey like encrypt & decrypt ? Bye, Bruno -- PGP key ID: 0x2e604d51 Key : http://www.costacurta.org/keys/bruno_costacurta_pgp_key.html Key fingerprint = 713F 7956 9441 7DEF 58ED 1951 7E07 569B 2E60 4D51 -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20070607/c8116dc6/attachment-0001.pgp From dave.smith at st.com Thu Jun 7 16:00:49 2007 From: dave.smith at st.com (David SMITH) Date: Thu, 7 Jun 2007 15:00:49 +0100 Subject: decrypt : primary key or subkey ? In-Reply-To: <200706071231.19630.pubmb01@skynet.be> References: <200706061623.59065.pubmb01@skynet.be> <200706061853.56601.pubmb01@skynet.be> <20070607082708.GJ10506@bristol.st.com> <200706071231.19630.pubmb01@skynet.be> Message-ID: <20070607140049.GL10506@bristol.st.com> On Thu, Jun 07, 2007 at 12:31:19PM +0200, Bruno Costacurta wrote: > Hello David, > > (note: I'm able to revoke this subkey (done but not sent to keyserver yet)). Do you mean that you have already generated the revocation certificate previously, or that you have just generated one now? > The problem is that subkey comes alone and automatically when keypair is > generated (and related keyring created). > During creation there is only one password required which is linked to the > primary key. My secret key and related password are OK. You only have one passphrase to protect the primary key; this passphrase automatically protects all of its subkeys. (Actually, I think that the passphrase protects the keyring file rather than the key, but ICBW). The fact that you don't have a separate passphrase for your subkey is normal and not a problem. > Where in this process is the secret part (and related password) of subkey > specified ? As I mentioned, you don't have a separate password. Public and secret parts are always generated together; they cannot be generated separately. > How to specify correct attributes for subkey like encrypt & decrypt ? Public parts are always used for encryption, and private parts are always used for decryption. There is an exception to this, where some keys are used for signing, but I am ignoring this since you are talking about keys generated for en/decryption. There is no point in generating a key for encryption but not decryption - they are always generated as a pair - public for encryption, and secret for decryption. If you think about it, any other scheme is nonsensical. For example, encrypting with the secret key would mean that anyone could decrypt the encrypted message (since the public key is, well, public). The secret key can't be generated from the public key, for obvious reasons. Somehow I think you've lost the secret part of the subkey. -- David Smith | Tel: +44 (0)1454 462380 Home: +44 (0)1454 616963 STMicroelectronics | Fax: +44 (0)1454 462305 Mobile: +44 (0)7932 642724 1000 Aztec West | TINA: 065 2380 GPG Key: 0xF13192F2 Almondsbury | Work Email: Dave.Smith at st.com BRISTOL, BS32 4SQ | Home Email: David.Smith at ds-electronics.co.uk From shavital at mac.com Thu Jun 7 17:32:08 2007 From: shavital at mac.com (Charly Avital) Date: Thu, 07 Jun 2007 18:32:08 +0300 Subject: decrypt : primary key or subkey ? In-Reply-To: <200706071231.19630.pubmb01@skynet.be> References: <200706061623.59065.pubmb01@skynet.be> <200706061853.56601.pubmb01@skynet.be> <20070607082708.GJ10506@bristol.st.com> <200706071231.19630.pubmb01@skynet.be> Message-ID: <466824F8.7090500@mac.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Bruno Costacurta wrote the following on 6/7/07 1:31 PM: [...] > > Hello David, > > (note: I'm able to revoke this subkey (done but not sent to keyserver yet)). > >[...] Bruno, I have just downloaded (again) your key now, and it looks like: pub 1024D/2E604D51 created: 2006-06-11 expires: never usage: SC trust: unknown validity: unknown This key was revoked on 2007-06-07 by DSA key 2E604D51 Bruno Costacurta sub 2048g/0CC897B5 created: 2006-06-11 revoked: 2007-06-07 usage: E [ unknown] (1). Bruno Costacurta [ revoked] (2) pubmb01 [ revoked] (3) pubmb02 [ revoked] (4) Bruno Costacurta [ unknown] (5) Bruno Costacurta [ unknown] (6) Bruno Costacurta It would seem that you have revoked both the primary key and the subkey. I *believe*, but I am not sure, that you could have revoked *only* the subkey, and generated a new subkey in its stead. That would have kept your primary key "alive", with a new subkey, hopefully valid for encryption to you. I might be wrong, but I believe that in the present situation, generating a new E subkey will not resuscitate your primary key. I hope you get more definite opinions from other forum subscribers. Regards, Charly -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (Darwin) Comment: GnuPG for Privacy Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEVAwUBRmgk9M3GMi2FW4PvAQhXJAgAsIzxvD3mn3+kxKUUQsGqkLdGBi19lIhW cWORBVMiIbG2XfRGcErIKdrsJ8yz3VNOWCdv7jPLCbCRJcow6HQcD+h+Rh1zdDtZ Hs7RstoLGP4+7rCCPkFtCmiIHA1VC/vN7PZ+6HKbMzxqbHAKIUnmkoFvPvod1fkB a6fgZbNcD/Yimz0cLognDRem9wBV/zPCcuutlgqIO7faCzrcMsub/Uz+OGwzsIi5 elGvcQm/c2Vx46C85IUzm8V1goE4RGSc5CDmwOHhOLkd76Oim/kS1Xwk0u6LmbOI 6E1C4aHb7ikL7YLkTKpDcn5exwNnKFWVbzhagahW7dB9RmcnMB0XeA== =FXjD -----END PGP SIGNATURE----- From khellman at mcprogramming.com Fri Jun 8 09:41:38 2007 From: khellman at mcprogramming.com (Keith Hellman) Date: Fri, 8 Jun 2007 01:41:38 -0600 Subject: Verifying Signatures in a Script Message-ID: <20070608074137.GA27256@localhost.localdomain> I would like a script to verify that I've signed a document. Verifying a signature is easy with gnupg, but I can't find a switch that requires the signature be that of a particular public key. As it is, a document signed by someone else (whose public key I have) would slip through my script if I just use the exit code. My best solution so far is to detect the identity printed out by gpg on stderr --- but this seems a fragile solution. I'd like to be able to say: $ gpg --verify-specific-user khellman at mcprogramming.com --verify signedoc.gpg Does this functionality exist? Did I miss something in the docs? Is there a workaround? TIA -- Keith Hellman #include khellman at mcprogramming.com from disclaimer import standard khellman at mines.edu -*- public key @ pgp.mit.edu B5354B76 Y!M: mcprogramming AIM/ICQ: 485403897 gtalk: jabber at mcprogramming.com -*- "In any project that is multi-threaded, most bugs will come from threading issues. This is regardless of programming language -- it's a deep, as yet ununderstood property of threads." -- Guido van Rossum -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : /pipermail/attachments/20070608/b704c175/attachment.pgp From james at freecharity.org.uk Fri Jun 8 16:52:10 2007 From: james at freecharity.org.uk (James Davis) Date: Fri, 08 Jun 2007 15:52:10 +0100 Subject: Importing backed up card generated key Message-ID: <46696D1A.6050609@freecharity.org.uk> I've just generated a key pair using my smartcard and asked it to make a backup which it did. I'm doing a practice restore to see how the procedure works and I'm a little stuck. I can import my new public key onto my keyring but when I try to import the secret key it fails to do so and I get the following output. $ gpg --import james.davis at ja.net-20070608-secret.gpg gpg: key D7DDFF42: no user ID gpg: Total number processed: 1 gpg: secret keys read: 1 $ What should I be doing? :-) James -- http://www.freecharity.org.uk/ - Free IT services for charities http://www.freecharity.org.uk/wiki/ - The VCSWiki From dan_yt555 at yahoo.com Sun Jun 10 19:33:47 2007 From: dan_yt555 at yahoo.com (Dan T.) Date: Sun, 10 Jun 2007 10:33:47 -0700 (PDT) Subject: Verifying Signatures in a Script In-Reply-To: <20070608074137.GA27256@localhost.localdomain> Message-ID: <455059.34542.qm@web63102.mail.re1.yahoo.com> --- Keith Hellman wrote: > I would like a script to verify that I've signed a document. > Verifying a signature is easy with gnupg, but I can't find a switch > that requires the signature be that of a particular public key. > > As it is, a document signed by someone else (whose public key I > have) would slip through my script if I just use the exit code. My > best solution so far is to detect the identity printed out by gpg > on stderr --- but this seems a fragile solution. > > I'd like to be able to say: $ gpg --verify-specific-user > khellman at mcprogramming.com --verify signedoc.gpg > > Does this functionality exist? Did I miss something in the docs? Is > there a workaround? Keith, Look into the --status-fd output, I think the VALIDSIG value is what you want. I hope this help. Dan ____________________________________________________________________________________ Looking for earth-friendly autos? Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center. http://autos.yahoo.com/green_center/ From hs2412 at gmail.com Mon Jun 11 18:51:16 2007 From: hs2412 at gmail.com (Hardeep Singh) Date: Mon, 11 Jun 2007 22:21:16 +0530 Subject: PGP software pirated In-Reply-To: References: Message-ID: Hi All Someone gave me a PGP signed message that unlocks the paid version of PGP. Just to be sure it worked, I tried it and then uninstalled the software (I dont use pirated stuff, GPG is much better for me). However, does this mean that someone was able to find the private key for the key PGP uses to sign licenses? If that could be found, then probably our keys can also be cracked. While I personally find this impossible, I want to know how the hackers were able to give me a signed message? Is it possible they tweaked PGP to use their private key instead of PGPs and hence PGP is not really broken? Regards Hardeep Singh From hs2412 at gmail.com Mon Jun 11 18:54:23 2007 From: hs2412 at gmail.com (Hardeep Singh) Date: Mon, 11 Jun 2007 22:24:23 +0530 Subject: Revoke and expire Message-ID: Hi When a key is revoked using the revocation certificate, does it have the same effect as reaching the expiry date of the key? In other words if I set a key to no expire but generate a revocation certificate, it is equally safe? Regards Hardeep From khellman at mcprogramming.com Mon Jun 11 18:56:38 2007 From: khellman at mcprogramming.com (Keith Hellman) Date: Mon, 11 Jun 2007 10:56:38 -0600 Subject: Verifying Signatures in a Script In-Reply-To: <455059.34542.qm@web63102.mail.re1.yahoo.com> References: <20070608074137.GA27256@localhost.localdomain> <455059.34542.qm@web63102.mail.re1.yahoo.com> Message-ID: <20070611165638.GB4294@localhost.localdomain> On Sun, Jun 10, 2007 at 10:33:47AM -0700, Dan T. wrote: > Look into the --status-fd output, I think the VALIDSIG > value is what you want. > > I hope this help. > > Dan > Just as a follow-up, I pursued Sven's idea and simply created a specialized directory: $ mkdir .my_signature Exported my public key to its location $ gpg --home ~/.my_signature --import <(gpg --export ) (or something like that...) And now I simply invoke gpg (or gpgv) from within my script as if gpg --home ~/.my_signature --verify ${FILE} ; then ... Works like a charm, it also has a benefit of easily managing the signatures I want my script to accept, without cluttering up my script will silly whose-signed-this-thing logic. I just import or remove the appropriate public keys from ./my_signature's database. Cheers. -- Keith Hellman #include khellman at mcprogramming.com from disclaimer import standard khellman at mines.edu -*- public key @ pgp.mit.edu B5354B76 Y!M: mcprogramming AIM/ICQ: 485403897 gtalk: jabber at mcprogramming.com -*- Experience is a harsh teacher. She gives the test before you learn the lesson. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : /pipermail/attachments/20070611/cd7fbdea/attachment.pgp From rjh at sixdemonbag.org Mon Jun 11 19:11:08 2007 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 11 Jun 2007 12:11:08 -0500 Subject: Revoke and expire In-Reply-To: References: Message-ID: <099E6B17-D2AC-49BB-8F43-A4E520817E89@sixdemonbag.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > When a key is revoked using the revocation certificate, does it have > the same effect as reaching the expiry date of the key? In other words > if I set a key to no expire but generate a revocation certificate, it > is equally safe? It depends on what you mean by "same effect". You can't encrypt a message to an expired key, precisely because it's expired. You can't encrypt a message to a revoked key, precisely because it's revoked. If by "same effect" you mean "both keys are equally unusable", then yeah. Same effect. If by "same effect" you mean "they work the same way", then no. Different. With one, GnuPG simply sees that the key has expired. You can unexpire the key just by resetting your computer's clock. With the other, GnuPG sees the key has been revoked, and unrevoking it is kind of problematic. - -- Robert J. Hansen "Most people are never thought about after they're gone. 'I wonder where Rob got the plutonium?' is better than most get." -- Phil Munson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iFYEAREIAAYFAkZtgiwACgkQf2XByo0Cu7PQdgDfYSHgpicOUcseTUVpWEFLp6aS hRaYL23H5181vADeP+aK/WkQFsFq401z3AJLwyIqN2KOn9cfxdnaeokBHAQBAQgA BgUCRm2CLAAKCRC3APSC/q+BCT//B/9QYb9SN30BABc/HZOzr5M702l8KT/Y1i7g 2wmHMWo6tYFO9XOdkbVApDFLHDYzK5UzphajUwkuY2rNk0Lk4/lBW725igOTIbl0 Utc2VvHd3+Ltbzli9Tpj6VjHrsV+gc1vLjF8B60A8kj9zHy88+QOUmZXFEI+r/y/ 721zF2qSf60xXRCkugn1/sttzX2fV6fi5E4S/n62n/VrkbFjUloGF2wmT5VO9dXm bmLkSHU23Z2qWNa0JUcrfc+UYT2kDSIVRO5LkvCAG/v0ViSg7GASEze+AaGrnU/3 WZnUWZumeuFoyHxoptvXALrbWRudXn2TM6hv8Cz1jndjXyILwGFN =nlgN -----END PGP SIGNATURE----- From dshaw at jabberwocky.com Mon Jun 11 19:26:16 2007 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 11 Jun 2007 13:26:16 -0400 Subject: Revoke and expire In-Reply-To: References: Message-ID: <20070611172616.GA9020@jabberwocky.com> On Mon, Jun 11, 2007 at 10:24:23PM +0530, Hardeep Singh wrote: > Hi > > When a key is revoked using the revocation certificate, does it have > the same effect as reaching the expiry date of the key? In other words > if I set a key to no expire but generate a revocation certificate, it > is equally safe? They're similar, but different. A key that has reached its expiration date is not usable, but a new expiration date can be put on it that makes the key usable again. A key that has been revoked cannot be easily un-revoked. Note that I'm talking about whole keys here. It is possible to un-revoke a revoked user ID on a key. David From rjh at sixdemonbag.org Mon Jun 11 19:08:31 2007 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 11 Jun 2007 12:08:31 -0500 Subject: PGP software pirated In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > However, does this mean that someone was able to find the private key > for the key PGP uses to sign licenses? All license enforcement mechanisms are fundamentally DRM technologies. DRM uses encryption algorithms, but DRM is not an encryption algorithm. Pretty much all computer security authorities agree that DRM is a shell game. Not only doesn't it work, but it can't work. There are some very strong arguments supporting this proposition. Don't worry about encrypted messages. There's very little chance that someone has figured out how to break the crypto going into an OpenPGP-encrypted message. All that's happened is a DRM system has been circumvented... again. > I want to know how the hackers were able to give me a > signed message? Due to the provisions of the Digital Millennium Copyright Act, this is a very dangerous question for any U.S. citizen to answer. An overzealous federal prosecutor could easily claim that an in-depth technical explanation amounts to trafficking in circumvention devices. If other people want to answer you, they certainly can. However, I'm not. - -- Robert J. Hansen "Most people are never thought about after they're gone. 'I wonder where Rob got the plutonium?' is better than most get." -- Phil Munson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iFYEAREIAAYFAkZtgY8ACgkQf2XByo0Cu7M8wADeJAAahSg4kDj3a/uLh0h87KD3 lW0Sw7jMW2PhEADeNgQxkFSyTfNGnLRglgzvFKQf8I2Pg9YXSgK6YokBHAQBAQgA BgUCRm2BjwAKCRC3APSC/q+BCTYkCAC7wD1IhLuFCnoiZdwMOwrOl+tkIGRka4Li b3uzpKhsXIf/dan1wQcettdM3Yvy5V8B+Bpv4SzYD8Y1wPbfwaLiQ0ygqjZ6JTTF HG2Kr1IldOo3sULGSiN/PVMbutHWbMGfvm/WRiuDG4BMudovu3LSXNGpk/bbCjgy eDsAzgMru+3TIXnykP4kbP9HeGwXDrQbFKt4mSJUaceKwPc1ZOdgxJTgT0afoh5x Mbbl7fyD8aPQIvW7XZruS9jiwL7pwcZB1+k7geVx0ay8xeU6KbyfifvZXCfarQGW v9s8pM6nie+ZbbrFQL+H8QQmtFZsdSrH0GwoND0rlLqRhuN0BdbI =rA5x -----END PGP SIGNATURE----- From dshaw at jabberwocky.com Mon Jun 11 19:39:59 2007 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 11 Jun 2007 13:39:59 -0400 Subject: PGP software pirated In-Reply-To: References: Message-ID: <20070611173959.GB9020@jabberwocky.com> On Mon, Jun 11, 2007 at 10:21:16PM +0530, Hardeep Singh wrote: > Hi All > > Someone gave me a PGP signed message that unlocks the paid version of > PGP. Just to be sure it worked, I tried it and then uninstalled the > software (I dont use pirated stuff, GPG is much better for me). > However, does this mean that someone was able to find the private key > for the key PGP uses to sign licenses? If that could be found, then > probably our keys can also be cracked. While I personally find this > impossible, I want to know how the hackers were able to give me a > signed message? Is it possible they tweaked PGP to use their private > key instead of PGPs and hence PGP is not really broken? I suspect what you got was either someone elses license file, or possibly something that patches the PGP code itself to bypass the need for licensing. Even if the PGP license key was somehow compromised (which I highly doubt), it does not follow that "probably our keys can also be cracked". David From hs2412 at gmail.com Tue Jun 12 17:27:05 2007 From: hs2412 at gmail.com (Hardeep Singh) Date: Tue, 12 Jun 2007 20:57:05 +0530 Subject: PGP software pirated In-Reply-To: <20070611173959.GB9020@jabberwocky.com> References: <20070611173959.GB9020@jabberwocky.com> Message-ID: > Even if the PGP license key was somehow compromised (which I highly > doubt), it does not follow that "probably our keys can also be > cracked". Why not? From rjh at sixdemonbag.org Tue Jun 12 19:16:08 2007 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 12 Jun 2007 12:16:08 -0500 Subject: PGP software pirated In-Reply-To: References: <20070611173959.GB9020@jabberwocky.com> Message-ID: <466ED4D8.5060904@sixdemonbag.org> Hardeep Singh wrote: >> Even if the PGP license key was somehow compromised (which I highly >> doubt), it does not follow that "probably our keys can also be >> cracked". > > Why not? Because DRM is not the same as encryption. It's like saying "just because you saw a car break down doesn't mean there's a fundamental problem with the wheels that we all use every day." DRM uses encryption, but DRM has a _lot_ more going on under the hood. It's far more likely that, _if_ the PGP license key was compromised, that it was compromised by an insider who knew it, that it was deliberately leaked, that it was... etc., etc. Breaking the crypto involved is literally the last thing on the list to consider. From jbruni at mac.com Wed Jun 13 03:33:46 2007 From: jbruni at mac.com (Joseph Oreste Bruni) Date: Tue, 12 Jun 2007 18:33:46 -0700 Subject: PGP software pirated In-Reply-To: References: <20070611173959.GB9020@jabberwocky.com> Message-ID: <5B3F959D-2ED0-4698-8416-72DEE9CC6FF0@mac.com> On Jun 12, 2007, at 8:27 AM, Hardeep Singh wrote: >> Even if the PGP license key was somehow compromised (which I highly >> doubt), it does not follow that "probably our keys can also be >> cracked". > > > Why not? > Breaking PGP's license key doesn't not in any way imply that my private key has been compromised. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2508 bytes Desc: not available Url : /pipermail/attachments/20070612/ab8bc8aa/attachment.bin From pubmb01 at skynet.be Wed Jun 13 17:15:47 2007 From: pubmb01 at skynet.be (Bruno Costacurta) Date: Wed, 13 Jun 2007 17:15:47 +0200 Subject: decrypt : primary key or subkey ? In-Reply-To: <466824F8.7090500@mac.com> References: <200706061623.59065.pubmb01@skynet.be> <200706071231.19630.pubmb01@skynet.be> <466824F8.7090500@mac.com> Message-ID: <200706131715.47908.pubmb01@skynet.be> On Thursday 07 June 2007 17:32:08 Charly Avital wrote: > Bruno Costacurta wrote the following on 6/7/07 1:31 PM: > [...] > > > Hello David, > > > > (note: I'm able to revoke this subkey (done but not sent to keyserver > > yet)). > > > >[...] > > Bruno, > > I have just downloaded (again) your key now, and it looks like: > > pub 1024D/2E604D51 created: 2006-06-11 expires: never usage: SC > trust: unknown validity: unknown > This key was revoked on 2007-06-07 by DSA key 2E604D51 Bruno Costacurta > > sub 2048g/0CC897B5 created: 2006-06-11 revoked: 2007-06-07 usage: E > [ unknown] (1). Bruno Costacurta > [ revoked] (2) pubmb01 > [ revoked] (3) pubmb02 > [ revoked] (4) Bruno Costacurta > [ unknown] (5) Bruno Costacurta > [ unknown] (6) Bruno Costacurta > > It would seem that you have revoked both the primary key and the subkey. > > I *believe*, but I am not sure, that you could have revoked *only* the > subkey, and generated a new subkey in its stead. That would have kept > your primary key "alive", with a new subkey, hopefully valid for > encryption to you. > > I might be wrong, but I believe that in the present situation, > generating a new E subkey will not resuscitate your primary key. > (sorry for delays. I was off and abroad). Correct. But at least the revoked key will not be used anymore for future encryption I cannot decrypt. And future sender will use a valid encryption / decyption setup. > I hope you get more definite opinions from other forum subscribers. > > Regards, > Charly > > > > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -- PGP key ID: 0x2e604d51 Key : http://www.costacurta.org/keys/bruno_costacurta_pgp_key.html Key fingerprint = 713F 7956 9441 7DEF 58ED 1951 7E07 569B 2E60 4D51 -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20070613/368d6687/attachment-0001.pgp From pubmb01 at skynet.be Wed Jun 13 17:18:54 2007 From: pubmb01 at skynet.be (Bruno Costacurta) Date: Wed, 13 Jun 2007 17:18:54 +0200 Subject: decrypt : primary key or subkey ? In-Reply-To: <20070607140049.GL10506@bristol.st.com> References: <200706061623.59065.pubmb01@skynet.be> <200706071231.19630.pubmb01@skynet.be> <20070607140049.GL10506@bristol.st.com> Message-ID: <200706131718.54944.pubmb01@skynet.be> On Thursday 07 June 2007 16:00:49 David SMITH wrote: > On Thu, Jun 07, 2007 at 12:31:19PM +0200, Bruno Costacurta wrote: > > Hello David, > > > > (note: I'm able to revoke this subkey (done but not sent to keyserver > > yet)). > > Do you mean that you have already generated the revocation certificate > previously, or that you have just generated one now? (sorry for delays. I was off and abroad). I simply revoked the subkey Elgamal and sent update to keyserver. Looks like now this is reflected and so I do not (currently) have any key for encryption. This what I intended to do as I was not able to decrypt. Later I'll created a new subkey and update it the same way (after verification of correct encrypt/decrypt behaviour). I think that the problem came few months ago : as I changed computer I exported secret key only, but not secret-subkey. And so I installed the keyring but without secret part of my subkey on my current computer. Question: An export-secret should be followed by a export-secret-subkey ? Correct ? > > > The problem is that subkey comes alone and automatically when keypair is > > generated (and related keyring created). > > During creation there is only one password required which is linked to > > the primary key. My secret key and related password are OK. > > You only have one passphrase to protect the primary key; this passphrase > automatically protects all of its subkeys. > > (Actually, I think that the passphrase protects the keyring file rather > than the key, but ICBW). The fact that you don't have a separate > passphrase for your subkey is normal and not a problem. > > > Where in this process is the secret part (and related password) of subkey > > specified ? > > As I mentioned, you don't have a separate password. > > Public and secret parts are always generated together; they cannot be > generated separately. > > > How to specify correct attributes for subkey like encrypt & decrypt ? > > Public parts are always used for encryption, and private parts are > always used for decryption. There is an exception to this, where some > keys are used for signing, but I am ignoring this since you are talking > about keys generated for en/decryption. > > There is no point in generating a key for encryption but not decryption - > they are always generated as a pair - public for encryption, and secret > for decryption. If you think about it, any other scheme is nonsensical. > For example, encrypting with the secret key would mean that anyone could > decrypt the encrypted message (since the public key is, well, public). > > The secret key can't be generated from the public key, for obvious > reasons. > > Somehow I think you've lost the secret part of the subkey. -- PGP key ID: 0x2e604d51 Key : http://www.costacurta.org/keys/bruno_costacurta_pgp_key.html Key fingerprint = 713F 7956 9441 7DEF 58ED 1951 7E07 569B 2E60 4D51 -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20070613/7911ad51/attachment-0001.pgp From dshaw at jabberwocky.com Wed Jun 13 18:04:08 2007 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 13 Jun 2007 12:04:08 -0400 Subject: decrypt : primary key or subkey ? In-Reply-To: <200706131718.54944.pubmb01@skynet.be> References: <200706061623.59065.pubmb01@skynet.be> <200706071231.19630.pubmb01@skynet.be> <20070607140049.GL10506@bristol.st.com> <200706131718.54944.pubmb01@skynet.be> Message-ID: <20070613160408.GA27488@jabberwocky.com> On Wed, Jun 13, 2007 at 05:18:54PM +0200, Bruno Costacurta wrote: > I think that the problem came few months ago : as I changed computer > I exported secret key only, but not secret-subkey. And so I > installed the keyring but without secret part of my subkey on my > current computer. > > Question: An export-secret should be followed by a > export-secret-subkey ? Correct ? No. --export-secret exports the whole secret key, including subkeys. --export-secret-subkeys exports ONLY the subkeys, and is likely not what you want. David From hhhobbit at securemecca.net Wed Jun 13 22:02:14 2007 From: hhhobbit at securemecca.net (Henry Hertz Hobbit) Date: Wed, 13 Jun 2007 14:02:14 -0600 Subject: Revoke and expire In-Reply-To: References: Message-ID: <46704D46.4090503@securemecca.net> gnupg-users-request at gnupg.org wrote: David Shaw wrote: > On Mon, Jun 11, 2007 at 10:24:23PM +0530, Hardeep Singh wrote: >> Hi >> >> When a key is revoked using the revocation certificate, does it have >> the same effect as reaching the expiry date of the key? In other words >> if I set a key to no expire but generate a revocation certificate, it >> is equally safe? > > They're similar, but different. A key that has reached its expiration > date is not usable, but a new expiration date can be put on it that > makes the key usable again. A key that has been revoked cannot be > easily un-revoked. > > Note that I'm talking about whole keys here. It is possible to > un-revoke a revoked user ID on a key. How do you unrevoke a key, especially if it is on the keyservers? I can think of making a backup of the key, revoking it and then sending the revocation to the keyservers, then unpacking the non- revoked folder, extending the date, and squirreling that away in some safe deposit box just in case I need it some time in the future. Once you are pretty sure you will never need it again you can destroy the backup. But that means it is only unrevoked for myself. Was that what you meant? But more to the point, what would most people prefer for somebody else to do when they no longer intend to use a key, especially if it is on the keyservers - allow it to expire or revoke it with some message like "key deprecated"? This is more along the line of human usability and preferences, not technical. I am assuming from what has been said that most people want the key revoked, rather than just allowing it to elapse and expire like Johannes Ullrich does. Any opinions? HHH -- Why hack in when you can drive in on Hwys. 80, 110, 194, 220, 443, 993, 994 & 995? From dshaw at jabberwocky.com Wed Jun 13 22:38:25 2007 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 13 Jun 2007 16:38:25 -0400 Subject: Revoke and expire In-Reply-To: <46704D46.4090503@securemecca.net> References: <46704D46.4090503@securemecca.net> Message-ID: <20070613203825.GA28035@jabberwocky.com> On Wed, Jun 13, 2007 at 02:02:14PM -0600, Henry Hertz Hobbit wrote: > gnupg-users-request at gnupg.org wrote: > David Shaw wrote: > > > On Mon, Jun 11, 2007 at 10:24:23PM +0530, Hardeep Singh wrote: > >> Hi > >> > >> When a key is revoked using the revocation certificate, does it have > >> the same effect as reaching the expiry date of the key? In other words > >> if I set a key to no expire but generate a revocation certificate, it > >> is equally safe? > > > > They're similar, but different. A key that has reached its expiration > > date is not usable, but a new expiration date can be put on it that > > makes the key usable again. A key that has been revoked cannot be > > easily un-revoked. > > > > Note that I'm talking about whole keys here. It is possible to > > un-revoke a revoked user ID on a key. > > How do you unrevoke a key, especially if it is on the keyservers? > I can think of making a backup of the key, revoking it and then > sending the revocation to the keyservers, then unpacking the non- > revoked folder, extending the date, and squirreling that away in > some safe deposit box just in case I need it some time in the future. > Once you are pretty sure you will never need it again you can destroy > the backup. But that means it is only unrevoked for myself. Was > that what you meant? Essentially, yes, though there are simpler ways to do it. Save a revoked key to a file and run 'gpgsplit' on it. Delete the revocation packet. Join the parts back together again, and poof: you have a unrevoked key. The catch, of course, is that the key on the keyservers is still revoked. You can send out this "non-revoked" key, but as soon as someone refreshes from a keyserver, it'll become revoked again. There are a few interesting attacks around this sort of packet tampering. Say that Alice got a copy of Bob's private key and his passphrase. Bob finds this out, and immediately revokes his key and sends the revocation to a keyserver. Later, Charlie wants to communicate with Bob, and Alice "helpfully" gives him a copy of Bob's un-revoked public key, knowing that she can read anything encrypted to it. This doesn't work in practice, as Bob will presumably notice that Charlie is using a revoked key. (GPG will actually warn Bob when decrypting Charlie's message) Still, Alice could get one message that way... > But more to the point, what would most people prefer for somebody > else to do when they no longer intend to use a key, especially if > it is on the keyservers - allow it to expire or revoke it with > some message like "key deprecated"? This is more along the line > of human usability and preferences, not technical. I am assuming > from what has been said that most people want the key revoked, > rather than just allowing it to elapse and expire like Johannes > Ullrich does. Any opinions? I have a different opinion for full keys (for which I mildly favor revocation because it's an explicit step that means "this key is dead, full stop") and subkeys, which I'd just let expire. It's not really a big deal though - either way, the key and/or subkey isn't usable. David From rjh at sixdemonbag.org Wed Jun 13 22:43:18 2007 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 13 Jun 2007 15:43:18 -0500 Subject: Revoke and expire In-Reply-To: <46704D46.4090503@securemecca.net> References: <46704D46.4090503@securemecca.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > How do you unrevoke a key, especially if it is on the keyservers? You don't. Data can only be added to keys on the keyservers. It can't be removed. This is a deliberate design decision on the part of the keyservers, and helps to prevent certain kinds of attacks. However, given that revocations typically happen by adding a revocation signature, by removing the revocation signature from your own local copy of the key you should be able to make the key usable again. - -- Robert J. Hansen "Most people are never thought about after they're gone. 'I wonder where Rob got the plutonium?' is better than most get." -- Phil Munson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iFYEAREIAAYFAkZwVuYACgkQf2XByo0Cu7NYhADfVZh2PGLikec9+BShXp7ymgrl 2Mm949xhkgFh1ADeM+u2GHMzCfyGXQJkSS1OwEHNiCODrIZ8DGB3JYkBHAQBAQgA BgUCRnBW5gAKCRC3APSC/q+BCbxwCAC9CchWGx1zXslM/UKnf7mQPAmN+CkWU/js nh7k3ecfYPNq/sZ3jCtdBgFbTNexirZfdcVa5OATD6WMRjfI8LmOAA1N3cOtzY6v rLezmITdYSdkuG90sR9pitNDjWVOB21nCwrW69l3fgwP2qNBgEv4bZSqtFxGVdvE xI/vHRnEGXdBdyU8qwziCT5oxb1KR7szi56E2zcBdCw7+azgIkvCvfZbmo+W66L9 /85AReBM8kDByk0CaHNdJBSB/051Eta/ZtVUuC2BkDcum+828EtLRQCCFXqkSAzJ HVZ6ARjUKeQDwa7kngVb4yUNKOk24e2pv1MKygLrVvUi9KdUlbAE =UHqG -----END PGP SIGNATURE----- From pubmb01 at skynet.be Thu Jun 14 08:39:03 2007 From: pubmb01 at skynet.be (Bruno Costacurta) Date: Thu, 14 Jun 2007 08:39:03 +0200 Subject: decrypt : primary key or subkey ? In-Reply-To: <20070613160408.GA27488@jabberwocky.com> References: <200706061623.59065.pubmb01@skynet.be> <200706131718.54944.pubmb01@skynet.be> <20070613160408.GA27488@jabberwocky.com> Message-ID: <200706140839.03436.pubmb01@skynet.be> On Wednesday 13 June 2007 18:04:08 David Shaw wrote: > On Wed, Jun 13, 2007 at 05:18:54PM +0200, Bruno Costacurta wrote: > > I think that the problem came few months ago : as I changed computer > > I exported secret key only, but not secret-subkey. And so I > > installed the keyring but without secret part of my subkey on my > > current computer. > > > > Question: An export-secret should be followed by a > > export-secret-subkey ? Correct ? > > No. --export-secret exports the whole secret key, including subkeys. > --export-secret-subkeys exports ONLY the subkeys, and is likely not > what you want. > > David Humm...so I can definitely not explain why my subkey was unable to decrypt message as secret key was not found. Remind: signature validation works fine. Anyway this not-working key is now revoked... ...and now what is the best way to create / add a new subkey with encryption / decryption capabilities (under Linux) ? Thanks. Bruno > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -- PGP key ID: 0x2e604d51 Key : http://www.costacurta.org/keys/bruno_costacurta_pgp_key.html Key fingerprint = 713F 7956 9441 7DEF 58ED 1951 7E07 569B 2E60 4D51 -- From pubmb01 at skynet.be Thu Jun 14 13:11:40 2007 From: pubmb01 at skynet.be (Bruno Costacurta) Date: Thu, 14 Jun 2007 13:11:40 +0200 Subject: Can someone test my encryption subkey ? Message-ID: <200706141311.48067.pubmb01@skynet.be> Hello, could you please email me an encrypted message for test ? PGP key ID: 0x2e604d51 Keyserver hkp://subkeys.pgp.net Many thanks. Bye, Bruno -- PGP key ID: 0x2e604d51 Keyserver hkp://subkeys.pgp.net Key fingerprint = 713F 7956 9441 7DEF 58ED 1951 7E07 569B 2E60 4D51 -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20070614/004e6f2b/attachment.pgp From guillaume.yziquel at free.fr Thu Jun 14 13:00:56 2007 From: guillaume.yziquel at free.fr (Guillaume Yziquel) Date: Thu, 14 Jun 2007 13:00:56 +0200 Subject: Regenerating keys on a cryptocard. Message-ID: <46711FE8.5070409@free.fr> Hello, I've got a cryptocard, and I wish to regenerate keys on it. I've already got a few keys on it, that I wish to discard. Here's part of the output of what I did: > yziquel at seldon:~$ gpg --card-edit > > Version ..........: 1.1 > Manufacturer .....: PPC Card Systems > Name of cardholder: Guillaume Yziquel > Signature PIN ....: forced > > Command> admin > Admin commands are allowed > > Command> generate > Make off-card backup of encryption key? (Y/n) Y > > gpg: NOTE: keys are already stored on the card! > > Replace existing keys? (y/N) y > gpg: sending command `SCD SETATTR' to agent failed: ec=6.32769 > gpg: error clearing forced signature PIN flag: general error > > Command> I do not really get the meaning of this message. Any help would be highly appreciated. Sincerely yours, Guillaume Yziquel. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 370 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20070614/9eafabdb/attachment.pgp From pubmb01 at skynet.be Fri Jun 15 11:35:19 2007 From: pubmb01 at skynet.be (Bruno Costacurta) Date: Fri, 15 Jun 2007 11:35:19 +0200 Subject: 'export-secret-subkeys' between 2 computers Message-ID: <200706151135.19984.pubmb01@skynet.be> Hello to all, I work on two computer and, as I created a new subkey on the first (test on this new key are OK) I'm trying to export this new secret subkey to the second computer (keyring and main secret key already present on it) 'gpg --export-secret-subkey > myfile' on computer A 'gpg --import myfile' on B However subkjey doesn't appear on B and indeed I cannot decrypt on B (but works on A) as secret is not found. (sorry do not have more log yet as currently present on A) Are my commands correct ? Or is there something specific to do to update / exported secret subkey between two computers ? Thanks. Bye, Bruno -- PGP key ID: 0x2e604d51 Key server: hkp://subkeys.pgp.net Key fingerprint = 713F 7956 9441 7DEF 58ED 1951 7E07 569B 2E60 4D51 -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20070615/0bbc574d/attachment.pgp From snoken at tunedal.nu Sat Jun 16 10:58:55 2007 From: snoken at tunedal.nu (Snoken) Date: Sat, 16 Jun 2007 10:58:55 +0200 Subject: RSA 1024 ridiculous Message-ID: <200706160932.l5G9W0QT001130@www11.aname.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I just read the latest CRYPTO-GRAM, June 15, 2007, by Bruce Schneier. He writes: "We have a new factoring record: 307 digits (1023 bits). It's a special number -- 2^1039 - 1 -- but the techniques can be generalized. Expect regular 1024-bit numbers to be factored soon. I hope RSA application users would have moved away from 1024-bit security years ago, but for those who haven't yet: wake up. http://www.physorg.com/news98962171.html " I suppose this means that 1024 bit RSA-keys are ridiculous and the Open PGP Card is a joke. And what about all web sites protected by SSL with a 1024-bit RSA-certificate? Snoken -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) - GPGrelay v0.959 iD8DBQFGc65EWisObvnr8tQRAi0rAJ9jIiFPcG+vojmX874gdNQog5MNfwCdFanW aF6loNTtu/DC85G4qoyUni8= =zURT -----END PGP SIGNATURE----- From brian at briansmith.org Sat Jun 16 17:05:20 2007 From: brian at briansmith.org (Brian Smith) Date: Sat, 16 Jun 2007 22:05:20 +0700 Subject: RSA 1024 ridiculous In-Reply-To: <200706160932.l5G9W0QT001130@www11.aname.net> References: <200706160932.l5G9W0QT001130@www11.aname.net> Message-ID: <000001c7b027$cc874a20$5e01a8c0@Junk> Snoken wrote: > I suppose this means that 1024 bit RSA-keys are ridiculous > and the Open PGP Card is a joke. And what about all web sites > protected by SSL with a 1024-bit RSA-certificate? This seems to be more-or-less on schedule: http://en.wikipedia.org/wiki/Key_size#Asymmetric_algorithm_key_lengths IF you have a life-long digital secret that you want to protect from people with hundreds of millions of dollars to spend, and you insist on using RSA public key encryption to protect it during transit over the internet, then you need to use RSA 15,360 (not a typo) + AES 256 + hope. But, I think RSA 3072 + AES 128 should be good enough to get you a waterboarding ticket; even RSA 1024 + 3DES would result in spyware or a key logger on your client machine to prevent them from having to fill up the bucket. Regarding HTTPS: If you go to any SSL certificate vendor, you will see them talking only about "256 bit SSL" and they usually have no recommendations at all regarding the RSA key length. The certificate vendors treat HTTPS as a marketing feature and not a security feature. As a result, the RSA 1024 + AES 256 is the most common combination I see when I'm browsing with Firefox. I cannot find it in the specs right now, but I think that even the latest S/MIME and PGP/MIME specs only require implementations to support RSA keys sizes up to 2048 bits. I have used 4096 bit keys for (Thawte Freemail) S/MIME certificates in Thunderbird and Outlook 2003 without problems. Regards, Brian From r.post at sara.nl Sat Jun 16 15:49:35 2007 From: r.post at sara.nl (Remco Post) Date: Sat, 16 Jun 2007 15:49:35 +0200 Subject: RSA 1024 ridiculous In-Reply-To: <200706160932.l5G9W0QT001130@www11.aname.net> References: <200706160932.l5G9W0QT001130@www11.aname.net> Message-ID: <4673EA6F.7000607@sara.nl> Snoken wrote: > Hi, > I just read the latest CRYPTO-GRAM, June 15, 2007, by Bruce Schneier. > He writes: > > "We have a new factoring record: 307 digits (1023 bits). It's a > special number -- 2^1039 - 1 -- but the techniques can be > generalized. Expect regular 1024-bit numbers to be factored soon. I > hope RSA application users would have moved away from 1024-bit > security years ago, but for those who haven't yet: wake up. > http://www.physorg.com/news98962171.html " > > I suppose this means that 1024 bit RSA-keys are ridiculous and the > Open PGP Card is a joke. And what about all web sites protected by > SSL with a 1024-bit RSA-certificate? As I read the article, last time it took 9 years to generalize the method used for the special number to any number. Now, my key is valid for one year, and I expect messages protected by that key to be a secret for maybe a year longer, that means that at the current rate I'll be able to use my card for at least 5 more years end maybe longer. And then still, it takes 11 months on a huge cluster of computers to factor out my key, or to compare, all of the compute power available in this country for a substantial amount of time. I guess you're right, if the nsa is after you, you need stronger keys. If it's just anybody else, I'd say you'll be safe for a few more years. Your ssl certificates will have expired by that time, and maybe a 2048 bit openpgp card will be available (at a reasonable prise). > Snoken > _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users -- Met vriendelijke groeten, Remco Post SARA - Reken- en Netwerkdiensten http://www.sara.nl High Performance Computing Tel. +31 20 592 3000 Fax. +31 20 668 3167 PGP Key fingerprint = 6367 DFE9 5CBC 0737 7D16 B3F6 048A 02BF DC93 94EC "I really didn't foresee the Internet. But then, neither did the computer industry. Not that that tells us very much of course - the computer industry didn't even foresee that the century was going to end." -- Douglas Adams From shavital at mac.com Sat Jun 16 19:24:00 2007 From: shavital at mac.com (Charly Avital) Date: Sat, 16 Jun 2007 20:24:00 +0300 Subject: Failing to compile in MacOS X [Announce] Libgcrypt 1.3.0 (development) released In-Reply-To: <87r6pw95d0.fsf@wheatstone.g10code.de> References: <87r6pw95d0.fsf@wheatstone.g10code.de> Message-ID: <46741CB0.2030008@mac.com> Werner Koch wrote the following on 5/4/07 2:48 PM: > Hello! > > We are pleased to announce the availability of Libgcrypt 1.3.0. This > is the first release of a series of development versions ebentually > leading to a new stable 1.4 series. [...] Configured for: Darwin (i386-apple-darwin8.9.1),MacOS X 10.4.9 ------make----- gcc -E -I../src -I../src -DHAVE_CONFIG_H \ `test -f 'mpih-add1.S' || echo './'`mpih-add1.S \ | grep -v '^#' > mpih-add1.s make[2]: *** [mpih-add1.lo] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 ---------------- I guess I'll have to wait for 1.4. Werner, thanks. Charly From rjh at sixdemonbag.org Sat Jun 16 19:47:25 2007 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 16 Jun 2007 12:47:25 -0500 Subject: RSA 1024 ridiculous In-Reply-To: <200706160932.l5G9W0QT001130@www11.aname.net> References: <200706160932.l5G9W0QT001130@www11.aname.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 I'll get back to this bit in a moment. ;) > I suppose this means that 1024 bit RSA-keys are ridiculous and the > Open PGP Card is a joke. Not necessarily. There's certainly a strong argument to be made for moving to RSA-2048, but just because something is susceptible to an attack involving an enormous amount of horsepower doesn't mean that it's useless. As an example, you apparently have no objection to signing with SHA1, despite the fact it's subject to an attack requiring a work factor of about 2**63... which is in the same ballpark as factoring RSA-1024. If it takes over a CPU-century of number crunching and extraordinarily special mathematical properties to be able to break RSA-1024, then I think the RSA-1024 keys I use for secure SMTP are just fine. Likewise, credit card transactions secured by RSA-1024 SSL certs are probably just fine for now; there are far, _far_ easier ways to get credit card numbers than to rent a year of supercomputing time just to get the key to _one_ web site. We should be migrating to RSA-2048, sure. Just like we should be migrating to SHA256. But it's not the case that RSA-1024 is 'ridiculous' or the OpenPGP card is 'a joke'. - -- Robert J. Hansen "Most people are never thought about after they're gone. 'I wonder where Rob got the plutonium?' is better than most get." -- Phil Munson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iFYEAREIAAYFAkZ0Ii0ACgkQf2XByo0Cu7PikgDffNZ71tKX/GnkIyVX77tE2r3K sXCIx8vqn4oblwDghCzUjJvxGNS7btDhE+qlLTuXbUouMgoQqfafvYkBHAQBAQgA BgUCRnQiLQAKCRC3APSC/q+BCS0dB/44AJ68utpLuk3jRmt0gBQbcRNSERLX3G79 FCBH7ReBhYCc6luJR0OGsdOb0DfVVStfot7DkvTsXIc+YHeE3U9JAmaSqrVD9Qwm y40uTu9PXM/87k17nUtTN6S5OLo0IX0IA2pXqde+cY1gA7lz3fBFN5XUUrCnC1W9 ZUoekK7bV9JheL7//QHkmflkgOnLaA/+0Iq1V5+9rjM0ySSNvQvijFUjcivL3UAN CsD/a09GOtiFxwFzrx7+56imd3H+j5tRfhmIhCc5l+ZQnZGSEhnVl249W7EYRXbj +faV9LY3wBkMvH14bKdkgoLfCqHNX2XmGkjWigztcro1cSfGn34N =YHhO -----END PGP SIGNATURE----- From bahamut at digital-signal.net Sun Jun 17 01:46:05 2007 From: bahamut at digital-signal.net (Andrew Berg) Date: Sat, 16 Jun 2007 18:46:05 -0500 Subject: RSA 1024 ridiculous In-Reply-To: <200706160932.l5G9W0QT001130@www11.aname.net> References: <200706160932.l5G9W0QT001130@www11.aname.net> Message-ID: <4674763D.6020600@digital-signal.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Snoken wrote: > Hi, I just read the latest CRYPTO-GRAM, June 15, 2007, by Bruce > Schneier. He writes: > > "We have a new factoring record: 307 digits (1023 bits). It's a > special number -- 2^1039 - 1 -- but the techniques can be > generalized. Expect regular 1024-bit numbers to be factored soon. > I hope RSA application users would have moved away from 1024-bit > security years ago, but for those who haven't yet: wake up. > http://www.physorg.com/news98962171.html " > > I suppose this means that 1024 bit RSA-keys are ridiculous and the > Open PGP Card is a joke. And what about all web sites protected by > SSL with a 1024-bit RSA-certificate? Snoken > Anyone who's worried about an entity with the power needed to break their messages in time to make any use of it has probably already been using a longer key size for a while now. - -- Windows NT 5.1.2600.2180 | Thunderbird 2.0.0.4 | Enigmail 0.95.1 | GPG 1.4.7 Key ID: 0x60A78FCB - available on major keyservers and upon request Fingerprint: 4A84 CAE2 A0D3 2AEB 71F6 07FD F88E 0340 60A7 8FCB -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEVAwUBRnR2PfiOA0Bgp4/LAQOpngf+JCg56eeHSN4KCD1UBW5AF7FjHMqy1pEO pY9M31GWR/1hnaHG3b0/EYjGUXiH5Ev5zBlwKFk7/fDqHqcrw88A+WRcpbVx1oHs ZQfjYUkqMic66sEwJ9HrXkBt1XQOFK6jsuVq7Ar3Irqy7rr2MzOYJcvpAgAoPJb3 34phVybR2UHS8N8JBe7qNXZvK0hkicH0mYO1a42HkWgsMU8WxpTAoDblVDIdCsRI 4wy0NP+j1i3LmY+SPwr/0U4yyYPp/6+0Y3UpVTHd8LZbEVVdsWJb6bZWAcDhEqTn +xfXSRIDQeee/Z8icBvn4J6W4I4rHQBMdzON9mjcf8sfekZ5biyAlA== =CeDk -----END PGP SIGNATURE----- From benjamin at py-soft.co.uk Sun Jun 17 02:12:06 2007 From: benjamin at py-soft.co.uk (Benjamin Donnachie) Date: Sun, 17 Jun 2007 01:12:06 +0100 Subject: RSA 1024 ridiculous In-Reply-To: <4674763D.6020600@digital-signal.net> References: <200706160932.l5G9W0QT001130@www11.aname.net> <4674763D.6020600@digital-signal.net> Message-ID: <46747C56.90901@py-soft.co.uk> Andrew Berg wrote: > Anyone who's worried about an entity with the power needed to break > their messages in time to make any use of it has probably already been > using a longer key size for a while now. Or, more likely for someone that paranoid, a one time pad. Ben From benjamin at py-soft.co.uk Sun Jun 17 03:01:17 2007 From: benjamin at py-soft.co.uk (Benjamin Donnachie) Date: Sun, 17 Jun 2007 02:01:17 +0100 Subject: Failing to compile in MacOS X [Announce] Libgcrypt 1.3.0 (development) released In-Reply-To: <46741CB0.2030008@mac.com> References: <87r6pw95d0.fsf@wheatstone.g10code.de> <46741CB0.2030008@mac.com> Message-ID: <467487DD.1050504@py-soft.co.uk> Charly Avital wrote: >> We are pleased to announce the availability of Libgcrypt 1.3.0. This >> is the first release of a series of development versions ebentually >> leading to a new stable 1.4 series. > Configured for: Darwin (i386-apple-darwin8.9.1),MacOS X 10.4.9 No problems here with Darwin (powerpc-apple-darwin8.9.0), MacOSX 10.4.9 =================== All 16 tests passed =================== I haven't tried to build a fat/universal binary yet though. Take care, Ben From stef at caunter.ca Sun Jun 17 03:36:25 2007 From: stef at caunter.ca (Stef Caunter) Date: Sat, 16 Jun 2007 20:36:25 -0500 (EST) Subject: RSA 1024 ridiculous In-Reply-To: <200706160932.l5G9W0QT001130@www11.aname.net> References: <200706160932.l5G9W0QT001130@www11.aname.net> Message-ID: On Sat, 16 Jun 2007, Snoken wrote: > I suppose this means that 1024 bit RSA-keys are ridiculous and the > Open PGP Card is a joke. And what about all web sites protected by > SSL with a 1024-bit RSA-certificate? The only thing that is ridiculous is this flame-bait language. Feel the freedom to post back with something thoughtful and constructive after you read up on the considerable body of science on the subject. Until then, no one should be rising to this bait. Stefan Caunter http://caunter.ca/contact.html From shavital at mac.com Sun Jun 17 06:31:16 2007 From: shavital at mac.com (Charly Avital) Date: Sun, 17 Jun 2007 00:31:16 -0400 Subject: Failing to compile in MacOS X [Announce] Libgcrypt 1.3.0 (development) released In-Reply-To: <467487DD.1050504@py-soft.co.uk> References: <87r6pw95d0.fsf@wheatstone.g10code.de> <46741CB0.2030008@mac.com> <467487DD.1050504@py-soft.co.uk> Message-ID: <4674B914.6060808@mac.com> Benjamin Donnachie wrote the following on 6/16/07 9:01 PM: > Charly Avital wrote: >>> We are pleased to announce the availability of Libgcrypt 1.3.0. This >>> is the first release of a series of development versions ebentually >>> leading to a new stable 1.4 series. >> Configured for: Darwin (i386-apple-darwin8.9.1),MacOS X 10.4.9 > > No problems here with Darwin (powerpc-apple-darwin8.9.0), MacOSX 10.4.9 > > =================== > All 16 tests passed > =================== > > I haven't tried to build a fat/universal binary yet though. > Now from a PPC Configured for: Darwin (powerpc-apple-darwin8.9.0). ------------make----------- grep: /usr/local/lib/libintl.la: No such file or directory sed: /usr/local/lib/libintl.la: No such file or directory libtool: link: `/usr/local/lib/libintl.la' is not a valid libtool archive make[2]: *** [libgcrypt.la] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 ------------------- Seems that the system is missing some library? Charly From maccrest at gmail.com Sun Jun 17 11:14:35 2007 From: maccrest at gmail.com (Crest) Date: Sun, 17 Jun 2007 11:14:35 +0200 Subject: RSA 1024 ridiculous In-Reply-To: <000001c7b027$cc874a20$5e01a8c0@Junk> References: <200706160932.l5G9W0QT001130@www11.aname.net> <000001c7b027$cc874a20$5e01a8c0@Junk> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Am 16.06.2007 um 17:05 schrieb Brian Smith: > IF you have a life-long digital secret that you want to protect from > people with hundreds of millions of dollars to spend, and you > insist on > using RSA public key encryption to protect it during transit over the > internet, then you need to use RSA 15,360 (not a typo) + AES 256 + > hope. > But, I think RSA 3072 + AES 128 should be good enough to get you a > waterboarding ticket; even RSA 1024 + 3DES would result in spyware > or a > key logger on your client machine to prevent them from having to > fill up > the bucket. Does GnuPG support RSA keys longer than 4096 bits? I saw a modified old PGPi version doing so but ist took half a minute to sign a short message off less than one 1kb on a pentium1 based laptop... Isn't it more usefull to switch to ECC instead of using that large keys? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQIVAwUBRnT7e/950yjRhRAFAQptHQ//Whn2WqiGe+eMHlGVU153dsET9G/Jb/fb RMG6y8k0IL+N3xMHwJ3/QbSYEhXFcR+F7Nlw7c959ooMuX9w3lRmRffiv4LcCHdb B0lOkdjCsNo5NSuO0F4jwB3jnEltFWk0Ju2NBB9dwnr/83QOjjZctBqbDwiygNr/ tyNaWw54OV1YcwGSCIeTBYEr5FZO/O3ul5g3UxDS7LBkVlT3k2AxQkXeMBscEF8G CxlQ26EWZfnf3mcUC6clGDUfwpakP7sUKIQm4iZTkk1TuTw85lVuklUzvJTz6Cu8 CxkS3zh18/PdBIeSAvURcQD5OALeIKAi4vL5CPFlPRx13jXuep+pyLeDVAMkjM8O htNZhxZ1/eI/Kcrusv/rhXqnwnw9JhjPBmUQf3u2/2Wp5wJ4V0REntzkjxNEaxk8 h9zjZbbYS46eqtpShlst5emaRfgwdsPIm7ux+2YpHqnlIELrmgrVdsuXxal5mBmg ImKLR8TgUb5gp7/fCWiii6cZsoN5Eb5CROFxvgOcdscU++HmH36VnMUXObde6fpr 2cz3viFuUPi9Fbg5zOdoCosCrEs2GYyxVb19HPEu4B/qQN/xw+0FVFawsyl6brDZ 1WdO3DX/a0+vqBhBrrKqdkXSZPi5WxoJjsJIyXI724W7gsaAoCH33NwtdO6ahtRO HOQovbEoWjw= =zKtG -----END PGP SIGNATURE----- From r.post at sara.nl Sun Jun 17 16:32:42 2007 From: r.post at sara.nl (Remco Post) Date: Sun, 17 Jun 2007 16:32:42 +0200 Subject: RSA 1024 ridiculous In-Reply-To: References: <200706160932.l5G9W0QT001130@www11.aname.net> <000001c7b027$cc874a20$5e01a8c0@Junk> Message-ID: <4675460A.1070004@sara.nl> Crest wrote: > > Isn't it more usefull to switch to ECC instead of using that large keys? Does gnupg support elliptic curve crypto? ;-) -- Met vriendelijke groeten, Remco Post SARA - Reken- en Netwerkdiensten http://www.sara.nl High Performance Computing Tel. +31 20 592 3000 Fax. +31 20 668 3167 PGP Key fingerprint = 6367 DFE9 5CBC 0737 7D16 B3F6 048A 02BF DC93 94EC "I really didn't foresee the Internet. But then, neither did the computer industry. Not that that tells us very much of course - the computer industry didn't even foresee that the century was going to end." -- Douglas Adams From benjamin at py-soft.co.uk Sun Jun 17 16:40:12 2007 From: benjamin at py-soft.co.uk (Benjamin Donnachie) Date: Sun, 17 Jun 2007 15:40:12 +0100 Subject: RSA 1024 ridiculous In-Reply-To: <4675460A.1070004@sara.nl> References: <200706160932.l5G9W0QT001130@www11.aname.net> <000001c7b027$cc874a20$5e01a8c0@Junk> <4675460A.1070004@sara.nl> Message-ID: <467547CC.3090905@py-soft.co.uk> Remco Post wrote: > Does gnupg support elliptic curve crypto? ;-) Not yet... Ben From bahamut at digital-signal.net Sun Jun 17 17:46:17 2007 From: bahamut at digital-signal.net (Andrew Berg) Date: Sun, 17 Jun 2007 10:46:17 -0500 Subject: RSA 1024 ridiculous In-Reply-To: <4675460A.1070004@sara.nl> References: <200706160932.l5G9W0QT001130@www11.aname.net> <000001c7b027$cc874a20$5e01a8c0@Junk> <4675460A.1070004@sara.nl> Message-ID: <46755749.4000303@digital-signal.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Remco Post wrote: > Does gnupg support elliptic curve crypto? ;-) I found this link on the Wikipedia page: http://www.calcurco.cat/eccGnuPG/index.en.html - -- Windows NT 5.1.2600.2180 | Thunderbird 2.0.0.4 | Enigmail 0.95.1 | GPG 1.4.7 Key ID: 0x60A78FCB - available on major keyservers and upon request Fingerprint: 4A84 CAE2 A0D3 2AEB 71F6 07FD F88E 0340 60A7 8FCB -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEVAwUBRnVXSfiOA0Bgp4/LAQMD+AgAuQNLsp7dQxl9jgiTjOejqIBBuRF2t7Z/ TvIU0HC7fztaJD0SaaX65IZlGM54+v8tmD90chBMtzM7AkrJchEQ/AAh6NmeMoGv X/GgK8KhVgMUxDAhCQPYgqXLIvlXQPKrVg7I723ge93DKGwIg/rt7zjUfEM0rc7Q 2UYib/DePZzaq7olS9WOE4ngR5jBrhoLGJwsRrCjLWA6ayiLBkuaaQhg8N/I6eau GKbgnIsZnh1RHgmm/QBr5qvRwZcNfAYAt78zp3gGMMMBaj5Bk+GsxX9nZXI8RU8z L/m17BuSZsuD9q0KL/wAeldvMZhE8sNdy7jpmjYIc2fVgGgoitacDw== =25Ca -----END PGP SIGNATURE----- From dshaw at jabberwocky.com Sun Jun 17 18:58:35 2007 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 17 Jun 2007 12:58:35 -0400 Subject: RSA 1024 ridiculous In-Reply-To: References: <200706160932.l5G9W0QT001130@www11.aname.net> <000001c7b027$cc874a20$5e01a8c0@Junk> Message-ID: <20070617165835.GA7252@jabberwocky.com> On Sun, Jun 17, 2007 at 11:14:35AM +0200, Crest wrote: > Am 16.06.2007 um 17:05 schrieb Brian Smith: > > > IF you have a life-long digital secret that you want to protect from > > people with hundreds of millions of dollars to spend, and you > > insist on > > using RSA public key encryption to protect it during transit over the > > internet, then you need to use RSA 15,360 (not a typo) + AES 256 + > > hope. > > But, I think RSA 3072 + AES 128 should be good enough to get you a > > waterboarding ticket; even RSA 1024 + 3DES would result in spyware > > or a > > key logger on your client machine to prevent them from having to > > fill up > > the bucket. > > Does GnuPG support RSA keys longer than 4096 bits? I saw a modified > old PGPi version doing so but ist took half a minute to sign a short > message off less than one 1kb on a pentium1 based laptop... GnuPG supports RSA keys much larger than 4096 bits. It does not, however, currently allow generation of such keys, so the keys must come from elsewhere. > Isn't it more usefull to switch to ECC instead of using that large keys? For many cases, yes. However, ECC is not yet defined for OpenPGP. Until that happens, there won't be official support for it in GnuPG. Note, though, there is a ECC version of GnuPG out there if you want to try it. David From atom at smasher.org Sun Jun 17 17:48:14 2007 From: atom at smasher.org (Atom Smasher) Date: Sun, 17 Jun 2007 11:48:14 -0400 (EDT) Subject: RSA 1024 ridiculous In-Reply-To: <4675460A.1070004@sara.nl> References: <200706160932.l5G9W0QT001130@www11.aname.net> <000001c7b027$cc874a20$5e01a8c0@Junk> <4675460A.1070004@sara.nl> Message-ID: <20070617154819.85990.qmail@smasher.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Sun, 17 Jun 2007, Remco Post wrote: > Does gnupg support elliptic curve crypto? ;-) ====================== if you're paranoid about RSA, then there's no reason to go to ECC since the math behind it is still young and uncertain. while a 1024 bit RSA key ~may~ not be secure for a long time, it's old age is due only to computing horsepower, not a "break" in the math behind it. as such, a larger RSA key buys time... and only time will tell if it buys "enough" time for a particular need. gpg does support RSA-2048/SHA-256 (or even RSA-4096/SHA-512) which is what i've been using for a while now. i'll sign this email with RSA-2048/SHA-256 (my default on this key) just to show what it looks like. it's a big signature block, but not ridiculous and on a reasonably powerful computer it's hardly a noticeable delay to work with such keys. - -- ...atom ________________________ http://atom.smasher.org/ 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 ------------------------------------------------- "Next time you hear a scientist asserting that gene splicing is safe, remind yourself that there is no scientific evidence for that statement." -- Donella H. Meadows, adjunct professor of environmental studies, Dartmouth College -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) Comment: What is this gibberish? Comment: http://atom.smasher.org/links/#digital_signatures iQEcBAEBCAAGBQJGdVfDAAoJEAx/d+cTpVcihScIAKERMem7anBsU6GGBTlSDFhy 06QSnLycBLsAPoSWG/MMQgZ58ReOk7u3XRer0xzVa6ogBn6wSvvJ68/Vwz26Zzxl cAhlZn2NSAAvXrXu6Zbne+zLX/sv7FWuGfS+nyd+BBLWXU9UDlLYpxlTigNwsCLU 2+EjGO+O4XtY/GVEAWSWxk0jCfLOXAQ0EJoky6WN2r3tpEQm/LjYqeFlOhmQ9YaP nZwCx0So21L/GBa7B0W6vIiMuLnIww4E5L/gScUFuBQDYeLd3qh7ZvnsGFuJkBfh /0C4gACMBRIFLfNesZ1mSpcmBukGqz1R/6AjTmgfEAOI2QgfMxLhUbKXp0gukG0= =CkyM -----END PGP SIGNATURE----- From bahamut at digital-signal.net Sun Jun 17 20:02:58 2007 From: bahamut at digital-signal.net (Andrew Berg) Date: Sun, 17 Jun 2007 13:02:58 -0500 Subject: RSA 1024 ridiculous In-Reply-To: <20070617154819.85990.qmail@smasher.org> References: <200706160932.l5G9W0QT001130@www11.aname.net> <000001c7b027$cc874a20$5e01a8c0@Junk> <4675460A.1070004@sara.nl> <20070617154819.85990.qmail@smasher.org> Message-ID: <46757752.2040000@digital-signal.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Atom Smasher wrote: > gpg does support RSA-2048/SHA-256 (or even RSA-4096/SHA-512) which > is what i've been using for a while now. i'll sign this email with > RSA-2048/SHA-256 (my default on this key) just to show what it > looks like. it's a big signature block, but not ridiculous and on a > reasonably powerful computer it's hardly a noticeable delay to > work with such keys. Try signing/encrypting files that are tens, hundreds, or thousands of megabytes in size. Sure, your average machine can sign/encrypt messages that don't even fill a cluster without breaking a sweat, but if the sensitive data is large, RSA-4096 isn't a good choice unless a gov't agency wants that data. - -- Windows NT 5.1.2600.2180 | Thunderbird 2.0.0.4 | Enigmail 0.95.1 | GPG 1.4.7 Key ID: 0x60A78FCB - available on major keyservers and upon request Fingerprint: 4A84 CAE2 A0D3 2AEB 71F6 07FD F88E 0340 60A7 8FCB -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEVAwUBRnV3UviOA0Bgp4/LAQN7hgf/buVG0w8ddbzysqDJT/AA5tfFnmEbotzS y+26YnXoGn1TgghyCL1h2GC4UXirFGWj50Ql5TuuJBR2xvt8/StRe1ZVYOKaHTs4 pytDLMyi4/K93uNdavnIt5NijYFmrJhFLTSm6/d3l+eEZl/d4jkovJc/YqjvsFOf 73lHUDbBDzvACjPi7maU4StCNgbybQ114Tm9mgtDwIzqtSkDODkV4kUtmVVFypnf Tu4haS8KOOepsYTIGSxxhrTJOgI7E/iLDq/9dMUFYaH8XKpb2pJnHTUkExGYZdKm mbopiCM8xKOalPrNaiCnkH0HbqOyNjdX8VwWe4CoGoj82UeJ99aCqQ== =nEp3 -----END PGP SIGNATURE----- From benjamin at py-soft.co.uk Sun Jun 17 20:14:47 2007 From: benjamin at py-soft.co.uk (Benjamin Donnachie) Date: Sun, 17 Jun 2007 19:14:47 +0100 Subject: New version of mac-gpg2 In-Reply-To: <467579B9.4060903@py-soft.co.uk> References: <87r6pw95d0.fsf@wheatstone.g10code.de> <46741CB0.2030008@mac.com> <467579B9.4060903@py-soft.co.uk> Message-ID: <46757A17.3020000@py-soft.co.uk> Benjamin Donnachie wrote: > As previous mac-gpg2 releases, this release is intended for power users > only. Universal binary, MacOSX Tiger 10.4.9 and above. Ben From bahamut at digital-signal.net Sun Jun 17 20:20:17 2007 From: bahamut at digital-signal.net (Andrew Berg) Date: Sun, 17 Jun 2007 13:20:17 -0500 Subject: RSA 1024 ridiculous In-Reply-To: <46757A1E.4010201@uibk.ac.at> References: <200706160932.l5G9W0QT001130@www11.aname.net> <000001c7b027$cc874a20$5e01a8c0@Junk> <4675460A.1070004@sara.nl> <20070617154819.85990.qmail@smasher.org> <46757752.2040000@digital-signal.net> <46757A1E.4010201@uibk.ac.at> Message-ID: <46757B61.90006@digital-signal.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Robert H?bener wrote: > Andrew Berg wrote: >> Try signing/encrypting files that are tens, hundreds, or >> thousands of megabytes in size. Sure, your average machine can >> sign/encrypt messages that don't even fill a cluster without >> breaking a sweat, but if the sensitive data is large, RSA-4096 >> isn't a good choice unless a gov't agency wants that data. > The work for the RSA-part of the algorithm is always the same: It > only has to process either the hash of the message/file or the key > for the symmetric cipher. I don't completely understand. Does this mean that encryption/signature time is only dependent on the hash, and that RSA key size doesn't matter in this regard? - -- Windows NT 5.1.2600.2180 | Thunderbird 2.0.0.4 | Enigmail 0.95.1 | GPG 1.4.7 Key ID: 0x60A78FCB - available on major keyservers and upon request Fingerprint: 4A84 CAE2 A0D3 2AEB 71F6 07FD F88E 0340 60A7 8FCB -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEVAwUBRnV7YfiOA0Bgp4/LAQOH2gf+POMCNDoSeQeGYuct0RTMPCaV2ByvB0wB 2uXCpGPqlA71pgd+wQ+UC/yEE0f+8v3j3lv7PBfM4e3q3HJhcsAAZJe6lcCYGX1Z duF9yRfZdrn2TcCIL6URdMds788HWUyGurazzun+kJzUfEkd3hE0BPWyvzyBKV82 7c+ti7v2cPAVhcRx2ZDQ50ttVpbWNuIFzRWevS94ns6YQ/HOk9YW2ZB/wowEtOXk nxivQqWgCEO0meRjPiw4uhS2TNdP5tnKrr0Yh6kXOf2t27L6PNU2JN8tRIA9DByH muy6q5ZQcoF0P0uN/tvE2hZfD4tkXu6cvkZW/G60GEuWYSpdL51uAA== =u+hz -----END PGP SIGNATURE----- From dshaw at jabberwocky.com Sun Jun 17 20:48:03 2007 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 17 Jun 2007 14:48:03 -0400 Subject: RSA 1024 ridiculous In-Reply-To: <46757B61.90006@digital-signal.net> References: <200706160932.l5G9W0QT001130@www11.aname.net> <000001c7b027$cc874a20$5e01a8c0@Junk> <4675460A.1070004@sara.nl> <20070617154819.85990.qmail@smasher.org> <46757752.2040000@digital-signal.net> <46757A1E.4010201@uibk.ac.at> <46757B61.90006@digital-signal.net> Message-ID: <20070617184803.GB31743@jabberwocky.com> On Sun, Jun 17, 2007 at 01:20:17PM -0500, Andrew Berg wrote: > Robert H?bener wrote: > > Andrew Berg wrote: > >> Try signing/encrypting files that are tens, hundreds, or > >> thousands of megabytes in size. Sure, your average machine can > >> sign/encrypt messages that don't even fill a cluster without > >> breaking a sweat, but if the sensitive data is large, RSA-4096 > >> isn't a good choice unless a gov't agency wants that data. > > The work for the RSA-part of the algorithm is always the same: It > > only has to process either the hash of the message/file or the key > > for the symmetric cipher. > I don't completely understand. Does this mean that > encryption/signature time is only dependent on the hash, and that RSA > key size doesn't matter in this regard? Not exactly. There are two main costs when signing a file: the cost to hash the file, which is dependent on the size of the file and the chosen hash algorithm. The other cost is the signing algorithm. Since the data signed in a signature is the hash output, and since hashes are generally tiny relative to the size of the file, this is really the cost of the signing algorithm itself (the biggest hash algorithm supported by GnuPG is SHA-512, and that's only 64 bytes long). David From benjamin at py-soft.co.uk Sun Jun 17 20:13:13 2007 From: benjamin at py-soft.co.uk (Benjamin Donnachie) Date: Sun, 17 Jun 2007 19:13:13 +0100 Subject: New version of mac-gpg2 (was Re: Failing to compile in MacOS X [Announce] Libgcrypt 1.3.0 (development) released) In-Reply-To: <46741CB0.2030008@mac.com> References: <87r6pw95d0.fsf@wheatstone.g10code.de> <46741CB0.2030008@mac.com> Message-ID: <467579B9.4060903@py-soft.co.uk> Charly Avital wrote: > I guess I'll have to wait for 1.4. I've just prepared a new version of gpg v2.0.4 for the Mac which uses libgcrypt v.1.3.0 It can be found at http://www.py-soft.co.uk/~benjamin/download/mac-gpg/mac-gnupg-2.0.4-2.zip with detached signature at http://www.py-soft.co.uk/~benjamin/download/mac-gpg/mac-gnupg-2.0.4-2.zip.sig gpg (GnuPG) 2.0.4 Copyright (C) 2007 Free Software Foundation, Inc. This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details. Home: ~/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA, ELG Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH Hash: MD5, SHA1, RIPEMD160, TIGER192, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 As previous mac-gpg2 releases, this release is intended for power users only. Ben From bahamut at digital-signal.net Sun Jun 17 21:01:47 2007 From: bahamut at digital-signal.net (Andrew Berg) Date: Sun, 17 Jun 2007 14:01:47 -0500 Subject: RSA 1024 ridiculous In-Reply-To: <46757FBC.10105@radde.name> References: <200706160932.l5G9W0QT001130@www11.aname.net> <000001c7b027$cc874a20$5e01a8c0@Junk> <4675460A.1070004@sara.nl> <20070617154819.85990.qmail@smasher.org> <46757752.2040000@digital-signal.net> <46757FBC.10105@radde.name> Message-ID: <4675851B.3000405@digital-signal.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Sven Radde wrote: > The actual "bulk" data processing is done by a symmetric algorithm > / hash function. You only encrypt the key to the symmetric > algorithm / sign the hash value. Both are typically 256bit or > smaller. > > In fact, the larger the data you want to process, the *smaller* the > impact of a larger key is. (If it takes minutes to hash a few > gigabytes, it doesn't matter if signing the hash takes 10, 100 or > 1000 milliseconds.) I think I understand after doing a little research as suggested. Only the hash is signed, and only the key (for the symmetric encryption) is encrypted with the public key, and the message itself is encrypted symmetrically. The recipient unlocks the symmetric key with the private key that corresponds to the public key with which it was encrypted and can then decrypt the message. Large file sizes aren't an issue because the files (or messages) are encrypted symmetrically, which is much more efficient than encrypting them directly asymmetrically. Right? - -- Windows NT 5.1.2600.2180 | Thunderbird 2.0.0.4 | Enigmail 0.95.1 | GPG 1.4.7 Key ID: 0x60A78FCB - available on major keyservers and upon request Fingerprint: 4A84 CAE2 A0D3 2AEB 71F6 07FD F88E 0340 60A7 8FCB -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEVAwUBRnWFGviOA0Bgp4/LAQME+Qf/S8YTteXkIWKFfzZr7d3ERRSiqOz7BEJX JEKv12pve0U4WIPQW11g7nTomKVDOgk8ALMTaAkXA5x1u9KJ7KNV5y9ewMtxXPxz a1jTWUzZgrJdReWM7t7FtOaLojPwdZbOoTtlcM+skektsCMs/XdStCO4xVTzKJwI 3G2sDpMX/pVNSpKSbfs842h4Px51DkQxK4M0Hg0lzO9nxC9+mAIUfHEU0PIeFR/s ttsRA+autGY+HJOpDKwRWyDXkcOkjVZY4Dc7Jdl1OycYNbsXloyxJykBE2y1s24Z RytmUc1Qbzk/d9D6Z9sE0h3zeU5pooyR8ic7INyvcpT+4l/U5EZe4A== =RLRi -----END PGP SIGNATURE----- From eocsor at gmail.com Sun Jun 17 20:43:31 2007 From: eocsor at gmail.com (Roscoe) Date: Mon, 18 Jun 2007 04:13:31 +0930 Subject: RSA 1024 ridiculous In-Reply-To: <46757B61.90006@digital-signal.net> References: <200706160932.l5G9W0QT001130@www11.aname.net> <000001c7b027$cc874a20$5e01a8c0@Junk> <4675460A.1070004@sara.nl> <20070617154819.85990.qmail@smasher.org> <46757752.2040000@digital-signal.net> <46757A1E.4010201@uibk.ac.at> <46757B61.90006@digital-signal.net> Message-ID: RSA keysize will influence how long it takes you to encrypt or sign a message. But how long the RSA signing/encryption step takes is going to be the same no matter what the message length. That's because you are only ever signing a hash of the message or encrypting the symmetric session key used to encrypt the message. I doubt I could notice the difference on my computer between encrypting at 20GB tarball with a 1024bit key or a 4096bit key. With large amounts of data most of the time is spent on the symmetric encryption (or perhaps on compression or disk io?). The bigger the amount of data you're encrypting the less you're going to notice RSA keysize differences :). On 6/18/07, Andrew Berg wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: RIPEMD160 > > Robert H?bener wrote: > > Andrew Berg wrote: > >> Try signing/encrypting files that are tens, hundreds, or > >> thousands of megabytes in size. Sure, your average machine can > >> sign/encrypt messages that don't even fill a cluster without > >> breaking a sweat, but if the sensitive data is large, RSA-4096 > >> isn't a good choice unless a gov't agency wants that data. > > The work for the RSA-part of the algorithm is always the same: It > > only has to process either the hash of the message/file or the key > > for the symmetric cipher. > I don't completely understand. Does this mean that > encryption/signature time is only dependent on the hash, and that RSA > key size doesn't matter in this regard? > > - -- > Windows NT 5.1.2600.2180 | Thunderbird 2.0.0.4 | Enigmail 0.95.1 | GPG > 1.4.7 > Key ID: 0x60A78FCB - available on major keyservers and upon request > Fingerprint: 4A84 CAE2 A0D3 2AEB 71F6 07FD F88E 0340 60A7 8FCB > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iQEVAwUBRnV7YfiOA0Bgp4/LAQOH2gf+POMCNDoSeQeGYuct0RTMPCaV2ByvB0wB > 2uXCpGPqlA71pgd+wQ+UC/yEE0f+8v3j3lv7PBfM4e3q3HJhcsAAZJe6lcCYGX1Z > duF9yRfZdrn2TcCIL6URdMds788HWUyGurazzun+kJzUfEkd3hE0BPWyvzyBKV82 > 7c+ti7v2cPAVhcRx2ZDQ50ttVpbWNuIFzRWevS94ns6YQ/HOk9YW2ZB/wowEtOXk > nxivQqWgCEO0meRjPiw4uhS2TNdP5tnKrr0Yh6kXOf2t27L6PNU2JN8tRIA9DByH > muy6q5ZQcoF0P0uN/tvE2hZfD4tkXu6cvkZW/G60GEuWYSpdL51uAA== > =u+hz > -----END PGP SIGNATURE----- > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > From r.post at sara.nl Sun Jun 17 21:42:01 2007 From: r.post at sara.nl (Remco Post) Date: Sun, 17 Jun 2007 21:42:01 +0200 Subject: RSA 1024 ridiculous In-Reply-To: <46757B61.90006@digital-signal.net> References: <200706160932.l5G9W0QT001130@www11.aname.net> <000001c7b027$cc874a20$5e01a8c0@Junk> <4675460A.1070004@sara.nl> <20070617154819.85990.qmail@smasher.org> <46757752.2040000@digital-signal.net> <46757A1E.4010201@uibk.ac.at> <46757B61.90006@digital-signal.net> Message-ID: <46758E89.8070508@sara.nl> Andrew Berg wrote: > Robert H?bener wrote: >> The work for the RSA-part of the algorithm is always the same: It >> only has to process either the hash of the message/file or the key >> for the symmetric cipher. > I don't completely understand. Does this mean that > encryption/signature time is only dependent on the hash, and that RSA > key size doesn't matter in this regard? > there is a hash calculated over the message, the longer the message, the longer it takes to calculate the hash (given a particular hash algorithm). Then the hash is encrypted using your secret key (in RSA), the longer your key, the longer this step takes (again given a particular hash alg.). So, a longer key has relatively little impact on the total time, esp. when signing long messages. (any yes we do this because public/private key crypto is quite cpu intensive). Also, because of this, there is a session key generated for each message, and that key is encrypted using recipients public key when encrypting a message. So in order to achieve good message security, you need both a strong rsa key and a strong session key. -- Met vriendelijke groeten, Remco Post SARA - Reken- en Netwerkdiensten http://www.sara.nl High Performance Computing Tel. +31 20 592 3000 Fax. +31 20 668 3167 PGP Key fingerprint = 6367 DFE9 5CBC 0737 7D16 B3F6 048A 02BF DC93 94EC "I really didn't foresee the Internet. But then, neither did the computer industry. Not that that tells us very much of course - the computer industry didn't even foresee that the century was going to end." -- Douglas Adams From newton at hammet.net Sun Jun 17 21:24:22 2007 From: newton at hammet.net (Newton Hammet) Date: Sun, 17 Jun 2007 14:24:22 -0500 Subject: RSA 1024 ridiculous / RSA 8192 sublime, and, possible with gnupg. In-Reply-To: <20070617165835.GA7252@jabberwocky.com> References: <200706160932.l5G9W0QT001130@www11.aname.net> <000001c7b027$cc874a20$5e01a8c0@Junk> <20070617165835.GA7252@jabberwocky.com> Message-ID: <1182108262.6087.25.camel@linux> On Sun, 2007-06-17 at 12:58 -0400, David Shaw wrote: > >> >>> Lot's of other stuff, not top-posted here. > GnuPG supports RSA keys much larger than 4096 bits. It does not, > however, currently allow generation of such keys, so the keys must > come from elsewhere. > > > Isn't it more usefull to switch to ECC instead of using that large keys? > > For many cases, yes. However, ECC is not yet defined for OpenPGP. > Until that happens, there won't be official support for it in GnuPG. > Note, though, there is a ECC version of GnuPG out there if you want to > try it. > > David > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users To coax bigger RSA keys out of gnupg-1.4.7 you have to download and recompile the source, but with one change in the following file: gnupg-1.4.7/g10/keygen.c Here is diff -r output, 2 source trees, one source tree containing the single difference: nhammet at linux:~/gpg_test_8192> diff -r * 2>&1|grep -v 'Only in' diff -r gnupg-1.4.7/g10/keygen.c gnupg_1.4.7x/g10/keygen.c 1528a1529 > max=8192; In more detail it's the following case stanza: case PUBKEY_ALGO_RSA: min=1024; max=8192; /* Line of code to allow 8192 key generation.*/ break; It is the case stanza in the first switch statement in the function: ask_keysize(int algo) in the file g10/keygen.c I can successfully generate an 8192-key (in under 10 minutes). If I get around 2it, I will test this key for signing, maybe generate a 8192-bit RSA sub-key and test that, too. I did this before in gnupg-1.2.1 (Check the mailing list archives) but it was a different change... I think, to a header file. (I don't have or can no longer find the detritus from that excursion) I was much more energetic then testing, signing, encrypting, and decrypting with a 8192-bit RSA key. The real rub will be to see if it behaves well with unaltered (for 8192 key generation) gnupg-1.4.7) for encrypting, signing, decrypting, etc., but I suspect it will be copacetic with unaltered official gnupg-1.4.7. (Werner Koch and the gang are pretty thorough with this code, it is high quality stuff) Regards, Newton -- Public Key: 4096R/136FC036 2004-02-09 Newton Hammet Key fingerprint = 785F DFF3 7029 3FBD 45CE 747C 93CA E808 136F C036 Key servers: pgp.mit.edu, others... From newton at hammet.net Sun Jun 17 19:41:16 2007 From: newton at hammet.net (Newton Hammet) Date: Sun, 17 Jun 2007 12:41:16 -0500 Subject: RSA 1024 ridiculous /8192 is sublime In-Reply-To: <20070617165835.GA7252@jabberwocky.com> References: <200706160932.l5G9W0QT001130@www11.aname.net> <000001c7b027$cc874a20$5e01a8c0@Junk> <20070617165835.GA7252@jabberwocky.com> Message-ID: <1182102077.6087.5.camel@linux> gnupg as distributed may not be generating larger than 4096 bit keys but it is easy enough to (or was in the past) to modify the source code in I think one place and change it to whatever you want. In my case I was able to successfully generate a 8192-bit RSA key and tested it with encryption, decryption, signing, etc. and it worked. My Hard drive, like my closet and garage, however is resisting my attempts to figure out where I put this particular piece of enterprise. (I think it was back in 2003 +/-). I will keep looking for it. -Newgon On Sun, 2007-06-17 at 12:58 -0400, David Shaw wrote: > On Sun, Jun 17, 2007 at 11:14:35AM +0200, Crest wrote: > > Am 16.06.2007 um 17:05 schrieb Brian Smith: > > > > > IF you have a life-long digital secret that you want to protect from > > > people with hundreds of millions of dollars to spend, and you > > > insist on > > > using RSA public key encryption to protect it during transit over the > > > internet, then you need to use RSA 15,360 (not a typo) + AES 256 + > > > hope. > > > But, I think RSA 3072 + AES 128 should be good enough to get you a > > > waterboarding ticket; even RSA 1024 + 3DES would result in spyware > > > or a > > > key logger on your client machine to prevent them from having to > > > fill up > > > the bucket. > > > > Does GnuPG support RSA keys longer than 4096 bits? I saw a modified > > old PGPi version doing so but ist took half a minute to sign a short > > message off less than one 1kb on a pentium1 based laptop... > > GnuPG supports RSA keys much larger than 4096 bits. It does not, > however, currently allow generation of such keys, so the keys must > come from elsewhere. > > > Isn't it more usefull to switch to ECC instead of using that large keys? > > For many cases, yes. However, ECC is not yet defined for OpenPGP. > Until that happens, there won't be official support for it in GnuPG. > Note, though, there is a ECC version of GnuPG out there if you want to > try it. > > David > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -- Public Key: 4096R/136FC036 2004-02-09 Newton Hammet Key fingerprint = 785F DFF3 7029 3FBD 45CE 747C 93CA E808 136F C036 Key servers: pgp.mit.edu, others... From jeandavid8 at verizon.net Sun Jun 17 20:49:21 2007 From: jeandavid8 at verizon.net (Jean-David Beyer) Date: Sun, 17 Jun 2007 14:49:21 -0400 Subject: Which key is used when more than one are valid? Message-ID: <46758231.3040805@verizon.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 My gnupg file that I get with edit-keys myuid contains, among other things: sub 2048g/48FF0850 created: 2007-02-24 expires: 2008-02-24 sub 4096g/124E0663 created: 2007-06-17 expires: 2009-06-16 How do I know which key is used when sending e-mail? Or is this a Thunderbird question? - -- .~. Jean-David Beyer Registered Linux User 85642. /V\ PGP-Key: 9A2FC99A Registered Machine 241939. /( )\ Shrewsbury, New Jersey http://counter.li.org ^^-^^ 14:45:01 up 5 days, 19:45, 5 users, load average: 4.13, 4.21, 4.30 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGdYIwPtu2XpovyZoRArhqAKDPQET44cuCxGO1oFYZsUsLJh8fiwCgmetE 6W6u+B98xcLDDy+msrqrsv8= =IuPV -----END PGP SIGNATURE----- From wk at gnupg.org Sun Jun 17 22:40:17 2007 From: wk at gnupg.org (Werner Koch) Date: Sun, 17 Jun 2007 22:40:17 +0200 Subject: RSA 1024 ridiculous In-Reply-To: <46757752.2040000@digital-signal.net> (Andrew Berg's message of "Sun, 17 Jun 2007 13:02:58 -0500") References: <200706160932.l5G9W0QT001130@www11.aname.net> <000001c7b027$cc874a20$5e01a8c0@Junk> <4675460A.1070004@sara.nl> <20070617154819.85990.qmail@smasher.org> <46757752.2040000@digital-signal.net> Message-ID: <87ejkas4b2.fsf@wheatstone.g10code.de> On Sun, 17 Jun 2007 20:02, bahamut at digital-signal.net said: > Try signing/encrypting files that are tens, hundreds, or thousands of > megabytes in size. Sure, your average machine can sign/encrypt > messages that don't even fill a cluster without breaking a sweat, but > if the sensitive data is large, RSA-4096 isn't a good choice unless a > gov't agency wants that data. Although I agree that 4096 bit RSA is far too paranoid, the size of a file to encrypt is independent of the public key size. The bulk of the file is encrypted using a symmetric cipher, i.e AES 128 or 256. SHA-256 is not used at all for encryption - only SHA-1 for a special kind of checksum (a MIC). Shalom-Salam, Werner From dshaw at jabberwocky.com Sun Jun 17 23:18:39 2007 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 17 Jun 2007 17:18:39 -0400 Subject: RSA 1024 ridiculous /8192 is sublime In-Reply-To: <1182102077.6087.5.camel@linux> References: <200706160932.l5G9W0QT001130@www11.aname.net> <000001c7b027$cc874a20$5e01a8c0@Junk> <20070617165835.GA7252@jabberwocky.com> <1182102077.6087.5.camel@linux> Message-ID: <20070617211838.GC31743@jabberwocky.com> On Sun, Jun 17, 2007 at 12:41:16PM -0500, Newton Hammet wrote: > gnupg as distributed may not be generating larger than 4096 bit keys > but it is easy enough to (or was in the past) to modify the source code > in I think one place and change it to whatever you want. > > In my case I was able to successfully generate a 8192-bit RSA key > and tested it with encryption, decryption, signing, etc. and it > worked. > > My Hard drive, like my closet and garage, however is resisting > my attempts to figure out where I put this particular piece of > enterprise. (I think it was back in 2003 +/-). > > I will keep looking for it. It's in keygen.c:ask_keysize. It's trivial to change, but be aware that we've set it to 4096 for a reason (several reasons). Of course, I firmly believe in the right of everyone to shoot themselves in the foot if they insist on it. David From dshaw at jabberwocky.com Sun Jun 17 23:20:32 2007 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 17 Jun 2007 17:20:32 -0400 Subject: Which key is used when more than one are valid? In-Reply-To: <46758231.3040805@verizon.net> References: <46758231.3040805@verizon.net> Message-ID: <20070617212032.GD31743@jabberwocky.com> On Sun, Jun 17, 2007 at 02:49:21PM -0400, Jean-David Beyer wrote: > My gnupg file that I get with edit-keys myuid > contains, among other things: > > sub 2048g/48FF0850 created: 2007-02-24 expires: 2008-02-24 > sub 4096g/124E0663 created: 2007-06-17 expires: 2009-06-16 > > How do I know which key is used when sending e-mail? > Or is this a Thunderbird question? GnuPG picks the subkey for you unless explicitly told which one to use. In the above case, it would pick the second key, as it is more recent. David From dshaw at jabberwocky.com Sun Jun 17 23:38:49 2007 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 17 Jun 2007 17:38:49 -0400 Subject: RSA 1024 ridiculous / RSA 8192 sublime, and, possible with gnupg. In-Reply-To: <1182108262.6087.25.camel@linux> References: <200706160932.l5G9W0QT001130@www11.aname.net> <000001c7b027$cc874a20$5e01a8c0@Junk> <20070617165835.GA7252@jabberwocky.com> <1182108262.6087.25.camel@linux> Message-ID: <20070617213849.GA8066@jabberwocky.com> On Sun, Jun 17, 2007 at 02:24:22PM -0500, Newton Hammet wrote: > I did this before in gnupg-1.2.1 (Check the mailing list archives) > but it was a different change... I think, to a header file. (I don't > have or can no longer find the detritus from that excursion) I was > much more energetic then testing, signing, encrypting, and decrypting > with a 8192-bit RSA key. > > The real rub will be to see if it behaves well with unaltered (for > 8192 key generation) gnupg-1.4.7) for encrypting, signing, decrypting, > etc., but I suspect it will be copacetic with unaltered official > gnupg-1.4.7. (Werner Koch and the gang are pretty thorough with this > code, it is high quality stuff) There is no magic "stop working if the key is > 4096 bits" in the RSA code. The math doesn't work that way, anyway. The limit in GnuPG is artificial, but carefully considered to balance multiple factors like performance, and perhaps most crucially, interoperability with other OpenPGP implementations. Every year someone (re)patches GnuPG to raise the key size limit for RSA. This is followed by a flurry of messages until people see just how inconvenient a giant RSA signature is and then move on. This year is slightly different in that I'm waiting for someone to discover they can also raise the key size limit for DSA. That, at least, is marginally less strange as I put in code to make the hash size automatically rise as the key size rises. Using SHA-1 with a 8192-bit RSA key is... odd. David From jmoore3rd at bellsouth.net Mon Jun 18 00:24:16 2007 From: jmoore3rd at bellsouth.net (John W. Moore III) Date: Sun, 17 Jun 2007 18:24:16 -0400 Subject: Which key is used when more than one are valid? In-Reply-To: <20070617212032.GD31743@jabberwocky.com> References: <46758231.3040805@verizon.net> <20070617212032.GD31743@jabberwocky.com> Message-ID: <4675B490.9080304@bellsouth.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 David Shaw wrote: > On Sun, Jun 17, 2007 at 02:49:21PM -0400, Jean-David Beyer wrote: >> My gnupg file that I get with edit-keys myuid >> contains, among other things: >> >> sub 2048g/48FF0850 created: 2007-02-24 expires: 2008-02-24 >> sub 4096g/124E0663 created: 2007-06-17 expires: 2009-06-16 >> >> How do I know which key is used when sending e-mail? >> Or is this a Thunderbird question? > > GnuPG picks the subkey for you unless explicitly told which one to > use. In the above case, it would pick the second key, as it is more > recent. However, 'Account Settings' within Thunderbird does allow You to select which Key to use _if_ Enigmail is also Installed. JOHN ;) Timestamp: Sunday 17 Jun 2007, 18:24 --400 (Eastern Daylight Time) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8-svn4511: (MingW32) Comment: Public Key at: http://tinyurl.com/8cpho Comment: Gossamer Spider Web of Trust: http://www.gswot.org Comment: My Homepage: http://tinyurl.com/yzhbhx iQEcBAEBCgAGBQJGdbSOAAoJEBCGy9eAtCsPkqgH/2IwEzCq7AQ4Fea7QSzkO7d9 G9jFJ02bfdkGAkIeHT0SHGfHmsvwaNlCKq0b1GkeAYPr1EsFw181f17+cCswO3mg MhjibdKtJN7qcR/gbfDq/j0EhW6t+XYMPIGY/O3vJ7KZNU/EjoKAQXHcQBHXqH2Z fSGje8Wqqgapc+FvdhKWQm+d6LmsmgBm1jSfLDN8GDZH5qU+ZpXTmODEfOfSx/dP FsmYd51J6wZQMySMAxJ29Wq7wJoTaDJ64IudEBVhf2DFCfvnM6O78CMzoFWRhtIF OrHglneP9WvTcNWWCn/nJWoACHxmf4YbBg33gph512e8WinklOp/hfGdwWG3YQ0= =TQql -----END PGP SIGNATURE----- From jmoore3rd at bellsouth.net Mon Jun 18 00:31:15 2007 From: jmoore3rd at bellsouth.net (John W. Moore III) Date: Sun, 17 Jun 2007 18:31:15 -0400 Subject: RSA 1024 ridiculous / RSA 8192 sublime, and, possible with gnupg. In-Reply-To: <20070617213849.GA8066@jabberwocky.com> References: <200706160932.l5G9W0QT001130@www11.aname.net> <000001c7b027$cc874a20$5e01a8c0@Junk> <20070617165835.GA7252@jabberwocky.com> <1182108262.6087.25.camel@linux> <20070617213849.GA8066@jabberwocky.com> Message-ID: <4675B633.5050808@bellsouth.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 David Shaw wrote: > This year is slightly different in that I'm waiting for someone to > discover they can also raise the key size limit for DSA. That, at > least, is marginally less strange as I put in code to make the hash > size automatically rise as the key size rises. Using SHA-1 with a > 8192-bit RSA key is... odd. Wait No longer. However, as You point out; Why use a large Key with the available Hash selections. Even considering DSA2, Everyone I know has already begun migration away from DSA to RSA. Personally, I feel Compiling GnuPG with the ability to generate an 8192 Key, while amusing, is akin to selling someone a .22cal hollowpoint weapon instead of a .45ACP for Personal Defense because it 'kicks' less. JOHN ;) Timestamp: Sunday 17 Jun 2007, 18:30 --400 (Eastern Daylight Time) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8-svn4511: (MingW32) Comment: Public Key at: http://tinyurl.com/8cpho Comment: Gossamer Spider Web of Trust: http://www.gswot.org Comment: My Homepage: http://tinyurl.com/yzhbhx iQEcBAEBCgAGBQJGdbYxAAoJEBCGy9eAtCsPqhYH/2G07aLHAH7uRUiianl9c/VD rbIoFoAHr1BbnSfH0tzuGippnhZZyOVWqKIMJruTXrebT3jKc+J6FKUbPFMVUbMP cSr8m7R/+tYBBrN/YIIEPEP7hLgOh92/0P2wR6O4iSu1xTAzJUsgnJc5cpf51/w7 eFOfrOquu6hFkvLbQJtCugZ1Idr/Zuw/PRHl1MkncSXOzBIBQ/tiOnLfIZ0Ym4SN dxu3prb9D6cbII7Jd7qJvLHVp+rerdTapzsE8PIh2bTBKogqaOokoBzwrZYzjd0h gPZXEEZ/+446ST2KxA8kOGC7fnhYYu+G4O2rIBGedAL/IlVDm1jU9lLZdLHHrFA= =usf1 -----END PGP SIGNATURE----- From jeandavid8 at verizon.net Mon Jun 18 02:26:35 2007 From: jeandavid8 at verizon.net (Jean-David Beyer) Date: Sun, 17 Jun 2007 20:26:35 -0400 Subject: Which key is used when more than one are valid? In-Reply-To: <4675B490.9080304@bellsouth.net> References: <46758231.3040805@verizon.net> <20070617212032.GD31743@jabberwocky.com> <4675B490.9080304@bellsouth.net> Message-ID: <4675D13B.9010907@verizon.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 John W. Moore III wrote: > David Shaw wrote: >>> On Sun, Jun 17, 2007 at 02:49:21PM -0400, Jean-David Beyer wrote: >>>> My gnupg file that I get with edit-keys myuid >>>> contains, among other things: >>>> >>>> sub 2048g/48FF0850 created: 2007-02-24 expires: 2008-02-24 >>>> sub 4096g/124E0663 created: 2007-06-17 expires: 2009-06-16 >>>> >>>> How do I know which key is used when sending e-mail? >>>> Or is this a Thunderbird question? >>> GnuPG picks the subkey for you unless explicitly told which one to >>> use. In the above case, it would pick the second key, as it is more >>> recent. > > However, 'Account Settings' within Thunderbird does allow You to select > which Key to use _if_ Enigmail is also Installed. > > JOHN ;) > Timestamp: Sunday 17 Jun 2007, 18:24 --400 (Eastern Daylight Time) It allows me to pick the key, but not the sub-key, unless I am missing something. - -- .~. Jean-David Beyer Registered Linux User 85642. /V\ PGP-Key: 9A2FC99A Registered Machine 241939. /( )\ Shrewsbury, New Jersey http://counter.li.org ^^-^^ 20:25:01 up 6 days, 1:25, 3 users, load average: 4.51, 4.29, 4.11 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGddE7Ptu2XpovyZoRAhwLAJsHutIe1FSKiuSfS6AovqvTv897JgCeMFgp ra/GHa7ZEWiq3VQ0k6iUlOU= =zFXY -----END PGP SIGNATURE----- From jharris at widomaker.com Mon Jun 18 02:55:26 2007 From: jharris at widomaker.com (Jason Harris) Date: Sun, 17 Jun 2007 20:55:26 -0400 Subject: new (2007-06-10) keyanalyze results (+sigcheck) Message-ID: <20070618005526.GA900@wilma.widomaker.com> New keyanalyze results are available at: http://keyserver.kjsl.com/~jharris/ka/2007-06-10/ Signatures are now being checked using keyanalyze+sigcheck: http://dtype.org/~aaronl/ Earlier reports are also available, for comparison: http://keyserver.kjsl.com/~jharris/ka/ Even earlier monthly reports are at: http://dtype.org/keyanalyze/ SHA-1 hashes and sizes for all the "permanent" files: 2c78886524d01203b8a805e6e72224f84d10cb68 14902056 preprocess.keys 799cf84b30198c0f84128f47a68e13d0154bedbe 8640906 othersets.txt fa83f9a4e2b4563cdac52a531db8f5428fe3ccd4 3560718 msd-sorted.txt baaeed0c20caa1a4a3560b18bc67065532e47d51 2276 keyring_stats fd7ca4bac414586aae346eaff3cfeb1721bbb02d 1401542 msd-sorted.txt.bz2 ac997bfae18a6f202f675fd23165e68af751df7b 26 other.txt 0ab8465957042f48f28a266ec595b076ca7f4ebf 1878107 othersets.txt.bz2 2c9378b0d8c1ca93b3e00615670b1709f8f477f7 6070207 preprocess.keys.bz2 4b48f13770f4e53fe2b636299f9e7b432d9f48bc 15373 status.txt 3aebe1595990611a814ddc67e2908b7ab5db2997 194403 top1000table.html be74cdef4e48f9d494ca72f1eaf1f2ece827f443 29602 top1000table.html.gz ad7643888b57086d0c88be4d39cc133bc9b05dac 9714 top50table.html 022e831a11ef152e44e483a65638b1b712f0eea8 2529 D3/D39DA0E3 -- Jason Harris | NIC: JH329, PGP: This _is_ PGP-signed, isn't it? jharris at widomaker.com _|_ web: http://keyserver.kjsl.com/~jharris/ Got photons? (TM), (C) 2004 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 313 bytes Desc: not available Url : /pipermail/attachments/20070617/8fc30aa1/attachment.pgp From JPClizbe at tx.rr.com Mon Jun 18 04:01:39 2007 From: JPClizbe at tx.rr.com (John Clizbe) Date: Sun, 17 Jun 2007 21:01:39 -0500 Subject: Which key is used when more than one are valid? In-Reply-To: <4675D13B.9010907@verizon.net> References: <46758231.3040805@verizon.net> <20070617212032.GD31743@jabberwocky.com> <4675B490.9080304@bellsouth.net> <4675D13B.9010907@verizon.net> Message-ID: <4675E783.7030200@tx.rr.com> Jean-David Beyer wrote: > John W. Moore III wrote: >> David Shaw wrote: >>>> On Sun, Jun 17, 2007 at 02:49:21PM -0400, Jean-David Beyer wrote: >>>>> My gnupg file that I get with edit-keys myuid >>>>> contains, among other things: >>>>> >>>>> sub 2048g/48FF0850 created: 2007-02-24 expires: 2008-02-24 >>>>> sub 4096g/124E0663 created: 2007-06-17 expires: 2009-06-16 >>>>> >>>>> How do I know which key is used when sending e-mail? >>>>> Or is this a Thunderbird question? >>>> GnuPG picks the subkey for you unless explicitly told which one to >>>> use. In the above case, it would pick the second key, as it is more >>>> recent. > >> However, 'Account Settings' within Thunderbird does allow You to select >> which Key to use _if_ Enigmail is also Installed. > > It allows me to pick the key, but not the sub-key, unless I am missing > something. Subkeys may be explicitly specified by appending an exclamation mark (!) suffix; eg, 0x124E0663! This flag tells GnuPG to use the specified primary or secondary key and not to try and calculate which primary or secondary key to use. -- John P. Clizbe Inet: John (a) Mozilla-Enigmail.org You can't spell fiasco without SCO. PGP/GPG KeyID: 0x608D2A10/0x18BB373A "what's the key to success?" / "two words: good decisions." "what's the key to good decisions?" / "one word: experience." "how do i get experience?" / "two words: bad decisions." "Just how do the residents of Haiku, Hawai'i hold conversations?" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 663 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20070617/5c248feb/attachment-0001.pgp From dshaw at jabberwocky.com Mon Jun 18 04:27:37 2007 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 17 Jun 2007 22:27:37 -0400 Subject: RSA 1024 ridiculous / RSA 8192 sublime, and, possible with gnupg. In-Reply-To: <4675B633.5050808@bellsouth.net> References: <200706160932.l5G9W0QT001130@www11.aname.net> <000001c7b027$cc874a20$5e01a8c0@Junk> <20070617165835.GA7252@jabberwocky.com> <1182108262.6087.25.camel@linux> <20070617213849.GA8066@jabberwocky.com> <4675B633.5050808@bellsouth.net> Message-ID: <20070618022737.GA8360@jabberwocky.com> On Sun, Jun 17, 2007 at 06:31:15PM -0400, John W. Moore III wrote: > David Shaw wrote: > > > This year is slightly different in that I'm waiting for someone to > > discover they can also raise the key size limit for DSA. That, at > > least, is marginally less strange as I put in code to make the hash > > size automatically rise as the key size rises. Using SHA-1 with a > > 8192-bit RSA key is... odd. > > Wait No longer. However, as You point out; Why use a large Key with the > available Hash selections. Even considering DSA2, Everyone I know has > already begun migration away from DSA to RSA. Personally, I feel > Compiling GnuPG with the ability to generate an 8192 Key, while amusing, > is akin to selling someone a .22cal hollowpoint weapon instead of a > .45ACP for Personal Defense because it 'kicks' less. I have no idea what this means... which makes it an excellent analogy for the key size question. It takes some understanding of the issues to know why a particular key size matches up with a particular hash size, is used with particular software, for particular usage, etc. I don't understand the issues in your example (beyond saying "they're two different bullets"), so if I needed to choose between them, I'd have to do some learning first to even understand the question, much less reach the right answer for me. The defaults in GnuPG are chosen to be basically sane for the overwhelming majority of users. People who are recompiling GnuPG need to understand the implications of the change they are making and be aware they're throwing away that safety net. David From atom at smasher.org Mon Jun 18 06:04:11 2007 From: atom at smasher.org (Atom Smasher) Date: Mon, 18 Jun 2007 00:04:11 -0400 (EDT) Subject: RSA 1024 ridiculous In-Reply-To: <46757752.2040000@digital-signal.net> References: <200706160932.l5G9W0QT001130@www11.aname.net> <000001c7b027$cc874a20$5e01a8c0@Junk> <4675460A.1070004@sara.nl> <20070617154819.85990.qmail@smasher.org> <46757752.2040000@digital-signal.net> Message-ID: <20070618040408.90162.qmail@smasher.org> On Sun, 17 Jun 2007, Andrew Berg wrote: > Try signing/encrypting files that are tens, hundreds, or thousands of > megabytes in size. Sure, your average machine can sign/encrypt messages > that don't even fill a cluster without breaking a sweat, but if the > sensitive data is large, RSA-4096 isn't a good choice unless a gov't > agency wants that data. ===================== regardless of the size of the message... if it's being signed/verified then you're signing/verifying a hash. if it's being de/encrypted you're de/encrypting a session key. for all practical purposes the overhead of using larger keys and hashes doesn't get worse with larger messages. -- ...atom ________________________ http://atom.smasher.org/ 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 ------------------------------------------------- "Your password must be at least 18770 characters and cannot repeat any of your previous 30689 passwords. Please type a different password. Type a password that meets these requirements in both text boxes." -- Microsoft takes security seriously in Knowledge Base Article Q276304. From atom at smasher.org Mon Jun 18 06:23:21 2007 From: atom at smasher.org (Atom Smasher) Date: Mon, 18 Jun 2007 00:23:21 -0400 (EDT) Subject: RSA 1024 ridiculous / RSA 8192 sublime, and, possible with gnupg. In-Reply-To: <20070618022737.GA8360@jabberwocky.com> References: <200706160932.l5G9W0QT001130@www11.aname.net> <000001c7b027$cc874a20$5e01a8c0@Junk> <20070617165835.GA7252@jabberwocky.com> <1182108262.6087.25.camel@linux> <20070617213849.GA8066@jabberwocky.com> <4675B633.5050808@bellsouth.net> <20070618022737.GA8360@jabberwocky.com> Message-ID: <20070618042318.6450.qmail@smasher.org> On Sun, 17 Jun 2007, David Shaw wrote: > The defaults in GnuPG are chosen to be basically sane for the > overwhelming majority of users. People who are recompiling GnuPG need > to understand the implications of the change they are making and be > aware they're throwing away that safety net. ====================== maybe the above text, or something like it, should be included in the code as a comment just above the lines that get changed to increase the key size... /* edit the line below to shoot yourself in the foot */ -- ...atom ________________________ http://atom.smasher.org/ 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 ------------------------------------------------- "None are more hopelessly enslaved than those who falsely believe they are free." -- Johann Wolfgang Von Goethe From sven at radde.name Sun Jun 17 20:38:52 2007 From: sven at radde.name (Sven Radde) Date: Sun, 17 Jun 2007 20:38:52 +0200 Subject: RSA 1024 ridiculous In-Reply-To: <46757752.2040000@digital-signal.net> References: <200706160932.l5G9W0QT001130@www11.aname.net> <000001c7b027$cc874a20$5e01a8c0@Junk> <4675460A.1070004@sara.nl> <20070617154819.85990.qmail@smasher.org> <46757752.2040000@digital-signal.net> Message-ID: <46757FBC.10105@radde.name> Hi! Andrew Berg schrieb: > Try signing/encrypting files that are tens, hundreds, or thousands of > megabytes in size. Sure, your average machine can sign/encrypt > messages that don't even fill a cluster without breaking a sweat, but > if the sensitive data is large, RSA-4096 isn't a good choice unless a > gov't agency wants that data. No matter what size the data is that you want to encrypt/sign, the size of the public key only adds a constant factor to it. The actual "bulk" data processing is done by a symmetric algorithm / hash function. You only encrypt the key to the symmetric algorithm / sign the hash value. Both are typically 256bit or smaller. In fact, the larger the data you want to process, the *smaller* the impact of a larger key is. (If it takes minutes to hash a few gigabytes, it doesn't matter if signing the hash takes 10, 100 or 1000 milliseconds.) Using email actually is something like the "worst case" for large public keys. You may want to do some research on "hybrid" cryptosystems for more thorough information. cu, Sven From robert.huebener at uibk.ac.at Sun Jun 17 20:14:54 2007 From: robert.huebener at uibk.ac.at (=?ISO-8859-1?Q?Robert_H=FCbener?=) Date: Sun, 17 Jun 2007 20:14:54 +0200 Subject: RSA 1024 ridiculous In-Reply-To: <46757752.2040000@digital-signal.net> References: <200706160932.l5G9W0QT001130@www11.aname.net> <000001c7b027$cc874a20$5e01a8c0@Junk> <4675460A.1070004@sara.nl> <20070617154819.85990.qmail@smasher.org> <46757752.2040000@digital-signal.net> Message-ID: <46757A1E.4010201@uibk.ac.at> Andrew Berg wrote: > Try signing/encrypting files that are tens, hundreds, or thousands of > megabytes in size. Sure, your average machine can sign/encrypt > messages that don't even fill a cluster without breaking a sweat, but > if the sensitive data is large, RSA-4096 isn't a good choice unless a > gov't agency wants that data. The work for the RSA-part of the algorithm is always the same: It only has to process either the hash of the message/file or the key for the symmetric cipher. From james at freecharity.org.uk Mon Jun 18 12:10:57 2007 From: james at freecharity.org.uk (James Davis) Date: Mon, 18 Jun 2007 11:10:57 +0100 Subject: Importing backed up card generated key In-Reply-To: <46696D1A.6050609@freecharity.org.uk> References: <46696D1A.6050609@freecharity.org.uk> Message-ID: <46765A31.8090303@freecharity.org.uk> James Davis wrote: > I've just generated a key pair using my smartcard and asked it to make a > backup which it did. I'm doing a practice restore to see how the > procedure works and I'm a little stuck. I can import my new public key > onto my keyring but when I try to import the secret key it fails to do > so and I get the following output. > > $ gpg --import james.davis at ja.net-20070608-secret.gpg > gpg: key D7DDFF42: no user ID > gpg: Total number processed: 1 > gpg: secret keys read: 1 > $ > > What should I be doing? :-) Sorry to bring up this thread again but I've still not been able to work out what I should be doing and I'd appreciate any help you can give me as it's holding back my adoption of the smart card. Thanks, James -- http://www.freecharity.org.uk/ - Free IT services for charities http://www.freecharity.org.uk/wiki/ - The VCSWiki From v.simon at ieee.org Mon Jun 18 23:07:09 2007 From: v.simon at ieee.org (Simon Valiquette) Date: Mon, 18 Jun 2007 17:07:09 -0400 Subject: RSA 1024 ridiculous In-Reply-To: <20070617154819.85990.qmail@smasher.org> References: <200706160932.l5G9W0QT001130@www11.aname.net> <000001c7b027$cc874a20$5e01a8c0@Junk> <4675460A.1070004@sara.nl> <20070617154819.85990.qmail@smasher.org> Message-ID: <4676F3FD.6040408@ieee.org> Atom Smasher un jour ?crivit: > > On Sun, 17 Jun 2007, Remco Post wrote: >> >> Does gnupg support elliptic curve crypto? ;-) > ====================== > > if you're paranoid about RSA, then there's no reason to go to ECC since > the math behind it is still young and uncertain. The algorithm is publicly known since over 20 years, so It start to be not that young anymore. As an argument, ECDSA is one of the recommended algorithm by NIST and approved in FIPS 186-2. It is also known that the NSA, the government of Canada and probably many other countries use ECC to protect at least some of their sensitive information. It seems that ECDSA is also already used by at least some banks, but I don't know well enough to be sure. Here another argument to support ECC trustiness: "NSA has determined that beyond the 1024-bit public key cryptography in common use today, rather than increase key sizes beyond 1024-bits, a switch to elliptic curve technology is warranted." http://www.nsa.gov/ia/industry/crypto_suite_b.cfm Note that NSA also ask that current electronic signatures be strong enough to last at least 50 years, which is something certainly not OT on this list. That said, 2 years ago I was looking at ECC, and then found out that there is apparently hundreds of patents in USA, not directly on ECC, but on different optimisation, family of curves with special properties, small variations with ECC, an unknown number of undisclosed submarine patents and so on. That alone is enough to discourage ECC in free software for years (and in closed source software where companies are afraid of being sued). Another point, and not the least, is that implementing ECC properly is very difficult and error prone. That said, here OSS probably have an advantage as scholars will tend to study implementations for which they have the source code. > while a 1024 bit RSA key > ~may~ not be secure for a long time, it's old age is due only to computing > horsepower, not a "break" in the math behind it. as such, a larger RSA key > buys time... and only time will tell if it buys "enough" time for a > particular need. NIST is saying that RSA-1024 will be ok for up to 2010, but that you should prepare to switch to something more secure in the next few years. It also means that if there is something you need to protect for more than 5 years, you should not use RSA-1024. Simon Valiquette From james at freecharity.org.uk Tue Jun 19 15:24:37 2007 From: james at freecharity.org.uk (James Davis) Date: Tue, 19 Jun 2007 14:24:37 +0100 Subject: Problems generating keys on card "`SCD WRITEKEY' to agent failed: ec=4.281" Message-ID: <4677D915.5050300@freecharity.org.uk> I'm sure I'll get there eventually. I tried generating some new keys on the card today and after it appeared to successfully generate the keys this error came up. Here's part of the output from gpg. "James Davis " Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O You need a Passphrase to protect your secret key. Not enough random bytes available. Please do some other work to give the OS a chance to collect more entropy! (Need 46 more bytes) +++++ +++++ gpg: sending command `SCD WRITEKEY' to agent failed: ec=4.281 gpg: storing key onto card failed: general error Key generation failed: general error Command> I've turned on logging in scdaemon but there's nothing in there that looks obviously wrong at first glance. James -- http://www.freecharity.org.uk/ - Free IT services for charities http://www.freecharity.org.uk/wiki/ - The VCSWiki From alex at bofh.net.pl Tue Jun 19 16:05:30 2007 From: alex at bofh.net.pl (Janusz A. Urbanowicz) Date: Tue, 19 Jun 2007 16:05:30 +0200 Subject: RSA 1024 ridiculous In-Reply-To: <46757752.2040000@digital-signal.net> References: <200706160932.l5G9W0QT001130@www11.aname.net> <000001c7b027$cc874a20$5e01a8c0@Junk> <4675460A.1070004@sara.nl> <20070617154819.85990.qmail@smasher.org> <46757752.2040000@digital-signal.net> Message-ID: <20070619140529.GX26179@hell.pl> On Sun, Jun 17, 2007 at 01:02:58PM -0500, Andrew Berg wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: RIPEMD160 > > Atom Smasher wrote: > > gpg does support RSA-2048/SHA-256 (or even RSA-4096/SHA-512) which > > is what i've been using for a while now. i'll sign this email with > > RSA-2048/SHA-256 (my default on this key) just to show what it > > looks like. it's a big signature block, but not ridiculous and on a > > reasonably powerful computer it's hardly a noticeable delay to > > work with such keys. > Try signing/encrypting files that are tens, hundreds, or thousands of > megabytes in size. Sure, your average machine can sign/encrypt > messages that don't even fill a cluster without breaking a sweat, but > if the sensitive data is large, RSA-4096 isn't a good choice unless a > gov't agency wants that data. Erm... when you use OpenPGP, or really any other modern crypto protocol, you don't put actual plaintext through RSA, RSA operates only on a hash or random session key for symmetric cipher.y =alx -- JID: alex at hell.pl PGP: 0x46399138 od zwracania uwagi na detale s? lekarze, adwokaci, programi?ci i zegarmistrze -- Czerski From bahamut at digital-signal.net Tue Jun 19 16:36:31 2007 From: bahamut at digital-signal.net (Andrew Berg) Date: Tue, 19 Jun 2007 09:36:31 -0500 Subject: RSA 1024 ridiculous In-Reply-To: <20070619140529.GX26179@hell.pl> References: <200706160932.l5G9W0QT001130@www11.aname.net> <000001c7b027$cc874a20$5e01a8c0@Junk> <4675460A.1070004@sara.nl> <20070617154819.85990.qmail@smasher.org> <46757752.2040000@digital-signal.net> <20070619140529.GX26179@hell.pl> Message-ID: <4677E9EF.4030003@digital-signal.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Janusz A. Urbanowicz wrote: > On Sun, Jun 17, 2007 at 01:02:58PM -0500, Andrew Berg wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: RIPEMD160 >> >> Atom Smasher wrote: >>> gpg does support RSA-2048/SHA-256 (or even RSA-4096/SHA-512) which >>> is what i've been using for a while now. i'll sign this email with >>> RSA-2048/SHA-256 (my default on this key) just to show what it >>> looks like. it's a big signature block, but not ridiculous and on a >>> reasonably powerful computer it's hardly a noticeable delay to >>> work with such keys. >> Try signing/encrypting files that are tens, hundreds, or thousands of >> megabytes in size. Sure, your average machine can sign/encrypt >> messages that don't even fill a cluster without breaking a sweat, but >> if the sensitive data is large, RSA-4096 isn't a good choice unless a >> gov't agency wants that data. > > Erm... when you use OpenPGP, or really any other modern crypto > protocol, you don't put actual plaintext through RSA, RSA operates > only on a hash or random session key for symmetric cipher.y > > =alx I wonder how many more people are going to tell me this, even after I've demonstrated that I understand the concept (I'm pretty sure I even signed that message!). - -- Windows NT 5.1.2600.2180 | Thunderbird 2.0.0.4 | Enigmail 0.95.1 | GPG 1.4.7 Key ID: 0x60A78FCB - available on major keyservers and upon request Fingerprint: 4A84 CAE2 A0D3 2AEB 71F6 07FD F88E 0340 60A7 8FCB -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEVAwUBRnfp7viOA0Bgp4/LAQPUzQgAnyT20Djkk74bd4pI7D3Mz+R8Wt1QFjTU DmWyQc+r+5cwN4EPJ8vGwiUylkpWrSk4Y9FDJnANypX8U8kbWWU37OaJmhBGpNsx 436Jq/Ekw0t4k4OF5sp4lcXsiZUakJb6UzPoJO4G1UMKJsmRPNab306g9rFaLwEm sR0TQ1+7OvLhUHnBWUcZwQmZg8U3K1abG4P55xjfEnX3BM7oWjMytD21rHAjSiDn unFV6CwVc0lmiGAQsPGnnYg+NKdRoZQXFYC6zJwyqxmWXfx1G8OCDO9EaKymbAyC RQ8grkZ6oo2J6qJRHLhPfOfd1GDMxn4X4NPdnw6b98nhndCHZeIWCw== =iLn9 -----END PGP SIGNATURE----- From jbruni at mac.com Tue Jun 19 17:32:23 2007 From: jbruni at mac.com (Joseph Oreste Bruni) Date: Tue, 19 Jun 2007 08:32:23 -0700 Subject: RSA 1024 ridiculous In-Reply-To: <4677E9EF.4030003@digital-signal.net> References: <200706160932.l5G9W0QT001130@www11.aname.net> <000001c7b027$cc874a20$5e01a8c0@Junk> <4675460A.1070004@sara.nl> <20070617154819.85990.qmail@smasher.org> <46757752.2040000@digital-signal.net> <20070619140529.GX26179@hell.pl> <4677E9EF.4030003@digital-signal.net> Message-ID: <9D9D02B0-7D70-400F-8973-B553B0727806@mac.com> On Jun 19, 2007, at 7:36 AM, Andrew Berg wrote: > I wonder how many more people are going to tell me this, even after > I've demonstrated that I understand the concept (I'm pretty sure I > even signed that message!). Just think of it as "review". :) From bahamut at digital-signal.net Tue Jun 19 18:47:45 2007 From: bahamut at digital-signal.net (Andrew Berg) Date: Tue, 19 Jun 2007 11:47:45 -0500 Subject: RSA 1024 ridiculous In-Reply-To: <9D9D02B0-7D70-400F-8973-B553B0727806@mac.com> References: <200706160932.l5G9W0QT001130@www11.aname.net> <000001c7b027$cc874a20$5e01a8c0@Junk> <4675460A.1070004@sara.nl> <20070617154819.85990.qmail@smasher.org> <46757752.2040000@digital-signal.net> <20070619140529.GX26179@hell.pl> <4677E9EF.4030003@digital-signal.net> <9D9D02B0-7D70-400F-8973-B553B0727806@mac.com> Message-ID: <467808B1.1040701@digital-signal.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Joseph Oreste Bruni wrote: > On Jun 19, 2007, at 7:36 AM, Andrew Berg wrote: > >> I wonder how many more people are going to tell me this, even >> after I've demonstrated that I understand the concept (I'm pretty >> sure I even signed that message!). > Just think of it as "review". "Annoying" is more accurate. - -- Windows NT 5.1.2600.2180 | Thunderbird 2.0.0.4 | Enigmail 0.95.1 | GPG 1.4.7 Key ID: 0x60A78FCB - available on major keyservers and upon request Fingerprint: 4A84 CAE2 A0D3 2AEB 71F6 07FD F88E 0340 60A7 8FCB -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEVAwUBRngIsfiOA0Bgp4/LAQO2RAf5AS+xP//XQl+AheoDNbCxgAdXcdsV3y5K j9/JTIHPufpFZRKZQ9rZs/aLBy+QW266JLxgop/duXvRIsrvdnvH/xspoFolnlQS tBdGpPz0nrQXi7sNH0ZUiYPfD09u2sc8+FmYnms95PhVyRb25JGs8rggl3lWqQ+x yObnGLhg3FZKkGevNtrcF+2r0NchTTMMNnqyl87wuyu+AiPd0VrUBjFjCqsBMo4z CUj4s8D4Ck1oZCVziVT0Xb31JonxxwRtWoLLStD1VVk0YobE096v3GHfFv3Pv694 lfgtWwFuAWqWTF5Ryk+5hW9Yt+MBD/RDsk+VTaItOfjJo2JN7Ai51Q== =5SRJ -----END PGP SIGNATURE----- From hhhobbit at securemecca.net Wed Jun 20 05:14:49 2007 From: hhhobbit at securemecca.net (Henry Hertz Hobbit) Date: Tue, 19 Jun 2007 21:14:49 -0600 Subject: RSA 4096 ridiculous? (was RSA 1024 ridiculous) In-Reply-To: References: Message-ID: <46789BA9.5040805@securemecca.net> "Janusz A. Urbanowicz" wrote: On Sun, Jun 17, 2007 at 01:02:58PM -0500, Andrew Berg wrote: > > > > Atom Smasher wrote: >> > > gpg does support RSA-2048/SHA-256 (or even RSA-4096/SHA-512) >> > > which is what i've been using for a while now. i'll sign >> > > this email with RSA-2048/SHA-256 (my default on this key) >> > > just to show what it looks like. it's a big signature block, >> > > but not ridiculous and on a reasonably powerful computer >> > > it's hardly a noticeable delay to work with such keys. > > Try signing/encrypting files that are tens, hundreds, or thousands > > of megabytes in size. Sure, your average machine can sign/encrypt > > messages that don't even fill a cluster without breaking a sweat, > > but if the sensitive data is large, RSA-4096 isn't a good choice > > unless a gov't agency wants that data. > > Erm... when you use OpenPGP, or really any other modern crypto > protocol, you don't put actual plaintext through RSA, RSA operates > only on a hash or random session key for symmetric cipher.y Let's put some actual sizes and times on this in a real world situation. BTW, I am in total agreement that 1024 bit keys will be useful for at least a few more years whether they are DSA or RSA. It is more likely a crack will come from bad pass-phrases or key loggers stealing good pass-phrases and stolen secret keys than from shorter key sizes. Responding most specifically to Andrew's objections, what is wrong with 4096 bit RSA keys? If they are so awful, then why does GnuPG allow us to generate them? The default for RSA keys in both GnuPG and PGP is 2048 bits anyway. I created a temporary 4096 bit RSA key and compared it to my present 1024 bit DSA key for detached signing of moderately sized files which in addition to signed email messages is all I need it for anyway. I have no need to sign huge files. On other hand, I occasionally need to encrypt huge files, and even though I use something like TWOFISH or AES-256 for the symmetric cipher, it takes me less time to encrypt the file than it took me to tar it. It also takes me much less time to encrypt the tarred file than it takes to do the final bzip2 of the encrypted file. But the real killer is the uploading of my file to an Internet file storage server. That seems to take forever! Download speed is significantly faster. But other than the slightly longer time it took to create the RSA key, I didn't notice it took any longer to sign the files and here are the actual sizes. I copied the *.sig files to the extension names indicating which key was used to sign it, but cp'd that to $FILENAME.sig for the verifications: 109238 hosts.min 65 hosts.min.1024D 536 hosts.min.4096R 535610 hosts 65 hosts.1024D 536 hosts.4096R 35435 proxy.txt 65 proxy.txt.1024D 536 proxy.txt.4096R Here are the preferences on that RSA key: Command> showpref [ultimate] (1). Bogus User Cipher: TWOFISH, AES256, AES192, AES, CAST5, 3DES Digest: SHA512, SHA384, SHA256, SHA1 Compression: ZLIB, BZIP2, ZIP, Uncompressed Features: MDC, Keyserver no-modify It took me infinitely longer to type the pass-phrase for the signing than it took to actually create the sigs which seemed to be almost instantaneous. Timing the signing is sort of ridiculous unless I used keys without pass-phrases. Here is the difference in the times of verifying the file with both sigs (and I don't have a super fast machine - the CPU is over three years old): # 1024 BIT DSA KEY $ time gpg --verify hosts.sig gpg: Good signature from "Henry Hertz Hobbit " real 0m0.041s user 0m0.037s sys 0m0.003s $ time gpg --verify proxy.txt.sig gpg: Good signature from "Henry Hertz Hobbit " real 0m0.012s user 0m0.008s sys 0m0.004s # 4096 BIT RSA KEY $ time gpg --verify hosts.sig gpg: Good signature from "Bogus User " real 0m0.042s user 0m0.036s sys 0m0.003s $ time gpg --verify proxy.txt.sig gpg: Good signature from "Bogus User " real 0m0.014s user 0m0.007s sys 0m0.006s >From a user perspective, the time difference for verifying is the same for both keys and in this case it is almost instantaneous. The shortest file used in these test is longer than most email messages unless you have lots of attachments. Although the signature file is bigger for the 4096 bit RSA key (~ 8.25 times the size of the 1024 bit DSA key) it is constant in size and 536 bytes isn't unreasonable even if the message is only a few lines. After all, it verified the message, didn't it? 536 bytes to do that is a small price to pay. It is nice to do it with less, but that size becomes more reasonable the bigger the message or file becomes. So the only relevant question as I see it is, can the Crypto Card and other users handle my 4096 bit RSA sigs? If they can't then I will have some problems, won't I? Correct me if I am wrong, but I don't think I will have any problems with Crypto Card users in using my SIGS. Interoperability is the key to usability here. You people can tinker-toy with bigger key sizes than 4096, but I am NOT going to modify the code to accommodate you. The reason why is I assume the people writing the code have picked those limits for legitimate reasons. I may be wrong on that but I am not going to second guess them. In this case though, it doesn't appear the limits were set because of inordinately larger times. Less than a tenth of second? Whoop-de-doo! Since they have given me the option of using 4096 bit RSA keys, unless it poses usability problems for other people, why can't I use them? More to the point, why shouldn't I use them? Maybe it will allow me to keep the keys just that little bit longer (assuming nobody compromises them). HHH From snoken at tunedal.nu Wed Jun 20 10:42:28 2007 From: snoken at tunedal.nu (Snoken) Date: Wed, 20 Jun 2007 10:42:28 +0200 Subject: RSA 4096 ridiculous? (was RSA 1024 ridiculous) Message-ID: <200706200842.l5K8gdEY019750@www11.aname.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Interoperability with PGP 8 matters too. Signatures made with RSA 4096-keys (or shorter) and SHA256 can be verified by users of PGP 8. N.B. Not any other new hashes! Please note the option: --pgp8 Snoken At 05:14 2007-06-20, you wrote: >"Janusz A. Urbanowicz" wrote: > - --- snip -- >So the only relevant question as I see it is, can the Crypto Card >and other users handle my 4096 bit RSA sigs? If they can't then >I will have some problems, won't I? Correct me if I am wrong, but I >don't think I will have any problems with Crypto Card users in >using my SIGS. Interoperability is the key to usability here. - -- snip -- > >HHH > >_______________________________________________ >Gnupg-users mailing list >Gnupg-users at gnupg.org >http://lists.gnupg.org/mailman/listinfo/gnupg-users -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) - GPGrelay v0.959 iD8DBQFGeOifWisObvnr8tQRAizlAJ9UJSOOOLJWzc3x6sEnYxPIejHNIgCfSowu 3aNrKritMymKoFQ+GUXo6eE= =c85H -----END PGP SIGNATURE----- From wk at gnupg.org Wed Jun 20 11:36:55 2007 From: wk at gnupg.org (Werner Koch) Date: Wed, 20 Jun 2007 11:36:55 +0200 Subject: RSA 4096 ridiculous? In-Reply-To: <46789BA9.5040805@securemecca.net> (Henry Hertz Hobbit's message of "Tue, 19 Jun 2007 21:14:49 -0600") References: <46789BA9.5040805@securemecca.net> Message-ID: <874pl3otl4.fsf@wheatstone.g10code.de> On Wed, 20 Jun 2007 05:14, hhhobbit at securemecca.net said: > It took me infinitely longer to type the pass-phrase for the signing > than it took to actually create the sigs which seemed to be almost > instantaneous. Timing the signing is sort of ridiculous unless I used That is true for your desktop box. However, for small devices like PDAs a 4k RSA key is a lot of work. The problem might not be the generation or verification of a single signature but some of use have hundreds of signatures on their key and checking them all will take a lot of time. Salam-Shalom, Werner From snoken at tunedal.nu Wed Jun 20 13:21:02 2007 From: snoken at tunedal.nu (Snoken) Date: Wed, 20 Jun 2007 13:21:02 +0200 Subject: RSA useless for encryption was: RE: RSA 1024 ridiculous In-Reply-To: <000001c7b027$cc874a20$5e01a8c0@Junk> References: <200706160932.l5G9W0QT001130@www11.aname.net> <000001c7b027$cc874a20$5e01a8c0@Junk> Message-ID: <200706201121.l5KBLGan025599@www11.aname.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 At 17:05 2007-06-16, Brian Smith wrote: >Snoken wrote: >> I suppose this means that 1024 bit RSA-keys are ridiculous >> and the Open PGP Card is a joke. And what about all web sites >> protected by SSL with a 1024-bit RSA-certificate? > >This seems to be more-or-less on schedule: >http://en.wikipedia.org/wiki/Key_size#Asymmetric_algorithm_key_lengths > - --- snip --- > >Regards, >Brian > > >_______________________________________________ >Gnupg-users mailing list >Gnupg-users at gnupg.org >http://lists.gnupg.org/mailman/listinfo/gnupg-users Hi, I estimate that RSA 1024-bit keys have a very limited use for encryption. Encryption usually intends to protect for a substantially longer time than the time a signature is of any interest. Brian ("Brian Smith" ) looked inWikipedia. Me too: "As of 2003 RSA Security claims that 1024-bit RSA keys are equivalent in strength to 80-bit symmetric keys" http://en.wikipedia.org/wiki/Key_size#Asymmetric_algorithm_key_lengths I checked with the source: http://www.rsa.com/rsalabs/node.asp?id=2004 In 2003 users of RSA 1024-bit keys were advised to drop them before 2010. Now the situation is somewhat worse than it looked in 2003. Unfortunately the OpenPGP Cards are limited to a use RSA-keys of 1024 bits, both for encryption and signing. Any work in progress for an improved card? Snoken -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) - GPGrelay v0.959 iD8DBQFGeQ3KWisObvnr8tQRAt0VAJ41qrUBSU7hsDydwnT4ixhfwE4tvgCdHpMZ J6mI9LJYQx6Ymq+c1aoZ1kM= =HQKy -----END PGP SIGNATURE----- From brian at briansmith.org Wed Jun 20 13:49:36 2007 From: brian at briansmith.org (Brian Smith) Date: Wed, 20 Jun 2007 18:49:36 +0700 Subject: RSA useless for encryption was: RE: RSA 1024 ridiculous In-Reply-To: <200706201121.l5KBLGan025599@www11.aname.net> References: <200706160932.l5G9W0QT001130@www11.aname.net><000001c7b027$cc874a20$5e01a8c0@Junk> <200706201121.l5KBLGan025599@www11.aname.net> Message-ID: <000201c7b331$163fd540$5e01a8c0@Junk> Snoken wrote: > I checked with the source: > http://www.rsa.com/rsalabs/node.asp?id=2004 > > In 2003 users of RSA 1024-bit keys were advised to drop them > before 2010. Now the situation is somewhat worse than it > looked in 2003. That is not what the RSA website says. The website says, more-or-less, everything that has ever been encrypted with an 1024-bit key will be practically decipherable by 2010. That means, if you didn't want the data you sent over a compromised channel to be readable by 2010, you should have NEVER used RSA 1024 to start with. It does not mean "stop using RSA 1024 in 2010." Here's one way to think about it: If you have a E-commerce site, and you are protecting credit card numbers using RSA 1024 + AES 128, you should not accept any credit card that expires in 2010 or later. But, if you take RSA's recommendation to heart, you are safe in accepting any card that expires 2009 or earlier. Similarly, that website says, more-or-less, if you use RSA 2048 to protect data that you distribute, then that data will be protected until ~2030. That is why I said that, if you want to protect data for your *entire lifetime*, i.e. you don't want your data to be unprotected until after you die, you need to use RSA 15K + AES, or switch algorithms altogether. But, even now, if you have a secret that you want to keep for a year or two, RSA 1024 + 3DES is more than sufficient protection, even against very powerful entities. Regards, Brian From brian at briansmith.org Wed Jun 20 14:32:03 2007 From: brian at briansmith.org (Brian Smith) Date: Wed, 20 Jun 2007 19:32:03 +0700 Subject: RSA 4096 ridiculous? In-Reply-To: <874pl3otl4.fsf@wheatstone.g10code.de> References: <46789BA9.5040805@securemecca.net> <874pl3otl4.fsf@wheatstone.g10code.de> Message-ID: <000301c7b337$048e8250$5e01a8c0@Junk> Werner Koch wrote: > > It took me infinitely longer to type the pass-phrase for the signing > > than it took to actually create the sigs which seemed to be almost > > instantaneous. Timing the signing is sort of ridiculous > > That is true for your desktop box. However, for small > devices like PDAs a 4k RSA key is a lot of work. The problem > might not be the generation or verification of a single > signature but some of use have hundreds of signatures on > their key and checking them all will take a lot of time. The software only needs to verify the signatures that are going to affect the trust of the key. For a lot of people this will usually be a very small number (0 or 1). Even if a key has hundreds of signatures, it is unlikely that the user has (a) installed those hundreds of keys onto the device, and (b) granted key-signing trust to more than a few of them. None of the mobile phones I tried had no trouble using RSA 4096 to encrypt or decrypt a 16 byte key. If the phone has a JVM and/or a web browser, RSA 4096 and AES should be no problem. Regards, Brian From atom at smasher.org Wed Jun 20 16:29:42 2007 From: atom at smasher.org (Atom Smasher) Date: Wed, 20 Jun 2007 10:29:42 -0400 (EDT) Subject: RSA 4096 ridiculous? In-Reply-To: <874pl3otl4.fsf@wheatstone.g10code.de> References: <46789BA9.5040805@securemecca.net> <874pl3otl4.fsf@wheatstone.g10code.de> Message-ID: <20070620142942.92886.qmail@smasher.org> On Wed, 20 Jun 2007, Werner Koch wrote: > That is true for your desktop box. However, for small devices like PDAs > a 4k RSA key is a lot of work. The problem might not be the generation > or verification of a single signature but some of use have hundreds of > signatures on their key and checking them all will take a lot of time. ========================== just remember moore's law... a few years ago i got the cheapest palm-pilot i could find (original zire, ~$85). about a year later i again got the cheapest palm-pilot i could find (zire 22, ~$75). i spent $10 less, and the zire-22 runs circles around the original zire, most noticeably when i generate OPIE passwords. -- ...atom ________________________ http://atom.smasher.org/ 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 ------------------------------------------------- "A computer without Windows is like a chocolate cake without mustard." -- Elfer From hhhobbit at securemecca.net Wed Jun 20 17:28:26 2007 From: hhhobbit at securemecca.net (Henry Hertz Hobbit) Date: Wed, 20 Jun 2007 09:28:26 -0600 Subject: RSA 4096 ridiculous? (was RSA 1024 ridiculous) In-Reply-To: <200706200840.l5K8eauq016755@www11.aname.net> References: <46789BA9.5040805@securemecca.net> <200706200840.l5K8eauq016755@www11.aname.net> Message-ID: <4679479A.5070508@securemecca.net> Snoken wrote: > Hi, > Interoperability with PGP 8 matters too. > Signatures made with RSA 4096-keys (or shorter) and SHA256 can be > verified by users of PGP 8. > N.B. Not any other new hashes! > Please note the option: --pgp8 > Snoken What I was trying to do was bring a real world perspective to this question. Are you using PGP 8? Do you know anybody who is using PGP 8? http://www.pgpi.org http://www.pgpi.org/news/#20021203 (personally, I think they should close the web pages down, I get all the history I need on the History channel on TV) Since PGP 8 was released in December 2002 and nothing has been done with it for 4-1/2 years now, it is getting pretty long in tooth. PGP Corporation is up to at least PGP 10.x the last time I checked (last year). I would advise people using software that is that old (PGP 8) to update to newer stuff. Whether they drag the keys they created with PGP 8 along with them is up to them. I haven't had any problems with building GnuPG 1.4.x for either FreeBSD or OpenBSD. It of course works with all versions of Linux, Mac OS X, and Windows. I won't discuss the GnuPG 2.0.X line since it hasn't been built for Windows yet. Most of the people using my SIGS to verify that what I have provided is kosher will be using Microsoft Windows. They will outnumber Linux users by a factor of at least 4:1. They will also take the GnuPG defaults (with a key that lasts forever - how optimistic). There will be a smattering of Mac and other OS users. But they will *ALL* be working from a desktop system. They may have a PDA, but that is a secondary platform for them. Werner cautioned that a key size this large (4096R) causes severe problems with PDAs with limited CPU power and a large number of signatures on each key. I have absolutely no reason to doubt his statements and accept them as true. I don't see my keys being used with either of those constraints. What I am providing is for end user desktop systems and I cannot foresee these keys which will be part of the WOT as having more than just a few sigs. Most of the people using what I am providing have even more powerful machines than I have. You see, I gave you the actual stuff that is going to be signed - a blocking hosts file and PAC filter that blocks broad swaths of the Internet. I am still working on the Ad filtering stuff. Most web sites that can detect AdBlock Plus in Firefox still can't detect the presence of a PAC filter. These keys are NOT the keys that are used with this email account (still 1024 bit DSA for at least a year and I see no valid reason to change it - it works well). Caution and experience teaches me that you never know for sure how something will end up being used. Just because it is technically feasible to use a 4096 bit RSA key doesn't mean it is the optimal choice. Each person's choice has to be tailored to how they and *OTHERS* will use that key. Keep the *OTHERS* in mind when you make your choices. We have already established that 1024 bit RSA keys still have a few years of TECHNICAL life left in them (which should also hold true for DSA keys as well). But CPUs just keep getting faster (even on PDAs - where did the Hobbit chip go?), and I don't foresee anybody using my keys on a PDA. If they do, at least they won't have a lot of sigs on that particular key. I worked on the nascent PDAs with the PenPoint OS. The hand writing recognition I worked on was infinitely superior to what exists now if you ask me. But for the life of me I can't understand somebody using these keys on that limited of a platform. If they do, it will only be for one or two questions to me and answers from me and after that they will just delete my key on their PDA. That has been my experience up to now and I see no reason for it to change. In other words, I don't foresee anybody other than desktop platform users who will be using this key (it does NOT replace my present key). But that sig will be infinitely better than a check sum that anybody can change. At this point I am still leaning toward the maximum which may be seen as a minimum eight years from now. I am always looking toward the future. I also want something that people can't even question from a technical perspective. Keep that last statement in mind. If I have to, I will remove keys entirely (secure remove written by myself) for tricky operations with bad hosts on the Internet And don't think for one minute that Linux systems are secure from all Internet attacks - THEY ARE NOT SECURE FROM ALL OF THEM! That holds for Mac OS-X and *BSD as well. HHH -- Why hack in when you can drive in on Hwys. 80, 110, 194, 220, 443, 993, 994 & 995? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20070620/9e8883cf/attachment.pgp From bahamut at digital-signal.net Wed Jun 20 18:26:09 2007 From: bahamut at digital-signal.net (Andrew Berg) Date: Wed, 20 Jun 2007 11:26:09 -0500 Subject: If the message is encrypted symmetrically... Message-ID: <46795521.80408@digital-signal.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Why can't I use the same (symmetric) key I used to encrypt (public key is used to generate symmetric key that the corresponding private key can calculate) to decrypt? - -- Windows NT 5.1.2600.2180 | Thunderbird 2.0.0.4 | Enigmail 0.95.1 | GPG 1.4.7 Key ID: 0x60A78FCB - available on major keyservers and upon request Fingerprint: 4A84 CAE2 A0D3 2AEB 71F6 07FD F88E 0340 60A7 8FCB -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEVAwUBRnlVIfiOA0Bgp4/LAQO6egf/atnJhe45Ov+FXsbD/OSLuMEE95OUhlUl 7ttdIZCJ0jyT1kxAkqYi2gDUAj4SXS18wEstGEKZFHgJpKgFEhvCFAkSPTtpCqxK H03xdOgMAUycwuy+fNbTvyJ8OjEoiBvtfmrf3cR9ntNDi83W6Z6964VlO8Q5qDIX J33DHEncyW56v0612/cabXDUrUhciydRI4/7SglWhEfUhlUIPn6kRjOqRaFTRyZN 8nEc/5UGC46TDwKZTcQwPDX26/ldrLhkNXNfdx3dtSH9pDB49OG5AYPFnL9BzUX1 BJfn6xbYMLUnswL6xKfmMnkRUxqy0IO39tLBJBwabaGVQEPm3yX7rA== =0Zfv -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Wed Jun 20 19:09:23 2007 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 20 Jun 2007 12:09:23 -0500 Subject: RSA 4096 ridiculous? (was RSA 1024 ridiculous) In-Reply-To: <4679479A.5070508@securemecca.net> References: <46789BA9.5040805@securemecca.net> <200706200840.l5K8eauq016755@www11.aname.net> <4679479A.5070508@securemecca.net> Message-ID: <7261DE5C-948D-4B81-B956-D1299A81BB9E@sixdemonbag.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > What I was trying to do was bring a real world perspective to > this question. Are you using PGP 8? Do you know anybody who > is using PGP 8? Yes and yes. I far prefer PGP 8.1 over PGP 9.0+, and I've heard comments from many other users who say likewise. The thing which is killing PGP 8.1 is its lack of support for creating SHA256 messages, not its age. > Since PGP 8 was released in December 2002 and nothing has been > done with it for 4-1/2 years now, it is getting pretty long in > tooth. Many people still use PGP 6.5.8, which dates back to pre-2000. > PGP Corporation is up to at least PGP 10.x the last time > I checked (last year). PGP 9.6 is the latest. - -- Robert J. Hansen "Most people are never thought about after they're gone. 'I wonder where Rob got the plutonium?' is better than most get." -- Phil Munson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iFYEAREIAAYFAkZ5X0MACgkQf2XByo0Cu7PxqwDeK9GRjV6j4Ho2YIKmba0aVWZK HaHgMWbXDHsAVADeOK8A9lkXh6s5Tl9H1BPTOLHBdj1r5WI1jSLD+4kBHAQBAQgA BgUCRnlfQwAKCRC3APSC/q+BCd0GCADhC4RDSzChe0mB7j3ogPR49dOH9vlK92v1 fv/NXqPCGv7D8oa5R4cPYpsleL84Kmx6M1+6yqeGt42jz2s4B+yAK6KJ4UFM2kKY lI+bU6QTBf0eLtndSCwaNTARUSYly8ywZGlKoaGuS0zddWff0lmbtQbHabHUBxlE PdaIvPb+nBxhxfaShoBi5vFZdhAQV6sWrRbxblr1NTRq8iPBlPZDHBDMpw+wVbQ3 ZDXmHYfJZb9/oIeSEJoiwiFfU3eb+Opix6KvArHYP5oTmSr5F3xplKy/+J7aGW6Z vggHFWjH5SmJv3Zp82wxqWsW6Qpnocge4wzj6uJXRbK9gCHJFgpu =eE9A -----END PGP SIGNATURE----- From jbruni at mac.com Wed Jun 20 20:14:55 2007 From: jbruni at mac.com (Joseph Oreste Bruni) Date: Wed, 20 Jun 2007 11:14:55 -0700 Subject: If the message is encrypted symmetrically... In-Reply-To: <46795521.80408@digital-signal.net> References: <46795521.80408@digital-signal.net> Message-ID: <1F9937E6-BB33-4793-8A2E-1B9C1F522962@mac.com> By definition of symmetric encryption, you must use the same key to decrypt that was used to encrypt. I'm not sure what you're really asking. When you say "public key is used to generate symmetric key" you lost me. Symmetric keys are typically just random numbers pulled from /dev/ random or similar. Joe On Jun 20, 2007, at 9:26 AM, Andrew Berg wrote: > Why can't I use the same (symmetric) key I used to encrypt (public key > is used to generate symmetric key that the corresponding private key > can calculate) to decrypt? > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2508 bytes Desc: not available Url : /pipermail/attachments/20070620/c5019ae5/attachment.bin From bahamut at digital-signal.net Wed Jun 20 20:22:44 2007 From: bahamut at digital-signal.net (Andrew Berg) Date: Wed, 20 Jun 2007 13:22:44 -0500 Subject: If the message is encrypted symmetrically... In-Reply-To: <1F9937E6-BB33-4793-8A2E-1B9C1F522962@mac.com> References: <46795521.80408@digital-signal.net> <1F9937E6-BB33-4793-8A2E-1B9C1F522962@mac.com> Message-ID: <46797074.1000408@digital-signal.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Joseph Oreste Bruni wrote: > By definition of symmetric encryption, you must use the same key to > decrypt that was used to encrypt. I'm not sure what you're really > asking. > > When you say "public key is used to generate symmetric key" you > lost me. Symmetric keys are typically just random numbers pulled > from /dev/random or similar. The public key generates a key that symmetrically encrypts the message, which can be deciphered by its corresponding private key. What stops Bob from using Alice's public key to generate a symmetric key that can decrypt her messages? - -- Windows NT 5.1.2600.2180 | Thunderbird 2.0.0.4 | Enigmail 0.95.1 | GPG 1.4.7 Key ID: 0x60A78FCB - available on major keyservers and upon request Fingerprint: 4A84 CAE2 A0D3 2AEB 71F6 07FD F88E 0340 60A7 8FCB -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEVAwUBRnlwc/iOA0Bgp4/LAQNX0gf/VNcoK0gWCaX77661Jkdai5WPbiZQKhtj m0kvq6f/EObSfd2IlgN3QEddP3KzDODlxcY53sHMNaYfhEy8HmxAHADOSjpKxx7h CtA2D26v+ollTwAq9i1D1pEJ1ibXf65VnEi2qSdNEkOkxjk60AJv2m017O7W3ZPh jVVI3DxI3BoBJRL1ZXxfGwFN7dcXHgDL/o79yi5dqwEI2vIUVpN8F5lsgO1SBFZ+ ZupjjaXaCqep6TLyruDxr3lXJIK7E/MJWFVNphZ28hjorfZU7LShcLl12N7S02oP ysQsmNdtqUosxiXFCOU7R3N5kjgtJGtx+mz2cNoROS3dfis4B6dTwA== =/Kax -----END PGP SIGNATURE----- From wk at gnupg.org Wed Jun 20 20:26:30 2007 From: wk at gnupg.org (Werner Koch) Date: Wed, 20 Jun 2007 20:26:30 +0200 Subject: RSA 4096 ridiculous? In-Reply-To: <000301c7b337$048e8250$5e01a8c0@Junk> (Brian Smith's message of "Wed, 20 Jun 2007 19:32:03 +0700") References: <46789BA9.5040805@securemecca.net> <874pl3otl4.fsf@wheatstone.g10code.de> <000301c7b337$048e8250$5e01a8c0@Junk> Message-ID: <87wsxylbxl.fsf@wheatstone.g10code.de> On Wed, 20 Jun 2007 14:32, brian at briansmith.org said: > None of the mobile phones I tried had no trouble using RSA 4096 to > encrypt or decrypt a 16 byte key. If the phone has a JVM and/or a web > browser, RSA 4096 and AES should be no problem. I did a quick benchmark: $ tests/benchmark rsa Algorithm generate 100*sign 100*verify ---------------------------------------------- RSA 1024 bit 150ms 830ms 30ms RSA 2048 bit 2140ms 4310ms 80ms RSA 3072 bit 5470ms 12430ms 160ms RSA 4096 bit 14350ms 28420ms 270ms This is raw signing of a random number 8 bits shorter than the modulus using a public exponent of 65537. The numbers indeed show that verificaion is only by a factor of 3 slower for a 4k key compared to 2k key. Thus, this proves your statement. The sign operation is of course far slower: A single sign operation takes 0.28 seconds on my 1500Mhz Pentium M. Given that this is the same time as for a decrypt operation, this will be noticable if you receive a mail encrypted to several hidden keys (--throw-keyid) and you need to do trial decryptions. FWIW, here are the figures for other algorithms: $ tests/benchmark dsa Algorithm generate 100*sign 100*verify ---------------------------------------------- DSA 1024/160 - 910ms 440ms DSA 2048/224 - 1570ms 1900ms DSA 3072/256 - 3630ms 4400ms $ tests/benchmark ecc Algorithm generate 100*sign 100*verify ---------------------------------------------- ECDSA 192 bit 60ms 1530ms 1170ms ECDSA 224 bit 30ms 760ms 1380ms ECDSA 256 bit 40ms 960ms 1800ms ECDSA 384 bit 90ms 2150ms 4210ms ECDSA 521 bit 210ms 5430ms 10510ms (ECC is still experimental in Libgcrypt and not much opmitized) Shalom-Salam, Werner From dshaw at jabberwocky.com Wed Jun 20 20:39:02 2007 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 20 Jun 2007 14:39:02 -0400 Subject: If the message is encrypted symmetrically... In-Reply-To: <46797074.1000408@digital-signal.net> References: <46795521.80408@digital-signal.net> <1F9937E6-BB33-4793-8A2E-1B9C1F522962@mac.com> <46797074.1000408@digital-signal.net> Message-ID: <20070620183902.GA8380@jabberwocky.com> On Wed, Jun 20, 2007 at 01:22:44PM -0500, Andrew Berg wrote: > Joseph Oreste Bruni wrote: > > By definition of symmetric encryption, you must use the same key to > > decrypt that was used to encrypt. I'm not sure what you're really > > asking. > > > > When you say "public key is used to generate symmetric key" you > > lost me. Symmetric keys are typically just random numbers pulled > > from /dev/random or similar. > The public key generates a key that symmetrically encrypts the > message, which can be deciphered by its corresponding private key. No. The symmetric key is not generated by the public key. As Joseph said, the symmetric key is random. The symmetric key is used to encrypt the data, and then the public key is used to encrypt the symmetric key. David From jbruni at mac.com Wed Jun 20 20:38:38 2007 From: jbruni at mac.com (Joseph Oreste Bruni) Date: Wed, 20 Jun 2007 11:38:38 -0700 Subject: If the message is encrypted symmetrically... In-Reply-To: <46797074.1000408@digital-signal.net> References: <46795521.80408@digital-signal.net> <1F9937E6-BB33-4793-8A2E-1B9C1F522962@mac.com> <46797074.1000408@digital-signal.net> Message-ID: Gotcha. The public key does not "generate" the key. I'm going to walk through the process again, so please bear with me. I'm going to send you a message. GPG creates a random key from a source of entropy such as /dev/ random. This key is used in a symmetric cipher such as AES128 to encrypt my message. This symmetric KEY is then ENCRYPTED using your public key and attached to the end of the message. When you receive the message, you use your private key to DECRYPT the symmetric key and then use the symmetric key to decrypt the message. Since only your private key can decrypt the attached symmetric key, only you can subsequently decrypt the message. On Jun 20, 2007, at 11:22 AM, Andrew Berg wrote: > The public key generates a key that symmetrically encrypts the > message, which can be deciphered by its corresponding private key. > What stops Bob from using Alice's public key to generate a symmetric > key that can decrypt her messages? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2508 bytes Desc: not available Url : /pipermail/attachments/20070620/81952a5c/attachment.bin From jbruni at mac.com Wed Jun 20 20:47:37 2007 From: jbruni at mac.com (Joseph Oreste Bruni) Date: Wed, 20 Jun 2007 11:47:37 -0700 Subject: If the message is encrypted symmetrically... In-Reply-To: <43090.140.242.26.81.1182364228.squirrel@webmail.io.com> References: <46795521.80408@digital-signal.net> <1F9937E6-BB33-4793-8A2E-1B9C1F522962@mac.com> <43090.140.242.26.81.1182364228.squirrel@webmail.io.com> Message-ID: Correct. If I'm sending a message that I want protected, I hash the contents with something like SHA-1. I encrypt this hash with my private key and attach the encrypted hash to the document. Recipients can then compute their own hash of the document, decrypt the attached, encrypted hash using my public key, and compare the results. If the hashes match, the document is good, and non- repudiation has been established since it was encrypted with MY private key. To extend our discussion, suppose I wish to send an encrypted message to multiple recipients. I would then encrypt the (randomly generated) symmetric key to each recipient's public key in turn. All of the encrypted copies (of the symmetric key) are attached. A valid recipient will be able to encrypt his (and only his) copy of the symmetric key and then decrypt the document. On Jun 20, 2007, at 11:30 AM, Newton Hammet wrote: > I am not exactly sure how the sig fits in but it is a hash value of > either > the original message or the encrypted message depending on the > order of > signing and encryption. This hash is encrypted with sender's > private key > part of his own public key. This part I am not sure of so others can > correct me if I am wrong with this part. > > I believe signatures are encrypted with private key and decrypted with > public key. In order to protect against some exploits it is best > to have > your public key consist of one signing key and a different key for > message > encryption. > > -Newton -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2508 bytes Desc: not available Url : /pipermail/attachments/20070620/290433a3/attachment.bin From bahamut at digital-signal.net Wed Jun 20 20:49:40 2007 From: bahamut at digital-signal.net (Andrew Berg) Date: Wed, 20 Jun 2007 13:49:40 -0500 Subject: If the message is encrypted symmetrically... Message-ID: <467976C4.2040304@digital-signal.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 > GPG creates a random key from a source of entropy such as > /dev/random. This key is used in a symmetric cipher such as AES128 > to encrypt my message. > This symmetric KEY is then ENCRYPTED using your public key and > attached to the end of the message. Ah. Makes sense. - -- Windows NT 5.1.2600.2180 | Thunderbird 2.0.0.4 | Enigmail 0.95.1 | GPG 1.4.7 Key ID: 0x60A78FCB - available on major keyservers and upon request Fingerprint: 4A84 CAE2 A0D3 2AEB 71F6 07FD F88E 0340 60A7 8FCB -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEVAwUBRnl2xPiOA0Bgp4/LAQMKHQf9G8vnKIW1MWYHwW24fi9eiWfXqi04ZN6/ 1zgKdzg2icAWUg7i5Ensec0DFZ1QkprtyO5J3K35oEv7n0Il14herNw9xQ4/BQCc hIU6H06HnspdydDLRJYxLtJNZEGkZH7Nx5Il+t+rTm2F+Ozd41SCdN76ciEM/ENt WmxSGzsEGgt4ggkB5Esw1J58Nj1uLv0+wBawc3pzZlccjLAW3NktH12GEwlCSnc7 L4U0NmjALwQaFL0IpGjSdNaG+Utm0NnPb1tjtJxdaH1MXvCnkyzFSu8tdnvgo0f+ GY088A0jARcXbZ493RgLpEuzxvZLO6L+H2QjN828CLrFEu5Zq7dFLw== =d2G0 -----END PGP SIGNATURE----- From huebener at gmail.com Wed Jun 20 11:38:35 2007 From: huebener at gmail.com (=?ISO-8859-1?Q?Robert_H=FCbener?=) Date: Wed, 20 Jun 2007 11:38:35 +0200 Subject: RSA 4096 ridiculous? (was RSA 1024 ridiculous) In-Reply-To: <46789BA9.5040805@securemecca.net> References: <46789BA9.5040805@securemecca.net> Message-ID: <4678F59B.6080408@gmail.com> In my view, gnupg already offers too much choice. There is no real reason to have so many options. They should have given 2 to chose from - a small and fast and a large and slow (both sort of balanced, too), say a) DSA-1024 (SHA1) & Elgamal-1024, cipher 3DES - fingerprint SHA1 and b) DSA-3072 (SHA256) & Elgamal-3072, cipher AES-128 - fingerprint SHA256 If one of the ingredients is broken, gnupg has to be redesigned anyways. The idea that we can simply go on in this case and use the fallback functions doesn't seem realistic to me. The easiest case to handle (fallback-wise) would be that AES is broken. But even then there would be a huge chaos and thousands of keys would have to be updated etc (which many users won't do anyways), so that the web of trust will break down then. A complete start will be best even in this case, with new keys. From rjh at sixdemonbag.org Thu Jun 21 11:59:59 2007 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 21 Jun 2007 04:59:59 -0500 Subject: RSA 4096 ridiculous? (was RSA 1024 ridiculous) In-Reply-To: <4678F59B.6080408@gmail.com> References: <46789BA9.5040805@securemecca.net> <4678F59B.6080408@gmail.com> Message-ID: <153BCF21-D745-42AE-A6AD-2CE402469DAB@sixdemonbag.org> From james at freecharity.org.uk Thu Jun 21 17:10:24 2007 From: james at freecharity.org.uk (James Davis) Date: Thu, 21 Jun 2007 16:10:24 +0100 Subject: Problems generating keys on card "`SCD WRITEKEY' to agent failed: ec=4.281" In-Reply-To: <4677D915.5050300@freecharity.org.uk> References: <4677D915.5050300@freecharity.org.uk> Message-ID: <467A94E0.6080702@freecharity.org.uk> James Davis wrote: > gpg: sending command `SCD WRITEKEY' to agent failed: ec=4.281 > gpg: storing key onto card failed: general error > Key generation failed: general error Further to my last e-mail this only occurs when I ask for a backup copy of my key to be kept. Keeping everything on the card causes no problems. James -- http://www.freecharity.org.uk/ - Free IT services for charities http://www.freecharity.org.uk/wiki/ - The VCSWiki From malayter at gmail.com Thu Jun 21 21:16:17 2007 From: malayter at gmail.com (Ryan Malayter) Date: Thu, 21 Jun 2007 14:16:17 -0500 Subject: RSA 4096 ridiculous? (was RSA 1024 ridiculous) In-Reply-To: <46789BA9.5040805@securemecca.net> References: <46789BA9.5040805@securemecca.net> Message-ID: <5d7f07420706211216t21d473bbg824caf7c5617b905@mail.gmail.com> On 6/19/07, Henry Hertz Hobbit wrote: > than it took me to tar it. It also takes me much less time to > encrypt the tarred file than it takes to do the final bzip2 of the > encrypted file. Huh? Why would you try to use bzip2 AFTER encrypting? Strongly-encrypted data is not compressible. And GnuPG uses gzip compression by default *before* encryption anyway. I suppose you could be using bzip to compress an ascii-armored GnuPG output, but that is pretty silly (just use binary output from GnuPG instead). -- RPM From hhhobbit at securemecca.net Fri Jun 22 01:52:26 2007 From: hhhobbit at securemecca.net (Henry Hertz Hobbit) Date: Thu, 21 Jun 2007 17:52:26 -0600 Subject: If the message is encrypted symmetrically In-Reply-To: References: Message-ID: <467B0F3A.2080603@securemecca.net> Joseph Oreste Bruni wrote: > To extend our discussion, suppose I wish to send an encrypted message > to multiple recipients. I would then encrypt the (randomly generated) > symmetric key to each recipient's public key in turn. All of the > encrypted copies (of the symmetric key) are attached. A valid > recipient will be able to encrypt his (and only his) copy of the > symmetric key and then decrypt the document. Everything is fine with what you said until you say this. In real practice what Thunderbird and Evolution (I can't speak for the other email programs) do is generate a separate symmetric encryption for each user. Without looking at the source code (which I have NOT done for this particular situation) you can't tell whether each user gets a separate random symmetric session key or whether all users share the same random symmetric session key. Knowing the paranoia of encryption coders, I suspect that each user gets their own randomly created symmetric session key. It also doesn't make much sense if you use the same random session key for every user. If you do that, why not just have one copy of the symmetric encryption? Without looking at the code though, I don't know that for certain. I suspect that the mail programs just use what GnuPG gives them and only do the one call to GnuPG, so you can actually do the tests with the multiple users on the command line without even using email. However, I do know that if you do tests by actually sending the same encrypted mail message (use a fairly large message of at least 64 K) to one, two, and three recipients then you can see this. Save all of the messages to a file and edit out the headers and you will find the approximate size differences for the three files: double = 2 * single triple = 3 * single triple = 1.5 * double If you had one shared symmetric encryption you wouldn't have those size changes since you would only be adding the size of the asymmetric encryption of the randomly generated session key used to do the symmetric encryption for each additional person. I will volunteer for being one of the three users (after yourself you need only one more user) if you want to do the tests actually using email itself, but I would advise just using the multiple recipients on the command line first and comparing the sizes there. Rummage around in the Enigmail section of the Thunderbird forum and if they don't have the answer just ask if they only do one call to GnuPG to do the encryption. HHH From JPClizbe at tx.rr.com Fri Jun 22 03:30:19 2007 From: JPClizbe at tx.rr.com (John Clizbe) Date: Thu, 21 Jun 2007 20:30:19 -0500 Subject: If the message is encrypted symmetrically In-Reply-To: <467B0F3A.2080603@securemecca.net> References: <467B0F3A.2080603@securemecca.net> Message-ID: <467B262B.4010000@tx.rr.com> Henry Hertz Hobbit wrote: > > I will volunteer for being one of the three users (after yourself > you need only one more user) if you want to do the tests actually > using email itself, but I would advise just using the multiple > recipients on the command line first and comparing the sizes there. > Rummage around in the Enigmail section of the Thunderbird forum > and if they don't have the answer just ask if they only do one > call to GnuPG to do the encryption. Though they may just tell you to ask the Enigmail guys. Enigmail makes one call to GnuPG when sending. After 'Send' is clicked and processing such as line ending canonizations, the message is passed to GnuPG for whatever processing is requested. The results from GnuPG are then assembled into the final message and passed back to SeaMonkey/Thunderbird's mailnews code for the actual putting the message on the wire, The only time Enigmail calls GnuPG twice in message processing is to get key information to display on the status line. I may be useful to look at that message being examined with a tool such as pgpdump to determine the size of the individual packets. -- John P. Clizbe Inet: John (a) Mozilla-Enigmail.org You can't spell fiasco without SCO. PGP/GPG KeyID: 0x608D2A10/0x18BB373A "what's the key to success?" / "two words: good decisions." "what's the key to good decisions?" / "one word: experience." "how do i get experience?" / "two words: bad decisions." "Just how do the residents of Haiku, Hawai'i hold conversations?" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 663 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20070621/70fb9d67/attachment.pgp From dirk.traulsen at lypso.de Fri Jun 22 08:52:10 2007 From: dirk.traulsen at lypso.de (Dirk Traulsen) Date: Fri, 22 Jun 2007 08:52:10 +0200 Subject: Question about check command In-Reply-To: <1180970783.12442.1193338545@webmail.messagingengine.com> References: <1180970783.12442.1193338545@webmail.messagingengine.com> Message-ID: <467B8DBA.23903.3CBC616F@dirk.traulsen.lypso.de> Am 4 Jun 2007 um 20:56 hat hs2412 at gmail.com geschrieben: > When I run the check command in edit-key mode, it shows me > something like > > sig! > or sig!1 > or sig!3 > > What does this mean? Hi Hardeep, there are two answers to your question: A simple one and a difficult one. It's easy to answer why these three differ, but not trivial to find the answer why they have the exclamation mark in common. 1. Why are there signatures shown with nothing, 1 or 3 after the exclamation mark? They are flags showing the certification check level or trust level the signer gave the UID and the key, while signing (certifying) it. 1-3 should be clear and zero is shown as sig! (not sig!0). You can find the solution in the manual: --list-sigs For each signature listed, there are several flags in between the "sig" tag and keyid. These flags give additional information about each signature. From left to right, they are the numbers 1-3 for certificate check level (see --ask-cert-level), "L" for a local or non-exportable signature (see --lsign-key), "R" for a nonRevocable signature (see the --edit-key command "nrsign"), "P" for a signature that contains a policy URL (see --cert-pol- icy-url), "N" for a signature that contains a notation (see --cert-notation), "X" for an eXpired signature (see --ask-cert- expire), and the numbers 1-9 or "T" for 10 and above to indicate trust signature levels (see the --edit-key command "tsign"). --default-cert-level n The default to use for the check level when signing a key. 0 means you make no particular claim as to how carefully you verified the key. 1 means you believe the key is owned by the person who claims to own it but you could not, or did not verify the key at all. This is useful for a "persona" verification, where you sign the key of a pseudonymous user. 2 means you did casual verification of the key. For example, this could mean that you verified that the key fingerprint and checked the user ID on the key against a photo ID. 3 means you did extensive verification of the key. For example, this could mean that you verified the key fingerprint with the owner of the key in person, and that you checked, by means of a hard to forge document with a photo ID (such as a passport) that the name of the key owner matches the name in the user ID on the key, and finally that you verified (by exchange of email) that the email address on the key belongs to the key owner. Note that the examples given above for levels 2 and 3 are just that: examples. In the end, it is up to you to decide just what "casual" and "extensive" mean to you. This option defaults to 0 (no particular claim). 2. What meaning has the exclamation mark? This is a question originally targeted to the developers of gnupg as it is not documented anywhere. At least I did not find it. It is not even documented in the DETAILS file. This made me so curious, that I downloaded the actual source code and began searching for the solution. Well, here is what I found: The signature list is put together by two different functions in g10\keylist.c -> list_keyblock_print and list_keyblock_colon, depending whether you used --with-colon as option or not. The flag directly behind the sig gives the result of the signature check. It is one of the following flags: [ ],!,-,%,?. empty = no signature check ! = successful check = good signature - = bad signature % = other error during check and only when using the --with-colon option (why?): ? = no or unusable public key So, this is my analysis of the source code and I'm really quite confident that it is correct, but it should be confirmed by a developer of gnupg. And I think, as this is part of the output, it really should get documented in the manual and at least in the DETAILS file. Dirk From dirk.traulsen at lypso.de Fri Jun 22 08:52:09 2007 From: dirk.traulsen at lypso.de (Dirk Traulsen) Date: Fri, 22 Jun 2007 08:52:09 +0200 Subject: errors in manual Message-ID: <467B8DB9.4003.3CBC6085@dirk.traulsen.lypso.de> Hi! I found 3 problems in the manual: 1. In the new manual the following options are missing: --batch --yes --no 2. The manual has now strange gaps in it (at least under German WinxP): Here are 3 examples: SYNOPSIS gpg [--homedir ___] [--options ____] [_______] _______ [____] --gen-random 0|1|2 Emit _____ random bytes of the given quality level. --gen-key ... in batch mode. See the file `___________' in the source 3. Please see part 2 of my parallel mail "Re: Question about check command". The check sigs flags are not documented. Dirk From hhhobbit at securemecca.net Fri Jun 22 10:56:03 2007 From: hhhobbit at securemecca.net (Henry Hertz Hobbit) Date: Fri, 22 Jun 2007 02:56:03 -0600 Subject: FireGPG Report In-Reply-To: References: Message-ID: <467B8EA3.60406@securemecca.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 FireGPG: ======== Here is the information on FireGPG which primarily does INLINE rather than OpenPGP/MIME encryption and signing: http://firegpg.tuxfamily.org/ FireGPG works well for INLINE encrypting and decrypting. You can use FireGPG to send / receive GnuPG encrypted messages. Further, despite them focusing on using GMail it, FireGPG will also work in sending and receiving encrypted messages with AOL / Netscape, HotMail, and Yahoo WebMail services. Read on ONLY if you want to help with the Signing (also INLINE) which has problems. I have done some extensive testing of FireGPG. Here are the results of the tests (the files will be there until the end of the present month): http://www.securemecca.com/ FireGPG.zip http://www.securemecca.com/AOL_FireGPG_SignTest.zip SHA1 sums of files: - ------------------- a293f08fb3821f79ed42c2ae6dea50cfe90e98ce AOL_FireGPG_SignTest.zip 47898a296c797ac1f014ac8442265c0746f348a1 FireGPG.zip Basically, I had no ends of grief in signing. That was both in sending and verifying. I was using FireGPG 0.3.3 to do the tests. The commands used to do the signing in 0.4.2.1 are the same as they were in 0.3.3. The main changes from 0.3.3. to 0.4.2.1 are localization. I can't see anything that they are doing wrong. Here is the main portion of the signing code: putIntoFile(tmpPASS, password); // DON'T MOVE THIS LINE ! try { runCommand(tmpRun, '' + this.getGPGCommand() + '' + " " + tmpStdOut + " --quiet --no-tty --no-verbose --status-fd 1 --armor --batch" + " --default-key " + keyID + " --output " + tmpOutput + " --passphrase-file " + tmpPASS + "" + getGPGCommentArgument() + getGPGAgentArgument() + " --clearsign " + tmpInput); } catch (e) { } removeFile(tmpPASS); // DON'T MOVE THIS LINE ! You can find the plugin on 'nix with: $ find ~/.mozilla/firefox -type f -name firegpg.jar -print After you copy the file some place else and unzip it using unzip or your choice of zip program, the files containing the commands are: content/cgpglin.js Linux / Unix (all tests done w. Linux) content/cgpgwin.js Windows I don't like closed sections so, I changed the VIM directives at the end of the file using MicroEMACS to: // vim:ai:sw=4:ts=4: Your mileage will vary, and if you don't use VIM, it won't matter. After that change in all the files I used vim to look at the files. The baseline was Thunderbird where all messages signed in Thunderbird verified in Thunderbird, and all messages encrypted in Thunderbird decrypted in Thunderbird. In all WebMail services signing, verifying, encrypting and decrypting, were always done by selecting the text and then doing a ^C despite X copying automatically. But it seemed to make no difference whether I did that or not. FINAL RESULTS: ============== SIGNING /VERIFYING can only be INLINE. But the results are all over the wall and you can't trust them! The snatching of the text is fine, but I suspect that after the message is signed, the webmail mucks around with the spacing characters or plays around with some hidden characters. But if it was hidden characters I could never see them in the file after saving from Evolution which makes no attempt to interpret INLINE signed or encrypted messages or other strange extended characters. All of my tests were done with line lengths of approximately 64 characters to make sure I didn't have forced wraps, but I think I got a few of them anyway, primarily with HotMail. I don't think there is anything that they can do about the signing failure but if the rest of you can look at the code maybe you can deduce what is going wrong. I couldn't deduce a pattern of when it worked and when it failed for me to try to zero in on what was going wrong. It was extremely exasperating to get one result on the command line and a different one in the WebMail or Thunderbird I saved the message from. I shifted to SHA1 for some additional tests with signing and it made NO DIFFERENCE. Results were still all over the wall. I didn't save those tests. ENCRYPTION is INLINE but it ALWAYS worked for me! If you are using Mac's Mail App, Evolution, or some other mail client that only understands OpenPGP/MIME encryption, then you will have to save the message to a file and decrypt it manually. I was able to get FireGPG to decrypt on OpenPGP/MIME encrypted message from Thunderbird but it only did it once so I would stick with INLINE. WARNINGS: Always be sure to clean your buffer cache after using FireGPG. Do a Tools -> Clear Private Data in both closing the browser and the next time you open the browser. The authors are native French speakers (one lives in Morocco) so if you want to converse with them individually by all means shift to Francais and they will appreciate it and you will get much faster results communication. HHH -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGe46jr3QZv1upb6wRCvpbAKCGp/wKUrWmtYYZL3fAYwvfdG20MQCfZ7gw TBZOq4/wMZWXL2GSuJF5ki4= =PJVh -----END PGP SIGNATURE----- From hhhobbit at securemecca.net Fri Jun 22 11:02:43 2007 From: hhhobbit at securemecca.net (Henry Hertz Hobbit) Date: Fri, 22 Jun 2007 03:02:43 -0600 Subject: FireGPG Report In-Reply-To: <467B8EA3.60406@securemecca.net> References: <467B8EA3.60406@securemecca.net> Message-ID: <467B9033.5030409@securemecca.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Henry Hertz Hobbit wrote: > I have done some extensive testing of FireGPG. Here are the > results of the tests (the files will be there until the end > of the present month): > > http://www.securemecca.com/ FireGPG.zip > http://www.securemecca.com/AOL_FireGPG_SignTest.zip > > SHA1 sums of files: > ------------------- > a293f08fb3821f79ed42c2ae6dea50cfe90e98ce AOL_FireGPG_SignTest.zip > 47898a296c797ac1f014ac8442265c0746f348a1 FireGPG.zip http://www.securemecca.com/FireGPG.zip (no space) Also, although I usually use GnuPG 1.4.7 for compatibility with Windows, FireGPG will work just fine with 2.0.x. You just have to set which GnuPG you want to use in the preferences. The results are still the same. HHH -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGe5Azr3QZv1upb6wRCpFCAKCiSWFrlWUPS9e6g0jf6bP18NaKPACfdbTA pJJ7N9rSX/4geGvyRkvXpYY= =Btv/ -----END PGP SIGNATURE----- From james at freecharity.org.uk Fri Jun 22 12:11:45 2007 From: james at freecharity.org.uk (James Davis) Date: Fri, 22 Jun 2007 11:11:45 +0100 Subject: Importing backed up card generated key In-Reply-To: <46765A31.8090303@freecharity.org.uk> References: <46696D1A.6050609@freecharity.org.uk> <46765A31.8090303@freecharity.org.uk> Message-ID: <467BA061.5040000@freecharity.org.uk> James Davis wrote: > Sorry to bring up this thread again but I've still not been able to work > out what I should be doing and I'd appreciate any help you can give me > as it's holding back my adoption of the smart card. I'm making a little progress on this. Someone suggested it was because gpg was confused by the existing secret key it believed was on the card but deleting my secret key before trying to import it from the backup didn't help. I can use the backed up key using --secret-keyring ~/sk_B6D49AF9C7335BD1.gpg and copying sk_B6D49AF9C7335BD1.gpg over ~/.gnupg/secring.gpg works too but neither are entirely practical. I've got other secret keys which I'd like to avoid overwriting if it's just my card I've lost. I thoguht I could do something like $ gpg -a --secret-keyring ~/sk_B6D49AF9C7335BD1.gpg --export-secret-key C7335BD1 > mysecretkey.asc but again I end up with a secret key that gpg refuses to import with an error "gpg: key C7335BD1: no user ID". Is there some way I can force a user ID upon gpg when I import the key? James -- http://www.freecharity.org.uk/ - Free IT services for charities http://www.freecharity.org.uk/wiki/ - The VCSWiki From hhhobbit at securemecca.net Fri Jun 22 12:42:08 2007 From: hhhobbit at securemecca.net (Henry Hertz Hobbit) Date: Fri, 22 Jun 2007 04:42:08 -0600 Subject: RSA 4096 ridiculous? In-Reply-To: References: Message-ID: <467BA780.6020804@securemecca.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Werner Koch wrote: > The sign operation is of course far slower: A single sign operation > takes 0.28 seconds on my 1500Mhz Pentium M. Given that this is the same > time as for a decrypt operation, this will be noticable if you receive a > mail encrypted to several hidden keys (--throw-keyid) and you need to do > trial decryptions. First, thanks for the stats. What may be suitable for me may be totally impractical for somebody sending backup files that are signed and encrypted on the sending machine, then sent across a network where they are automatically verified by the receiving machine. At least now people have some hard numbers to make reasonable decisions for keys that meet their own needs. THANK YOU! PLEASE DEFINE NOTICEABLE! If it is still only 0.xx ... 2 seconds for your stated conditions which is multiple users with the sender using - --throw-keyid (which I don't use) that is acceptable to me. I wait much longer than that for the POP server to start giving me the files anyway. Also, even though I type extremely fast my pass-phrases are inordinately long and rather complex which requires a fair amount of time for me to type them. In other words, it may take me far longer to type the pass-phrase than it does to decrypt or decrypt + verify all of the encrypted messages. The primary purpose for these keys I am going to create is to sign just a few files only a few times per week or month anyway. It appears 4096R isn't as awful as some people thought it was. And computers are just going to keep getting faster. That includes PDAs. HHH -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGe6eAr3QZv1upb6wRCuxXAKCCrdjM47iwQammWnNx5f60iwYKSwCePDJb +0XHfZG1S+Swgh3tCVxE6eI= =cyNY -----END PGP SIGNATURE----- From wk at gnupg.org Fri Jun 22 13:07:36 2007 From: wk at gnupg.org (Werner Koch) Date: Fri, 22 Jun 2007 13:07:36 +0200 Subject: RSA 4096 ridiculous? In-Reply-To: <467BA780.6020804@securemecca.net> (Henry Hertz Hobbit's message of "Fri, 22 Jun 2007 04:42:08 -0600") References: <467BA780.6020804@securemecca.net> Message-ID: <87fy4kgscn.fsf@wheatstone.g10code.de> On Fri, 22 Jun 2007 12:42, hhhobbit at securemecca.net said: > PLEASE DEFINE NOTICEABLE! If it is still only 0.xx ... 2 seconds for > your stated conditions which is multiple users with the sender using A second is definitely noticable and even half a second is often annoying. I regular take part in discussions with a dozen or so people and some of them have the habit of using --throw-keyid. Browsing througbn these message takes quite a while mainly due to the decryption time. With larger keys it would get more annoying. > time for me to type them. In other words, it may take me far longer > to type the pass-phrase than it does to decrypt or decrypt + verify Not to me as I cache my passphrase for an hour or so. > I am going to create is to sign just a few files only a few times > per week or month anyway. It's up to you. I still believe that there are hidden bugs in gpg which are easier to exploit than to break such a larger key. Shalom-Salam, Werner From wk at gnupg.org Fri Jun 22 13:16:58 2007 From: wk at gnupg.org (Werner Koch) Date: Fri, 22 Jun 2007 13:16:58 +0200 Subject: Importing backed up card generated key In-Reply-To: <467BA061.5040000@freecharity.org.uk> (James Davis's message of "Fri, 22 Jun 2007 11:11:45 +0100") References: <46696D1A.6050609@freecharity.org.uk> <46765A31.8090303@freecharity.org.uk> <467BA061.5040000@freecharity.org.uk> Message-ID: <87bqf8grx1.fsf@wheatstone.g10code.de> Hi, Are you using gpg or gpg2 and what version? gpg2 and card interactions are not that well tested. If you have problems with scdaemon, I suggest to use the gpg internal code instead of gpg -> gpg-agent -> scdaemon: Put a "disable-scdaemon" into gpg-agent.conf, give gpg-agent a HUP and check that no scdaemon is running anymore (you may just kill it). Then use "gpg --no-use-agent --edit-key". The command "bkuptocard" may then be used to store a backup key on a card. Yes, we really need a howto on recovering smartcard keys. Salam-Shalom, Werner From wk at gnupg.org Fri Jun 22 13:26:55 2007 From: wk at gnupg.org (Werner Koch) Date: Fri, 22 Jun 2007 13:26:55 +0200 Subject: Question about check command In-Reply-To: <467B8DBA.23903.3CBC616F@dirk.traulsen.lypso.de> (Dirk Traulsen's message of "Fri, 22 Jun 2007 08:52:10 +0200") References: <1180970783.12442.1193338545@webmail.messagingengine.com> <467B8DBA.23903.3CBC616F@dirk.traulsen.lypso.de> Message-ID: <877ipwgrgg.fsf@wheatstone.g10code.de> On Fri, 22 Jun 2007 08:52, dirk.traulsen at lypso.de said: > empty = no signature check > ! = successful check = good signature > - = bad signature > % = other error during check correct. > and only when using the --with-colon option (why?): > > ? = no or unusable public key In the standard listing (--check-sigs) we print a note at the end with the number of unusable or missing keys instead. This makes more sense than to list all the keyids we now about but won't be able to verify. The colon listing provides them so that frontends can take their own decision. I'll describe the "!" etc in man page. Shalom-Salam, Werner From wk at gnupg.org Fri Jun 22 13:49:16 2007 From: wk at gnupg.org (Werner Koch) Date: Fri, 22 Jun 2007 13:49:16 +0200 Subject: errors in manual In-Reply-To: <467B8DB9.4003.3CBC6085@dirk.traulsen.lypso.de> (Dirk Traulsen's message of "Fri, 22 Jun 2007 08:52:09 +0200") References: <467B8DB9.4003.3CBC6085@dirk.traulsen.lypso.de> Message-ID: <873b0kgqf7.fsf@wheatstone.g10code.de> On Fri, 22 Jun 2007 08:52, dirk.traulsen at lypso.de said: > 1. In the new manual the following options are missing: > > --batch > --yes > --no Already fixed: 2007-04-10 Werner Koch * gpg.texi (GPG Configuration Options): Document --batch, no-tty, --yes and --no. > 2. The manual has now strange gaps in it (at least under German > WinxP): > Here are 3 examples: > > SYNOPSIS > gpg [--homedir ___] [--options ____] [_______] _______ [____] The pseudo variables used to be printed bold by using a backspace and printing again. That was removed using sed $(printf "s/\b.//g") but that won't work for the new underlined markup. I'll change it to sed `printf "s/_\b//g;s/\b.//g"` Thanks, Werner From wk at gnupg.org Fri Jun 22 13:58:57 2007 From: wk at gnupg.org (Werner Koch) Date: Fri, 22 Jun 2007 13:58:57 +0200 Subject: RSA 4096 ridiculous? In-Reply-To: <5d7f07420706211216t21d473bbg824caf7c5617b905@mail.gmail.com> (Ryan Malayter's message of "Thu, 21 Jun 2007 14:16:17 -0500") References: <46789BA9.5040805@securemecca.net> <5d7f07420706211216t21d473bbg824caf7c5617b905@mail.gmail.com> Message-ID: <87y7icfbem.fsf@wheatstone.g10code.de> On Thu, 21 Jun 2007 21:16, malayter at gmail.com said: > Huh? Why would you try to use bzip2 AFTER encrypting? > Strongly-encrypted data is not compressible. And GnuPG uses gzip > compression by default *before* encryption anyway. You may also use bzip2 encryption using "--compress-algo bzip2". This overrides the preference system as the used compression method is subject to preference calculation. Shalom-Salam, Werner From dshaw at jabberwocky.com Fri Jun 22 14:54:51 2007 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 22 Jun 2007 08:54:51 -0400 Subject: RSA 4096 ridiculous? (was RSA 1024 ridiculous) In-Reply-To: <5d7f07420706211216t21d473bbg824caf7c5617b905@mail.gmail.com> References: <46789BA9.5040805@securemecca.net> <5d7f07420706211216t21d473bbg824caf7c5617b905@mail.gmail.com> Message-ID: <20070622125451.GB15447@jabberwocky.com> On Thu, Jun 21, 2007 at 02:16:17PM -0500, Ryan Malayter wrote: > On 6/19/07, Henry Hertz Hobbit wrote: > > than it took me to tar it. It also takes me much less time to > > encrypt the tarred file than it takes to do the final bzip2 of the > > encrypted file. > > Huh? Why would you try to use bzip2 AFTER encrypting? > Strongly-encrypted data is not compressible. And GnuPG uses gzip > compression by default *before* encryption anyway. If you want bzip2, use can use bzip2 directly from within GnuPG: --compress-algo bzip2 For some inputs (like text), bzip2 does some impressive things. David From bahamut at digital-signal.net Fri Jun 22 17:43:15 2007 From: bahamut at digital-signal.net (Andrew Berg) Date: Fri, 22 Jun 2007 10:43:15 -0500 Subject: Two questions Message-ID: <467BEE13.6070902@digital-signal.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 1. Why is it using RIPEMD160, when my preference is SHA256? > C:\Documents and Settings\backup\ThunderbirdPortable\App\gpg>gpg > --edit-key "Andrew Berg " gpg (GnuPG) > 1.4.7; Copyright (C) 2006 Free Software Foundation, Inc. This > program comes with ABSOLUTELY NO WARRANTY. This is free software, > and you are welcome to redistribute it under certain conditions. > See the file COPYING for details. > > Secret key is available. > > pub 2048R/60A78FCB created: 2007-04-20 expires: 2012-04-18 > usage: SCA trust: ultimate validity: ultimate sub > 2048R/BBC5C9CF created: 2007-04-20 expires: 2012-04-18 usage: E > [ultimate] (1). Andrew Berg > > Command> showpref [ultimate] (1). Andrew Berg > Cipher: AES256, AES192, AES, CAST5, > 3DES Digest: SHA256, RIPEMD160, SHA1 Compression: BZIP2, ZLIB, ZIP, > Uncompressed Features: MDC, Keyserver no-modify > > Command> pref [ultimate] (1). Andrew Berg > S9 S8 S7 S3 S2 H8 H3 H2 Z3 Z2 Z1 [mdc] > [no-ks-modify] Before, it even had the order of SHA1, SHA256, RIPEMD160. Is it a limitation of the key? If so, which hash do you recommend (I doubt I'll be signing anything big)? 2. How do I make the key ID "Andrew Berg" mean my newer key for this address instead of my older one (bahamut at madhatt.com)? - -- Windows NT 5.1.2600.2180 | Thunderbird 2.0.0.4 | Enigmail 0.95.1 | GPG 1.4.7 Key ID: 0x60A78FCB - available on major keyservers and upon request Fingerprint: 4A84 CAE2 A0D3 2AEB 71F6 07FD F88E 0340 60A7 8FCB -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEVAwUBRnvuEviOA0Bgp4/LAQMYsQf+JGh/gepHUN7xRS4F1NgqgUARO38sSDne oCN+0dG3ss4muxoNrufhbYjREm6D4ucpOulaGgLb8T5atLP44CL+hCFBfoHJzqRR zYmiyDUa5oX28H7DaS1WuTvSwo16McqpA8kd3WxgeaYSOFvStGr5/CXG6ZAI8iQa ZXZxDar7jQLzM1FhaNuFeHmZpatMaI/6rFbdEjatoBYcJyY/lkb/xsSBqy5cg7PE i7jnU3l9BTbb/CF2cV7RG3B/gVRHrHy1D6T/Tt9Ot90g4N1J+UMHj8a0kt/Lntyc SwbwJMGByzAt7WPqhjmsW8idmDzraDTZ9+6ckUGokbB2rq/UjFqDvA== =00g3 -----END PGP SIGNATURE----- From JPClizbe at tx.rr.com Fri Jun 22 19:49:16 2007 From: JPClizbe at tx.rr.com (John Clizbe) Date: Fri, 22 Jun 2007 12:49:16 -0500 Subject: Two questions In-Reply-To: <467BEE13.6070902@digital-signal.net> References: <467BEE13.6070902@digital-signal.net> Message-ID: <467C0B9C.1090500@tx.rr.com> Andrew Berg wrote: > 1. Why is it using RIPEMD160, when my preference is SHA256? Ummm, a) A 160 bit hash is required by whatever it is you are doing and RIPEMD160 has a higher preference than SHA-1 under your present preference list and/or b) You have not explicitly enabled DSA2 hash generation with 'enable-dsa2' > 2. How do I make the key ID "Andrew Berg" mean my newer key for this > address instead of my older one (bahamut at madhatt.com)? GnuPG will use the first key that matches the key ID supplied as it, presently (subject to change) sequentially reads the keyring files. If you have multiple keys that match a given search term, ie "Andrew Berg", then the easiest way to avoid ambiguity is to refer to the keys via the short hexadecimal key ID, eg 0xdecafbad. There is a place on the 'OpenPGP Security' tab within Account Settings in Thunderbird, to tell Enigmail to use a specific key ID rather than matching a key via email address. You also may wish to specify the new key as the default-key along with various other helpful settings in gpg.conf. -- John P. Clizbe Inet: John (a) Mozilla-Enigmail.org You can't spell fiasco without SCO. PGP/GPG KeyID: 0x608D2A10/0x18BB373A "what's the key to success?" / "two words: good decisions." "what's the key to good decisions?" / "one word: experience." "how do i get experience?" / "two words: bad decisions." "Just how do the residents of Haiku, Hawai'i hold conversations?" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 663 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20070622/f49f30f2/attachment-0001.pgp From jbruni at mac.com Fri Jun 22 19:54:23 2007 From: jbruni at mac.com (Joseph Oreste Bruni) Date: Fri, 22 Jun 2007 10:54:23 -0700 Subject: Two questions In-Reply-To: <467BEE13.6070902@digital-signal.net> References: <467BEE13.6070902@digital-signal.net> Message-ID: <8FC73146-0113-1000-C306-4F33F44C9EC2-Webmail-10010@mac.com> 1. In your gpg.conf, you can specify a "digest-algo SHA256" which will set your default signature algorithm. The preferences in your key are used by others to determine which algorithms to use when sending messages to you. Not the other way around. 2. Your key ID will be a number (e.g. CD55 18C7) not your name. If the name you indicate matches more than one key, the first is assumed. The only way to exactly specify a key is by its (relativetly) unique key ID. I'm not sure if this answers your question. Here is another answer to your question with a different interpretation: If you have a key with multiple UID's and you want to change your primary UID, select the UID using "UID #" and then use the "primary" command from within the "--edit-key" menu. -- PGP Fingerprint: C54A C9DD 84AD C6FC D343 67C4 5195 D63A CD55 18C7 On Friday, June 22, 2007, at 08:47AM, "Andrew Berg" wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: RIPEMD160 > >1. Why is it using RIPEMD160, when my preference is SHA256? >> C:\Documents and Settings\backup\ThunderbirdPortable\App\gpg>gpg >> --edit-key "Andrew Berg " gpg (GnuPG) >> 1.4.7; Copyright (C) 2006 Free Software Foundation, Inc. This >> program comes with ABSOLUTELY NO WARRANTY. This is free software, >> and you are welcome to redistribute it under certain conditions. >> See the file COPYING for details. >> >> Secret key is available. >> >> pub 2048R/60A78FCB created: 2007-04-20 expires: 2012-04-18 >> usage: SCA trust: ultimate validity: ultimate sub >> 2048R/BBC5C9CF created: 2007-04-20 expires: 2012-04-18 usage: E >> [ultimate] (1). Andrew Berg >> >> Command> showpref [ultimate] (1). Andrew Berg >> Cipher: AES256, AES192, AES, CAST5, >> 3DES Digest: SHA256, RIPEMD160, SHA1 Compression: BZIP2, ZLIB, ZIP, >> Uncompressed Features: MDC, Keyserver no-modify >> >> Command> pref [ultimate] (1). Andrew Berg >> S9 S8 S7 S3 S2 H8 H3 H2 Z3 Z2 Z1 [mdc] >> [no-ks-modify] >Before, it even had the order of SHA1, SHA256, RIPEMD160. Is it a >limitation of the key? If so, which hash do you recommend (I doubt >I'll be signing anything big)? > >2. How do I make the key ID "Andrew Berg" mean my newer key for this >address instead of my older one (bahamut at madhatt.com)? > >- -- >Windows NT 5.1.2600.2180 | Thunderbird 2.0.0.4 | Enigmail 0.95.1 | GPG >1.4.7 >Key ID: 0x60A78FCB - available on major keyservers and upon request >Fingerprint: 4A84 CAE2 A0D3 2AEB 71F6 07FD F88E 0340 60A7 8FCB >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.7 (MingW32) >Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > >iQEVAwUBRnvuEviOA0Bgp4/LAQMYsQf+JGh/gepHUN7xRS4F1NgqgUARO38sSDne >oCN+0dG3ss4muxoNrufhbYjREm6D4ucpOulaGgLb8T5atLP44CL+hCFBfoHJzqRR >zYmiyDUa5oX28H7DaS1WuTvSwo16McqpA8kd3WxgeaYSOFvStGr5/CXG6ZAI8iQa >ZXZxDar7jQLzM1FhaNuFeHmZpatMaI/6rFbdEjatoBYcJyY/lkb/xsSBqy5cg7PE >i7jnU3l9BTbb/CF2cV7RG3B/gVRHrHy1D6T/Tt9Ot90g4N1J+UMHj8a0kt/Lntyc >SwbwJMGByzAt7WPqhjmsW8idmDzraDTZ9+6ckUGokbB2rq/UjFqDvA== >=00g3 >-----END PGP SIGNATURE----- > > >_______________________________________________ >Gnupg-users mailing list >Gnupg-users at gnupg.org >http://lists.gnupg.org/mailman/listinfo/gnupg-users > > From dshaw at jabberwocky.com Fri Jun 22 21:20:21 2007 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 22 Jun 2007 15:20:21 -0400 Subject: Two questions In-Reply-To: <467BEE13.6070902@digital-signal.net> References: <467BEE13.6070902@digital-signal.net> Message-ID: <20070622192021.GA20007@jabberwocky.com> On Fri, Jun 22, 2007 at 10:43:15AM -0500, Andrew Berg wrote: > 1. Why is it using RIPEMD160, when my preference is SHA256? The preference on the key is unrelated to what you will use when signing with that key (though given how often this comes up, I'm tempted to change it). Pick the hashes you like, and put a line in your config file listing those hashes: personal-digest-prefs SHA256 RIPEMD160 This will use SHA256 when possible (i.e. when signing with a RSA or DSA2 key), and RIPEMD160 otherwise. > 2. How do I make the key ID "Andrew Berg" mean my newer key for this > address instead of my older one (bahamut at madhatt.com)? In your config file: default-key (your-keyid-here) David From dshaw at jabberwocky.com Fri Jun 22 21:33:09 2007 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 22 Jun 2007 15:33:09 -0400 Subject: Two questions In-Reply-To: <8FC73146-0113-1000-C306-4F33F44C9EC2-Webmail-10010@mac.com> References: <467BEE13.6070902@digital-signal.net> <8FC73146-0113-1000-C306-4F33F44C9EC2-Webmail-10010@mac.com> Message-ID: <20070622193309.GB20007@jabberwocky.com> On Fri, Jun 22, 2007 at 10:54:23AM -0700, Joseph Oreste Bruni wrote: > 1. In your gpg.conf, you can specify a "digest-algo SHA256" which > will set your default signature algorithm. The preferences in your > key are used by others to determine which algorithms to use when > sending messages to you. Not the other way around. See the warnings on "digest-algo" in the manual. In short, don't use it. David From jbruni at mac.com Fri Jun 22 22:25:37 2007 From: jbruni at mac.com (Joseph Oreste Bruni) Date: Fri, 22 Jun 2007 13:25:37 -0700 Subject: Two questions In-Reply-To: <20070622193309.GB20007@jabberwocky.com> References: <467BEE13.6070902@digital-signal.net> <8FC73146-0113-1000-C306-4F33F44C9EC2-Webmail-10010@mac.com> <20070622193309.GB20007@jabberwocky.com> Message-ID: <8FC73146-0113-1000-C5D2-4F33F44C9EC2-Webmail-10010@mac.com> -- PGP Fingerprint: C54A C9DD 84AD C6FC D343 67C4 5195 D63A CD55 18C7 On Friday, June 22, 2007, at 12:36PM, "David Shaw" wrote: >On Fri, Jun 22, 2007 at 10:54:23AM -0700, Joseph Oreste Bruni wrote: > >> 1. In your gpg.conf, you can specify a "digest-algo SHA256" which >> will set your default signature algorithm. The preferences in your >> key are used by others to determine which algorithms to use when >> sending messages to you. Not the other way around. > >See the warnings on "digest-algo" in the manual. In short, don't use >it. > >David Good to know. It appears to work with either the short strings (pref) or the long strings (showpref). The manual only indicates short strings (pref). Joe From shavital at mac.com Fri Jun 22 23:48:44 2007 From: shavital at mac.com (Charly Avital) Date: Fri, 22 Jun 2007 17:48:44 -0400 Subject: Smart card: pcsctest fails In-Reply-To: <8FC73146-0113-1000-C306-4F33F44C9EC2-Webmail-10010@mac.com> References: <467BEE13.6070902@digital-signal.net> <8FC73146-0113-1000-C306-4F33F44C9EC2-Webmail-10010@mac.com> Message-ID: <467C43BC.8000500@mac.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I can use the card to sign, like in this message. Commands like gpg2 --card status, or gpg --card-status produce the correct output and information. But pcsctest ends with: Testing SCardConnect : Sharing violation. I have searched the web, found lots of reports of this 'sharing violation], but no suggestion how to remedy. Running: PPC MacOS 10.4.9 gpg 1.4.7 gpg2 2.0.4 OpenPGP card SCR243 PCMCIA reader TIA. Charly key -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (Darwin) Comment: GnuPG for Privacy Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRnxDeSRJoUyU/RYhAQJJTAP+LUhXl5/HEV1sFbZykUWgSCBfevejJpPG JFgrJe0AJbGhbsOluBrdP4oOfHeWpVxBq9b490XyO+tsiS/66FCEsrdtUkhRgBKX TL/r3Nq7o0h8Qhs4hbrxevP3U+FjiXWZAsTgjmqe5UNSllNKgLe9/apVaEeb+doj y1XfNC1Pza0= =39SL -----END PGP SIGNATURE----- From ashutosh.n.sharma at aexp.com Fri Jun 22 23:33:04 2007 From: ashutosh.n.sharma at aexp.com (Ashutosh N Sharma) Date: Fri, 22 Jun 2007 14:33:04 -0700 Subject: problem using encryption Message-ID: We installed gnupg 1.4.7 on Sun Solaris SPARC 8. Generated the keys also. But when we try to encrypt a file-it asks for the UID-how to provide it? I tried providing the user ID as "xpress (comment) " But no success... What's the problem-where we are going wrong? To create the keys again....i deleted .gnupg directory also-is it wrong?. This is the output of key generation: ===================================================================================================================== bash-2.03$ gpg --gen-key --verbose bash-2.03$ gpg --gen-key --verbose gpg (GnuPG) 1.4.7; Copyright (C) 2006 Free Software Foundation, Inc. This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details. gpg: WARNING: using insecure memory! gpg: please see http://www.gnupg.org/faq.html for more information Please select what kind of key you want: (1) DSA and Elgamal (default) (2) DSA (sign only) (5) RSA (sign only) Your selection? 5 RSA keys may be between 1024 and 4096 bits long. What keysize do you want? (2048) 4096 Requested keysize is 4096 bits Please specify how long the key should be valid. 0 = key does not expire = key expires in n days w = key expires in n weeks m = key expires in n months y = key expires in n years Key is valid for? (0) 0 Key does not expire at all Is this correct? (y/N) y You need a user ID to identify your key; the software constructs the user ID from the Real Name, Comment and Email Address in this form: "Heinrich Heine (Der Dichter) " Real name: xpress Email address: ashutosh.n.sharma at aexp.com Comment: "GPG Testing.... You selected this USER-ID: "xpress ("GPG Testing....) " Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? N Real name: credit secure You selected this USER-ID: "credit secure ("GPG Testing....) " Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? 0 Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o You need a Passphrase to protect your secret key. We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. ........+++++ ...........+++++ gpg: writing self signature gpg: RSA/SHA1 signature from: "2D64B2BE [?]" gpg: writing public key to `/export/home/xpress/.gnupg/pubring.gpg' gpg: writing secret key to `/export/home/xpress/.gnupg/secring.gpg' gpg: /export/home/xpress/.gnupg/trustdb.gpg: trustdb created gpg: using PGP trust model gpg: key 2D64B2BE marked as ultimately trusted public and secret key created and signed. gpg: checking the trustdb gpg: 1 keys cached (1 signatures) gpg: 1 keys processed (0 validity counts cleared) gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u pub 4096R/2D64B2BE 2007-06-22 Key fingerprint = FF6D BE13 4E53 1411 DBA2 E051 D9D7 AE9F 2D64 B2BE uid credit secure ("GPG Testing....) Note that this key cannot be used for encryption. You may want to use the command "--edit-key" to generate a subkey for this purpose. bash-2.03$ ===================================================================================================================== With Best Regards Ashutosh Sharma Enterprise Case, Communication, Billing & Payments Email: ashutosh.n.sharma at aexp.com American Express made the following annotations on 06/22/07, 14:33:11 ------------------------------------------------------------------------------ ****************************************************************************** "This message and any attachments are solely for the intended recipient and may contain confidential or privileged information. If you are not the intended recipient, any disclosure, copying, use, or distribution of the information included in this message and any attachments is prohibited. If you have received this communication in error, please notify us by reply e-mail and immediately and permanently delete this message and any attachments. Thank you." American Express a ajout? le commentaire suivant le 06/22/07, 14:33:11 Ce courrier et toute pi?ce jointe qu'il contient sont r?serv?s au seul destinataire indiqu? et peuvent renfermer des renseignements confidentiels et privil?gi?s. Si vous n'?tes pas le destinataire pr?vu, toute divulgation, duplication, utilisation ou distribution du courrier ou de toute pi?ce jointe est interdite. Si vous avez re?u cette communication par erreur, veuillez nous en aviser par courrier et d?truire imm?diatement le courrier et les pi?ces jointes. Merci. ****************************************************************************** ============================================================================== From ashutosh.n.sharma at aexp.com Fri Jun 22 23:36:54 2007 From: ashutosh.n.sharma at aexp.com (Ashutosh N Sharma) Date: Fri, 22 Jun 2007 14:36:54 -0700 Subject: encryption failed: unusable public key Message-ID: bash-2.03$ gpg -r "xpress (comment) " --encrypt /export/home/xpress/ashu/readme.txt gpg: WARNING: using insecure memory! gpg: please see http://www.gnupg.org/faq.html for more information gpg: xpress (comment) : skipped: unusable public key gpg: /export/home/xpress/ashu/readme.txt: encryption failed: unusable public key bash-2.03$ echo $? 2 when i go to $HOME/.gnupg- ls -la bash-2.03$ ls -la total 46 drwx------ 2 xpress logadmin 512 Jun 22 14:34 . drwxr-xr-x 121 xpress logadmin 12288 Jun 22 14:17 .. -rw------- 1 xpress logadmin 1147 Jun 22 14:32 pubring.gpg -rw------- 1 xpress logadmin 1147 Jun 22 14:32 pubring.gpg~ -rw------- 1 xpress logadmin 600 Jun 22 14:32 random_seed -rw------- 1 xpress logadmin 2476 Jun 22 14:32 secring.gpg -rw------- 1 xpress logadmin 1280 Jun 22 14:32 trustdb.gpg what we are missing-what i have done wrong...? With Best Regards Ashutosh Sharma Enterprise Case, Communication, Billing & Payments Email: ashutosh.n.sharma at aexp.com American Express made the following annotations on 06/22/07, 14:37:02 ------------------------------------------------------------------------------ ****************************************************************************** "This message and any attachments are solely for the intended recipient and may contain confidential or privileged information. If you are not the intended recipient, any disclosure, copying, use, or distribution of the information included in this message and any attachments is prohibited. If you have received this communication in error, please notify us by reply e-mail and immediately and permanently delete this message and any attachments. Thank you." American Express a ajout? le commentaire suivant le 06/22/07, 14:37:02 Ce courrier et toute pi?ce jointe qu'il contient sont r?serv?s au seul destinataire indiqu? et peuvent renfermer des renseignements confidentiels et privil?gi?s. Si vous n'?tes pas le destinataire pr?vu, toute divulgation, duplication, utilisation ou distribution du courrier ou de toute pi?ce jointe est interdite. Si vous avez re?u cette communication par erreur, veuillez nous en aviser par courrier et d?truire imm?diatement le courrier et les pi?ces jointes. Merci. ****************************************************************************** ============================================================================== From benjamin at py-soft.co.uk Sat Jun 23 01:24:08 2007 From: benjamin at py-soft.co.uk (Benjamin Donnachie) Date: Sat, 23 Jun 2007 00:24:08 +0100 Subject: Smart card: pcsctest fails In-Reply-To: <467C43BC.8000500@mac.com> References: <467BEE13.6070902@digital-signal.net> <8FC73146-0113-1000-C306-4F33F44C9EC2-Webmail-10010@mac.com> <467C43BC.8000500@mac.com> Message-ID: <467C5A18.7020408@py-soft.co.uk> Charly Avital wrote: > But pcsctest ends with: > Testing SCardConnect : Sharing violation. I think the scdaemon (part of gpg-agent) opens the card with exclusive access. If you want to run pcsctest, kill gpg-agent and then restart it after. Take care, Ben From ashutosh.n.sharma at aexp.com Sat Jun 23 01:34:47 2007 From: ashutosh.n.sharma at aexp.com (Ashutosh N Sharma) Date: Fri, 22 Jun 2007 16:34:47 -0700 Subject: encryption failed In-Reply-To: <467C5A18.7020408@py-soft.co.uk> Message-ID: skipped: unusable public key gpg: just.txt: encryption failed: unusable public key what to do with this error-i cannot do a basic encryption of a file. I have generated a 2048 or 4096 bytes RSA keys successfully but i m not able to use the keys for encryting some very basic files. With Best Regards Ashutosh Sharma Enterprise Case, Communication, Billing & Payments Email: ashutosh.n.sharma at aexp.com American Express made the following annotations on 06/22/07, 16:34:54 ------------------------------------------------------------------------------ ****************************************************************************** "This message and any attachments are solely for the intended recipient and may contain confidential or privileged information. If you are not the intended recipient, any disclosure, copying, use, or distribution of the information included in this message and any attachments is prohibited. If you have received this communication in error, please notify us by reply e-mail and immediately and permanently delete this message and any attachments. Thank you." American Express a ajout? le commentaire suivant le 06/22/07, 16:34:54 Ce courrier et toute pi?ce jointe qu'il contient sont r?serv?s au seul destinataire indiqu? et peuvent renfermer des renseignements confidentiels et privil?gi?s. Si vous n'?tes pas le destinataire pr?vu, toute divulgation, duplication, utilisation ou distribution du courrier ou de toute pi?ce jointe est interdite. Si vous avez re?u cette communication par erreur, veuillez nous en aviser par courrier et d?truire imm?diatement le courrier et les pi?ces jointes. Merci. ****************************************************************************** ============================================================================== From JPClizbe at tx.rr.com Sat Jun 23 02:25:21 2007 From: JPClizbe at tx.rr.com (John Clizbe) Date: Fri, 22 Jun 2007 19:25:21 -0500 Subject: problem using encryption In-Reply-To: References: Message-ID: <467C6871.6020309@tx.rr.com> Ashutosh N Sharma wrote: > We installed gnupg 1.4.7 on Sun Solaris SPARC 8. > Generated the keys also. > bash-2.03$ gpg --gen-key --verbose > bash-2.03$ gpg --gen-key --verbose > gpg (GnuPG) 1.4.7; Copyright (C) 2006 Free Software Foundation, Inc. > This program comes with ABSOLUTELY NO WARRANTY. > This is free software, and you are welcome to redistribute it > under certain conditions. See the file COPYING for details. > > gpg: WARNING: using insecure memory! > gpg: please see http://www.gnupg.org/faq.html for more information > Please select what kind of key you want: > (1) DSA and Elgamal (default) > (2) DSA (sign only) > (5) RSA (sign only) The default DSA/Elgamal combination allows you to create a 4096-bit encryption key. But anyway... gpg --expert --gen-key Please select what kind of key you want: (1) DSA and Elgamal (default) (2) DSA (sign only) (3) DSA (set your own capabilities) (5) RSA (sign only) (7) RSA (set your own capabilities) Your selection? 7 You need Certify, Sign, and Encrypt capabilities which is the default configuration. Enter Q to continue the process. Be nice, use your real name as part of the UserID creation. When you go to encrypt, provide the keyID you wish to encrypt to, eg 0xdecafbad. The key generation process will tell you the key ID; ie, in the email you sent, the key ID was 2D64B2BE. -- John P. Clizbe Inet: John (a) Mozilla-Enigmail.org You can't spell fiasco without SCO. PGP/GPG KeyID: 0x608D2A10/0x18BB373A "what's the key to success?" / "two words: good decisions." "what's the key to good decisions?" / "one word: experience." "how do i get experience?" / "two words: bad decisions." "Just how do the residents of Haiku, Hawai'i hold conversations?" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 663 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20070622/3e5b0af1/attachment.pgp From ashutosh.n.sharma at aexp.com Sat Jun 23 03:34:13 2007 From: ashutosh.n.sharma at aexp.com (Ashutosh N Sharma) Date: Fri, 22 Jun 2007 18:34:13 -0700 Subject: problem using encryption In-Reply-To: <467C6871.6020309@tx.rr.com> Message-ID: Thanks John, It worked really well. With Best Regards Ashutosh Sharma Enterprise Case, Communication, Billing & Payments Email: ashutosh.n.sharma at aexp.com "John Clizbe" To Ashutosh N Sharma/AMER/EXT/AEXP at AMEX 06/22/2007 05:25 PM cc "GnuPG Users" Subject Please respond to Re: problem using encryption "GnuPG Users" Ashutosh N Sharma wrote: > We installed gnupg 1.4.7 on Sun Solaris SPARC 8. > Generated the keys also. > bash-2.03$ gpg --gen-key --verbose > bash-2.03$ gpg --gen-key --verbose > gpg (GnuPG) 1.4.7; Copyright (C) 2006 Free Software Foundation, Inc. > This program comes with ABSOLUTELY NO WARRANTY. > This is free software, and you are welcome to redistribute it > under certain conditions. See the file COPYING for details. > > gpg: WARNING: using insecure memory! > gpg: please see http://www.gnupg.org/faq.html for more information > Please select what kind of key you want: > (1) DSA and Elgamal (default) > (2) DSA (sign only) > (5) RSA (sign only) The default DSA/Elgamal combination allows you to create a 4096-bit encryption key. But anyway... gpg --expert --gen-key Please select what kind of key you want: (1) DSA and Elgamal (default) (2) DSA (sign only) (3) DSA (set your own capabilities) (5) RSA (sign only) (7) RSA (set your own capabilities) Your selection? 7 You need Certify, Sign, and Encrypt capabilities which is the default configuration. Enter Q to continue the process. Be nice, use your real name as part of the UserID creation. When you go to encrypt, provide the keyID you wish to encrypt to, eg 0xdecafbad. The key generation process will tell you the key ID; ie, in the email you sent, the key ID was 2D64B2BE. -- John P. Clizbe Inet: John (a) Mozilla-Enigmail.org You can't spell fiasco without SCO. PGP/GPG KeyID: 0x608D2A10/0x18BB373A "what's the key to success?" / "two words: good decisions." "what's the key to good decisions?" / "one word: experience." "how do i get experience?" / "two words: bad decisions." "Just how do the residents of Haiku, Hawai'i hold conversations?" (See attached file: signature.asc) American Express made the following annotations on 06/22/07, 18:34:19 ------------------------------------------------------------------------------ ****************************************************************************** "This message and any attachments are solely for the intended recipient and may contain confidential or privileged information. If you are not the intended recipient, any disclosure, copying, use, or distribution of the information included in this message and any attachments is prohibited. If you have received this communication in error, please notify us by reply e-mail and immediately and permanently delete this message and any attachments. Thank you." American Express a ajout? le commentaire suivant le 06/22/07, 18:34:19 Ce courrier et toute pi?ce jointe qu'il contient sont r?serv?s au seul destinataire indiqu? et peuvent renfermer des renseignements confidentiels et privil?gi?s. Si vous n'?tes pas le destinataire pr?vu, toute divulgation, duplication, utilisation ou distribution du courrier ou de toute pi?ce jointe est interdite. Si vous avez re?u cette communication par erreur, veuillez nous en aviser par courrier et d?truire imm?diatement le courrier et les pi?ces jointes. Merci. ****************************************************************************** ============================================================================== -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/octet-stream Size: 677 bytes Desc: not available Url : /pipermail/attachments/20070622/6a0cf70b/attachment.obj From hhhobbit at securemecca.net Sat Jun 23 04:51:27 2007 From: hhhobbit at securemecca.net (Henry Hertz Hobbit) Date: Fri, 22 Jun 2007 20:51:27 -0600 Subject: RSA 4096 ridiculous? In-Reply-To: References: Message-ID: <467C8AAF.3050107@securemecca.net> Ryan Malayter" wrote: >On 6/19/07, Henry Hertz Hobbit wrote: >> than it took me to tar it. It also takes me much less time to >> encrypt the tarred file than it takes to do the final bzip2 of the >> encrypted file. > > Huh? Why would you try to use bzip2 AFTER encrypting? > Strongly-encrypted data is not compressible. And GnuPG uses gzip > compression by default *before* encryption anyway. I gave you the false impression "I" am doing it. gpg is the one that is calling bzip2. If you say it calling bzip2 first and then encrypting, I will take your word for it, but I assumed the compression would be done last. Generally speaking for small stuff I do use -a, but for this stuff I don't: 76007185 Jun 12 13:35 Quarantine.tar.gpg And in this case the encryption isn't so much for protecting the data from the prying eyes of others as it is for protecting other people from the data contained therein. It is all BAD; mostly Trojans. HHH From hhhobbit at securemecca.net Sat Jun 23 07:40:16 2007 From: hhhobbit at securemecca.net (Henry Hertz Hobbit) Date: Fri, 22 Jun 2007 23:40:16 -0600 Subject: Compression before encryption is best In-Reply-To: <467C8AAF.3050107@securemecca.net> References: <467C8AAF.3050107@securemecca.net> Message-ID: <467CB240.8040800@securemecca.net> Ryan: That was a bad example to give you, and I DID use public encryption given what was in the file to give it a little greater protection. But because it contains all binary files, you don't get much from compression anyway. I must hasten to add for the files that are in the Quarantine folder that I always add a ".ck" extension for files I THINK are bad (after analysis), and a ".BAD" extension if my decision has been confirmed by at least one AntiVirus company. By extension changes I mean: PotentiallyBad.cab -> PotentiallyBad.cab.ck ReallyBad.exe -> ReallyBad.exe.BAD But since I had to change the order of compression on my key to put bzip2 first, to me it was manual. Frequently I use just symmetric encryption with the "-a" flag in a script. I had some problems doing it without the flag (can't remember what it was) so I left the script that way. I should probably modify the script to give a choice. Depending on how big the file is, I may or may not use the script. Usually I am in such a hurry I end up using the script. I did a short test using symmetric encryption (AES), and my key set to do NO compression (my default, and it should have nothing to do with symmetric encryption). Here are the results of the test (you should be able to deduce what the other files are from the comments): 1154945 Hosts.tar.bz2.gpg bzipped, then encrypted 1157556 Hosts.tar.bz2 1390758 Hosts.tar.gz.gpg 1390807 Hosts.tar.gz 1390856 Hosts.tar.zip.gpg 1390929 Hosts.tar.zip 1407485 Hosts.tar.gpg encrypted ONLY 1407732 Hosts.tar.gpg.gz 1407858 Hosts.tar.gpg.zip 1414045 Hosts.tar.gpg.bz2 encrypted, then bzipped 6400000 Hosts.tar -------------------------- (using "-a" option) 1906066 Hosts.tar.asc 1446067 Hosts.tar.asc.bz2 If you aren't using the "-a" option, you should NOT attempt to compress it after you have encrypted it because it just makes the file size LARGER! This is altered if you do an --armor as you noted, and my scripts are set to do "-a" encryption right now. Since the size difference was only marginally larger for the *.asc file I figured I would just bzip2 the file after it was encrypted. When I am in a hurry it is easier to use script and then bzip2, but it is NOT the smallest file. That file is the one that bzipped, and then encrypted without the "-a" option. Encryption does some compression. It reduced the size of all the compressed files, and the size of the TAR file considerably whether you use "-a" option or not. HHH From bahamut at digital-signal.net Sat Jun 23 20:02:37 2007 From: bahamut at digital-signal.net (Andrew Berg) Date: Sat, 23 Jun 2007 13:02:37 -0500 Subject: Two questions In-Reply-To: <8FC73146-0113-1000-C306-4F33F44C9EC2-Webmail-10010@mac.com> References: <467BEE13.6070902@digital-signal.net> <8FC73146-0113-1000-C306-4F33F44C9EC2-Webmail-10010@mac.com> Message-ID: <467D603D.1060003@digital-signal.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Joseph Oreste Bruni wrote: > 2. Your key ID will be a number (e.g. CD55 18C7) not your name. If > the name you indicate matches more than one key, the first is > assumed. The only way to exactly specify a key is by its > (relativetly) unique key ID. "Andrew Berg" returns my old key; "Andrew Berg " returns the newer key. > I'm not sure if this answers your question. Here is another answer > to your question with a different interpretation: If you have a key > with multiple UID's and you want to change your primary UID, select > the UID using "UID #" and then use the "primary" command from > within the "--edit-key" menu. They're two different keys. John Clizbe wrote: > If you have multiple keys that match a given search term, ie > "Andrew Berg", then the easiest way to avoid ambiguity is to refer > to the keys via the short hexadecimal key ID Yeah, but I tend to remember my name much more easily than my key ID. > 0xdecafbad :-D > You also may wish to specify the new key as the default-key along > with various other helpful settings in gpg.conf. I can't get the format right. I thought of something: why not delete the old key outright? Not only has it been revoked, but that email address doesn't even exist anymore (which is why I revoked it). - -- Windows NT 5.1.2600.2180 | Thunderbird 2.0.0.4 | Enigmail 0.95.1 | GPG 1.4.7 Key ID: 0x60A78FCB - available on major keyservers and upon request Fingerprint: 4A84 CAE2 A0D3 2AEB 71F6 07FD F88E 0340 60A7 8FCB -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEVAwUBRn1gPfiOA0Bgp4/LAQMUpwgAhBArAUPuyvfUlXPRem3zvk9x+Fd/epg3 jycxsSJr/RpMW94xKPZ4Sb2OmHLgWK8ua56AwgM2q6Hap/LuSKIXpqab/hZF4OOC eKmbWAufhIPnfLaXbJZt7xTrM6TcvntTKq+LAL/UVqeER6omZhl2ty6OECQG0bXl O50vK0JmojGnpdU240WSEJGUZjMjsQIuhsVeBzCL/uXKWx/Wgp+pMkZ1Htwz+z+j WUT+bIicVwCBBJFGMLhJChL4TZ8sZtDFgBTDTrwS4PH9HyBTqYqHEMaG5KhYm8St wdtgbTz/A5BadUAo57OaLWmTI5kQlUt54T6lvLK8HPJTCWhsVMP5Fw== =pfJZ -----END PGP SIGNATURE----- From JPClizbe at tx.rr.com Sat Jun 23 21:21:17 2007 From: JPClizbe at tx.rr.com (John Clizbe) Date: Sat, 23 Jun 2007 14:21:17 -0500 Subject: Two questions In-Reply-To: <467D603D.1060003@digital-signal.net> References: <467BEE13.6070902@digital-signal.net> <8FC73146-0113-1000-C306-4F33F44C9EC2-Webmail-10010@mac.com> <467D603D.1060003@digital-signal.net> Message-ID: <467D72AD.8050803@tx.rr.com> Andrew Berg wrote: > John Clizbe wrote: >> If you have multiple keys that match a given search term, ie >> "Andrew Berg", then the easiest way to avoid ambiguity is to refer >> to the keys via the short hexadecimal key ID > Yeah, but I tend to remember my name much more easily than my key ID. > >> 0xdecafbad > :-D With a bit of practice, they're easily remembered. > >> You also may wish to specify the new key as the default-key along >> with various other helpful settings in gpg.conf. > I can't get the format right. default-key 0xdecafbad # use this key to sign default-recipient-self # always encrypt a copy to me encrypt-to 0xdeadbeef # also encrypt to my second key > I thought of something: why not delete the old key outright? Not only > has it been revoked, but that email address doesn't even exist anymore > (which is why I revoked it). Revoking the old and adding a new userID is the route I'd take, but we've already had that discussion. The only reason for keeping your old key is to decrypt anything that may have been encrypted to it. If you delete the old key you will lose access to anything encrypted to that key. If you /really/ want to use your name to lookup your current key, you could add a new UID to the old key that doesn't match your name and delete the UID that does match; eg "A. Berg-revoked". You may use anything you like, so long as it doesn't match whatever you are using for a search term. -- John P. Clizbe Inet: John (a) Mozilla-Enigmail.org You can't spell fiasco without SCO. PGP/GPG KeyID: 0x608D2A10/0x18BB373A "what's the key to success?" / "two words: good decisions." "what's the key to good decisions?" / "one word: experience." "how do i get experience?" / "two words: bad decisions." "Just how do the residents of Haiku, Hawai'i hold conversations?" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 663 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20070623/ec481d55/attachment-0001.pgp From hs2412 at gmail.com Sun Jun 24 12:07:46 2007 From: hs2412 at gmail.com (Hardeep Singh) Date: Sun, 24 Jun 2007 15:37:46 +0530 Subject: Converting ascii armored signature to cleartext Message-ID: Hi If someone sends me an ASCII armoured file with some signed text, can I convert it into cleartext sign so that I can display it to people without GPG also? Regards Hardeep Singh From laurent.jumet at skynet.be Sun Jun 24 13:33:13 2007 From: laurent.jumet at skynet.be (Laurent Jumet) Date: Sun, 24 Jun 2007 13:33:13 +0200 Subject: Converting ascii armored signature to cleartext In-Reply-To: Message-ID: Hello Hardeep ! "Hardeep Singh" wrote: > If someone sends me an ASCII armoured file with some signed text, can > I convert it into cleartext sign so that I can display it to people > without GPG also? In my opinion, an armoured not-encrypted file is compressed with the algorithm defined by its creator: Z0 Uncompressed Z1 ZIP Z2 ZLIB Z3 BZIP2 But I don't think it's easy to read it without GPG. -- Laurent Jumet KeyID: 0xCFAF704C From bahamut at digital-signal.net Mon Jun 25 01:11:30 2007 From: bahamut at digital-signal.net (Andrew Berg) Date: Sun, 24 Jun 2007 18:11:30 -0500 Subject: Two questions Message-ID: <467EFA22.1040800@digital-signal.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 John Clizbe wrote: >>> You also may wish to specify the new key as the default-key >>> along with various other helpful settings in gpg.conf. >> I can't get the format right. > > default-key 0xdecafbad # use this key to sign > default-recipient-self # always encrypt a copy to me encrypt-to > 0xdeadbeef # also encrypt to my second key I forgot to move it to the right place. The format was right. :-[ >> I thought of something: why not delete the old key outright? Not >> only has it been revoked, but that email address doesn't even >> exist anymore (which is why I revoked it). > The only reason for keeping your old key is to decrypt anything > that may have been encrypted to it. If you delete the old key you > will lose access to anything encrypted to that key. I decided to export the pair, and then delete the copy inside the keyring. - -- Windows NT 5.1.2600.2180 | Thunderbird 2.0.0.4 | Enigmail 0.95.1 | GPG 1.4.7 Key ID: 0x60A78FCB - available on major keyservers and upon request Fingerprint: 4A84 CAE2 A0D3 2AEB 71F6 07FD F88E 0340 60A7 8FCB -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEVAwUBRn76IviOA0Bgp4/LAQNKsQf+NstSaAv7JSz7pZwlxCY8m5S61T/dgbvF nAD0O0+zpZoi/LGE/TCXHTpiiL5iK23L4zfjGXZlZW1zJOKbY0RQljDLfDnvNyH/ xzzIPutXB9G4weZ4ed0VH/Xp13FLHnUO5s+uWEWekjf1zss7gTv4lO0uikcipcaS 6iD//UmhzhRDyQCSmRHRXROClSeDT/lNK3r7mF+LOBkGI9pDDPSLV4exOeNcRAb7 Yp1h0DVQecCnWMOJTg3XMzQR4g88O+Y8k0vbyDYR3drf3HF+IzaGOKPmrTLyGdUd p6cBTH2VwUgpAuxf60KxLgxEaQkbqXrD/+UDVrHAOsJ3ngXJ3C+Gzw== =FJXl -----END PGP SIGNATURE----- From odigo at web.de Thu Jun 21 20:11:16 2007 From: odigo at web.de (odigo) Date: Thu, 21 Jun 2007 11:11:16 -0700 (PDT) Subject: Prolem with gpg --with-fingerprint < keyfile Message-ID: <11238619.post@talk.nabble.com> Hi, first, sorry for my bad english. I'm not a native speaker. I use gpg in a linux shell script to extract the fingerprint. Every key is in one file. I use gpg in the way that i put the file stream into gpg like this "gpg --with-fingerprint < keyfile". I need that for a project at my university. Usually that works fine. But now i found a problem i can't solve. This key for example doesn't work in this way, i don't get the line with fpr at the beginning: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.4.5 (GNU/Linux) mQGiBDgxFEgRBADPJ4FWedaQRTTssiGA49t5J3tDDmVzFCoY/GgDyAEWmnNGmcjR esy5xCDSd4cUqXUeK0ivDIUplj/nk7yj5VZzKsqjjWlNYtGuDx5Ah2GmkhqFayqW MpqDI3TaPEctEh8p9XghrPfSUbuTSY2FKSivWKNMIADGiT9YuGh8pYxI4wCg/70M NHzkiBC5dKj4Rn0B1Zy20OED/19f6HIl+6UIuofCYtVkFRx5KhsN4qHL3hCmp03J lIOk9tKznNI/FxWjDXTTHjLOzhctg2f8PACh+D/ePiolNVKGlD8+GPJHz7B1jbsD TObIfXPFP2q/fIZ/D1MDu0PnW9hLVPfOxFAA4b+hE++Un74zYtgU6aqR8jFdCVzL 8vz7A/9HBvIGyca/ATWl1J5+slrEtzxdfutV6QZ89Gq0LTvAhtFiRn6VxJ7STEV4 eunIpmxYskKRthjBzdk1Y2W6RsTlibnhXz8TvsaN+Zakh2DEnn/QA/sJAT5ikzlG //wXz6x8vVDa5QVVqrnviHWYnGRAhuwoYEOUmHd7/lzORGJRC4hhBB8RAgAhBQI/ eqDYFwyAEcdNGDSq6Q4VpxMVAslxrl9u8r31AgcAAAoJENx3iwdOdUvtIroAn3Ym SK0FLhIKpieDY/a2JFtOicz2AKCwbH6j1YioavYeD98n7TfsP1HDZbQhUmFpbmVy IFcuIEdlcmxpbmcgPGRzYkBndi5tcGcuZGU+iEYEEBECAAYFAkQGYxQACgkQIIdH gCGsbMSOXACff49WNBQX1s27bfNBq53Mz/u1v3UAn2AujSM56wFfwXGaC8mTVCP1 zRLiiEYEEBECAAYFAkQQc60ACgkQ7UaByb89+bRVTACg8BnccV6ov4k+AFFCFZvh Fpv2UssAnRqx9cSqYGkm4fAo99MP4EzPwvegiEYEEBECAAYFAkR1pGAACgkQXeJJ llsDWKLABwCfS20z4nQ3vC8i8eOTGMIIFz7ztB8An0xTw3Km3gY3ZUv3rW/7RHI3 n6C2iEwEEBECAAwFAkTp6UkFgwCtif8ACgkQB6g1EUxThvfCkQCgjCmcjCpbWafu d2UPq2wAqlrEcf8AmQGLlCUX+ARf7MMmFkwTp93/KVYriGUEExECACUCGwMHCwkI BwMCAQMVAgMDFgIBAh4BAheABQI/ep8YBQkM7SVLAAoJENx3iwdOdUvt/FoAoLH3 JbIGpmyP/VM7DmGjO9MFrKKeAJ9CQWtRHhKKnxr53o+Y0vG8I8XRxohlBBMRAgAl AhsDBwsJCAcDAgEDFQIDAxYCAQIeAQIXgAUCP3qgqQUJDO0m3wAKCRDcd4sHTnVL 7T5KAKDyMA17TxijCy7sy0EmIv0qub+GFgCfTTlD75SgsRT4J/IS0OuthFbcHmSI ZQQTEQIAJQIbAwcLCQgHAwIBAxUCAwMWAgECHgECF4AFAkAOdyYFCQ1mn1oACgkQ 3HeLB051S+3XRQCgvLqDD4lmDBHmCLl4M+tI+QmLTWcAniFMmVmnHn6jA6COTNfL wISmIzRIiGUEExECACUCGwMHCwkIBwMCAQMVAgMDFgIBAh4BAheABQJADncmBQkN Zp9aAAoJENx3iwdOdUvt10UAoNTLfOAsIOMGMIs8bWOWj/SasaxdAKDOz3v3EDO9 n7hsVJ2cb32ACkWoE4hoBBMRAgAoBwsJCAcDAgECGQECF4ACGwMCHgEDFgIBAxUC AwUCQA53JgUJDWafWgAKCRDcd4sHTnVL7TlDAKCx/o54O0Pfe5KkBZH3BriPYJQq vQCbBbxC6/iCIybqPr8OWPqXVyiSLwqIggQTEQIAQgUCQpxNOAUJDO0m3wcLCQgH AwIBAheAGRhsZGFwOi8va2V5c2VydmVyLnBncC5jb20CGwMDFgIBBR4BAAAAAxUC AwAKCRDcd4sHTnVL7Q2/AJ0aWooU9hoaV1MkLFvlALT6IVB9hACeJ7aHYl+XDhCw AejCRh0crSCmCNGIggQTEQIAQgUCQvhz+AUJDWZfAAcLCQgHAwIBAheAGRhsZGFw Oi8va2V5c2VydmVyLnBncC5jb20CGwMDFgIBBR4BAAAAAxUCAwAKCRDcd4sHTnVL 7aXxAJwJmKWnKP0DQJly2h+/nHP/DYR8yQCg96ffAeqTxNBZMqzV9oKJ7AXziY+I ggQTEQIAQgcLCQgHAwIBAheAGRhsZGFwOi8va2V5c2VydmVyLnBncC5jb20CGwMD FgIBBR4BAAAAAxUCAwUCRZjwdwUJD0kPrQAKCRDcd4sHTnVL7QV7AJoC/nDBEtI9 6cd9lmKPrY88TFsa6ACg5s+0qLAE1noniYfa6H3ANXrW79qJARwEEAECAAYFAkQG +8wACgkQ+fnDJwmNErNuUAf/b+nrraBXuVuEKPEKMphAnPk3I/XLbecBWddfbPrN PpFp6LVdQPbyNCWjVGfSDSymG3WhRIL4OQQjha/J7om9/HciCGkLZfpIFT+VzxVL bRCiewNJXiQjhnpZBkiFclH5PQzIetM21KXQfFuOterbmXf72+1LHp0YeBfeQ9ny xppI2k+XEaZfvhZZlHK4dMsLMTgD10Ej+ickodhIfWhDPdw5RO9PUHUAP1fx3ABB Ot6E/pgkjZVofks1TY1Fbz/Wrfa6dcc9W36Ia8BTGGkbTFVI3d5l3imanTkjFbHQ 3iSvURVjNcHqZmdtvb3P0Vx37GYt2/oyED5ORJz19SuJAokBIgQQAQIADAUCQpxO mwUDABJ1AAAKCRCXELibyletfD/yB/9E77EifRY5SV31j6jS6Srm+CVZSkNjZRMe BLLtCQUOGFGaWBBGEshbyWOCfwL08YEJR/RFfbI9TWjKDPP7Zz2Ch+QSeav08XVQ iZrw5GsbNHXrhK+NByLtYwcoIsnCwRbUswdGVKhHNOOIVnAKHISzXDh4BharNm6w 9bMtJNaWgWIR3rw9FMXc5bU4s57HiOqe7X50Uo/9fGDND/SoDYlMAV4OoVHhBPTe wRabDDITtn0ywxSJc7xk1mqp85LzPClVGQDVMe0nZIKy78N9NFNws8rThV/iks9a fbDFja9jQInhVx20RTwg5F+Wkng00Ld5XxeDiIt70XoIDl3Hiy8DiQEiBBABAgAM BQJCrdgaBQMAEnUAAAoJEJcQuJvKV6189ysIAKMvKLy/cIuPakCDU7htbfyhoBsz Ia8f/ePcrxZQd+R+oQZSMd2uZh4nkxOBRXOVN3I/5MQQYuBv3K1SaGH8b4U9KWqd zvT9RSwpornXd+GkbleQ0sm6Vgv71Dsvghen8QYOv3zXCkMWY722Y/V5rV0ZCcwF QiWIV6LeNtTHeJEvtzPw9lw7SZbO5+nJhg5tRLDmqg7kbk25fdH2cs1usaadbq1/ qSi88qgIB8yp7aQGjAwWANMC/F6VMKmHEP2e0XgSqWxOU3I9tRebgl1oCwGdm8pz loXhFDSThO6z9LmpiuANahjl3nWIDKWO+mjYNRPMLwhWontVL+AORFdKqumJASIE EAECAAwFAkK+/AMFAwASdQAACgkQlxC4m8pXrXw4pwf9E5gLE5meMVmDQBX/6h1M jirOe4b5bTmpf9Io2rxFswCpJF5sBfQbwcpAs51F5IDvb/m6l20ryTnxUcNbQ7MR VwrP3ULikFoq3ruo/W7NHHtcqr3AShpu34Eb6jesAtNfz3kKdznRXGfooMCAgQZm Z3gVJx/cdtSX4JGLKi9bIin3yLnHIGAYbegWqwYqDrFGVjfPbFw0rc3jFOyLvBB5 pqXalrI/MW91R0z4eCppOzuL8ViRA8iqS1d27k6SJ0cC4RPvXt/AsziyjgWvD2QB c04I7tWibA6x3WcBWsjWrOJWrjUJTd5BGLXnh/uzE9BpzmDGDs5ZWoviaTc+E49u uYkBIgQQAQIADAUCQtF7oAUDABJ1AAAKCRCXELibyletfELVB/9rIkVwqcwC9UVg Z9J3ngfRr3elkAEpFKoQYj+C3Sx+/+KoebBn+YDrftf8u0sQLXWm6FYbDoR4wjcH 7mL530By9W17JBXIBwv6UtpNnhZ+ORJmYYdkdnugjEJT0KjBlzYqOqUAtxPLkR1e TS0ruLNGXGzqbBrrMgvI9Xx6lHaZFhsYAMrxu65LEk/e6EBN4r3A7vvkyuhdjE3M QMB3ogezT7NIHxdQK4qVqBI0ApFQpGsHUBwK5cEscCOrn1IMGGWAQSFr+5IVFtRX DVBG2J1V6n3S5AS7cpEqohEGxFSVrBS1FqvJrwSFsbvST968nmcJcXlQI6lYHQeH Pq2rvXFCiQEiBBABAgAMBQJC40dLBQMAEnUAAAoJEJcQuJvKV618w68IAMSp+N7T e9qOWaQ9TEvlHtHyuthTPPUVgJIrFsmltDIzQHsvhu+JF+UhaQ1ZuPHezL8lQKgy dcDD2bNVuIEyyLGc483rMzWVLPHIT/CDt21cwjQcJArCPKyfQACKc8ETakSS6naR DOn4QV+Roq4lS0WuqxGJ0GkjNM8XZK/mYCYxlATb7c59L+ryAEc+sMJNjIWRJYEL jtA/MF0U+uVsjT0ZincbhtXpxeam/z1q+pI+NFr+DnRcxKV3COSMcfRvHKKyTPks ZqQ2MYnk7ANWX+BC/EIHLgiBQVstPZEsIyo7l3gVtY38jRjvpCOKDHNrjCquj0NY kkd1M3hq8R1UEFKJASIEEAECAAwFAkLj7xAFAwASdQAACgkQlxC4m8pXrXwBXwgA sa6UFUC6OXa1ZdkTxrAuF1Jn0DzVncG1vBQJohVwl3b/ESAyk4i4hr4jc0aup5J2 FQsazgA8CabC/Vzo0T+WPkS+/rfrh4RnsZh48gJxb/y08QuBYuSSaUvreRqT8xz0 S+q6VVDR4yRvIGuT5VEd1tgxHh+6SEuxSTJEPCa9Rm87k0WtqIZVqJstl4i1sF1k jMwaagmwGq4VR451SE4oo1KlNDTJWp/Ghmf+KTW7oMt33MYMy4c/DFguqmWAK3qC MI9wfSDtCyD/0HBmgmlPKY0oWudY1+ra6Q2nrwd0QC+Vl4Hol6kzSgotro23vm0i IPwnY5UQEmHlBXY8YnChNYkBIgQQAQIADAUCQunfQAUDABJ1AAAKCRCXELibylet fG3PB/0fGvtdt0mQJvuiindqj9mKWDUij8MQhunoKJ5/bhrKz7nON7v7EIKYHQ47 iYo+ya6TubzGpy2VRS4/A4LTk5GxnWINse7O9DJ1qUtIHwF/o83HtLC8dDw4MNW8 +zBHiaszWOeHDMPaAr61HaSATPB66nb6YX4+RjAO0ictb9/Tryc5JItvamd9vL1b 57DiwGJ0uEG1GpMc5swD8KwriGmoEw55rmlKnMPDLcTi92uEDtFFIusne88/33tA khrAMAy971AX+LGuGD/gtSaT+QNRhd1Ir8N6QVm12Q8pywBzZw+xdi9ehCTu67RU nEk05rJk77hLt/sFZsq/Z1iY5hbsiQEiBBABAgAMBQJC7IJgBQMAEnUAAAoJEJcQ uJvKV618ErMH/jPfNm+hxdvDMqGVahKykXrTqpZN9R4J54weHvTskvrj8W5Tu2QK RmvSYIBtMysZCUivxT5SVaDdrbeC+eeOVBSw7NM4HuDQhd8WVnXQGysif2IvijSJ qAGlq49BfTjQvJ+9tg85VUO0JdrnDCWpvIXiAlbFGBGQ4hjmwYGM3UBpaOJ8eI4d LHikdJ8RmbKKHYLQ6urhkX2ILda66EcWAr1ON6r2UF0iFlcWSFnujnA/6BHJfV8J GRFYfMiDpVWPe6Mq1kiZRAPQGyBmuH37odTulxaejI53L9xt75sksMQAX3yYKJuA /AzjO6cHqb5PyLm4F91H/dVgJC29Kgv1JUqJASIEEAECAAwFAkLtKnQFAwASdQAA CgkQlxC4m8pXrXxGiAf/QtA0AJfbLcAv6v18qL51JM1S9f60+rUJaYK95Swg/tvs Is/SKuitSdfE0nh0yJ5yYMK2Pamtiycvl3KwebBvrkqUrkDKEeth92lI5Da2gKaV frqR64HscCGW61oN2qCjuK0RRbY83txQouSnHT7a/IEEPPnrIuKkI1HoYCna34Gt +qbUjSh7XsNTgYSHql0koHNwEVwAd9CKOPhsr5Ub8Xz0Oioq17k/nlIwRuX/w5id +4BTVPQUFwMsiCN0/+wJ+P6Xu0/oUxMyLkIyRx3BLaA1y35Gs7BYjGYkd24bfOFo vNQVH4UDxRxmDrF8FdA1fewcLFhjWCfZ0WeOtSfLGIkBIgQQAQIADAUCQvh0TQUD ABJ1AAAKCRCXELibyletfK45CAC65Ch01dkRAKAdvn72bz6jUdnyREyGtRG1wt41 AEDkPZHZW6obLLrGB39H2PUIkwWK4mn8UlBJX4iub14QvsbJ9H5SsUYK52LjbKaS VYloaK7d9lQI4P9otjlACb/HLM4Uw79ZejX1B7lsGI+cI8dVNZnwEd0CMGj9frfA VIsTDJkSCANJi631DOsyfXALjyMScbYLokTbb+Hj/pNy2mTYNBKYBB37andqQOnM MbDUlS00qw+ncrSbMNdJXVWJgMVpsPR+OMDyj/Lcd0yvXMWu4GlGHs5NAiW3JeRA ytg1SbThwH/G1QNqhGvIgbBFXiZdj+AJpd6KijPfWsBDf4ztiQEiBBABAgAMBQJD CthsBQMAEnUAAAoJEJcQuJvKV618xQEH/iZB293v54v3PyUGvJ4eA3tt37MuAER/ yYejgHbmpP/fs4pm911cC35Npi20Lx5H+q0izasOfYW0SENkX/E6V82I2E2W9NVA 13Z/KPW+Vrb50N+uLR/mHC0HgIAcb66DywJEy2faRtftYTypQCxof/7IwNbJWWxK /4YQjor3ga8Gvlencqfk7CUHdZM1Nq0rrkXvi/az0k8TKeXfy4lN7tXQVa7oRpgs zTfRk9Duow/EpsWSS0EYCVHs+HqCykyYXZO3KImfCbrZroCdEMXRAh7nYmTo0ww5 X99m07O+Uy4YC/p80zJv1qod6g5HRju533vBpSi0EwWGHYG0/KRCcH2JASIEEAEC AAwFAkMMLc8FAwASdQAACgkQlxC4m8pXrXzimQf9FPT1jHp3exxbl3mt3EVWNlS8 nZ5QlsZMu1xCfvL+Zxo86qWYvd/w7U5GltVzlKOlY5JOi3OQsoRAkGHK9rfYiHPP TRJ11tBvHIiB+UyuxUPATvVD24WFvKfbKUse8w9BWZM1L+XRzE5t3Uj/pnQY25KF bPSc3ID+MKeXZsGfdBaNcxhKlfaufiMp7LCRCah79+1o3mO9OKm/i8+qJCBIleDv 38PtQmpdPQPMKj6Nk1bZjz+gxxplsRM2qAJ+FAdgth+Jw74hxvDp/t89gcC025jI VDwnSpflXcr1nQ8uB8RK9RVxfYxjYX3h0c7UcPeTPlNA1+EvG+CR53sVXjQLPIkB IgQQAQIADAUCQxDIuAUDABJ1AAAKCRCXELibyletfIXkCACWFhMekMP/hos+jO5B 2ihBuiPa98iNkcLpA92aYw2hN4j22/HfftrWKMTEh6/hg+YOaZ1isNH+OQfUMLQa TQXI5+6j4M7ourKSCBVLBM4Huvj07zQWaqSzaHltr6h1jKkZN3GRG28LBns4EX4/ 8bXHZ1sWDhRvujVOBRzcUNwLfVFM6R6KDUmz4C0GwfGdWwhv1l02vNqjijg5QKXE TmaNAZLaSedQElMQrxHgQHjWGHF4WcgZTKi9eBQAVV4S0LhTXdT8ix98TPOQ3v4u iN00AYROL5TabilauB1saWYxuFYztFzLFPPlnOXK4hKQ0MxKlqf1HAn19gxjkHKb f5WViQEiBBABAgAMBQJDE2x9BQMAEnUAAAoJEJcQuJvKV618G5gH+QFJnEXqFFv3 YDfRpPiox2p5EFi8C26MAaVPnN8lw+nK4mOOQr+HUdm1mhamxbDMfd27++5I+OwY INLqQq2gse3nDb68yBgICv/G2YJ8t1F0vzNekHHhZwpkXkZv65ZFAAw9iP6QQ3eO U6m4I3e6frz9eKUv2zl7ScqZfWzO3jRsL0GMUnC8W/+gWRtr7y7iGynhOd9o9Pa0 QDHSWLYzQWgJLkC7tgjsgy6iVwZHnwwoLcKjoOWw0bg0qNGJrGRZ8uR63qLeQdMc s4DkfrIP8SE8pyzSh13fyxui5OwmuINJxmRUd7yZkCw98aQthJATJwpDruZZs7HP 6G2JH7MigYKJASIEEAECAAwFAkMUFXsFAwASdQAACgkQlxC4m8pXrXxAbAf+JICi Ypr2EHYQWizFtdTHcV23J0xPmsuj//6aY+/y3DD26DSwld3X+WDp4dJBIdhRl3bg x7RIANa2LtlOzcjDmqH49OU0XLumviXdMCdNLNnh0NVllW+hlNvNYxRoLgWfTctY Kwmp90RTs8SeflznwuLdK7hayfumv3wo/bejbSMBoxxCASxD97mRj7YP/KNcH/6h L7uC5hLOIUqyvcsK5sFnRUkp4ldU+FjJpCXv/BTP+JUxl0Gc0eyExBepaDYy69rL XPxuYIF6nRULRYfYmReXgfQfaaCGALsXnCLhZ4eyIZOCxjCuMQNuDXzNRJ+tHSGr WKO3lgq161g0YsUgVYkBIgQQAQIADAUCQxYPWAUDABJ1AAAKCRCXELibyletfNSE CADA08ADDJW0wUPFv2YmDUjyFKjR6fdx8cNZRDPr3Ml9Wi3p6B5H5PD6cK3dHJIK 4x5E+amGsbJ9wzWDQa9RueR2+GYAsGC+qfqsNBIGa8nUwNR2SjTFP/7fUAENOUiV q+ldOxNCR2dZ4u9OBqzUl5RQWAOO6n/Ld4AbbXA1x5cBEMgybZhKk/zEgn9X6T2K yp7u5RJWwaZQp6EK/u7SwaSxez133BiK8iUUDc5rV1KiStq9hanlWp2PUidneCc/ x6NjAFlKpHL10nlvqJ6tQovyyky/aHLdc2+tbZPvyB7pXB9GOvtIMNmG9qBOvLKn fKaXqzFt9Zmp7v4O19snrlr0iQEiBBABAgAMBQJDF2FqBQMAEnUAAAoJEJcQuJvK V618zhQIAJj4w3FwBHrZjXESOYNahOyrA8z4DgTp2/ylAkCr3mOWFWTPA8gf5K8y zH7vsGwHUSX/SpiwItwsN7qvq+gRZ+qwP9FjVyBDG/CfyvKLUlawGLnUyEqWy8DS iDX+b3M7h0C8jClrP07oW4dUFXkuGugmrS5CUu1Q1CEfczcmLfS1KkBXBhSAr5GH UY6yrVBOYxXI3HOW1CaRYU5Yi7DVk4XFcnIlYz470u5vkYIkuL39wJiJA+QOhF5h Uj04dxkecoCjUpoNnagZ6a5cOR8j6LemtzeLpYUUozzUofFciWiiDNRXANZkQPFA B9LaAjZQ5mV6Vsjw8lh3hN/BpHTx96CJASIEEAECAAwFAkMYsiMFAwASdQAACgkQ lxC4m8pXrXxwMwf/QEVXGw+XrKxB15pReBN1WYiGqh+Vd76xTKHDTy9Ruhgm4KtX ptc4pg9JYIHHX6/vwQtQ39b/BP0oxoVHWjF1HUoQ3JYB1pbgSpHkvWYQrnOegX/P R0lFywe8tx3lUkkGnB7AucLW3oxB6n3xlMcrMhaIvpBVUYOFeyAY2inyq5v0yEbS l1uSonlqv7QVHApBttnZYu8lo0zbTGdbmIpYorC64pzopHgvAm+nK7hMNIOZe7XF T8C/jggsKRWZunm0kgRku6rS1DMPWTjfC1U5CchJ78sknVTPkD/cp0aCMWyIA881 zwCGyy+tDNPcMH0na4Dk/FEEgyendOhlTkHrvIkBIgQQAQIADAUCQxlbVwUDABJ1 AAAKCRCXELibyletfCBdCACBkn+Q7WMJCNVfzNlQg6Qk5/cp9i7VcMNTXaMMlG8R /an4FY65lp0RrNr4DmVD9IFqaKQa/Brnk02yuzrXqaR3/dlmRqAMzBHUsQmsHp8M L7dRr/m/BliWXgaprh/Y5zxiAHDyH5vRtjOQTIEKr6iuL68P83WQSkacnlnkwKaP qHoWnaf19r5tF5Tv1VwzU+OtoGw7whe7lcfreqEiUm+UNJq/gMnNJ04AruLT03/J R+BK5vB+NL8LQBCxIrbQ8Ivdf/KNIQtPTZVDTlPjVdXPIBRNU7ohWo8T/Y633C35 OnVMuacz/EtnO2aD8gOKAzTnvQoLnhiiraERloqKmYmEiQEiBBABAgAMBQJDG1T6 BQMAEnUAAAoJEJcQuJvKV618JdsIALUr8Czn7vrBACPx/lYi73goUtphi13DIX6G Gy9f6jziImTImM5/Jx9FVS7U8DKatDBcvqqFgb74lho27O7gon0K5AmDirwBE78p kAJERza4pP1N0CO4WY6YKikf4ZpH4dJCOAWmTQ9D0E4GJ8yHrjYQBbACDvtEdMNM gqgXErO96L7hOmI9ZnWLe0yREAEgmv7A+3Yj83ulGKrZUFrc0ztB8v3AqteLNAXL 3UUpATOjZJaULD1MAZxPRj/MK0fFAZcGM7GBBl64DTdAEVhRxMrtAqHeWamveJKV OpFtMaJpuI8Baa1qJNZ1xm5LJ6Qen0YPwUz8SZn3uCh44Yz2ndyJASIEEAECAAwF AkMzJocFAwASdQAACgkQlxC4m8pXrXyFvQgAyyxzWoCsV0HKjJTa/pN4pAYnU7Yc jG37jl7it7uFCqvC4vI4e3J/ktLOv4FG/+dBClNrXeBOwIkVBXvQ04PIAqAyX7KI XIyCvLuqWMFPozZw8Txltl6mJOeJLjpn50460XWri20iIzDZXT22dNJCeBJPAt29 vAunaB2yHAJQavFEwCkbfe8uPFsWw39MWlwKCNuyBNbsHH80D2UvhtdXFjmpiMCH mzmE9iipTy8iLWkZ2g7s9a3A2LbiwarQjE6Du9x1IDMeYgnaVFWYO8cU7OMJ9Cau 5M7OexsbgyHgtyU+A6eAE+BX5v7Z2Kw8fxSIUpgeK1nzt1cWCri7jb3mpIkBIgQQ AQIADAUCQ/jUFwUDABJ1AAAKCRCXELibyletfHh5CACa5QV+eWhzsFjNioCYm4we DQlRoEaB+ucMVvGoN886ndtCkqc3RGAg1Rk+r7DOW/OqHBd9T4g2WxK8BYZQy1uB Pzv3Eu417B9OWPAW6WDl3ERo6efyjWssHzmrLtDM8cfPLtTrFol4j0qc1YEvJUym C9y898EctHj6hIVmsvuo8M5Z0y5Fjr7lgesT2k6OqTHDxya71ofpD1dxuKKj8Qyg v7pfyhAjYj6dXOET4147AtGzQCtltPwMSCP8IDYZAwhzI6SAIDU1NUAndZ3OJoKk 1nOQnSXgdEqgQHvUkRvjqH36xZTwTb5b5XNcTdcAeHTT/V292vFfTNGsZbTHGZ22 iQEiBBABAgAMBQJECqIkBQMAEnUAAAoJEJcQuJvKV618k+gH/261mr8srvidaSP4 0L+uunwV2poeJx8z1Sjw182Du01M5iegb4es0uIco4fAB8o42mmyzvW1zyysF+v5 dFNksPlpBYlZVYo8B7TgsnognbdngkSxfIQnaswIhHl4E84qTFCCg3vQ+jX7RQJU u3rkUDS4z0Q7kpEn4c+6QaGGRVoeCnQ0tYLq4IRfGMW/I5HflJM4IjYXIGtk6fKB xEAclsmcFF3P0LokL+jmZRFR0D2rN4E7XEdReooO8yWRX4q2W3fljHMWsblt+a35 NBrjw8QWFFXi2yiCABpaW3glADQPDJvsUZEXnYh+3jTiNODoYsz/QooaXJ/GD/V0 5vGsfROJASIEEAECAAwFAkRRx0kFAwASdQAACgkQlxC4m8pXrXwpiwgAmP24FCOq Yt7D6GCfy+gKtn5Iyi0vnmcxK2vSd1Cjv8OjjEomz3p9+y0yvA1siBIf481eiseQ bs2XD6fDnlfjMGEFdYzlzUUuwuZ68FvB+8xetFyNA5+l69n3gmBSbHl46Lno0pEg p2/xgUvWt34wad+xJ57JMztacd+X/X6SVrDrcAnX+0oDggRNE3pJUwDa4MG0tZK6 GGxXVMRp+HpR6LzNoJmYapUkwKJ/7pyjEmmz1+sEDWwwk7Yxf6PrsM6Sj0G0xi0j bi642EywyHzrNyw7XPWw2Wt0Ol7VBSldCq8nzkBSjPqqKOm8V0sHM0jckI8vX3IU ZWphzdxlR71DnIkBIgQQAQIADAUCRGORVgUDABJ1AAAKCRCXELibyletfBQcCACA pf1nlMLAG3jAD41FxF/zOTubpe3N5S9GdG1GNLAWLbW3/CVVwET8YHAD1JT43S4s UwMgYHgsIZB7ALywL6mZmC9j1vXaK7R3XjQ4us0IynfQ4DQcpOoLkPRgX8Nr2EpF 86ibhwZeIlIJdx4I1G6k72Vk40hMWEc19MNd1qpZ/am7ig0Uyq79pLZPgYVd06Zg C22OE1iFcmHCTSzCQM2D1zx0Fn22OYdXyK3Mq2mZ5lijpmwtz6TB/NhXMAoix2Kp 1ytXlVj9Uj+tnRs6AVoyxh+g5lJPUajNX9AempqFWi8U2Zj+asB7yWT0aB9SJ4MM PKSYFF+1HsJk99tL8UMDtCVSYWluZXIgVy4gR2VybGluZyA8ZHNiQG1wZy1ndi5t cGcuZGU+iEYEEBECAAYFAjgxFNQACgkQyXGuX27yvfUKKwCdGg64zVMQfn0pPIO8 nCjOfmxeqKAAnj8mcJV2oaG7I7I6suE7XYtDhAgNiEYEEBECAAYFAjiQM/kACgkQ yXGuX27yvfVtlQCg/BODS05P7Rn3aj/7B1sByfDhl8IAoL31zcEuvvC2M6gmNQSD DW/7XVo/iEYEEBECAAYFAkQGYxQACgkQIIdHgCGsbMT9TQCgkbWFnv5zSlVIyef/ uI22QFc4l34AoIXTn5ox/kC8wNrrslzhXvuLJsiDiEYEEBECAAYFAkQQc60ACgkQ 7UaByb89+bRMLwCgwZHT+D6Jx7nNrEJfGmB6Fwuu3EoAoOkYZ7Xbkb7FU1O4Izho icUxwgGTiEYEEBECAAYFAkR1pGAACgkQXeJJllsDWKILdwCfd3eWVuVgRse0M9zl mRHXFYPYOL8An1R0uGJU3pkido3DMuV9uONprRiTiEwEEBECAAwFAjgxG+oFAwfB cwAACgkQvniWj0k91BtqWwCgiBRRJ0BUUWkH25Q6PnJImNiwem8An0YnQzcD1vU9 ILUqpxLSa8etn9fCiEwEEBECAAwFAjiZgxMFAwdZTIAACgkQvniWj0k91BvivwCf ewZrqoJ/ltDero8kqTWsY0+xaWAAoNUE57b0otA21jAcG79KwWHh9c04iEwEEBEC AAwFAj/YZ4oFAwW/SgAACgkQTnlUuWJljbxk2QCfbG2s1L4+H+FIdja60hBe5qtP IG0AoMSdsDqDCO/zH8GyejRcT1kxAMrgiEwEEBECAAwFAkTp6UkFgwCtif8ACgkQ B6g1EUxThvcSpwCfdeGTd/eSoNuZ5SWipGIFNRsOtb8Anihs02p8LsAND1pYB+8V oolBmrAtiFAEEBECABAFAjiQOkIFAwdihwADBQF4AAoJEL54lo9JPdQbP+EAniYz 7y+FJhKBFNty0A9TVhtNta4+AJ4hblxH3xQtp2E9CLmDt2eeE9VTHIhRBBARAgAR BAsDAgEFAj96oKkFCQztJt8ACgkQ3HeLB051S+3duwCfUvQzuJAwgivfjlGoyqkU 4tKPyqAAoLJJ5yE5fHFYML6wmQhGXE5eXyjhiFEEEBECABEECwMCAQUCQA53JgUJ DWafWgAKCRDcd4sHTnVL7UCpAJ9p5HksGX4jYK0r0NxwAyfL2JmwHQCdGEb3fLSf cmjQmuP8pdHRQQxXgTOIUQQQEQIAEQQLAwIBBQJADncmBQkNZp9aAAoJENx3iwdO dUvtQKkAn3pip+o3oIp0SOZRoBsD7UQ1krMQAJ0elxkmCk6vvvOXkYuDowvU1o3d hYhRBBARAgARBAsDAgEFAkAOdyYFCQ1mn1oACgkQ3HeLB051S+1AqQCgnxqOo/r0 mhuVY7CD3ZNu16PPqmkAoMwit8O0P6QojiE2r1cpqD2brKGOiFEEEBECABEFAjgx FEgFCQfBcwAECwMCAQAKCRDcd4sHTnVL7chIAKDFftZ46JlvzWDVfhZxOeiqSwah ewCeK/MZVZyUu7Ni1LKR5DfLEWyOwT2IWQQQEQIAEQQLAwIBBQI/ep8YBQkM7SVL ABIHZUdQRwABAQkQ3HeLB051S+3YzACgtsMTxhq/Te1jKrpn5YfOd4aAeAAAoKSn MHsTf9XaWByAWSIJSLTCIUByiFkEEBECABEECwMCAQUCP3qgqQUJDO0m3wASB2VH UEcAAQEJENx3iwdOdUvt3bsAn1L0M7iQMIIr345RqMqpFOLSj8qgAKCySechOXxx WDC+sJkIRlxOXl8o4YhZBBARAgARBAsDAgEFAkAOdyYFCQ1mn1oAEgdlR1BHAAEB CRDcd4sHTnVL7UCpAJ9p5HksGX4jYK0r0NxwAyfL2JmwHQCdGEb3fLSfcmjQmuP8 pdHRQQxXgTOIWQQQEQIAEQQLAwIBBQJADncmBQkNZp9aABIHZUdQRwABAQkQ3HeL B051S+1AqQCgnxqOo/r0mhuVY7CD3ZNu16PPqmkAoMwit8O0P6QojiE2r1cpqD2b rKGOiQB1AwUQODEU4u1GQL4Iw45xAQHkewL/a72IFsIka6X3QummnXxlyrciCr1w GlfpKFkp7ryLzrqCTum1stuX7wQoFkwl9UurEDbY7/iLeyF8pFbFhmbrbhvN+oSi wbd8kwjH4blrZGMMY1VTH0+DiZj6Z1wj3BGZiHkEEBECADEECwMCARkYbGRhcDov L2tleXNlcnZlci5wZ3AuY29tBR4BAAAABQJFmPB3BQkPSQ+tABIHZUdQRwABAQkQ 3HeLB051S+1jGACg/n7fVpw1y6i9OEHVsHp40Mub0BcAoLcFb0zt7XdUXjPUkEjI HJ6Xd9QCiHkEEBECADEFAkKcTTgFCQztJt8ECwMCARkYbGRhcDovL2tleXNlcnZl ci5wZ3AuY29tBR4BAAAAABIJENx3iwdOdUvtB2VHUEcAAQEK7gCgzSDi6HYIMEHN fWM55ylAfB36Fo0An1WdEfQMw0yCuhGZHcRZBiobR/YsiHkEEBECADEFAkL4c/gF CQ1mXwAECwMCARkYbGRhcDovL2tleXNlcnZlci5wZ3AuY29tBR4BAAAAABIJENx3 iwdOdUvtB2VHUEcAAQHw8gCg4vuppHJpDx2SFOBrPunE5cG1d6cAoLEakhfvirgG Vr2oxb69YHCScwa7iHwEEAEBAAYFAjiQM+cACgkQ7UZAvgjDjnFfcwL/a0a30fR2 GFWVz1LvsDe1SnIRuKJ3HbtkVoFveU6fUMN20sR6DEXkrPHk1hOTI167PbZ9vEeW Y25jrBfGTkyIqKeq9Y8z0stFa/VsDnm85XqE0C3U1DFsjXOLDb3OejUMiQCVAwUQ PMZ2NOzwpTmnrhOzAQGm/QP/aMfYdpvBdoG+ydgucxeG3tP8cnHB4z4DyBbXr92O 3Oj9IuY2wULKVclEiadSoENf8I+KCOrLpYrvd6JpOpUZT5B70HAPONXpqpP7whn+ m7z5y/kR2Zw9tuvRXT+4CzQg3Z92FSFsfCN9pGLftutIMHIPpGmZMcD5wQ8GWJyH xiCJARwEEAECAAYFAj7OpBgACgkQjj4ZeCrcMLW0ugf9Hble1+ChTYXNdyO/BkHs 5mTgXn5dvbvqwuIFo69I8p5K0+Z+b2PQuZEuSGCGTZPybqenc4GwLFF8/NHLsWhs ApkA+HUsVXfeQ+IWDbHsr+lvarRhPSQKgA496VrkjG51A8ph7a0KiMKFQUxLESN+ ZM0cICF+mc6ltesJAY48W9EvjAPdgmDBoZxiBAXUttDi10rS0g8UgMDYLfMudumw 4vw8Z/fQfYVNNBo5J8TtefRUJS2SK3zGunyZX6RdH76+okMy3a38ufGenKAMDcRr Ab+XT1XlWQOPLGn7a2aQtEIcMLJ5KUInQEORF55gBCtNgrsdwdbcGSiSsbd/w8MI Q4kBHAQQAQIABgUCRAb7zAAKCRD5+cMnCY0Ssy73B/9SBQm4VMXgSkm1XLp08wXI A3LUk97kMnTjVE5hGUy1oRLTK/x3laCdQapK1U0jTc5CWgB5pPnO+26eEij5kBP8 kIuxkYfPEWPQAHXrvrkD/qdsVQQ+HNScdd6TN5gaZwnmOjcUBSoqqFgwoHEPMxPJ ZktWz4HIMOLQeX9O/+F7Y/1NOEreL+ADWsRr90Drof5ABV+Toxx6hm4bhgCWxPE5 4AiSZGRkgN9HA8kpNERNQHWSb5+U/La5jnzfGiZkSlRTKk7OFFj8RDlWnvjGLYoa HDVviOrb/Lohfhn8B16CVlQ5aAZswxYxWhdhgKOYtcxwkQLRvsyrmpb8Xr4iPJns iQEiBBABAgAMBQJCnE6bBQMAEnUAAAoJEJcQuJvKV618f6oH/19rAycd7aOxqmBR CNdOgT4hE0BWqd2XlQU+jgxNOWHpf7olMpYl33UNUIFnrHS4/AaMXbIwz2KaTtu/ VGOoG0plOU0CcG+Idb3BAgoMgBHiozh2E5PaLvW1ApKyiv1f5i9Jq7ZSFTtVxDrG 1u+V+W/rNTre4zkwgBFzxF8fTPrP/b46G5FFlcIxT7EnH6H3op8L9Fz+GgHBRg2v wKqhMTKvdeSs5HO8FZIztQFCm7ymeOeVYG+h+LvnqpuXUMvS1YIOIEuJbjnK0la/ tYh/9LlQj1v3Ec5NXnJVxdaX0GDwtLk97iDG5udBkYBvadxFDzQYzgOhjnqI+HKL O9xnWFmJASIEEAECAAwFAkKt2BoFAwASdQAACgkQlxC4m8pXrXy7SAgAne4DlAM2 6l+Fo19sOyEmuYic6tKH9VLHDcbCjO4GmOiBQzaWyVVEOcifx43FEiGijtunrei7 mwHj05/Suc+Luy/VYVQBGda13kUMN86GjiSXxCV22TJCElHZ2ECgKfrcucVnn8wE emK/xd1G6lWYiltCYNyGZUMejozda2oAMla85Xlx1YGMzTbw7dTgLzcXweanG/dU Hdrb/5eDyRR0xNj8uqvOcbFBP2PK+4R7RoaBZXLHs1ojWeMbuKOa2elwODhazjFo uQO2XF7BK+GUGVzTilllQppFYrC6935nImTeef8b8duMT22BkoXwb+112g+HkA5r EqeJwDgfp1MUUIkBIgQQAQIADAUCQr78AwUDABJ1AAAKCRCXELibyletfGIZB/oC 0oaVZCpE8UTPSjz2kywd2gY5Ux2M9PVAOBkQoBm+5tGn+I2rhv+GGknYZf/1AwnX swEFSJgYIDODgpFzKsVPgb2McbWiDiQWtFVTFq2n2yibOXvGRAcMOp2PGD/Ix67E TKAnrsN0102HFImqUHyM5CzN+J7770XdysHVGfZjRO/ExtcNh9HWqm2/RbsT+CIB 5peeaoaBlFsyoE8ebLaJ2YQ9KN0k48/pN4X9wxU3qWloytSYrIAKkSZlJ0TJ9Ois U0ELNpSexSeEYWRKeLCvlWKnlxml3VmEk8LX6cOFsOEXXsvVBJkj9AxnMmCdw7nd ktxRoSuv68cw1YN+vpy7iQEiBBABAgAMBQJC0XugBQMAEnUAAAoJEJcQuJvKV618 LhwH/i7JWvrP6lqgHdGF0iSUFiY+/t5MG9n7v2IPv9u+nTEGyOpbkDrkbwf8RamL HNk0qV6AA7OudRg3+bJYS0iZbCnoCjR4bYfb689T8g6jX8z3l2lcOPx9Yc2wDM4O p4riRhX7PYJ6UyTEOCEI1UgMIe3oGb5tNP54Uubwl3FxqWiZ0UTRxVCc3LHDuQ5i OvJWhJruUXhuY/ygjhwZf6PMFuWHzKwcxyevxqOjqyyODyaetMysWkmVZ99YfmIE z+SD/X4J+gkkhVW/uk25qks6HledA8cmgiKu6NryjW8+S3DwdoXrfHFrzxYXygFD babGfLYhFXpef+J9UJ2AStz3N76JASIEEAECAAwFAkLjR0sFAwASdQAACgkQlxC4 m8pXrXz+CQf+OzcGRY1gCeRN3nxnQhRHFXYN8H/8EnQMlB7AmjSkyVQf9z0cMwuL aQypiC/nUtlew+g0uSe7Doyt/6VHivhxb0j6HxxPJTsGhW89GgNezZheIKSJiP1s qxliD3iu6D/Yd2OEhr2vF+Y3F52B/Ubyq7pgwaLKGNvy9pc0j0fskagLdsikhKOk IqivOfWGJLBXmcVQlanSlBOtqAOlQsdp29uNGKdwoVEKQneztUHdFRddhnYKBOsb DLPA4xSWDmM7HIRIu/8xyk8ycj009MsjPm5/SZ969+DblLt68pL6nTo6gFkS9H6m 4NR5cz0k2RQzJa/Gs8PCO/FsOq5g/6rzookBIgQQAQIADAUCQuPvEAUDABJ1AAAK CRCXELibyletfPCCCAC1/vKn1DX3gyaTV7QRH8WQvu+r0c9HgGndsgYicIVYy7B1 PSOzOJvbC7qtk1pvpTtKYgDshddY36WfTjtPQ4voMOqTWZnAmbytcOGQvNli1EF3 3fer9SDiA9ICQRBypVGd7Um/JnQ5puKm3diTioHGbm3SLv0P+kubb/4ndbGiACwF uNcJOR6b2MSIqEWMLg+0vAMTNlqDE7lgc5oxAUgbBbv5vhxt7lGGssvUL7B2WNFB ynUAEglnBk3pF1Mpbf+vCzn91SlJiyrXD8jIRRDN2wdzstaA5ibURRO2hCkbT1eL 9/nQdHDrHa/z0Xm7jBRCOhMc+AF8Gmgk8TxEO3WjiQEiBBABAgAMBQJC6d9ABQMA EnUAAAoJEJcQuJvKV6184WMH/06uj+4YmFiV1dqHfF0W3TTGL7o9KOSF39hHyd53 Gsrsl4BIvaSyKXVxPrz8J8yBGZM5TwYndhFO5MeV+8IC8F41Z6CnA3NvyhUCrnbF WTDuU3QSU8WiJ7KZEyf/LdzK2lxy/Z920KRMjSRrF2JmlK9hGcnDrOhNzEroPdz5 FrRQsgU+jaw2fago+jj4+aJCbbisSy7hQ50v0EJu8/UuZeVBU80TQlKvxECk9q2H vNQEPWSRcZRriEghWX5nhZajixeyYsUb6MPnFU3V1cfXTFj5MkYvIB6+sWhA/NxM gOwD9eFwQVs52mW+GArGcwy1qg2Dq3MlAOYVInmxmzJ28eOJASIEEAECAAwFAkLs gmAFAwASdQAACgkQlxC4m8pXrXzHFQf/ex9CaZhATBSiKIjR5/E/pyl2dL2JwwDK i/WCUG++SbOgI5qjLjy+8ivlyMETYzhYCvH6MyTSvdT0m2hTjoFbYmqotveJa3TK Bq2eYGLhIa2sYpq3z6FXfx0mbg1933ZzX18wA1tw8qQyZ2kKA/WT22e147S0konD NVKruMdxsqXD+20ZVJHMonBlOkXKaagOiTMWVHKb/fnQ4oS0ntZsx8qpE+waLhk5 YjZTprc8Cxb9EwDX0YujyEwgfCynsrloPWnrfukMv2PMuuPrSqeLfeBwaMKHpv8L cRefq5OTd08naWEx1IgtWY9Fnq5i39EMVlDFzlbT6e1Sf2PgeGv9U4kBIgQQAQIA DAUCQu0qdAUDABJ1AAAKCRCXELibyletfBnmCACmhYxcqgIl/E+kvbRpzzm/78hk qgyGQavKJZ064onEWBJhfhQw4y2b2riKm5OghjO9WtzIMok0PMVTW+3k6afC3m9J 4/915LsVcD5Aw2RwxnRASxU2kGoNt6g4nuiQDcLuNUVAHmeCsx+WTYkvQz1WSsYI lzco+Pf5qWlL5gJCcR1MVtB1QI2SQXGhtwWClW74MNd7oSP0YIax9KiUZENythFl HJUGIh707GEqBBrMjt0eWgu1iT7Qq+iE+xYjDvdeqaesmqzZuCUR5eySjOHYb8iW 3XUWQK/sWONAjAIj7atVEk88N5GrlIL6STFM1YjmCXQ57RunKCHkBisvf5x6iQEi BBABAgAMBQJC+HRNBQMAEnUAAAoJEJcQuJvKV618xaAIAJRbMVTx58M8DEP/lEbS by3r0+DBvabRNjq1UwURFF3blYEN6yG2pxOcSP4MjA7jSiQ2YPcaaM/Wc+kG810o rJUoMhHKTGm/TpWpY9cn2vnKEKWKaQ9J6RtB0gfWpJZkclue6WsyR+bGhu4Z/3f1 AUZNyaP3xFizROvZV/q17GZlMiCrkN9G+fUiFS7s0tr40ozPtIq8Ps93VuvLU7ZX dP4/w+mJm5pO7D3LdnVC5F+nB/8vk8Su+a7WpEvJwf+zAAWICcQm/zRtj4g22/l1 ZhbON6HLqxIw8HRHo5X2x01gvcnn9ivC7tIdY64/jYohx4fYQgt28IU9w/eKgE2w Cu+JASIEEAECAAwFAkMK2GwFAwASdQAACgkQlxC4m8pXrXzKNAf/Yc5fXaYG/4m4 pBuejfKyPsWBNigamV6xKk1HQM4L5GRvwu9jBeTmj1ZkRwPiqoH34Mk9wNvZBbhm aoDR3ccs2bYDvr5LTWYUsnNdEIvt8xBoNpIH34iltJ/Q5piG3RFmLaHIbaRKjlld i6MQMn1RXxYjFDq6RaOOXfai2OiML4IPnjjzCD+E9Bf4sWW+pWF+CzBKrgGsziT6 nzPd8uXK9WkyipmB2ZpaTTm1PuuCMwoo+ukJHi4JTD9XcK4z0bMkpH/9Yd8BrO4A 9bWXJa0XkEKoAoMuhlkfaswG9suus+4DAEuW2Fehe4r86jPMYTXAyj30NYjFhoZj 8UEaFfw8qYkBIgQQAQIADAUCQwwtzwUDABJ1AAAKCRCXELibyletfC5PCAC6F1iG 0+4jTQqrHW+kEOEcwAnzwYjW6FNiw0bXTIZRBYqv1rERgaGgr4R0TKlXSslvYRqz sA4ZuyUAkDj2ddzyw/0WOoUgdfPK6oowcciW2aQblY+MRZvSLrDnu24H63Kl/pep 5b2gH+DpVyjZx4MUmY9X39Lgtoq5ME1iQHa5v/9Pl4ReDLWOHJs5QtgfL+ixgrWY X9QD1UOye9Ctz8oIoy3izyOzAG+P+mPOiPBo1l0lRe8mw3AnR3zXA3TvzBZKNBmF Ej/gutLzxqxP+i7EIdfaOAbnHy5rl59LM7/zlYJjsgi9O4ZSZnBGWqgQbzsJxHC3 5G9h7FlySd4PrUYLiQEiBBABAgAMBQJDEMi4BQMAEnUAAAoJEJcQuJvKV618ga0I ALwqJjfWr2jgSe0xkhc1hGaN9igQS4PGSUlPR4l6yp0ytGik5pByzOh1wkwdDwOf eN1h4FCcgrgWsBLvf5RaxnmNtw3RX4HDIDDk9bhxSvfG0zDlCM0OKzLa7KCCJGlw ABIV6zJm0dGGZMpZ8TdTC6humeCC27o4kJtGEMp/01OwrrTEYGvp524QKBunlVTI 3PL3Mk4W3NJTR8B9hWK2qtxW3gzJeDDDHJZJc4c7sSw9Kuy8EHSEmkk0qIr0q5Zp oY+0wOUL081fvKX+z8kjyvFcA3+SqZsMmwerW6JM7+CrITfZXHKjDKnAeKUKZUvS nvSfshhhvUrbrvJimrVxp7CJASIEEAECAAwFAkMTbH0FAwASdQAACgkQlxC4m8pX rXxiMAf8CjNdNNw5Lv7G9vw01PcStPmsFFK9ZJzM6Jk330K8CJ+ImPYeBwmEIHJU DV2Mcyr2QK+shYT2RQ1OeHaVFctrMHoevsJAVjyqHpztqmDGwp8NwNkCsDb8OuvU FFNFh4IsYhoPxNMzmjfkrihi0VWhC62ebaZyJwmXUzVEVO7wZtZhZiLTT5amEq/S 1HP2EiMay0AfcgH9UsvWqM6/ETyq2E4cVPKaQEJOIG2EnGdCx451Ljj8jtv+BbFw ufFn85J6Ro5aVyJwl+PyN3x2BnenBC1MB2wh9Tp6IkMGPI5bAb6b0Tk3rVBPSAPc ut71zFVG8H/Hq+rtxi+lNBLKLoKnrIkBIgQQAQIADAUCQxQVewUDABJ1AAAKCRCX ELibyletfCkTCACG2qHaYkUFlweHGiE4qewk6i68inr8luKq1zQV9gsGsUKm+WcQ 0tBBf7uv/XBozt5CawovfIT36eCGqLrIscbucjBWOeaHOHth9ZXKCX/z2AbuK9nO AE1NCNvEtfZNEckv7UskU5wK/A4jc6/FEUR/zE/ZFGLJIpDPGc6w1v6oJt/E/uBe mjfRowxHn6ndDlHLxz85vBuKhyQEVLKbMgoCDRPXwvhY5MFcfb6noLiVXDMmykMA XJErs9edFaijEuNy1qRVIbTeEkCbbWO+IWfPd/cunnrQ1vK5e35jBG8f8wdgYy5s UGLSh1YTtFQGd/FT7N3lua5qnYCJbJvJHAdLiQEiBBABAgAMBQJDFg9YBQMAEnUA AAoJEJcQuJvKV618z3oIAL8CJt8669+ebi2bhE12Znirgfo56n3DN7JATOQzkc0O jO/qanK5Ayq4mNYhsjou2KLKDXQFnhq2RUnPTR9eGlXrYgvumf3n+bywifqt1jni J2cZaYJDVsIbdtmsF+8WtHLP9mvGKE67SfCFJLcNHNZAFFKiwF0S1iR5rsFJFG4L iYtemFajssh03/8QrLS2Xp/4Rv7VFIA8XVzYjY/OwSeFwvcc7ZDtoL8GDg75ETnm Iw7R6+V8YPCmIc3kxVWsaYZVbvV+sr1vQlM/BAbH1tmzsty8ADHsvICJv3zWje9C iRAvwEYHsrqVFzje6ddszTM8MiS4WnwbHvx1qtm5RFSJASIEEAECAAwFAkMXYWoF AwASdQAACgkQlxC4m8pXrXx2HQgAwgE2o6pGtTySwjz0bUPE5c/xfGfPVvKP8gdT fHI5acawQy418JVZ46fpuDipk5r5W8D/b0Li8r9KA0ApT3TW3cyV3XUJuvRJB/7E KHLGceSp39ySHwSUh++giOqc22wB7w4nj9p/D/YuW1Gjq2A2XlNpBfYv3Nd1fhV6 cyIgDDn3Pd5l+HZYA4zAC74HSwDFbMaAeQvxhbW8tV6kaAvtYrbHlKHmYypGLp01 Jdw7bnKi7u4nv00Ar1SsWBY4Ud5WpszRVlkd/IwT0eL1U92bu+foXbpLahrnFOKN XUOk3OurvFREf4zJsf5leVMMDA7HWu2MnAK7i780NgJRlH7XfIkBIgQQAQIADAUC QxiyIwUDABJ1AAAKCRCXELibyletfALPB/0d+dUAruaBxkMzFuCFwL1y9gk9VTNu dhZBJMjF4KLUlSpeCstLZ1S24Mc/N/GtzVRF6h8OJ5gMaIMKdqaLRnEuHmltD3Kh WVs6+cfQPl9D+XpsvbBuvw75CykCG+tGqXH6PA7+vGBjNOP98oO18df4u8vPc3fG SI3X7iLEJFFGf4L4U0hw3Yikx5xD8r4682WSi8/EDo9iKkPRLRphfob33mrTi+fC vwoDbeKn2DU1MZK8Iu1JSKPFD6ZDY4HebrtqD8SyfZ4XHjsfiKz7J4GkRYj3suTW TyPvPaZlU0Dp1fAWn2URG9f4sJC7JmBoezTmN9MIA8eE52sDlyNTbOegiQEiBBAB AgAMBQJDGVtXBQMAEnUAAAoJEJcQuJvKV618zvMIAJcKhpQW4vKj4Z5MKn/mbXYz oKJ0OArB4QWbm5sj1Rec6edUT08bxCSOykP0qVdl1RYoUGZDFxCRXp6fbSKygJSe SAL4Kwa+uf8tkt1W8wyQaaMs++fwpuReDf4AM9Qj9NJAc0ajCtjdnzjC7Db4FYiA eYyCJPxa+wIiJ7Jx7mSqxyyvXK4wVDLnIanZj3W/0PmDKAjjLqPWwEGP2O5bBcSz upOReYzg7RY5nxU94FvXxhUv4ETKoQzpMl5kTKQoDic0CNTD+SmYAzOHzfP+v3iN o3VPN5xSgy29NlqQWluiE9BH0adK1ANnUVLJb87+M+MKQ+PRWPmFj1O0aonpTWyJ ASIEEAECAAwFAkMbVPoFAwASdQAACgkQlxC4m8pXrXx5kggAxhM40sB9ejbzeiOc C6/8hfssTOYRVrrCLpFNutTtU1n7zibQ8RsqpEGLWx9FdRqAb2JHpfoDEYWeQim1 M+sEBvDX2wVQuEkxFnUiALCqrMdQY9nFkQquQPu4AKcCQoCmG2ttK5dVl4vJranw CjNOcGDjzQSDIwYulSv74unuMUg04uFA7WQnT7QbyCKBE7LcYYvq0p3GCCwaI+Al Ky0Zo5gQbNTNk1RgVimB80CnOztk1gW+0Wfl8JU8kbTN5wn52/QCQcrmTOrT+mDq qEss+vFIdeFqth8cboYy+8MFX73HExzTo8BSNYUHFep1Ef7Wh/mFcjRbPKXMxKXQ bBwrdIkBIgQQAQIADAUCQzMmhwUDABJ1AAAKCRCXELibyletfKH6B/4pjUEGc0Em t7J3+xvyocia9vJRnG7tDegAa4FAppU0n8ccwQXA7/05320CKQP9/jb11JPgUqEC rghMR2PqB1qV96TbLaWozNrUUQ9sO9qIYZQeU6gOY7zWkZyAshkLKCPWOLr4EoRn CqPQIH2YumwZ0ZOrd0b55xGGtkmyMmJHO0R5wr0icp+TKc+WammIrHybp3rIsUhJ MwwFSUFyB4/KkQyMQ61v3QPy36yU8/mj3QE8q58R4e62dUojNO2BVAdM7KpjH8h9 rF2DS8L4FhaWjcWhZdIZe5qmwqTuA/qD245UvYLPv4vYnfHe7lt0bBTB5rOUjZAX PiZv2xFk5rSctCVSYWluZXIgVy4gR2VybGluZyA8Z2VybGluZ0Bndi5tcGcuZGU+ iEYEEBECAAYFAkQGYwYACgkQIIdHgCGsbMSDegCfdNaMUwcuZZHRMSUctsTAnnqs gBwAoKiTaVqFy81VOoh/CNXKX4yc2jpmiEYEEBECAAYFAkQQc6MACgkQ7UaByb89 +bS4qQCgxRfwKXupOdSg5Bkn8LchwE22AzgAoMMGbA+ve3lQjBnRITjK0oHi+5GX iEYEEBECAAYFAkR1pGAACgkQXeJJllsDWKJH2gCeOOQWG2hA49YG8cOaxA1RAct6 pLcAoL3QWZzuLmGIn45klbWygYV93r6kiEwEEBECAAwFAkTp6UkFgwCtif8ACgkQ B6g1EUxThvdrMwCgpBs0RADDX40ZI8LqtgOdeoDalhsAnjWikMPrIhxTr6V41TzT chT4hp0miGUEExECACUCGwMHCwkIBwMCAQMVAgMDFgIBAh4BAheABQI/ep8YBQkM 7SVLAAoJENx3iwdOdUvtbPwAmgM4EJML/FaxMJzM5Y+dbrREibYxAJ0RBmxkmJkb AOtEzn7ts0kkrMDZx4hlBBMRAgAlAhsDBwsJCAcDAgEDFQIDAxYCAQIeAQIXgAUC P3qgpwUJDO0m3wAKCRDcd4sHTnVL7RB2AJ48LTZE0pZj7iNN5OoSP/ZayCHgMgCf b+RhHFlzik2mzRysdkf164wKYXCIZQQTEQIAJQIbAwcLCQgHAwIBAxUCAwMWAgEC HgECF4AFAkAOdyIFCQ1mn1oACgkQ3HeLB051S+2ovQCg+5gz3Wwg+07m+t4eK104 QtuFVK4An2c3FRGknBgfLjdcFGEvndnM6EBfiGUEExECACUCGwMHCwkIBwMCAQMV AgMDFgIBAh4BAheABQJADncmBQkNZp9aAAoJENx3iwdOdUvtObgAn31p6krwN/Ct jPAJ3c0QB0W2LilDAJ0UQCNbOaieUGVMylqYezWH2DCZF4hoBBMRAgAoAhsDBwsJ CAcDAgEDFQIDAxYCAQIeAQIXgAUJDWafWgUCQBpuOQIZAQAKCRDcd4sHTnVL7S/w AJ96PF9ILQpj/LYnvkEufn8xRI0UegCfVxmP0plYsEuLMoEqtSqA062fE8uIaAQT EQIAKAIbAwcLCQgHAwIBAxUCAwMWAgECHgECF4AFCQ1mn1oFAkAabjwCGQEACgkQ 3HeLB051S+1TiwCcD2SpXQome/q0cWQD8qs8KRZWaesAoOdUDbjXJaZ2a/mRCth2 STGClFP0iGgEExECACgFAj+IHmYFCQztJt8HCwkIBwMCAQIZAQIXgAIbAwIeAQMW AgEDFQIDAAoJENx3iwdOdUvtI/4AoO4yua+FYQ/tZP5h5BbomkM7qlh2AJ94kk/d CJIi/JPmZ2wg5/1O7n46IohoBBMRAgAoBQI/sy0ABQkM7SbfBwsJCAcDAgECGQEC F4ACGwMCHgEDFgIBAxUCAwAKCRDcd4sHTnVL7WLTAKDyVOwwn4DYaV38btEeR4Tx Qh1c9ACdG9T1R7xIvttCWCvOblgnZMDc4vOIaAQTEQIAKAcLCQgHAwIBAhkBAheA AhsDAh4BAxYCAQMVAgMFAkAOdyYFCQ1mn1oACgkQ3HeLB051S+05QwCgsf6OeDtD 33uSpAWR9wa4j2CUKr0AmwW8Quv4giMm6j6/Dlj6l1coki8KiIUEExECAEUFAkKc TTgFCQztJt8HCwkIBwMCAQIZAQIXgBkYbGRhcDovL2tleXNlcnZlci5wZ3AuY29t AhsDAxYCAQUeAQAAAAMVAgMACgkQ3HeLB051S+1+JwCfavgvJgiHUC9H3MkpvkGA DlklXEQAoOpwLjb6wUs7SqaSQ51v7ahJM/wMiIUEExECAEUFAkL4c/gFCQ1mXwAH CwkIBwMCAQIZAQIXgBkYbGRhcDovL2tleXNlcnZlci5wZ3AuY29tAhsDAxYCAQUe AQAAAAMVAgMACgkQ3HeLB051S+2dvwCg51ZLOekBmU3eOtGO16BEBECd0MkAoN3c JUhK/7l27ChqrrtdYAtaEWkxiIUEExECAEUHCwkIBwMCAQIZAQIXgBkYbGRhcDov L2tleXNlcnZlci5wZ3AuY29tAhsDAxYCAQUeAQAAAAMVAgMFAkWY8HUFCQ9JD60A CgkQ3HeLB051S+05qwCdH25fea50MhhDIdXcT3ifSvVgSZUAn1eNY5JXIGFb+pzq GJ7puzQ8OJM8iQEcBBABAgAGBQJEBvvDAAoJEPn5wycJjRKzlUEH/1LzbgFihzTA 7RzSr1YRyyVu4Ufyppvok6eV7No6jJ96SvJVkDXYTmJ6/6O9m8l9DC/fzs//sct9 DRVv/Z7zcRpYi7bgcGpRRJ3U5VNJhfTR5LaG70OPm2gPKIz6OXeza4tX3jHuNkVJ KUdNlTR7smQr5ULHQc5zgpfQsEWiKifPyhpZu1chpqmikqpw8rgfES94dArABdMm 7kFl+E/S/WlmRCqKaiedPt4Si7QBci6iETB+M66mO5Qszb7i3EvEUJJWZRIpgm4d B2JPHXkM8D/OBsK4UkOBwKwcmaYtwjHPDjZbOjXSXnxFGoUG94ha7OnrbuIGN5xI DHgPk0nOPYCJASIEEAECAAwFAkKcTpsFAwASdQAACgkQlxC4m8pXrXxbHwgAvjVW 97eIAItaFbRZwXYLB1zyLrIjDTHk7KJtb5afU3hcMBZeYNyFCak8u/k5CEoGjR1x a0uGXwojyfT7TZRuCChvK0C0wQ+NwsZnn6bLW6717s2/NMlj/UT0/8SSS//Aa1T2 64497stcWjLRa7jGLwVS/9PKmqoqBBFwlVsjvvvild9IVvxDr3yJKtxhGSXyHRPC wigT7Am/tFI7y6CmY0PEwWoPk6n8tr1E/sB3P4+lcHbgLlotLdWkXGWVJDsE8lFb DVqFecFOKEMH5Za3+7uCxIJ4QHWVVNBoy2B1m6CG0J6ZDLawR3R44/ySXg4OisxT it6m3S0kbkps8Aw5QokBIgQQAQIADAUCQq3YGgUDABJ1AAAKCRCXELibyletfKBu B/4oUb4XOLEthHRK+IEyieveIN9HJW2qyGyBiYbfN+q5eBcGjvxjOJ+WvKwcxDLq gRoy1h5EOkqZOlqTHqDwOzrwTJ/ixCm+JBJDBrcmWnn+XtiSL0ZBDcosSJFfNteg ZnQqQWbDEZLRaRnmfLXqKcYioZKMFbCfEQmGPR6/aowI4UZ505n25rzNif40JhUD +4lf0hEf3YDec5SHDsy4ROKboyMIH97S73yYzPiwS9giLK+5CRjR4xJI4fQ0ntO8 UZG8TTB1+pWhZdYxGAlGntetVD5BGxm5JLt9BVEtqqhZcb6gChylDj1f6MsB9KFT kbVowBUg9ayuiYe2DjbqJmvYiQEiBBABAgAMBQJCvvwDBQMAEnUAAAoJEJcQuJvK V618tNIH/RGH1qtYmpU45sIVOthAZ1obEv0MteLn9Ja3yHgRizYxrhXbdNeXII+9 ib0K0purf+fUiUlVNkdU/OWq0Wt6AYodE1CWv9BXDheEUef4/hvU9OgyeWLvJaX6 2dvFrM4vO6ijwiSC77txUy3jUgGGNn5UTwfLiI5HliC9++z7R5Dk1eauKnYPZ5QV Qwk9BVoC4Uyq3eWqtlpaBKpY27JaolTuNuewfSAiqFysohUunLsXVDi6tJ980I59 HNnO//XS7BEUnk3Br4h342PbALE+n4KqUqDeHVyu+iSQBIdDwJMC4MEn+oVV0+Ls RC+u/zFG62lc0/IdZr7iqtevzgK5aR+JASIEEAECAAwFAkLRe6AFAwASdQAACgkQ lxC4m8pXrXxTBQgAxGS8vYVZiug0CEtGoYO4RwgpKeoSEqUevkHVff5XMaZpwEdV 5wA6a8iXR6DZGZLPOwRuZNyW4tscNgdiNcw0Qgu1ocYqcNznmS+5zukEAn6w4I1k YcOCRyD3g6fa5eiyh7fH/Btf4/iznFncZTQtii9zXk2xsjQ4HGPdqlnncLNb5IaB YUu/tICFuVsbsr72n9whLpoirR0luFGe6SuMXeW+o9na0YRX62kNFdRbaEu5Y5/O +Mj+c46Pv34A0H7myv2oanuwsx2X4tc3VAG4Izj69QcFgwQ4GKnS/CroGDxyr/Lt 8mRQyhWVC90+MJ9xSw/Xc9gPSAiQVsaeieKiOokBIgQQAQIADAUCQuNHSwUDABJ1 AAAKCRCXELibyletfNoJCACSjlk54mOn1sR6HNLA948RAenFNxfcYRow4GN2Q3Y6 K5JBnqZIZ1/K/4eeqCNMZw9HWk0qk3QvVbMMiKf/4eit9toSDseKhy/H33FIFvmz gpGtcEbhjgfqtVx99Wq9HXq6DRCEZdvMjptMuhg7GRCj2EBnVM4c4MYHqv0H4ykI azjNkkRQvqgmzeLdbFq7EjDvO0N8nATz/KepqbUy0pEArgjCvsxpVT5/09D4qMXw BGLOBG3DmFM9P8m1224roIsuBCuhcnjQuZF1nojjIX98llh9GCxzuxSt9miIdHnq 2SDZuHSSHvM1rrvoDnMXx4IHsZGvFZa5enMKAS+dvFIMiQEiBBABAgAMBQJC4+8Q BQMAEnUAAAoJEJcQuJvKV6181zcH+wTjRE9u/LCCAWUFY/9YioEeQ03KYkIVWQQ+ ZWki5B3shFKK5z8l2wDk21G6FjdP8LwT8WI9UwwO+k0HPEhse86iLjK0xLsVRMSi NoLMv//2I1RH/kdP+PH2VWtHFTZ+EMlMzETyXgbPxg56Zm6B2Dx5/27CSVxitFJZ IrWmORXa/InslMx0NNWP936zp0HtmX571PwK/ljjPHGqRbKnPL+Zda2lBGYtj3eN TsOOBfW4E21RKLtVyZNClhSShv/Qpwgpmtwe+825NE4Vo70woCL29SZTQL2N0hS7 I+B21F3SFcuxutTuUw2shf7fnmhAMnSE28XS69MQBJstETGZaryJASIEEAECAAwF AkLp30AFAwASdQAACgkQlxC4m8pXrXxqCQf/dNS099/OBUF3NUqzfQ0MNdBz68vZ hB+YqkN7TycnpDvvULNs38p31vINw3fUA71pqk63KXFncVGSDyPJ/k0qaviTaCvv FyQ2gkrvzjLyGmfakrrKJQag8M1ztTuC/Mht3JpD5xJY4V+IiMjBtnh9VRm3ZpG9 cryvBGyvlns/fU7iqXONjL/qYrvDzBqgxSC1qU+P6IMsq1Eim1saX/Z4MQ0vYkIh ZA35UORQSnr7Bs+y7+a8hOiC61lRcslDz2LFUB1f+e2MNFEvr/rirZflnjh5tAnh /TCb2A2r9yrBnQe/PYXJxl3hltXrmGpwWCzOO52sjlXsvoLRUTgR5pnmDYkBIgQQ AQIADAUCQuyCYAUDABJ1AAAKCRCXELibyletfIy3CACgAShDZmIx2Qk8x0RLVJ70 eUQc2/Go5sAffIRYdklyafkLJtT1jIAao5EmcxNvZyiTzGZkRC83SBVaXUxBfeIh m2xN8W8zdDQIBgBgEEt8QX4x8S/8nOA9OYn8dHXhE+HR+q5z2eF62BX7ySjCg+Da aQdFY5rvMOMjSmsIwu9U/BpfqftOhohkNOTbz5482okK5Js1y8U31u2tduAWNv33 XR3PjxkRggpMTErk8b21mcCFCPGGMMy+GkQsQpJdVZ5sRc02VKgAJZpZJTIvM6VN 6Co86SSUh181RwFtaTAbLLVTvTsrjzB18KYkya6XYg1g3rsKjer9SapBHWLrj+Sh iQEiBBABAgAMBQJC7Sp0BQMAEnUAAAoJEJcQuJvKV618VFwIAKnZQaPS17M7fI7R UA3Ao4+YJ4vmXIWXUGTV/cyJs6fia5tUQmYkxOjEXRX56DGFunQ9cMwbR+2JarxZ EjLrtAF+QyKcC39rH0FAkHRd2oK0lZcLLpY6jUhiEuwqHwF4xK1hpKQQ8tL/+0lV D6wvS3koSyabLNvaRFNQWx1OoXi54nlYh4At2U8rV79fjsFN7NZ8MgQY6P5QQUMb YGshjzMleRD+xf1XqJihYoxlGe8zQaR09hasl+twUjzz8WlFOB7pgepqWWR0fPD5 f/vX7nlcyrJHFg+o31f4owFX8eaIUquQ/degTvtha0RcJVR/q9ma0U5W2te0YK5G qcvuk6mJASIEEAECAAwFAkL4dE0FAwASdQAACgkQlxC4m8pXrXy56gf/TXcJaItB woOufz/UZH5TVCRme249r2M2g3tdh0Upik81TUB5GOwmQYfoBX9Qw6PjN6hf/jhX edqwYAW+ZHUWFcrHVIWRm1HOGgn8XLi980ZtR8I3ffx8HwWnfgcN2hhBYULNcToe M3nDw2Q1L5uaNZ+PqUj/zFSVpOWyewp3gZuPNQ3d0OL4qTHyZ/UxCgJdrxWKUFqY QrVXQHUQ1e0MlWuOMd3QKGns4aNW1otaON8p038Nmbups5OvQcC8j3JuysfA+c0E Mtm3CjOU8u0reUC9U5RcHYD8xS1iKM8g07Ec2mYnb3z9xyLmx9SQs+e3lQwKfhzt f3jKPzIsf0q/gYkBIgQQAQIADAUCQwrYbAUDABJ1AAAKCRCXELibyletfPSHB/sH aoGji/gdnL0qoxH+6NFZ36EZOb34CxK+kVlx7SNty6XJ/LuuNojGPzBQXllUiDTZ iGdPdaBqfCHQqqI1+HbhF6UY+KZQO79goraeS1SAjaJbTo+XZsWWkDmXANq+/MBN DWOSNdWuYNoMjTc1yDF2n7ePN/izHBC4Vxps0dKwpmR91avHljuC8X9ijLX0Yp/b xBP+k7P/BV3yQHdH4/DLn1UFmcw5DcVqyO4k/Tv99LMEeqYPU9Xdt+/dTp11hnB0 jgZYOUaWlNEBTyGXwtNOpIWCzoHxEwlSLLqVY1wcUeGO8eUhw0YfbAGBOd6fDSYa 2zsnXs2h2jv9OwQsHk/miQEiBBABAgAMBQJDDC3PBQMAEnUAAAoJEJcQuJvKV618 KIgIAI1aZbXD2cyHA33J4rIRk23Fg8IIV4OnHQ/cKX1nFW+PeU/vjTtVTwjikYmF Ih3Hf4/g70m9q3jvTjaaRRBI9B2PBgwg73TJvCWH2m7PgEZ0+kPiKgu38ZJrFRKn mhSzKzp4SzhEvgkL+egn1TnCwOrZzvgZfKVaUu1bjkU5D1dAB8OJeCCpQZcKyzB8 ri+OHVZl8Y2GSaR8RdWpy7g9lT5nYoVQ9RGs0oPBpScAObTCnysqKCziUX3F6Zbl a1Nrlk+/GorosgOnTq2XVyOCrvkA04Z4XSPhW8aiCC2/NNMZ7eVYFaFzR6LiN/zZ N7ek16idNUUCZi6H478pVsLoIIaJASIEEAECAAwFAkMQyLgFAwASdQAACgkQlxC4 m8pXrXzgMQf/V+KfzsAxdStZQ96ralkkhVktIYjQ816K/Nd/uE/YRCKFD3I+7UuV Cy+0H7SBnqm/nUDTG9JeLXVv9ns/9w4VQYx95XDqfvNIpSXPZ3P5borbE4EaXSEW kc+RrSEIqyEiAAS5R8iSLjEWm0i5drgzP7qC0vxMhAU2Psc5oTpTNI2iHXz0336o t40qvni1UN2N6z4n7v71AqNkcCRLMT1DJgYDvA8I9UA9qIUUGVkMok38FyOS1VKV ngOaA58XwXwT+MArWcF2WN5moYuXadJtLNePRUxYwGDDNdA2lSZfztsrM8YZFVb8 qpWYR72n7yrzZlbX52djqsK7IsKUDySSr4kBIgQQAQIADAUCQxNsfQUDABJ1AAAK CRCXELibyletfBuqCAC0pFpxD2p6t7d9hxtg1cnNFI7FhlmHDKVsVUNN7MUJvcKD Fn86eyYwaiUQpxSCwJshqR0OXosiEdYITFiyGEgzAJVLsmIE/xn9Pt6/ADBDgXDf tOindQqDJaqfGJFBZlwtg/ZG6UJpNnOin07J5LfbMNelh/elYU1K5QFq8nTqDS4F HWrkWrsWy7IOT6jRUSMDl9vl6F5nMGThkNSssdB1zG+FiV40XTUEp3L5/sOUmwo7 5aAKRQ4ylmvn4hOxnb53fc0UxOPtQQCaWqDmLAIlaXAFxPEKJZSF9opqdhEgW7Xj N1yFYh6J/H3hGPyfHM3oAnO/JuY7R0y1nFFAwyQIiQEiBBABAgAMBQJDFBV7BQMA EnUAAAoJEJcQuJvKV618IckH/1KJT4EkxLtbtiwMRN4r7EoSMxecVeVSN/Jzc1/0 rFBBXvycPblsn0/2QUERwts9SSdDREOeXYzU5ut47gQCjL/lIAvdTbasc1+sSShU VMU9p6Tz/bBAt1qQJGDFodScimirZGOKvKSJLTs+WH/D6c1PAml++2PRtF0Q0NXV bRJPvG7le4ZhOxLae5EXMPVSZrS29A8iioczPAiJZ7DUS4juq7reObkN8D2i5qh5 jU49t5rBLq5Il9gZlWQildhE5etx6JMFSYfB8VIdnRmZd5/+vgPvx/XjSJRV7iMW ApfSPdJt2pzdsyi/VmbNPXAZM1ZEakPQYcFKOz+6OekmerCJASIEEAECAAwFAkMW D1gFAwASdQAACgkQlxC4m8pXrXzVNQf+IhhSpa1LK1pPqua6wIcm9p2dW/CSZkUa d825a2SO2JW2FhETv83fnKz/G3mxQ93f1qbEglIAMV97AYwRo31B1JBDSebERjqa lwBEWN3dXDWmP7M9GLSwkozYY1a6qFdhn/DumYhg3dy6QJTNylWREAUiHl+H0qcU 0CKC3OW/wdDt5akhC+fTJWWRJjnY/H5W6pWQSPz8jGD66zcTfQsuQCO6SsmPwZS4 OBUffKdz9bs8otpytbFRQlczdm1uo2HMKyKpAlHswsLjdub9F3nu2HtIL4mXSk4b pwMwvJRn7nxWrKZmKUSJyaz1vqs4sp1kO4zTJHXaFQLrw/VYMG1WpYkBIgQQAQIA DAUCQxdhagUDABJ1AAAKCRCXELibyletfMY0B/4nsHuR3IDpz1WwmC4f0w/M+WwI mut4VaKua0pR9IokTV4wjBG8wkXI4k+Pevde7vq3VN/V1qQ44+crakyjhdIUWc04 pP0h58Ylg0GxNun/eO0mQBp5jIjCZnqTasmvK3khokFbpSnnQ0rMYa281RHBBenW MKOVzeHKJ4PS3411z2McCJ9lYPbHgPpsEzi6C8DdYXhtInbYeJeaE8BcBPqMEnL+ iwckAys7bm5d3LpJ/shRgZFXNaBiQ6vGFmSwNSP2fhN59wX5C7IsBmplIonTqP0N 3HMiIW1PlRqbk1LIa39sr22oxBv6xiSHtlIWOzv4Xwk4Qw05QN/VtN7041GaiQEi BBABAgAMBQJDGLIjBQMAEnUAAAoJEJcQuJvKV6187oQH/0nQHFNaxtDUzwV6Rmq6 cgHzVBWnLK39yLNUt/AVMbw4MhEseznUgu7YhpCMExSBD7kYtfhsslf0+3wdO/h2 a8U0tOBpybxIjbdBR0g+TxbazaabR9lOoUlDocUB5d3q7IYuIIUDhXYFqiVF6g90 JmehLCEuat4AIB43rLZ2NhtVak9JKe9/wBDSYWX9rzpE30zUGg6nr7NuswSn9Q9e FRYaG7/lP7ZOyEp6iGRhkwcMoAd62hHf+NobP2Vs/svOxxjmL+9c5AI9AM/IJyFw 6yq/PQNvHvTdEYUnDiCc9/rcXDepe3u6hsD236S/VAQ+S7vVQKgwoTtJfZPxyYJC hNSJASIEEAECAAwFAkMZW1cFAwASdQAACgkQlxC4m8pXrXzS4Qf8ChWoWbeLiq2j JkQ+GQnXZssF4djlsBZFnnxPLtFE0WiRGUg+Aml2KLp6ck22wbVlZgE6kC6dAx5K tqv1YxzlDn7Q1feQbcbSO9+jdOunIBWCz9IvH+BSkJKs82y86goivGgpIb9HJp9H i4139n7biflP4Fm+Y/CcTelO7dM/H3W8fHdTWxt8yAcFcwYuYNS9wKcar4g/OS9z sxPqojnZ3Obxb3Frsyguj3f8a61JA9zAPDIziUyjgT97VKXeCjnpKvU4DGmQgJC3 QZ7YYNFg+AAs37HRrG4tT1SdHv1gasEE63Nhf4gHNMDM/a15UJ6yT8EwtR9B46sL IJkSF+u1bYkBIgQQAQIADAUCQxtU+gUDABJ1AAAKCRCXELibyletfPLUCACyAPT4 8vkeUnNJqaeHw24p6VydIDOlxY3D2BjB95zQFW08VJcXtTbCq3hhAF+hMVGd5ozI nMlbvwCscQzStA9KDTltvEGYtUpH14yAeC5HQjHXGckomHgbTPyQXOkFlib8g1Xg 6it0Y5LKNj+rxy6qnXmK1JCcOwyB5L8ioQ91ROl8jKR/Dopxzr9tQENmq9mRYQ1+ WgZPyg80rQcocZcNj64pBKttehGo/Jtxk+FDd3eQuRR6Fd8uyIFcFPTTdI2qgsfH oSTAfn0lghfyLdMILroSqNjDkZN7BytlQZwB4k/z5XrnYXEswPvWUEXsUgNCEJ+F kVGgcHBqm9GY+9UOiQEiBBABAgAMBQJDMyaHBQMAEnUAAAoJEJcQuJvKV618p70I AKyB79UsBEfzDYu9lAt4d6KKdkJPOytUIgsWwlac2qcXRzhlOJoNjQ0sPSHT2v/p eBUl9y8h20MD4iUmbZUsLsDGiKpKIc60MHERhzVIpyE14Epty45FtCGm+dvxXVKZ 2Y/733a5I3jxFyZcoZrAapralZkUUFSuVUK3N2iE2QPqbFxcBs0xcRccsVfp7Sz9 r/5vMhcX+t10hv6yTcQSLEeHQ/vOQuLH36NCXCWqFIe9YBuL7RvYA8BGVcM0De41 IsuS58t+F5MClcXcFmglfyDaJCkl+A8QhONvTnhST75uL2oYNbO4fKCE2+vZlSLx zXPQ+IQr0oWafdf8rteCgPOJASIEEAECAAwFAkP41BcFAwASdQAACgkQlxC4m8pX rXxL8wf9EiFKRYVwJ8GlsxzIdE1jpLJKSGBJg9/qF3OQ+O3DXwfDbVfz31IxX/d1 K4BmPMNNpFkMA2Ne2TzoElUHMUEJtiY2SKawcm3XkhPTrvtt1pGUMcz4h/gZhpPp bPyQTh4wk9NLkfMbZsqATbk/wQShh/hnCdkASw9ZZ12b/y9Hq2WCSMMgUXQ1fctq FrQli3bZLJXfVVdzQYolWaME3FTYGtiJBdVkdkV2SPcKz4ODDFGiGb6mGWvbAn7a ls55eErFUVQsIYFBKbhx1H4xsVhNqneR/frziE1xSqDkDU7xIdYvs1FVJqpVhjuf UgNLNcOKWPzcHxilPog/7wuQKUwxW4kBIgQQAQIADAUCRAqiJAUDABJ1AAAKCRCX ELibyletfFiRCACBGbiUnCqICZwpMdIkpC4zgiNhuKO6sJRMXFk02MTRCj2K22Ke BBwiHIxmnb2wdvtbJ/AQehXgQVhLPhPyDvIoekMeBUMIg1I4T5RprZ7X8HZ55JwE +biZYzQIKZ79KZ9UEyk4NLuso4cKtgoSnoYy0p3Z6EvxQbGpF4UWFfkW4snbbQW5 fWIdlUXb3gbDwo1XLIgRafkK/5eca2RhuUNTjmx4D6rFNtPLWKnJZhRp6+eRPPtI ZOOXIiNYGFXFJ2xywGugEEmqTnU26NpKkfXiYauMAtsDrpduQdKu5l22PrxmSJ5d QVb9IItcR4eEuNSTf0XHsDi+M+JEutP82GYriQEiBBABAgAMBQJEUcdJBQMAEnUA AAoJEJcQuJvKV618e/QH/ikyUAXkv9n6QgsBYsZFLMuZLqUZ+QoDIBlit/GHcmET pT3uS8+smiVz7MRuPs3oZR6Vbr4k6V8Qfh7vaqiFVkrYAhhovgWDh1pOafruexvx hstxkyBzv9rl9aKhGdXPYkNu2scxSQ5qTqQwPtIUi0Gzt6ywqehJkVlfFFYROux2 ATbpziWCXxauVZnG5eOMvP38p1vLE3JdZm74UEmodcyW/3thEYe44Ud2+2/XrMUs snHCzhWh2TxdffVfdjw4KoBUS5oZDxvQ5RKUUw+17pzYAX1Rk1MG3kajZbhsJzPK YOx+ST96OQ4R8lGMwGpUn4WVe95YKGk7WHu7eTdzmOCJASIEEAECAAwFAkRjkVYF AwASdQAACgkQlxC4m8pXrXy08wgAu+Pmr14PXnIXAN2ZIrMIZCAatq42qQIGJ1f4 WZIn+PuuBUU9+l/enqkfLPOQl/K+G8UHUfE6xb5MLCpSRKRTkb+qo6Kwj8D2Pz0o BMiTtaDYpL6yy9WvqxAJQbVj17NNIb6O5D4gGKPZFZl+MWIE/EMfMmeOUheK9aLL 567G4hEg6LqcSsqYVIFVdqnD0UmykCtNZJhkU+fOcciGIset+f0NcKsEFfSiY6yt HOih7mNPe2V2E29PSTrngqGTh8R4mOe0k0/WjDnj5//Dc/ReyC0UIrNjmMkerAqN zLcz1KWZ+kxXjK59jbE17ZfckvPSbtqMazoq6KgTiYHP08wwALQpUmFpbmVyIFcu IEdlcmxpbmcgPGdlcmxpbmdAbXBnLWd2Lm1wZy5kZT6IRgQQEQIABgUCRAZjFAAK CRAgh0eAIaxsxIx7AKCNz4Q4yLaUZQtDv5NpClGX8d6UmQCeKh016PPS0vtTSD8H I3fZFVC7SluIRgQQEQIABgUCRBBzrQAKCRDtRoHJvz35tKulAKDtkCUwumINordS LfCaTMyrlzEYHgCfZpYiuvaNYIuBH1T6TGy+zexqrZWIRgQQEQIABgUCRHWkYAAK CRBd4kmWWwNYorZjAKCpnsRnhskDUPJ9V0XbYE9CjLdWnACeO5Vs1lSrzk/pKTt+ P5iaHXs8QayITAQQEQIADAUCROnpSQWDAK2J/wAKCRAHqDURTFOG98haAKCva72C 8OFGXNX6qn1+W2NFxnh0cACfXsPR0TWi1YxrSyld2XsgUw3yCDGIUQQQEQIAEQQL AwIBBQI/eqCpBQkM7SbfAAoJENx3iwdOdUvtTrYAn0gGjGPMEsyKFFm5LorV4Ey9 TMQ8AJ41cbxui5QI34MAsc1wMgJD4LKjLYhRBBARAgARBAsDAgEFAkAOdyYFCQ1m n1oACgkQ3HeLB051S+1YCgCdHhQji/Z2d6SiuiKojBUlewt94fwAoIrq7F+/dbXE 1WcXcItPBy2rkrEmiFEEEBECABEECwMCAQUCQA53JgUJDWafWgAKCRDcd4sHTnVL 7VgKAKCQO2z3McJMtBjiGfCj0/Ntyw5rUQCg6GFWLHiG7Y+dJivro/pllu/U3omI UQQQEQIAEQQLAwIBBQJADncmBQkNZp9aAAoJENx3iwdOdUvtWAoAoP6qaRDo3DZ2 H/K/D4X9OZvWmbNLAKDz0+vq+RJqbHMXG8TOMBjxZaU7WohRBBARAgARBQI6erTp BQkHwXMABAsDAgEACgkQ3HeLB051S+1SNACg5kUld8/DRItc/A4BSqwG4LsFXCAA oIc76rBqloLOZRQBLvygqc/mWDqriFkEEBECABEECwMCAQUCP3qfEwUJDO0lSwAS B2VHUEcAAQEJENx3iwdOdUvtLR4AoJLfHgxZwFKf7Uo6tmu/UoIwhJ3rAJ9UcRJT /laFDyUVwvIDy+ugq6oro4hZBBARAgARBAsDAgEFAj96oKkFCQztJt8AEgdlR1BH AAEBCRDcd4sHTnVL7U62AJ9IBoxjzBLMihRZuS6K1eBMvUzEPACeNXG8bouUCN+D ALHNcDICQ+Cyoy2IWQQQEQIAEQQLAwIBBQJADncmBQkNZp9aABIHZUdQRwABAQkQ 3HeLB051S+1YCgCgkDts9zHCTLQY4hnwo9PzbcsOa1EAoOhhVix4hu2PnSYr66P6 ZZbv1N6JiFkEEBECABEECwMCAQUCQA53JgUJDWafWgASB2VHUEcAAQEJENx3iwdO dUvtWAoAoP6qaRDo3DZ2H/K/D4X9OZvWmbNLAKDz0+vq+RJqbHMXG8TOMBjxZaU7 Woh5BBARAgAxBAsDAgEZGGxkYXA6Ly9rZXlzZXJ2ZXIucGdwLmNvbQUeAQAAAAUC RZjwdwUJD0kPrQASB2VHUEcAAQEJENx3iwdOdUvtN2YAoJtaeUNPNuvEnTrdiRWi C3tdMYzSAJ4wTaPItrum5ppuIYK6XOYmC6y1t4h5BBARAgAxBQJCnE04BQkM7Sbf BAsDAgEZGGxkYXA6Ly9rZXlzZXJ2ZXIucGdwLmNvbQUeAQAAAAASCRDcd4sHTnVL 7QdlR1BHAAEBrOwAniFnYeJBUmbpMh2X1Bw9AQNEY4e2AKDWxO5ta3A6kZ+Ejxu+ GRapO2rZT4h5BBARAgAxBQJC+HP4BQkNZl8ABAsDAgEZGGxkYXA6Ly9rZXlzZXJ2 ZXIucGdwLmNvbQUeAQAAAAASCRDcd4sHTnVL7QdlR1BHAAEB2AAAnRpH8tdSoU/8 6gVU1y3veG7jTgXSAKCiPKsK7damCEs58QjjMhA3tJKLFIkAlQMFEDzGd5bs8KU5 p64TswEBx6UD/iPY7JeQPCC1a0KCjEuopK4lNePCVQPo4y1nEXH6wZj4Xt6rlSkd +yFBD+SK4wjFbHpkjdojBjuWnKnLDi6qGE3tiYogjc6hoV3bRwy4sIKG9tRkdQ2o +/wHDeobV3rlnWKCUpV898HPjbonRFpBexv1Sz8jgjc0p/sAwzTOA5yxiQEcBBAB AgAGBQJEBvvMAAoJEPn5wycJjRKztaoIAJKT5S9oVZIT+rVcFpeB3FYrBqOXiGko HGcrbBOl3f64ajlhTCwq3R8sykh+iSJDJBa0645mpMt53KI4Ao9DLg6whPtcmKmG VKZh/CDet6OU/+EpwVWJZ9RM8lswhjCY1L6wG3XoiifJumIATCVZBwD06JI8yQkc xfVOZJ06eGqPsZAShzODw/LAYKNkPrI6lIdgfyZzwtacrhanhUFn1cd8JI9e/0e+ m34nIUtI830bBgVuAt/w7hYEvlDdzULnGqyDsTpPObloLYZqCc6wsZIK1Dk1fbXN ydrVTqbfqvei/wzMcqxJCZjWl0VaiJpoHEwEfPVEtNxu+hObVrRcpj6JASIEEAEC AAwFAj5eJGUFgwGUYuMACgkQuQPV1nqde1mS3wf/ZP+kIUo4wURvC6lCDMf/7BSG L2ptTvABeST1zRmYzd05SMoPKdsPS0sfuVSXNeUf8l5IFWJx0S6f4ZcjXxoIsHAr j7TR+ZZ32y70rzwupvJASzV8cfvugrLO8Vhz2B+LxkGy35CfBNavHs9KhIWBBRLD dMt8xuc5Sjn39xQGGZlWoB7m59dMfUv1EfP0qmhkq0GAfyfPhbsIyPD69t0MOTrB LB3z09rmSqFBUNZPknNL8kh3DlOqe8dJdfyQdylkHRXSO4iwWVyiKYRE67hakCZ2 MpKGxUdYxZelvsBAOFnxP3tWUp4b6Mib1L1/D4Ebb949aEvghm45zr9p26UzIIkB IgQQAQIADAUCQpxOmwUDABJ1AAAKCRCXELibyletfIhcCACnsF1XdOqvRO0CJmRF IHwCR/r/Os08ymzOPx1M1wrpXZPFZ3q1urWXT5+q8/TI9gbYNs6Oua2q4/uMgTlj uTOKhOQUVClEJ/LQ6jqwPk+UIDDuqRS21T1uv9XGvFgDpRN/vd0gtYVkcwyPqeCd EdKM19Znu7mjaEWeuPYMIwb7u3Nr3hnB/AiS0xHJCdVTb2U60e7uZbCIYAyQ3lPg MOa7LHeOMvLFyIO9hvh9RwK2IJGEHDeU61FLRbbaCFNY/xelKQv5GxdDMJ1kIrOP pjemfBuNDtvqGrUDlAPtE4sXqwTztGLqpBGFzlbIiVBy1M7kpVNTeGhKKR3g8mUz +V1wiQEiBBABAgAMBQJCrdgaBQMAEnUAAAoJEJcQuJvKV618uCYH/i7+dDaZ2g7p oaR4D6gF0RTnfPgIO0bvFcI3keC3p+6TTPqC/Yo4GuuV1XfVQpmtizAj+ezW7AJ2 TgXZ/ric9+y+6WRiPw+4ky9kv4DBdfvij3v46e61aGBt1TQ2Jq1yHyjuTxqh4S1f hjfWZydD+Zh1fA+D/GHBi3EZwMF0u5PdFUrZc+p3B9rPjQ9s8VRUN1QxHWE5K3nF 3p+D/bP5Yigm796f19IZNKfWvcXmWMCol8As/UTRmQfrZka5LEtmXZv5rNH9RAvE EwIm2hb/jNAn8OF41pzP398APW2PTpQbjph1mvMZL/hKWiJvQYHY9hTuWNnQ4weg la8jqGZw3x+JASIEEAECAAwFAkK+/AMFAwASdQAACgkQlxC4m8pXrXwWEwf+Mvb7 oSJpHPl77heH8OwirBzA+Hezk3jcGyFYwjYBQCYmOEskh/m2d3idMKicdKrFFwFR 9Xy55tH7pYiD2YYD37gYT4yy8CvgyDvd90n07anMicqwyG6B/EebFrNiNzZDzL7c JdYFdVIc7go2fJnScEPNY0lLwav9Kn2IcGrxrP+03rg8oPBW7xaxP3uXEJRVRpBs OHOL2ZnHBFMqWhv27mlICal+6ZMDSQhuLr1/HhHCY2W1N18/NqjnvDFA60xxa2qp CgerpXS3m/kW+jH/fQ9OuLSkvX8mWtbu10OrUXI8tjU8QcS833BPbb1yBNMC+g3J Z4fQdxLCcss9XA4KZIkBIgQQAQIADAUCQtF7oAUDABJ1AAAKCRCXELibyletfHaq CAC9DqLYFvP5vj5byzAAYphqEhBq/+bRkHfe5dlzqb/oo0zGC27ywuJCvrOI8tzv R5vm2ghVmZGfxHPr4h3Sw79jMi3ivSA2p5z9GODsiDbZleuezWglhozZP7tooS8o Ogx3Lmw4u0NfcitEihsnZMcG+QdV51bUr62SBi1FCIpz/L+GGTmyweZwG1xUxt1d yPBdtBe0W/1CubeRDnfh1mgQ9FM6ZwDE3CTWahSCgj6sPTrEzGPR3Hwdd2U0MLSV dXgfGu/hzJLcP+4xMfZtGoKtQ2jbiKMlUJyP4DocMTaxQ2FWjBXvN1IDdKueYkXK lQF7uNWrEBzLiz95lUWM5DqTiQEiBBABAgAMBQJC40dLBQMAEnUAAAoJEJcQuJvK V618Za4H+wZciKtkyaPOtrEu2176dgu2JTAp1lyGw8vjZApQgAEXbrpBqh0/TzlP 4EUi2WqNtxX5nHbC7YZwNiFQ3ojtWs0gGrSDdTZaSgzM7qpRUcHqNKGaMzbwWocg RSffeSMLiAE4KKlRYfZmNqLvli4OsAPyeVrSQW9G46MJydGf5OIt03NOCsiTPQo2 c32RdLHTs52ZwD20oyhYJg+tc9P7pEh0nnFE8GAhlyLuznRMmIUE2oC/0AvHU+Wu 7jd5cqTex5BZ5LMwJlj8xnxuLgNZJVv2uqHBLlO3lgMvlKFKvHBKcYsU0/A0ngzL mP8rUgrJaERNF9Gb5qwCot3u1pccJ6+JASIEEAECAAwFAkLj7xAFAwASdQAACgkQ lxC4m8pXrXxkZwgAs++tBNOs1Kaxhmq4JJH1VgHdBgYz9bQI0lCSvs4VNRpj1t9p 8f1ZYJMyQOFksm1IvIzp335RYmo/gss23oi/qLLNacQ52CZBFDhjzWZEuG+IQR+B cP5HixuF428oVgkGjMPYYArp8HSn0uAVcW79t2HOR05ri1jygT5wHM11IjV9elPx pVELAlqss6nqcZL2+gaxK5YpyroYdArVL5aBE6LMvCOjFzfmD43Orc/WMuBYIfqG LjsLSDLQBrYhTEL45NyFmlQ9P7WOvuAE1SQmJugdLKQxlN1yOfMIFDkxH8PooeBD Q+/Zzt4lLdfvhi0T2bzjfnOFKDJOMxf5DYLSCYkBIgQQAQIADAUCQunfQAUDABJ1 AAAKCRCXELibyletfKhUCACnRZqYfc5Q2KYMGjatxJdFpaoaEoWcdVQSL6oBSGST RX5ZnP260Xh8/9VUBn9OE5BLnRud7AAgEc2xnXZ+zbmJHWAQbsCZkIt+63RbSDUi /I+hYronyLopEKf/5CAx6t9GV3+EQsNsKIbrFxdK2SuVYe/uV58DaMjrA5ksGMO0 Rsfb3+HhTl6svz939dn3zlyDvASfuYVnQAiFpKb64U2e24ayOPatDSZifUjoTXWi Ax85yK/jq9s3sDAVx6P0mFE59E1Ef8dHNwE4ha8UQkCHg2ipU2dgoCPJUhtO4lCn v5/tvFkpDX9VuhVw//Bg8ldUOjkMN0XUvzh6EvZ5BYzNiQEiBBABAgAMBQJC7IJg BQMAEnUAAAoJEJcQuJvKV6180wkH/0Opsk+7eQ2bQK1h/d5dKGCv4ELZnwpSVMjn BkMINH5KVzfePnBV2okqDNlBQ7yYOEPsiUxePzBu9VW6eumA8RmQxYG0HSQOf+fZ Z5hRm+TF6RWNclTlVRYFdUp0ef1Bl0K4UI0kNsqf4uleO8NfpihLqWHWwzjBKfgI uLvO6W9LB4enjvY25WU6q86agRgXw1FzmVj3e2WsNgxSUZCG+TU8hA9Dxhr1cMpU ms4VgoEFNsKaESrrAcYeLsccnJGxRMHN+NfoAoUEKvobC56WgRbStdxxntZoRobX eH8LhMDjD0IcG5i5/bJELAmdrCa/jafJG+MWrHZ3y1yDcwsx7riJASIEEAECAAwF AkLtKnQFAwASdQAACgkQlxC4m8pXrXzOawf/TUKQtZdlB18zeAuuMCk9j/WQHSRt kcJ9mQMnApa1ZzTWfbfNm8J1wfHl+gNLGuGEsd6owEj6rlOiW+upnDwTIdrldtYT oSaj3YZon5thAZnwZZXlScUU6eqpbpgUgaIKzNdGwY62Tc9oQPp5RGUFG1HndG6f rm8Dtw7Bo5eTg5z9ycOAwWtnGRpG50622BTRCjqO8XelCJC3yfbjwgMwRADoIazS vQ+kwXR+i9qJ28aRJ0jRz4GGn5yJzzwA601yFUiWIBMawqvRv6bjZ2zDLeoq8VRS gprkLsIU1DCqCLdnGXquGlnsCMhzqB64XYkdg7+6/jNIddyRThGfWIiM5IkBIgQQ AQIADAUCQvh0TQUDABJ1AAAKCRCXELibyletfOK6CACuCncxJBt2yHXu/vJ8iryP XWgb8WMNhAM0PvJnSQ855Kgub9a44evaimye7Z4TTOvIrb/rFcqlrQFKWM0w2KUb l705EeZ989UUrBwrMsfgxoZzrwSe4zk+7kHENzidSeXnumaDRYYqaUuf0uX6TEa4 Yfin47KlOCkNZ1H8vxPqRHWIZR5KxVIfocB7AGitnnJkX6PNNpN/4yxutVKtiz1g GjbXsR0An4xtpKejN+wG0kE8elmrXxqszXH3Bga15T8kfmJ1wWFHoBGduSiTOlQV ZxF00vDUtEaJkaQNmui9fbY6QMefBLKPsKBpD2smLgSiz9/qio7WdUahAxm15vBQ iQEiBBABAgAMBQJDCthsBQMAEnUAAAoJEJcQuJvKV618SPkH/jJXXAVs3VbnO7lm shj5fn9Uhfu0Vpc75T/qHt/+fDnN7EYkYS2PbI1upVBrTaN3b4WYtI82UjVtara8 gDdPQ/SMvUrOaiu3OdCQwMRoA2TWNW7o1/OI9CdSmGyoY3R3LoPC/e8KbRHPHPK8 ATen2wF2/wFH7p4MrtTOmRv3JxsKASJdGfdEfjVQQ8pMdDXqUh3FXemOoJyK4qbC VC+ztTwXPhq/sycxUoyqjDLSSf0zM6z+oHlMGP3f4ZjhLKID8nurcnAJRU69Mk67 J5XEcvG5PdA4C+h142zxC3bjoyahZ7HXloYsL3LUkzNluJ51j1GYo4AF3m0PILOY AnDI3qCJASIEEAECAAwFAkMMLc8FAwASdQAACgkQlxC4m8pXrXzIjwf+J5BN33Ae aTIO61p8oeXl4Giz8fwPtCks395c/428wG9YjU0LXXlEvPfC64DK61maHUq/2MNb AtFjiNNbPGlDQDAA+e2/o4RBXX8Y+HMV0453tkKtNns8KA87qhGIwsNFkwEkqjhB kLomEgGwg/tMQw2WE3tP1LH4NbuluqSx9eOrXuosZovfYCOZB2aZJAXYJ35cdAJ2 GQwDsctzKDfBhA2L1pCnDkb69eE+oInHgmtfGWPbeOR/bsuYxwH9c9y3HI0/tDUZ LaWoJZhMeRDkzyGfvyjiGHu8p+yWq2WR+EqhbXt2FHKtH3hgIOekCX3G45z8aIXZ 7FYA3avTTQSHbYkBIgQQAQIADAUCQxDIuAUDABJ1AAAKCRCXELibyletfMOWB/92 jLmfIkobOO0k4G3rWhbFMdASpdtwrLeGWJiWB6gL5B5oNAxDWWUTo8VFbsJOY8X0 biOAodA6Hb/dw4YlEQdOCtzTQdNT7e3Bt8eyLbXla/CcrDu71Sgs6JJG/B27uSMS nCJVUa1/RxvvETNk28/jHMBGAmyf8g5JpnL1vYngaBK6hD45EAB9mTfJhr33OUup 0NP8TABz3o0zJArAlNsz8eZ5mj6gbDPUQN58htAIjUxnST3cvKRqM2v45LXFQ/BJ NojAjfNW1SiHkT7JdKgE04vXbXoAxxQWHWA6tnIVj/2uObxJHhedYpyNnDcJMYcN wWSjUZalp+f1O/M+ix4WiQEiBBABAgAMBQJDE2x9BQMAEnUAAAoJEJcQuJvKV618 gd4H/RtYGCUFUKlGdDNcjlVxBpmTLSjYZDWOtUlRtPDrsxqjz4l5gPvuVzy3ONIp x0PIQ5LkmwlcBVhhEqKfu+TAUsO4ChmcYG6M3bYPBTwdfdpp2mca8MFDgsHI1s55 2SUtiACqsnIP7YvQbp/mA9LzZlqfbqeCuZQKuoPkjF8gzLqfjn8j2csqEU2MfTP/ Y2HAXv2X3vn8bq/9KWyHlifEgLBGVmWSGuQycVtnhdz8fXKiHH2nZiG2Ds9biuJb v1FUOFDaifbguCZTLmRicLY6IJPyzLntUt3zHOs9yMX/RUL4mYRb9YbC7woEN0+E Tn3l0rHf466UjUJEdp0KsTXwJ2WJASIEEAECAAwFAkMUFXsFAwASdQAACgkQlxC4 m8pXrXzpigf/aSVTdS+9eIL6YXDi8hPmwiKVg2GRwogBDOIKbDVzn0E7L/NCUd38 HkyoKLFGrIFsaC7MnP4T8CT82hM8mU28J+SH5M+stqjA8RlsaJMfoE8Gwy4trgOV WM6LRju9J+1BVEC5GZRlA8AA8D9+0kEdJLg0EHwt7B1I7BsqZw3V2Pq3o3LJK4J2 inh1gCMKUYG+wlLPhKrTZpFR4FlmNmk9Lmrt2TqpaZgt6VgXAm/J+eOSEg7t4Z3S DMwOsAiEydaQEhkDBi/cA0coYB3ngHN2LfynNVN+//HF0umTVG5DrZKgFiF7Yww3 wzgNZkGzqDSw6tmWungLSb7DHyw8aZ1K/IkBIgQQAQIADAUCQxYPWAUDABJ1AAAK CRCXELibyletfHp9CADHhF8vEKF/M+Sh6FdRFtRLbSp5XjJXDOtmtrt7sXRATSsq O/J5olVydbOAS6Rn1Yy9EmxG/8tZlL1M9QWv457usYojRaQfsMB8rVF/VdIqlptm LZkoonrceDLZzWj8YwEez4eSsqz4RUbOmGa4Y+QqVfvJ1hkStMDsdDc6GqTrSi5O h2evwMnSzP+DhJeh2Xxoqahwes2+qmeCKieE5mI2rtxVVt6d6+EmqSCjfgGNyCV4 5ASmqTCUbmr17BjRl12WkIon+DQCf06zLyMJKHqRXAbduhhBx1VSNiNg6eNeJ7f6 ++AyWbKyUuKopZT47WkbGBxXWrxODI53ad6yc2uRiQEiBBABAgAMBQJDF2FqBQMA EnUAAAoJEJcQuJvKV618aqcH/2CYgrA4k5Bb3/tLhsB2TM0+ijm4ahYLfUvn4uKc 1qmmu/3AkwrWFBdz6tS0IBT/eQ6OfUH6GusRe6ssQrGDGmiCUrcJaldz42Z03fNT CDcO3ZqR7wHxwhtvbBQlM/6S2xGRJtgH1drK+8GQ0fsnestMm7RFifKtzh2j2kB4 9Zk9rtJ5nSdE6jZvFHe8XiVvYaBTdl8xgSnTZu7iviHnfYXPtqXSSNXoRYo84ydK zeRKei6MqkS8H1QI7wSwn1rREKlalAAtySbZs4dvAnZIVECdDnA1v9kQoBwzAMUv PGadLcHDWqQHFeULRItcOlZpiTCqt3hrTZzc8EGWTKrjRgGJASIEEAECAAwFAkMY siMFAwASdQAACgkQlxC4m8pXrXzWgAf/UJ3wJYaVA0h29JMcJUblD9HhRr47DZLS MLPfns1OeL2HB3Qwn/qcyzux4qeglBqQa6xeL5ZcYFv/c28x8enN5DYEMZXHuTfW x1UYv3j/ErsyLBwVocOTxL0cRdi8ldF5gxslKWFeNWokJ1PyzXJ4LJNcdef0iHOz dWymXZViYgC2/U30EM+uGXuRrZBKegWMRvj6uB59W4lkCu8/Mlfor92LjyAmK+kA aTjzOUEvP6HgbW/rNAIsqnrlCXkJauoqQGhJi+0/RHskkRmwDKighPseXXDxLALY a23jZ+CNHuAP1nSVsq29ak7UdvFApzEgCq+qh4EkPYgKgZzI9Oy1JIkBIgQQAQIA DAUCQxlbVwUDABJ1AAAKCRCXELibyletfPOkB/9F7MJxisU+JzU+aakKwHGLo7yH /c4fTMV+0fFxbDh+mm+V9IIZmsf0p0PHlHwPwICC2KlJ0ND1AQa9PLiQxDhLnGoa HNu6iBZa7uv2JEOS9P5zo9M0kYX+61St9HOdJwG/PwW5qie5N6DC20cAbmjgwB+a OFsReHd/xZeIKmAX35YdjKu6XuDuFnoacgW+JwJqgec9+j8gca/ihbX8f7LbGpXy rgUprIZ94zofmFEd987tMSgRgmTWO+uxFfPp/446kxTN/gOHiOaGFHgBreG0jbiW EtkxxZAl4Kt5L25x9RD1lvbPaioBaC6Cc2i1/MtOUmh6gDUYOf8KWLEN/41ViQEi BBABAgAMBQJDG1T6BQMAEnUAAAoJEJcQuJvKV618EM8H/i/f5bMjoG+sJUl3QbC4 gNrh7ipznm45BegpsQIbhUJXqo9KVI7/HVsUKxCC+ZZRSJqzwNMBs+IGPMxMENVy +0Uxt1KsUuiRB0epNLAZWBX06F2G9DQzAT6g3rn95/8ulPnV6Hn92cxuAwlgRuv5 4Y9aBOARgB5RQf4qA203rZMoQu1y0sP7fSc/53SVRlc6apQcyPFNsxbw61fMDFUO pq/URr+wj1q3y7KS70IaW3yfBe+VDajRYSvNHLlvP/KvNSB9CaOi6BLbSha/mQpO nBmWvlykHZHNqq3hjbt0bWq5MJqYnRC/2ETmmjEFJc8vDrQqLcBADXFuGnkhozKZ od+JASIEEAECAAwFAkMzJocFAwASdQAACgkQlxC4m8pXrXwEQwf/YeyiEpobn8N8 /z7xXwJu5Tj/JZSUJja4W6qtQIq4oThshna6SlOI9zNZ8jaIxL/kpqlSbCYQ8npf 6wWY2SV3mPtsTjKaLhF4/m9nWjoRobiKyjn0DdidGQCftKHhXzQP8wHq7/hV5Gih 1qn6EAfp/v3lzD0l9D+bLUFSrYM5X47CVE5UY6+fXuMkeRyj4svEtGSG5TFooepC QAJTDbSbUaWen4bhYyaWCmGQLlJRurXS9bb/HeH/57NIB4npFGzBQabyBM9fCMPN JOefka/BTAkwLANk8KXz26cO+NY5oeWZgLsom7P/qh1tA4WdeO8/3B67ZkR6WV0k QE9C/n2lbLkBDQQ4MIJhEAQAy8trvl/hI7HPzMpg3BvZ0QUbGZdQbKgUL7pUtSje J5mKXYJqPjTRSllYSDV6BLGGb3zsVmrclq7aYcQ4vuHjs4O2MABrOa7KUAjpZpFf +QdAXaMb6xu0tvjN2ktYsWddqozAWFsMPFUEnncljyqyB4nz1rft21yNQSQdD9Fa 0l0AAgID/2GYOGqZOe9MJeMtYgE3ij9Hs8n2lvNyUoSc1rrtzrcCQ+WXCBlla5KD R82L/Dt8V0NeHsJRK7sa5tyUYMbQGIpgQK7DMQxmwAsbkscLv0bB7x2gYvTlxvUE 25Waa3RSlq5mqJP1yZfW6klAqv0lGWbi8McZT8fSXbL7jZ66OCzViFQEGBECAAwF AkYoWRwFCQ9JVrsAEgdlR1BHAAEBCRDcd4sHTnVL7cIGAJ48i4LUqnxRZE7ZUH72 a+rqQnZiFgCeKQ/aFOt61nySpIzKtJJ/Apx2aIA= =Ofgq -----END PGP PUBLIC KEY BLOCK----- Does somebody know why and how i can solve the problem? Other keys with multiple EMailadresses works fine too. I can't import the keys to get the fingerprint, that's no solution (then it works without problems). I need that very urgent. Please help me Greets odigo -- View this message in context: http://www.nabble.com/Prolem-with-gpg---with-fingerprint-%3C-keyfile-tf3960438.html#a11238619 Sent from the GnuPG - User mailing list archive at Nabble.com. From peter at digitalbrains.com Mon Jun 25 12:55:11 2007 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 25 Jun 2007 12:55:11 +0200 Subject: Prolem with gpg --with-fingerprint < keyfile In-Reply-To: <11238619.post@talk.nabble.com> References: <11238619.post@talk.nabble.com> Message-ID: <467F9F0F.2080503@digitalbrains.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I've been playing around a bit with your public key file. I do not know the cause, but the following gave me the fingerprint: (watch out with the rm if you repeat this verbatim, it is more for illustration of method than to copy literally) $ gpg --dearmour test $ gpgsplit test.gpg $ rm *.sig $ cat 00* >test-nosig.gpg $ gpg --with-fingerprint test-nosig.gpg pub 1024D/4E754BED 1999-11-16 Rainer W. Gerling Key fingerprint = EB96 7ACE 1466 DA7E 48B8 261E DC77 8B07 4E75 4BED uid Rainer W. Gerling uid Rainer W. Gerling uid Rainer W. Gerling In other words, when I delete all the signatures from the file, the fingerprint does show up. Maybe someone with proper knowledge of it all can use this hint to determine the problem. By the way, let me be the first to say that in scripts you should probably use $ gpg --with-fingerprint --with-colons (Hardeep Singh's message of "Sun, 24 Jun 2007 15:37:46 +0530") References: Message-ID: <87odj4z19c.fsf@wheatstone.g10code.de> On Sun, 24 Jun 2007 12:07, hs2412 at gmail.com said: > If someone sends me an ASCII armoured file with some signed text, can > I convert it into cleartext sign so that I can display it to people > without GPG also? In general not because the canonicalization is different between the formats. A conversion would break the signature. Shalom-Salam, Werner From guillaume.yziquel at free.fr Mon Jun 25 17:58:18 2007 From: guillaume.yziquel at free.fr (Guillaume Yziquel) Date: Mon, 25 Jun 2007 17:58:18 +0200 Subject: Problems svn+ssh+gpg(-agent)+smartcard Message-ID: <467FE61A.6050000@free.fr> Hello, I have the following problem: I'm using svn with an ssh access, and I use gpg and gpg-agent with a smartcard to access my key and replace the passphrase. I'm using a debian etch with a 2.6.18-4 kernel. After my computer has freshly booted up, it works like a charm. But, as time goes on (and perhaps a screensaver goes by, I don't know), the system with gpg fails, and my computer ends up asking me some vulgar passphrase... Some version numbers: svn, version 1.4.2 (r22196) gpg (GnuPG) 1.4.6 gpg-agent (GnuPG) 2.0.4 I started logging messages for the purpose of looking into this, and I get the following messages, which I do not find extremely helpful: > 2007-06-25 13:32:21 gpg-agent[4577] DBG: detected card with S/N D2760001240101010001000007180000 It works fine. > 2007-06-25 17:16:13 gpg-agent[4577] error getting default authentication keyID of card: Erreur g?nerale > 2007-06-25 17:29:55 gpg-agent[4577] error getting default authentication keyID of card: Erreur g?nerale It then fails. > 2007-06-25 17:31:17 gpg-agent[4577] SIGTERM received - shutting down ... > 2007-06-25 17:31:17 gpg-agent[4577] gpg-agent (GnuPG) 2.0.0 stopped I reboot, and it works: > 2007-06-25 17:37:49 gpg-agent[3937] DBG: detected card with S/N D2760001240101010001000007180000 I'd really appreciate understanding what is happening... Guillaume Yziquel. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 370 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20070625/600dedef/attachment.pgp From james at freecharity.org.uk Mon Jun 25 20:14:57 2007 From: james at freecharity.org.uk (James Davis) Date: Mon, 25 Jun 2007 19:14:57 +0100 Subject: Problems svn+ssh+gpg(-agent)+smartcard In-Reply-To: <467FE61A.6050000@free.fr> References: <467FE61A.6050000@free.fr> Message-ID: <46800621.1060509@freecharity.org.uk> Guillaume Yziquel wrote: > I'd really appreciate understanding what is happening... There are some circumstances (bugs!) under which the scdaemon process stops working. Kill that process and try again; does that help? James -- FreeCharity.org.uk - Free hosting for charities and non-profits WordPress and Blogging Consultancy - (01348) 800101 From guillaume.yziquel at free.fr Tue Jun 26 10:36:54 2007 From: guillaume.yziquel at free.fr (Guillaume Yziquel) Date: Tue, 26 Jun 2007 10:36:54 +0200 Subject: Problems svn+ssh+gpg(-agent)+smartcard In-Reply-To: <46800621.1060509@freecharity.org.uk> References: <467FE61A.6050000@free.fr> <46800621.1060509@freecharity.org.uk> Message-ID: <4680D026.5020000@free.fr> James Davis a ?crit : > Guillaume Yziquel wrote: > >> I'd really appreciate understanding what is happening... > > There are some circumstances (bugs!) under which the scdaemon process > stops working. Kill that process and try again; does that help? > > James Thank you, James. Well, I haven't tried your solution yet. But I will soon, I'll bet... I think the scdaemon you're talking about is: > root 3672 0.0 0.1 17948 1380 ? Ssl 10:20 0:00 /usr/sbin/pcscd But, what is weird is that when this combination svn+ssh+gpg(-agent)+smartcard fails, I can still sign and decrypt electronic messages through the smartcard, handled through gpg-agent and the scdaemon (I guess). But perhaps the smartcard is handled in a different way in these two different cases. Is their anyway to monitor more closely what is happening than just looking at the logs? Thanks. Guillaume. From dshaw at jabberwocky.com Wed Jun 27 03:13:18 2007 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 26 Jun 2007 21:13:18 -0400 Subject: Converting ascii armored signature to cleartext In-Reply-To: <87odj4z19c.fsf@wheatstone.g10code.de> References: <87odj4z19c.fsf@wheatstone.g10code.de> Message-ID: <20070627011318.GA18469@jabberwocky.com> On Mon, Jun 25, 2007 at 02:06:55PM +0200, Werner Koch wrote: > On Sun, 24 Jun 2007 12:07, hs2412 at gmail.com said: > > > If someone sends me an ASCII armoured file with some signed text, can > > I convert it into cleartext sign so that I can display it to people > > without GPG also? > > In general not because the canonicalization is different between the > formats. A conversion would break the signature. Interestingly enough, while you can't always go from a signed file to a clearsigned file, you can safely do the opposite of what the original poster asked: converting from cleartext to a signed file (armored or not) is possible. (I'm not sure when someone would want to do this, but...) David From guillaume.yziquel at free.fr Wed Jun 27 11:51:16 2007 From: guillaume.yziquel at free.fr (Guillaume Yziquel) Date: Wed, 27 Jun 2007 11:51:16 +0200 Subject: Problems svn+ssh+gpg(-agent)+smartcard In-Reply-To: <4680D1F3.803@freecharity.org.uk> References: <467FE61A.6050000@free.fr> <46800621.1060509@freecharity.org.uk> <4680D026.5020000@free.fr> <4680D1F3.803@freecharity.org.uk> Message-ID: <46823314.8090107@free.fr> James Davis a ?crit : > Guillaume Yziquel wrote: > >> I think the scdaemon you're talking about is: >> >> root 3672 0.0 0.1 17948 1380 ? Ssl 10:20 0:00 /usr/sbin/pcscd > > No it's gnupg's smartcard daemon which really is called 'scdaemon'. It > appears that you're using the smartcard through the PCSC service. I > believe that it's preferred that you use gnupg's internal CCID driver. > > I'd see if you can use the internal CCID driver; but you might want to > see if restarting pcscd helps at all. No it does not. I just tested it, and I still have the same problem... And killing pcscd tursns off the little green LED on my smartcard reader. However, a ps fauxw yields (everything on this mail has been done in the same chronological order as the reading order): > yziquel 3881 0.0 0.1 13988 1028 ? Ss 10:16 0:00 /usr/bin/gpg-agent --daemon --enable-ssh-support --sh --log-file /home/yziquel/var/log/gpg-agent.log > yziquel 5825 0.0 0.1 18780 1456 ? SL 10:47 0:00 \_ scdaemon --multi-server So I guess I am also using scdaemon. Even if up to know it seems that things were going through pcscd, since I'm not able to sign an email since pcscd got killed. Guillaume. From guillaume.yziquel at free.fr Wed Jun 27 13:45:52 2007 From: guillaume.yziquel at free.fr (Guillaume Yziquel) Date: Wed, 27 Jun 2007 13:45:52 +0200 Subject: Problems svn+ssh+gpg(-agent)+smartcard In-Reply-To: <4680D1F3.803@freecharity.org.uk> References: <467FE61A.6050000@free.fr> <46800621.1060509@freecharity.org.uk> <4680D026.5020000@free.fr> <4680D1F3.803@freecharity.org.uk> Message-ID: <46824DF0.7000708@free.fr> > I'd see if you can use the internal CCID driver; but you might want to > see if restarting pcscd helps at all. > >> Is their anyway to monitor more closely what is happening than just >> looking at the logs? > > scdaemon can be configured to produce logs. I've created the following scdeamon.conf file in my ~/.gnupg/ directory: > yziquel at seldon:~/.gnupg$ cat scdaemon.conf > multi-server > log-file /home/yziquel/var/log/scdaemon.log I've removed pcscd. In fact, I needed pcscd because I was using some opensc packge together with some modified version of openssh-client. Now, I'm left with gnupg, scdaemon, but scdaemon does not seem to want to talk to the smartcard reader... Using Thunderbird and Enigmail, GnuPG, et ceter?, I get the following output in the scdaemon.log file: > yziquel at seldon:~/var/log$ cat scdaemon.log > 2007-06-27 13:41:59 scdaemon[4591] error receiving PC/SC OPEN response: premature EOF > 2007-06-27 13:41:59 scdaemon[4591] can't select application `openpgp': Non support? > 2007-06-27 13:42:13 scdaemon[4591] can't select application `openpgp': Non support? > 2007-06-27 13:42:33 scdaemon[4591] can't select application `openpgp': Non support? Using an SCR 335 smartcard reader. Guillaume. From guillaume.yziquel at free.fr Wed Jun 27 18:33:56 2007 From: guillaume.yziquel at free.fr (Guillaume Yziquel) Date: Wed, 27 Jun 2007 18:33:56 +0200 Subject: Problems svn+ssh+gpg(-agent)+smartcard In-Reply-To: <4682344A.6040306@freecharity.org.uk> References: <467FE61A.6050000@free.fr> <46800621.1060509@freecharity.org.uk> <4680D026.5020000@free.fr> <4680D1F3.803@freecharity.org.uk> <46823314.8090107@free.fr> <4682344A.6040306@freecharity.org.uk> Message-ID: <46829174.6060001@free.fr> James Davis a ?crit : > Guillaume Yziquel wrote: > >> And killing pcscd tursns off the little green LED on my smartcard reader. > > It will do. When I'm using the internal CCID support the light only > comes on when the reader is in use. OK. So I've been using the PC/SC daemon up to now... > I'm afraid that whatever your problem is it's beyond my little knowledge > :-) I've only had the card and reader for a month. Thanks anyway! > James From nocturnal at swehack.se Wed Jun 27 20:13:28 2007 From: nocturnal at swehack.se (User Nocturnal) Date: Wed, 27 Jun 2007 20:13:28 +0200 Subject: Problems with pthread when building gpgme. Message-ID: <20070627181328.GA53239@laptop.swehack.se> Hi I have a few problems with building gpgme on FreeBSD 6.2-RELEASE with posix threads that come in FreeBSD base installed. Not sure if the Posix threads are causing problems but here is what happens when i run make after running the configure script with all defaults. if /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/local/include -I/usr/local/include/pth -I/usr/local/include/pth -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT ath-pthread.lo -MD -MP -MF ".deps/ath-pthread.Tpo" -c -o ath-pthread.lo ath-pthread.c; then mv -f ".deps/ath-pthread.Tpo" ".deps/ath-pthread.Plo"; else rm -f ".deps/ath-pthread.Tpo"; exit 1; fi gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/local/include -I/usr/local/include/pth -I/usr/local/include/pth -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT ath-pthread.lo -MD -MP -MF .deps/ath-pthread.Tpo -c ath-pthread.c -fPIC -DPIC -o .libs/ath-pthread.o In file included from ath-pthread.c:36: /usr/local/include/pth/pthread.h:285: error: conflicting types for 'pthread_t' /usr/include/sys/_pthreadtypes.h:64: error: previous declaration of 'pthread_t' was here /usr/local/include/pth/pthread.h:286: error: conflicting types for 'pthread_attr_t' /usr/include/sys/_pthreadtypes.h:65: error: previous declaration of 'pthread_attr_t' was here /usr/local/include/pth/pthread.h:288: error: conflicting types for 'pthread_once_t' /usr/include/sys/_pthreadtypes.h:71: error: previous declaration of 'pthread_once_t' was here /usr/local/include/pth/pthread.h:289: error: conflicting types for 'pthread_mutexattr_t' /usr/include/sys/_pthreadtypes.h:67: error: previous declaration of 'pthread_mutexattr_t' was here /usr/local/include/pth/pthread.h:290: error: conflicting types for 'pthread_mutex_t' /usr/include/sys/_pthreadtypes.h:66: error: previous declaration of 'pthread_mutex_t' was here /usr/local/include/pth/pthread.h:291: error: conflicting types for 'pthread_condattr_t' /usr/include/sys/_pthreadtypes.h:69: error: previous declaration of 'pthread_condattr_t' was here /usr/local/include/pth/pthread.h:292: error: conflicting types for 'pthread_cond_t' /usr/include/sys/_pthreadtypes.h:68: error: previous declaration of 'pthread_cond_t' was here /usr/local/include/pth/pthread.h:293: error: conflicting types for 'pthread_rwlockattr_t' /usr/include/sys/_pthreadtypes.h:73: error: previous declaration of 'pthread_rwlockattr_t' was here /usr/local/include/pth/pthread.h:294: error: conflicting types for 'pthread_rwlock_t' /usr/include/sys/_pthreadtypes.h:72: error: previous declaration of 'pthread_rwlock_t' was here ath-pthread.c: In function `_gpgme_ath_connect': ath-pthread.c:161: warning: passing arg 2 of `__pthread_connect' discards qualifiers from pointer target type I have GNU Portable Threads 2.0.7 installed in /usr/local/include/pth and /usr/local/lib/pth, these seem to be the paths that the Makefile uses by default for -I and -L arguments to gcc. Med v?nliga h?lsningar Stefan Midjich aka nocturnal http://swehack.se [SWEHACK] From ken.takusagawa.2 at gmail.com Thu Jun 28 10:24:28 2007 From: ken.takusagawa.2 at gmail.com (Ken Takusagawa) Date: Thu, 28 Jun 2007 04:24:28 -0400 Subject: decrypting many files to stdout Message-ID: <4dcea1d80706280124w4cc3c809o4fa308c9e1ffea9a@mail.gmail.com> I have many files that are all encrypted with the same public key, and the private key is protected with a passphrase. Is there a way that I can decrypt all of them at once, concatenate the results and print it all to standard output but only have to type my passphrase once? I'd like to avoid having the decrypted files be written to disk, i.e., I'd like "-d" behavior but with multiple files. --ken From guillaume.yziquel at free.fr Thu Jun 28 15:49:50 2007 From: guillaume.yziquel at free.fr (Guillaume Yziquel) Date: Thu, 28 Jun 2007 15:49:50 +0200 Subject: Broken pipe? [was: Problems svn+ssh+gpg(-agent)+smartcard] In-Reply-To: <4680D1F3.803@freecharity.org.uk> References: <467FE61A.6050000@free.fr> <46800621.1060509@freecharity.org.uk> <4680D026.5020000@free.fr> <4680D1F3.803@freecharity.org.uk> Message-ID: <4683BC7E.9030207@free.fr> >> Is their anyway to monitor more closely what is happening than just >> looking at the logs? > > scdaemon can be configured to produce logs. > > James OK. I've a little more time to invest into solving this issue. I just turned the debugging level to "basic" in both gpg-agent and scdaemon's logging files. I also added the debug-ccid-driver into scdaemon.conf. When failing to decrypt and failing to access the SCR 335 smartcard reader, I get the logged output decribed below this message. It seems I have a broken pipe issue: > 2007-06-28 15:32:31 scdaemon[4291] DBG: ccid-driver: usb_claim_interface failed: -1 > 2007-06-28 15:32:31 scdaemon[4291] error sending PC/SC OPEN request: Relais bris? (pipe) Any further information, help, guidance, hints, suggested readings is welcome. > yziquel at seldon:~/var/log$ tail --lines=22 gpg-agent.log > 2007-06-28 15:23:14 gpg-agent[3905] SIGTERM received - shutting down ... > 2007-06-28 15:23:14 gpg-agent[3905] gpg-agent (GnuPG) 2.0.4 stopped > 2007-06-28 15:30:09 gpg-agent[3876] listening on socket `/tmp/gpg-vON33D/S.gpg-agent' > 2007-06-28 15:30:09 gpg-agent[3876] listening on socket `/tmp/gpg-j2fBIM/S.gpg-agent.ssh' > 2007-06-28 15:32:31 gpg-agent[3877] handler 0x651790 for fd 8 started > gpg-agent[3877.8] DBG: -> OK Pleased to meet you > gpg-agent[3877.8] DBG: <- OPTION display=:0.0 > gpg-agent[3877.8] DBG: -> OK > gpg-agent[3877.8] DBG: <- OPTION ttyname=/dev/tty > gpg-agent[3877.8] DBG: -> OK > gpg-agent[3877.8] DBG: <- OPTION lc-ctype=fr_CH.UTF-8 > gpg-agent[3877.8] DBG: -> OK > gpg-agent[3877.8] DBG: <- OPTION lc-messages=fr_CH.UTF-8 > gpg-agent[3877.8] DBG: -> OK > gpg-agent[3877.8] DBG: <- SCD SERIALNO openpgp > 2007-06-28 15:32:31 gpg-agent[3877] no running SCdaemon - starting it > 2007-06-28 15:32:31 gpg-agent[3877] DBG: first connection to SCdaemon established > 2007-06-28 15:32:31 gpg-agent[3877] DBG: additional connections at `/tmp/gpg-IJforS/S.scdaemon' > gpg-agent[3877.8] DBG: -> ERR 100663356 Non support? > gpg-agent[3877.8] DBG: <- BYE > gpg-agent[3877.8] DBG: -> OK closing connection > 2007-06-28 15:32:31 gpg-agent[3877] handler 0x651790 for fd 8 terminated > yziquel at seldon:~/var/log$ And also: > yziquel at seldon:~/var/log$ tail --lines=50 scdaemon.log > 2007-06-28 14:23:11 scdaemon[4591] can't select application `openpgp': Non support? > 2007-06-28 14:23:16 scdaemon[4591] can't select application `openpgp': Non support? > 2007-06-28 15:23:14 scdaemon[4591] SIGTERM received - shutting down ... > 2007-06-28 15:23:14 scdaemon[4591] scdaemon (GnuPG) 2.0.0 stopped > 2007-06-28 15:32:31 scdaemon[4291] listening on socket `/tmp/gpg-IJforS/S.scdaemon' > 2007-06-28 15:32:31 scdaemon[4291] handler for fd -1 started > 2007-06-28 15:32:31 scdaemon[4291] DBG: ccid-driver: using CCID reader 0 (ID=04E6:5115:X:0) > 2007-06-28 15:32:31 scdaemon[4291] DBG: ccid-driver: idVendor: 04E6 idProduct: 5115 bcdDevice: 0518 > 2007-06-28 15:32:31 scdaemon[4291] DBG: ccid-driver: ChipCard Interface Descriptor: > 2007-06-28 15:32:31 scdaemon[4291] DBG: ccid-driver: bLength 54 > 2007-06-28 15:32:31 scdaemon[4291] DBG: ccid-driver: bDescriptorType 33 > 2007-06-28 15:32:31 scdaemon[4291] DBG: ccid-driver: bcdCCID 1.00 > 2007-06-28 15:32:31 scdaemon[4291] DBG: ccid-driver: nMaxSlotIndex 0 > 2007-06-28 15:32:31 scdaemon[4291] DBG: ccid-driver: bVoltageSupport 1 5.0V > 2007-06-28 15:32:31 scdaemon[4291] DBG: ccid-driver: dwProtocols 3 T=0 T=1 > 2007-06-28 15:32:31 scdaemon[4291] DBG: ccid-driver: dwDefaultClock 4000 > 2007-06-28 15:32:31 scdaemon[4291] DBG: ccid-driver: dwMaxiumumClock 12000 > 2007-06-28 15:32:31 scdaemon[4291] DBG: ccid-driver: bNumClockSupported 0 > 2007-06-28 15:32:31 scdaemon[4291] DBG: ccid-driver: dwDataRate 9600 bps > 2007-06-28 15:32:31 scdaemon[4291] DBG: ccid-driver: dwMaxDataRate 307200 bps > 2007-06-28 15:32:31 scdaemon[4291] DBG: ccid-driver: bNumDataRatesSupp. 0 > 2007-06-28 15:32:31 scdaemon[4291] DBG: ccid-driver: dwMaxIFSD 252 > 2007-06-28 15:32:31 scdaemon[4291] DBG: ccid-driver: dwSyncProtocols 00000000 > 2007-06-28 15:32:31 scdaemon[4291] DBG: ccid-driver: dwMechanical 00000000 > 2007-06-28 15:32:31 scdaemon[4291] DBG: ccid-driver: dwFeatures 000100BA > 2007-06-28 15:32:31 scdaemon[4291] DBG: ccid-driver: Auto configuration based on ATR > 2007-06-28 15:32:31 scdaemon[4291] DBG: ccid-driver: Auto voltage selection > 2007-06-28 15:32:31 scdaemon[4291] DBG: ccid-driver: Auto clock change > 2007-06-28 15:32:31 scdaemon[4291] DBG: ccid-driver: Auto baud rate change > 2007-06-28 15:32:31 scdaemon[4291] DBG: ccid-driver: Auto PPS made by CCID > 2007-06-28 15:32:31 scdaemon[4291] DBG: ccid-driver: TPDU level exchange > 2007-06-28 15:32:31 scdaemon[4291] DBG: ccid-driver: dwMaxCCIDMsgLen 263 > 2007-06-28 15:32:31 scdaemon[4291] DBG: ccid-driver: bClassGetResponse echo > 2007-06-28 15:32:31 scdaemon[4291] DBG: ccid-driver: bClassEnvelope echo > 2007-06-28 15:32:31 scdaemon[4291] DBG: ccid-driver: wlcdLayout none > 2007-06-28 15:32:31 scdaemon[4291] DBG: ccid-driver: bPINSupport 0 > 2007-06-28 15:32:31 scdaemon[4291] DBG: ccid-driver: bMaxCCIDBusySlots 1 > 2007-06-28 15:32:31 scdaemon[4291] DBG: ccid-driver: usb_claim_interface failed: -1 > 2007-06-28 15:32:31 scdaemon[4291] error sending PC/SC OPEN request: Relais bris? (pipe) > scdaemon[4291.0] DBG: -> OK GNU Privacy Guard's Smartcard server ready > scdaemon[4291.0] DBG: <- GETINFO socket_name > scdaemon[4291.0] DBG: -> D /tmp/gpg-IJforS/S.scdaemon > scdaemon[4291.0] DBG: -> OK > scdaemon[4291.0] DBG: <- OPTION event-signal=12 > scdaemon[4291.0] DBG: -> OK > scdaemon[4291.0] DBG: <- SERIALNO openpgp > 2007-06-28 15:32:31 scdaemon[4291] can't select application `openpgp': Non support? > scdaemon[4291.0] DBG: -> ERR 100663356 Non support? > scdaemon[4291.0] DBG: <- RESTART > scdaemon[4291.0] DBG: -> OK > yziquel at seldon:~/var/log$ From alon.barlev at gmail.com Thu Jun 28 16:52:59 2007 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Thu, 28 Jun 2007 17:52:59 +0300 Subject: Broken pipe? [was: Problems svn+ssh+gpg(-agent)+smartcard] In-Reply-To: <4683BC7E.9030207@free.fr> References: <467FE61A.6050000@free.fr> <46800621.1060509@freecharity.org.uk> <4680D026.5020000@free.fr> <4680D1F3.803@freecharity.org.uk> <4683BC7E.9030207@free.fr> Message-ID: <9e0cf0bf0706280752t69bc1677l497099595db00e56@mail.gmail.com> On 6/28/07, Guillaume Yziquel wrote: > When failing to decrypt and failing to access the SCR 335 smartcard > reader, I get the logged output decribed below this message. > > It seems I have a broken pipe issue: > > > 2007-06-28 15:32:31 scdaemon[4291] DBG: ccid-driver: usb_claim_interface failed: -1 > > 2007-06-28 15:32:31 scdaemon[4291] error sending PC/SC OPEN request: Relais bris? (pipe) > > Any further information, help, guidance, hints, suggested readings is > welcome. Are you using a card that is capable of PKCS#11 interface? Alon. From maccrest at gmail.com Thu Jun 28 16:29:52 2007 From: maccrest at gmail.com (Crest) Date: Thu, 28 Jun 2007 16:29:52 +0200 Subject: decrypting many files to stdout In-Reply-To: <4dcea1d80706280124w4cc3c809o4fa308c9e1ffea9a@mail.gmail.com> References: <4dcea1d80706280124w4cc3c809o4fa308c9e1ffea9a@mail.gmail.com> Message-ID: <9EB9C0E9-A1B5-4DDD-8BDA-78D0D7213503@googlemail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Am 28.06.2007 um 10:24 schrieb Ken Takusagawa: > I have many files that are all encrypted with the same public key, and > the private key is protected with a passphrase. Is there a way that I > can decrypt all of them at once, concatenate the results and print it > all to standard output but only have to type my passphrase once? I'd > like to avoid having the decrypted files be written to disk, i.e., I'd > like "-d" behavior but with multiple files. man gpg # and search for --command-fd -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQIVAwUBRoPF4f950yjRhRAFAQpKJg//fNXNueR9A90WxcGpYFWmsOD6qbHSSVjJ bfxARWSRiuIHn61ZnOPJ4bC8wD+XOfUbR3uMtus1rP/BXn+N0SWDKe0Ahxz85vGQ Dim4HqCzkPBE09n0OHNr9KBmgXhefEbfWAZgoW3caW1O+n8p7MpAwPyMgVF+z3nx dys1+sskCRe43Akh3/fPBLE/awY8y7E9c7M5fBWB9clmNRkWB/wNlfObzucqUqjQ 0sSn5gJaGfdKvUtLhJO/Ns7SqENKIW8/gpSKQdXeuxVF0RPLYe8jxp/F20hoV53T V9WRa/fUaMISo1GEUif3sG1xhrj902tGfftm7cgtv024vgD71Fsaua0wIcsnXTuR TcXiF5fxQPAhXWQQuwn4NmZi9RCLN6jGILvD9G6vFtUA/Cn3+lHnSKhYOanp9ZE8 6XcVXNWFjg79wLDJd/TfiJmVsJvm8vFiFf7a8RETGQYyL+P/92RZRVa7F361aV7x FPHYUzGRenplAneh/b31VRjyFsK87Jcz0wqTilTLTGK5BpOKPeLKxwF4EoEiI80k 05G2pzl83V5wACTZFTWXXEImi9+wXSgEugL5I01ZE4N2VIzVaeKNLQsaK9nSa7Og i9mZYNm5yW7Wg3+0uApr79N6VbieWAqjUgNvmt5DCrpGrUcNdRHYuKbKidjXaCXX soazXUcq5No= =UBw5 -----END PGP SIGNATURE----- From Sucharitha.X.Panthika at chase.com Thu Jun 28 14:46:43 2007 From: Sucharitha.X.Panthika at chase.com (Sucharitha.X.Panthika at chase.com) Date: Thu, 28 Jun 2007 08:46:43 -0400 Subject: Gnupg RSA encryption with Bouncy Castle provider Message-ID: <576C22B3368703468CA4E8704A5F4D4F0FFDA7E4@swilnts812.wil.fusa.com> I have a problem reading the decrypted messages and the decryptStream.read() doesn't return me any bytes. See the code below that I used to encrypt data. I am writing data to file using the encryptStream returned by the following method. On the other hand when I write the content to the file with in the following method and later close all streams I can successfully decrypt the files. Has anyone used streaming with gpg using RSA successfully. If so, can any one share the information on how to do it. I created a key using RSA with 1024 bytes using gpg --gen-key and used addkey to add the sub key. I am using Bouncy Castle DataGenerators, Input and outputStreams to stream the output from program and writing the encrypted content to files. However the only way I could successfully decrypt files was when I open, write and close compression, encryption and literal streams in the same method. But for my needs I would like to return a encrypted stream and let that stream be used for writing various data to files. protected OutputStream encryptStream (String pPlainFilePath, boolean pAppend) throws IOException { //PGP Encryption Data Generator PGPEncryptedDataGenerator encryptedDataGen = null; //PGP Literal Data Generator PGPLiteralDataGenerator literalDataGen = null; //PGP Compressed Data Generator PGPCompressedDataGenerator compressedDataGen = null; //The outputstream associates with different data generator for encryption, compression and writing literal data. OutputStream encryptStream = null; OutputStream compressStream = null; OutputStream literalStream = null; //EncryptionDataGenerator opens this stream to create the encrypt stream. OutputStream outputStream = null; try { //PGPEncryption using SymmetricKey Algorithm CAST5 (128 bit key, as per RFC 2144), Configred Message IntegrityCheck, Random Number Genarator Algorithm SHA1PRNG with Bouncy Castle provider encryptedDataGen = new PGPEncryptedDataGenerator(getEncryptionAlgorithm(), isMessageIntegrityCheck(), SecureRandom.getInstance(getRNGAlgorithm()), PROVIDER_NAME); //Add a public key encrypted session key to the encrypted object encryptedDataGen.addMethod(getPublicKey()); String pEncFilePath = null; if ( isAsciiOutput() ) { pEncFilePath = pPlainFilePath + ".asc"; } else { pEncFilePath = pPlainFilePath + ".bpg"; } //Create a FileOutputStream for the file outputStream = new FileOutputStream(pEncFilePath, pAppend); //Use ArmoredOutputStream with base64 encoding if it is Ascii if ( isAsciiOutput() ) { outputStream = new ArmoredOutputStream(outputStream); } //Use EncryptiedDataGenerator to open an output stream to write the encrypted byes. encryptStream = encryptedDataGen.open(outputStream, new byte[ BYTE_ARRAY_SIZE ] ); compressedDataGen = new PGPCompressedDataGenerator(PGPCompressedData.BZIP2); compressStream = compressedDataGen.open(encryptStream, new byte[ BYTE_ARRAY_SIZE ]); literalDataGen = new PGPLiteralDataGenerator(true); literalStream = literalDataGen.open(compressStream, PGPLiteralData.BINARY, pEncFilePath, DateTools.getInstance().getSystemDate(), new byte[BYTE_ARRAY_SIZE]); } catch (PGPException e) { sLOGGER.error(e.getMessage(), e); if (e.getUnderlyingException() != null) { sLOGGER.error(e.getUnderlyingException()); } } catch (NoSuchProviderException e) { sLOGGER.error("No Such Provider named BC [BouncyCastle]" + e.getMessage(), e); } catch (NoSuchAlgorithmException e) { sLOGGER.error("No Such Algorithm [" + getRNGAlgorithm() + "]" + e.getMessage(), e); } finally { /*literalDataGen.close(); literalStream.close(); */ compressedDataGen.close(); compressStream.close(); encryptedDataGen.close(); encryptStream.close(); } return literalStream; //Encrypted and compressed outputstream } ----------------------------------------- This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. From Sucharitha.X.Panthika at chase.com Thu Jun 28 19:28:57 2007 From: Sucharitha.X.Panthika at chase.com (Sucharitha.X.Panthika at chase.com) Date: Thu, 28 Jun 2007 13:28:57 -0400 Subject: Gnupg RSA encryption with Bouncy Castle provider References: <576C22B3368703468CA4E8704A5F4D4F0FFDA7E4@swilnts812.wil.fusa.com> Message-ID: <576C22B3368703468CA4E8704A5F4D4F0FFDA7EA@swilnts812.wil.fusa.com> I have a problem reading the decrypted messages and the decryptStream.read() doesn't return me any bytes. See the code below that I used to encrypt data. I am writing data to file using the encryptStream returned by the following method. On the other hand when I write the content to the file with in the following method and later close all streams I can successfully decrypt the files. Has anyone used streaming with gpg using RSA successfully. If so, can any one share the information on how to do it. I created a key using RSA with 1024 bytes using gpg --gen-key and used addkey to add the sub key. I am using Bouncy Castle DataGenerators, Input and outputStreams to stream the output from program and writing the encrypted content to files. However the only way I could successfully decrypt files was when I open, write and close compression, encryption and literal streams in the same method. But for my needs I would like to return a encrypted stream and let that stream be used for writing various data to files. protected OutputStream encryptStream (String pPlainFilePath, boolean pAppend) throws IOException { //PGP Encryption Data Generator PGPEncryptedDataGenerator encryptedDataGen = null; //PGP Literal Data Generator PGPLiteralDataGenerator literalDataGen = null; //PGP Compressed Data Generator PGPCompressedDataGenerator compressedDataGen = null; //The outputstream associates with different data generator for encryption, compression and writing literal data. OutputStream encryptStream = null; OutputStream compressStream = null; OutputStream literalStream = null; //EncryptionDataGenerator opens this stream to create the encrypt stream. OutputStream outputStream = null; try { //PGPEncryption using SymmetricKey Algorithm CAST5 (128 bit key, as per RFC 2144), Configred Message IntegrityCheck, Random Number Genarator Algorithm SHA1PRNG with Bouncy Castle provider encryptedDataGen = new PGPEncryptedDataGenerator(getEncryptionAlgorithm(), isMessageIntegrityCheck(), SecureRandom.getInstance(getRNGAlgorithm()), PROVIDER_NAME); //Add a public key encrypted session key to the encrypted object encryptedDataGen.addMethod(getPublicKey()); String pEncFilePath = null; if ( isAsciiOutput() ) { pEncFilePath = pPlainFilePath + ".asc"; } else { pEncFilePath = pPlainFilePath + ".bpg"; } //Create a FileOutputStream for the file outputStream = new FileOutputStream(pEncFilePath, pAppend); //Use ArmoredOutputStream with base64 encoding if it is Ascii if ( isAsciiOutput() ) { outputStream = new ArmoredOutputStream(outputStream); } //Use EncryptiedDataGenerator to open an output stream to write the encrypted byes. encryptStream = encryptedDataGen.open(outputStream, new byte[ BYTE_ARRAY_SIZE ] ); compressedDataGen = new PGPCompressedDataGenerator(PGPCompressedData.BZIP2); compressStream = compressedDataGen.open(encryptStream, new byte[ BYTE_ARRAY_SIZE ]); literalDataGen = new PGPLiteralDataGenerator(true); literalStream = literalDataGen.open(compressStream, PGPLiteralData.BINARY, pEncFilePath, DateTools.getInstance().getSystemDate(), new byte[BYTE_ARRAY_SIZE]); } catch (PGPException e) { sLOGGER.error(e.getMessage(), e); if (e.getUnderlyingException() != null) { sLOGGER.error(e.getUnderlyingException()); } } catch (NoSuchProviderException e) { sLOGGER.error("No Such Provider named BC [BouncyCastle]" + e.getMessage(), e); } catch (NoSuchAlgorithmException e) { sLOGGER.error("No Such Algorithm [" + getRNGAlgorithm() + "]" + e.getMessage(), e); } finally { /*literalDataGen.close(); literalStream.close(); */ compressedDataGen.close(); compressStream.close(); encryptedDataGen.close(); encryptStream.close(); } return literalStream; //Encrypted and compressed outputstream } ----------------------------------------- This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. From kloecker at kde.org Thu Jun 28 22:24:46 2007 From: kloecker at kde.org (Ingo =?iso-8859-1?q?Kl=F6cker?=) Date: Thu, 28 Jun 2007 22:24:46 +0200 Subject: decrypting many files to stdout In-Reply-To: <4dcea1d80706280124w4cc3c809o4fa308c9e1ffea9a@mail.gmail.com> References: <4dcea1d80706280124w4cc3c809o4fa308c9e1ffea9a@mail.gmail.com> Message-ID: <200706282224.48954@erwin.ingo-kloecker.de> On Thursday 28 June 2007 10:24, Ken Takusagawa wrote: > I have many files that are all encrypted with the same public key, > and the private key is protected with a passphrase. Is there a way > that I can decrypt all of them at once, concatenate the results and > print it all to standard output but only have to type my passphrase > once? I'd like to avoid having the decrypted files be written to > disk, i.e., I'd like "-d" behavior but with multiple files. I suggest using gpg-agent for caching the passphrase. Then you only have to enter it once as long as gpg-agent is running and the cache-ttl is not expired. Use the following command line for starting gpg-agent (you probably want to use a shorter ttl than 3600 seconds aka 1 hour). eval "$(gpg-agent --daemon --default-cache-ttl 3600)" Then decrypt all files with a simple for-loop. Afterwards you might want to kill gpg-agent. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20070628/0ff088f7/attachment.pgp From wk at gnupg.org Fri Jun 29 10:25:33 2007 From: wk at gnupg.org (Werner Koch) Date: Fri, 29 Jun 2007 10:25:33 +0200 Subject: Broken pipe? In-Reply-To: <4683BC7E.9030207@free.fr> (Guillaume Yziquel's message of "Thu, 28 Jun 2007 15:49:50 +0200") References: <467FE61A.6050000@free.fr> <46800621.1060509@freecharity.org.uk> <4680D026.5020000@free.fr> <4680D1F3.803@freecharity.org.uk> <4683BC7E.9030207@free.fr> Message-ID: <87ved7b20y.fsf@wheatstone.g10code.de> On Thu, 28 Jun 2007 15:49, guillaume.yziquel at free.fr said: >> 2007-06-28 15:32:31 scdaemon[4291] DBG: ccid-driver: usb_claim_interface failed: -1 You have the pcscd running. "/etc/init.d/pcscd stop" will help. Disable pcscd unless you need it for other applications. >> 2007-06-28 15:32:31 scdaemon[4291] error sending PC/SC OPEN request: Relais bris? (pipe) /usr/local/lib/gnupg/pcsc-wrapper has a problem. Might be a problem withy libpcsc. Would need debugging (kill scdaemon, run scdaemon --server under strace -f to see what is going on). I am pretty sure that stopping pcscd solves your problems. Also make sure that the permissions for /proc/bus/usb/xxxx/nnn for your device are okay (you need write permissions). Salam-Shalom, Werner From hhhobbit at securemecca.net Fri Jun 29 10:15:21 2007 From: hhhobbit at securemecca.net (Henry Hertz Hobbit) Date: Fri, 29 Jun 2007 02:15:21 -0600 Subject: decrypting many files to stdout In-Reply-To: References: Message-ID: <4684BF99.1000806@securemecca.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Crest wrote: > Ken Takusagawa wrote: > >> I have many files that are all encrypted with the same public key, and >> the private key is protected with a passphrase. Is there a way that I >> can decrypt all of them at once, concatenate the results and print it >> all to standard output but only have to type my passphrase once? I'd >> like to avoid having the decrypted files be written to disk, i.e., I'd >> like "-d" behavior but with multiple files. > > man gpg # and search for --command-fd DETAILS PLEASE! I did, and tried to use the --multifile before that. When I looked for command-fd in the doc/DETAILS as promised by the man page it wasn't there. A search for how to use it on Google wasn't all that useful either. Now the following code will get you part way towards where you want to go (maybe). It is also available here (with srm code): http://www.securemecca.com/Crypto.tbz http://www.securemecca.com/Crypto.tbz.sig http://www.securemecca.com/Crypto.7z http://www.securemecca.com/Crypto.7z.sig For now they are signed with public key 5BA96FAC. Here is the script: - ------------------------------------------------------------------------ #!/bin/bash # What this script does is decrypt multiple publicly # encrypted files and concatenate all the files together # into one file. Optionally, you can print the file. The # order in which the files are in the output file is set # by where you put them in the cryptfiles file list. # # WARNING # There are so many things wrong with this shell script from a # security standpoint that I will not claim it. That holds for # who ever I am. Will somebody provide a better shell script # please? # # The /bin/sh designator does not always mean you are using the # Bourne shell. Most Linux systems do not have the Bourne shell # becuase all they have is BASH. Just make sure you don't have # any history going out of here. if test "$#" -eq 0 then echo echo usage: decryptNcat.sh OUTPUT_FILE_NAME echo exit fi OUTPUTFILE=$1 SAVEHISTSIZE=${HISTSIZE} HISTSIZE=0 export HISTSIZE if [ ! -s cryptfiles ] then echo put crypted files in a list in files cryptfiles echo with one file per line and make sure they are in echo the order you want them in. exit 1 fi rm -f ${OUTPUTFILE} touch ${OUTPUTFILE} echo -n what is the passphrase:\ \ read PASSPHRASE clear echo cat cryptfiles | while read FILE do if [ -s ${FILE} ] then gpg --list-packets --list-only ${FILE} > testforkey if grep -iq pubkey testforkey then echo adding file ${FILE} to the ${OUTPUTFILE} file echo gpg -q -d --passphrase ${PASSPHRASE} < ${FILE} \ >> ${OUTPUT_FILE} 2> /dev/null else echo file ${FILE} may not bea valid OpenPGP file echo skipping it echo fi else echo file ${FILE} either does not exist or is empty echo skipping it echo fi rm -f testforkey done PASSPHRASE=BOGUS export PASSPHRASE PASSPHRASE=BOGUS # Uncomment the following and substitute your commands to print # the file and then securely remove the file # if lp -q 100 ${OUTPUTFILE} # then # sleep 60 # srm ${OUTPUTFILE} # fi HISTSIZE=${SAVEHISTSIZE} export HISTSIZE exit - ------------------------------------------------------------------------ So what is wrong with it? 1. It is dangerous. - your secret pass-phrase is in a SHELL variable!? - worries about history - where has the Bourne shell gone? - pass-phrase is visible; use LCD; if you must use CRT do it so nobody can read it with RF sensors; make sure nobody is looking over your shoulder. - etcetera, etcetera, etcetera - you fill em in 2. It is inefficient. - cat cryptfiles | while read FILE ... - gpg -q -d --passphrase ${PASSPHRASE} < ${FILE} \ >> output 2> /dev/null - etcetera 3. It only gets you part way there. Ken wanted it to go to the printer, not a file. Yes, he can print the file and use srm on it to securely remove it but what if somebody hacks in or is in from the internet and steals the file in the process? So what is right with it? 1. You only type the pass-phrase once. Repetition of key things kills you - look at history. At least we aren't repeating the typing of our secret pass-phrase. 2. Modify the script to decrypt multiple files into separate files as they come in from remote sites. At least the sending is sort of automated by automatic encryption on the sending end. 4. IT WORKS! Well, sorta ... Now if you can flesh in the details on how to use command-fd or command-file options we are all ears. This script is NOT what Ken is looking for. But maybe, just maybe, it will give him some ideas. HHH -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGhL+Zr3QZv1upb6wRCoOMAKCex2sg9LEenWNeRtqVcpYPwvO7cQCgj0oG LiciRmk9vuWvJvum10DkxG8= =FeNJ -----END PGP SIGNATURE----- From wk at gnupg.org Fri Jun 29 10:31:06 2007 From: wk at gnupg.org (Werner Koch) Date: Fri, 29 Jun 2007 10:31:06 +0200 Subject: decrypting many files to stdout In-Reply-To: <200706282224.48954@erwin.ingo-kloecker.de> ("Ingo =?utf-8?Q?Kl=C3=B6cker=22's?= message of "Thu, 28 Jun 2007 22:24:46 +0200") References: <4dcea1d80706280124w4cc3c809o4fa308c9e1ffea9a@mail.gmail.com> <200706282224.48954@erwin.ingo-kloecker.de> Message-ID: <87r6nvb1rp.fsf@wheatstone.g10code.de> On Thu, 28 Jun 2007 22:24, kloecker at kde.org said: > eval "$(gpg-agent --daemon --default-cache-ttl 3600)" > > Then decrypt all files with a simple for-loop. Afterwards you might want > to kill gpg-agent. If you don't want gpg-agent to start with your session, it is easier to run it this way: gpg-agent --daemon --default-cache-ttl 3600 /bin/sh This invokes a new shell with everything setup for using gpg-agent. After you are finished you can simply give an "exit". The cache TTL is measured in seconds; without the option you get 10 minutes. Shalom-Salam, Werner From guillaume.yziquel at free.fr Fri Jun 29 11:04:54 2007 From: guillaume.yziquel at free.fr (Guillaume Yziquel) Date: Fri, 29 Jun 2007 11:04:54 +0200 Subject: Broken pipe? [was: Problems svn+ssh+gpg(-agent)+smartcard] In-Reply-To: <9e0cf0bf0706280752t69bc1677l497099595db00e56@mail.gmail.com> References: <467FE61A.6050000@free.fr> <46800621.1060509@freecharity.org.uk> <4680D026.5020000@free.fr> <4680D1F3.803@freecharity.org.uk> <4683BC7E.9030207@free.fr> <9e0cf0bf0706280752t69bc1677l497099595db00e56@mail.gmail.com> Message-ID: <4684CB36.1030005@free.fr> Alon Bar-Lev a ?crit : > On 6/28/07, Guillaume Yziquel wrote: >> When failing to decrypt and failing to access the SCR 335 smartcard >> reader, I get the logged output decribed below this message. >> >> It seems I have a broken pipe issue: >> >> > 2007-06-28 15:32:31 scdaemon[4291] DBG: ccid-driver: >> usb_claim_interface failed: -1 >> > 2007-06-28 15:32:31 scdaemon[4291] error sending PC/SC OPEN request: >> Relais bris? (pipe) >> >> Any further information, help, guidance, hints, suggested readings is >> welcome. > > Are you using a card that is capable of PKCS#11 interface? > > Alon. I'm reading through the GnuPG 2.0 manual, in .pdf version, available from http://www.gnupg.org/(en)/documentation/manuals.html (I really do appreciate page 113 of this .pdf file.) What I know is that it is an OpenPGP card. I've read http://gnupg-pkcs11.sourceforge.net/ and I'm quite positive that it's not using a PKCS#11 interface. I think that the problem is that no card-reader seems recognized. I'd be glad if it was only a smartcard protocol problem. Maybe the following helps: > yziquel at seldon:~$ echo scd getinfo reader_list | gpg-connect-agent --verbose --decode > gpg-connect-agent: connection to agent established > ERR 100663576 IPC parameter error > gpg-connect-agent: closing connection to agent Where do I get details about error codes? In the manual, it is written: > --pcsc-driver library > Use library to access the smartcard reader. The current default is > libpcsclite.so. Instead of using this option you might also want to > install a symbolic link to the default file name (e.g. from > libpcsclite.so.1). and I was rather surprised by that: do you still need libpcsclite.so.xxx to run the builtin ccid driver? Because I removed these file through aptitude. Because I've got the following complaint: > yziquel at seldon:~$ gpg --card-status > gpg: apdu_open_reader: failed to open driver `libpcsclite.so.1': libpcsclite.so.1: Ne peut ouvrir le fichier d'objet partag?: Aucun fichier ou r?pertoire de ce type > gpg: card reader not available > gpg: OpenPGP card not available: general error > yziquel at seldon:~$ I'll try to connect directly to scdaemon to see what is happening. Thanks. Guillaume. From guillaume.yziquel at free.fr Fri Jun 29 11:38:52 2007 From: guillaume.yziquel at free.fr (Guillaume Yziquel) Date: Fri, 29 Jun 2007 11:38:52 +0200 Subject: Broken pipe? In-Reply-To: <87ved7b20y.fsf@wheatstone.g10code.de> References: <467FE61A.6050000@free.fr> <46800621.1060509@freecharity.org.uk> <4680D026.5020000@free.fr> <4680D1F3.803@freecharity.org.uk> <4683BC7E.9030207@free.fr> <87ved7b20y.fsf@wheatstone.g10code.de> Message-ID: <4684D32C.7050406@free.fr> Werner Koch a ?crit : > On Thu, 28 Jun 2007 15:49, guillaume.yziquel at free.fr said: > >>> 2007-06-28 15:32:31 scdaemon[4291] DBG: ccid-driver: usb_claim_interface failed: -1 > > You have the pcscd running. "/etc/init.d/pcscd stop" will help. > Disable pcscd unless you need it for other applications. I've already purged pcsc with aptitude. And I still get the same messages: (Logging with option debug-level advanced and debug-ccid-driver) > yziquel at seldon:~$ tail -50 var/log/scdaemon.log > 2007-06-29 11:23:13 scdaemon[7486] SIGTERM received - shutting down ... > scdaemon[7486.0] DBG: <- [EOF] > 2007-06-29 11:23:13 scdaemon[7486] handler for fd -1 terminated > 2007-06-29 11:23:15 scdaemon[7486] scdaemon (GnuPG) 2.0.0 stopped > 2007-06-29 11:27:44 scdaemon[4321] listening on socket `/tmp/gpg-GyL8LI/S.scdaemon' > 2007-06-29 11:27:44 scdaemon[4321] handler for fd -1 started > 2007-06-29 11:27:44 scdaemon[4321] DBG: ccid-driver: using CCID reader 0 (ID=04E6:5115:X:0) > 2007-06-29 11:27:44 scdaemon[4321] DBG: ccid-driver: idVendor: 04E6 idProduct: 5115 bcdDevice: 0518 > 2007-06-29 11:27:44 scdaemon[4321] DBG: ccid-driver: ChipCard Interface Descriptor: > 2007-06-29 11:27:44 scdaemon[4321] DBG: ccid-driver: bLength 54 > 2007-06-29 11:27:44 scdaemon[4321] DBG: ccid-driver: bDescriptorType 33 > 2007-06-29 11:27:44 scdaemon[4321] DBG: ccid-driver: bcdCCID 1.00 > 2007-06-29 11:27:44 scdaemon[4321] DBG: ccid-driver: nMaxSlotIndex 0 > 2007-06-29 11:27:44 scdaemon[4321] DBG: ccid-driver: bVoltageSupport 1 5.0V > 2007-06-29 11:27:44 scdaemon[4321] DBG: ccid-driver: dwProtocols 3 T=0 T=1 > 2007-06-29 11:27:44 scdaemon[4321] DBG: ccid-driver: dwDefaultClock 4000 > 2007-06-29 11:27:44 scdaemon[4321] DBG: ccid-driver: dwMaxiumumClock 12000 > 2007-06-29 11:27:44 scdaemon[4321] DBG: ccid-driver: bNumClockSupported 0 > 2007-06-29 11:27:44 scdaemon[4321] DBG: ccid-driver: dwDataRate 9600 bps > 2007-06-29 11:27:44 scdaemon[4321] DBG: ccid-driver: dwMaxDataRate 307200 bps > 2007-06-29 11:27:44 scdaemon[4321] DBG: ccid-driver: bNumDataRatesSupp. 0 > 2007-06-29 11:27:44 scdaemon[4321] DBG: ccid-driver: dwMaxIFSD 252 > 2007-06-29 11:27:44 scdaemon[4321] DBG: ccid-driver: dwSyncProtocols 00000000 > 2007-06-29 11:27:44 scdaemon[4321] DBG: ccid-driver: dwMechanical 00000000 > 2007-06-29 11:27:44 scdaemon[4321] DBG: ccid-driver: dwFeatures 000100BA > 2007-06-29 11:27:44 scdaemon[4321] DBG: ccid-driver: Auto configuration based on ATR > 2007-06-29 11:27:44 scdaemon[4321] DBG: ccid-driver: Auto voltage selection > 2007-06-29 11:27:44 scdaemon[4321] DBG: ccid-driver: Auto clock change > 2007-06-29 11:27:44 scdaemon[4321] DBG: ccid-driver: Auto baud rate change > 2007-06-29 11:27:44 scdaemon[4321] DBG: ccid-driver: Auto PPS made by CCID > 2007-06-29 11:27:44 scdaemon[4321] DBG: ccid-driver: TPDU level exchange > 2007-06-29 11:27:44 scdaemon[4321] DBG: ccid-driver: dwMaxCCIDMsgLen 263 > 2007-06-29 11:27:44 scdaemon[4321] DBG: ccid-driver: bClassGetResponse echo > 2007-06-29 11:27:44 scdaemon[4321] DBG: ccid-driver: bClassEnvelope echo > 2007-06-29 11:27:44 scdaemon[4321] DBG: ccid-driver: wlcdLayout none > 2007-06-29 11:27:44 scdaemon[4321] DBG: ccid-driver: bPINSupport 0 > 2007-06-29 11:27:44 scdaemon[4321] DBG: ccid-driver: bMaxCCIDBusySlots 1 > 2007-06-29 11:27:44 scdaemon[4321] DBG: ccid-driver: usb_claim_interface failed: -1 > 2007-06-29 11:27:44 scdaemon[4321] error receiving PC/SC OPEN response: premature EOF > scdaemon[4321.0] DBG: -> OK GNU Privacy Guard's Smartcard server ready > scdaemon[4321.0] DBG: <- GETINFO socket_name > scdaemon[4321.0] DBG: -> D /tmp/gpg-GyL8LI/S.scdaemon > scdaemon[4321.0] DBG: -> OK > scdaemon[4321.0] DBG: <- OPTION event-signal=12 > scdaemon[4321.0] DBG: -> OK > scdaemon[4321.0] DBG: <- SERIALNO openpgp > 2007-06-29 11:27:44 scdaemon[4321] can't select application `openpgp': Non support? > scdaemon[4321.0] DBG: -> ERR 100663356 Non support? > scdaemon[4321.0] DBG: <- RESTART > scdaemon[4321.0] DBG: -> OK > yziquel at seldon:~$ Well instead of a broken pipe, I get a premature EOF... >>> 2007-06-28 15:32:31 scdaemon[4291] error sending PC/SC OPEN request: Relais bris? (pipe) > > /usr/local/lib/gnupg/pcsc-wrapper has a problem. Might be a problem > withy libpcsc. Would need debugging (kill scdaemon, run scdaemon > --server under strace -f to see what is going on). Uhh. I'll read how strace works, and I'll come back to you. > I am pretty sure that stopping pcscd solves your problems. Also make > sure that the permissions for /proc/bus/usb/xxxx/nnn for your device are > okay (you need write permissions). Visibly, purging pcscd does not solve the problem. Concerning permissions, I guess I have some work to do: > yziquel at seldon:~$ ls -Ral /proc/bus/usb/ > /proc/bus/usb/: > total 0 > drwxr-xr-x 5 root root 0 2007-06-29 11:24 . > dr-xr-xr-x 6 root root 0 2007-06-29 11:24 .. > dr-xr-xr-x 2 root root 0 2007-06-29 11:24 001 > dr-xr-xr-x 2 root root 0 2007-06-29 11:24 002 > dr-xr-xr-x 2 root root 0 2007-06-29 11:24 003 > -r--r--r-- 1 root root 0 2007-06-29 11:24 devices > > /proc/bus/usb/001: > total 0 > dr-xr-xr-x 2 root root 0 2007-06-29 11:24 . > drwxr-xr-x 5 root root 0 2007-06-29 11:24 .. > -rw-r--r-- 1 root root 43 2007-06-29 11:24 001 > > /proc/bus/usb/002: > total 0 > dr-xr-xr-x 2 root root 0 2007-06-29 11:24 . > drwxr-xr-x 5 root root 0 2007-06-29 11:24 .. > -rw-r--r-- 1 root root 43 2007-06-29 11:24 001 > > /proc/bus/usb/003: > total 0 > dr-xr-xr-x 2 root root 0 2007-06-29 11:24 . > drwxr-xr-x 5 root root 0 2007-06-29 11:24 .. > -rw-r--r-- 1 root root 43 2007-06-29 11:24 001 > -rw-r--r-- 1 root root 50 2007-06-29 11:24 002 > -rw-r--r-- 1 root root 111 2007-06-29 11:24 003 > yziquel at seldon:~$ Thanks, Werner. Guillaume. From marcus.brinkmann at ruhr-uni-bochum.de Fri Jun 29 12:13:31 2007 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Fri, 29 Jun 2007 12:13:31 +0200 Subject: [User Nocturnal] Problems with pthread when building gpgme. In-Reply-To: <87myyjb1ni.fsf@wheatstone.g10code.de> <20070627181328.GA53239@laptop.swehack.se> References: <87myyjb1ni.fsf@wheatstone.g10code.de> Message-ID: <87zm2j6pbo.wl%marcus.brinkmann@ruhr-uni-bochum.de> Hello, Please see: http://lists.gnupg.org/pipermail/gpa-dev/2007-February/002401.html and the other messages in that thread. At Wed, 27 Jun 2007 20:13:28 +0200, User Nocturnal wrote: > > Hi > > I have a few problems with building gpgme on FreeBSD 6.2-RELEASE with posix threads that come in FreeBSD base installed. > > Not sure if the Posix threads are causing problems but here is what happens when i run make after running the configure script with all defaults. > > if /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/local/include -I/usr/local/include/pth -I/usr/local/include/pth -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT ath-pthread.lo -MD -MP -MF ".deps/ath-pthread.Tpo" -c -o ath-pthread.lo ath-pthread.c; then mv -f ".deps/ath-pthread.Tpo" ".deps/ath-pthread.Plo"; else rm -f ".deps/ath-pthread.Tpo"; exit 1; fi > gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/local/include -I/usr/local/include/pth -I/usr/local/include/pth -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT ath-pthread.lo -MD -MP -MF .deps/ath-pthread.Tpo -c ath-pthread.c -fPIC -DPIC -o .libs/ath-pthread.o > In file included from ath-pthread.c:36: > /usr/local/include/pth/pthread.h:285: error: conflicting types for 'pthread_t' > /usr/include/sys/_pthreadtypes.h:64: error: previous declaration of 'pthread_t' was here > /usr/local/include/pth/pthread.h:286: error: conflicting types for 'pthread_attr_t' > /usr/include/sys/_pthreadtypes.h:65: error: previous declaration of 'pthread_attr_t' was here > /usr/local/include/pth/pthread.h:288: error: conflicting types for 'pthread_once_t' > /usr/include/sys/_pthreadtypes.h:71: error: previous declaration of 'pthread_once_t' was here > /usr/local/include/pth/pthread.h:289: error: conflicting types for 'pthread_mutexattr_t' > /usr/include/sys/_pthreadtypes.h:67: error: previous declaration of 'pthread_mutexattr_t' was here > /usr/local/include/pth/pthread.h:290: error: conflicting types for 'pthread_mutex_t' > /usr/include/sys/_pthreadtypes.h:66: error: previous declaration of 'pthread_mutex_t' was here > /usr/local/include/pth/pthread.h:291: error: conflicting types for 'pthread_condattr_t' > /usr/include/sys/_pthreadtypes.h:69: error: previous declaration of 'pthread_condattr_t' was here > /usr/local/include/pth/pthread.h:292: error: conflicting types for 'pthread_cond_t' > /usr/include/sys/_pthreadtypes.h:68: error: previous declaration of 'pthread_cond_t' was here > /usr/local/include/pth/pthread.h:293: error: conflicting types for 'pthread_rwlockattr_t' > /usr/include/sys/_pthreadtypes.h:73: error: previous declaration of 'pthread_rwlockattr_t' was here > /usr/local/include/pth/pthread.h:294: error: conflicting types for 'pthread_rwlock_t' > /usr/include/sys/_pthreadtypes.h:72: error: previous declaration of 'pthread_rwlock_t' was here > ath-pthread.c: In function `_gpgme_ath_connect': > ath-pthread.c:161: warning: passing arg 2 of `__pthread_connect' discards qualifiers from pointer target type > > I have GNU Portable Threads 2.0.7 installed in /usr/local/include/pth and /usr/local/lib/pth, these seem to be the paths that the Makefile uses by default for -I and -L arguments to gcc. > > > Med v?nliga h?lsningar > > Stefan Midjich aka nocturnal > http://swehack.se [SWEHACK] > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > From guillaume.yziquel at free.fr Fri Jun 29 13:44:58 2007 From: guillaume.yziquel at free.fr (Guillaume Yziquel) Date: Fri, 29 Jun 2007 13:44:58 +0200 Subject: Broken pipe? In-Reply-To: <87ved7b20y.fsf@wheatstone.g10code.de> References: <467FE61A.6050000@free.fr> <46800621.1060509@freecharity.org.uk> <4680D026.5020000@free.fr> <4680D1F3.803@freecharity.org.uk> <4683BC7E.9030207@free.fr> <87ved7b20y.fsf@wheatstone.g10code.de> Message-ID: <4684F0BA.9010203@free.fr> Werner Koch a ?crit : > On Thu, 28 Jun 2007 15:49, guillaume.yziquel at free.fr said: > > /usr/local/lib/gnupg/pcsc-wrapper has a problem. Might be a problem > withy libpcsc. Would need debugging (kill scdaemon, run scdaemon > --server under strace -f to see what is going on). I did run the scdaemon under strace, and I tried to post the output. But: > Your mail to 'Gnupg-users' with the subject > > Re: Broken pipe? > > Is being held until the list moderator can review it for approval. > > The reason it is being held: > > Message body is too big: 134467 bytes with a limit of 40 KB From hs2412 at gmail.com Sat Jun 30 11:12:49 2007 From: hs2412 at gmail.com (Hardeep Singh) Date: Sat, 30 Jun 2007 14:42:49 +0530 Subject: Converting ascii armored signature to cleartext In-Reply-To: <20070627011318.GA18469@jabberwocky.com> References: <87odj4z19c.fsf@wheatstone.g10code.de> <20070627011318.GA18469@jabberwocky.com> Message-ID: How do we do that? On 6/27/07, David Shaw wrote: > On Mon, Jun 25, 2007 at 02:06:55PM +0200, Werner Koch wrote: > > On Sun, 24 Jun 2007 12:07, hs2412 at gmail.com said: > > > > > If someone sends me an ASCII armoured file with some signed text, can > > > I convert it into cleartext sign so that I can display it to people > > > without GPG also? > > > > In general not because the canonicalization is different between the > > formats. A conversion would break the signature. > > Interestingly enough, while you can't always go from a signed file to > a clearsigned file, you can safely do the opposite of what the > original poster asked: converting from cleartext to a signed file > (armored or not) is possible. > > (I'm not sure when someone would want to do this, but...) > > David > -- Hardeep Singh From dshaw at jabberwocky.com Sat Jun 30 13:28:58 2007 From: dshaw at jabberwocky.com (David Shaw) Date: Sat, 30 Jun 2007 07:28:58 -0400 Subject: Converting ascii armored signature to cleartext In-Reply-To: References: <87odj4z19c.fsf@wheatstone.g10code.de> <20070627011318.GA18469@jabberwocky.com> Message-ID: <20070630112858.GA16020@jabberwocky.com> On Sat, Jun 30, 2007 at 02:42:49PM +0530, Hardeep Singh wrote: > On 6/27/07, David Shaw wrote: > > On Mon, Jun 25, 2007 at 02:06:55PM +0200, Werner Koch wrote: > > > On Sun, 24 Jun 2007 12:07, hs2412 at gmail.com said: > > > > > > > If someone sends me an ASCII armoured file with some signed text, can > > > > I convert it into cleartext sign so that I can display it to people > > > > without GPG also? > > > > > > In general not because the canonicalization is different between the > > > formats. A conversion would break the signature. > > > > Interestingly enough, while you can't always go from a signed file to > > a clearsigned file, you can safely do the opposite of what the > > original poster asked: converting from cleartext to a signed file > > (armored or not) is possible. > > > > (I'm not sure when someone would want to do this, but...) > How do we do that? You grab the signature from the clearsigned file, convert it to binary form, grab the text from the clearsigned file, package it inside a plaintext packet, and then just glue the two together. Something like this: 1. gpg --output text_part clearsigned_file 2. gpg --output sig_part.gpg --dearmor (now paste in the signature from the clearsigned file) ^D 3. Edit text_part and remove any whitespace at the end of each line, then remove the LAST (and only the last) message separator (CR, LF, etc). 4. gpg -z0 --textmode --store text_part 5. cat sig_part.gpg text_part.gpg > my_new_file.gpg Step 3 is the tricky bit, of course. Using a unix-ish system as an example, if the text file ends with "\n\n", you still only remove the last "\n". Step 5 makes a old-style signed file (you could make a new-style onepass signed file, but you'd need to create the onepass packet). It's an interesting side-effect of how the text canonicalization is done. The clearsigning rules are more strict than the regular signature rules, so it's possible to switch the packaging like this. David From m at riolenz.de Sat Jun 30 20:24:19 2007 From: m at riolenz.de (Mario Lenz) Date: Sat, 30 Jun 2007 20:24:19 +0200 Subject: getting signed text in plain Message-ID: <1183227859.3301.3.camel@etch> Hi @all! I'm trying to get the "plaintext" out of a signature, but without any success :-/ Here's a little bit of code to show you what I mean (I used a keyring without a password for testing so I don't need to gpgme_set_passphrase_cb): #include #include #include #include int main (int argc, char *argv[]) { gpgme_ctx_t ctx; gpgme_error_t err; gpgme_data_t plain, signed_text; char *agent_info, buffer[100]; ssize_t size; gpgme_check_version (NULL); err = gpgme_engine_check_version (GPGME_PROTOCOL_OpenPGP); if (err) exit (1); err = gpgme_new (&ctx); if (err) exit (2); err = gpgme_data_new_from_mem (&plain, "Hallo Leute\n", 13, 0); if (err) exit (3); err = gpgme_data_new (&signed_text); if (err) exit (4); err = gpgme_op_sign (ctx, plain, signed_text, GPGME_SIG_MODE_NORMAL); if (err) exit (5); gpgme_data_release (plain); err = gpgme_data_new (&plain); if (err) exit (6); gpgme_data_seek (signed_text, 0, SEEK_SET); err = gpgme_op_verify (ctx, signed_text, NULL, plain); if (err) exit (7); gpgme_data_seek (plain, 0, SEEK_SET); size = gpgme_data_read (plain, buffer, 100); if (size > 0) printf ("%s\n", buffer); else printf ("failed with size %d\n", size); gpgme_data_release (plain); gpgme_data_release (signed_text); gpgme_release (ctx); return 0; } Although verification doesn't fail, I'm unable to get the signed text out of plain. I've been trying this for some time now and wasn't able to make it work. Could you please help me? greez Mario PS I'm working on Debian Etch, but I linked the program above also against the latest gpgme version (1.1.4) and the problem stays. -- Rule One: Do not act incautiously when confronting little bald wrinkly smiling men. From guillaume.yziquel at free.fr Fri Jun 29 12:07:43 2007 From: guillaume.yziquel at free.fr (Guillaume Yziquel) Date: Fri, 29 Jun 2007 12:07:43 +0200 Subject: Broken pipe? In-Reply-To: <87ved7b20y.fsf@wheatstone.g10code.de> References: <467FE61A.6050000@free.fr> <46800621.1060509@freecharity.org.uk> <4680D026.5020000@free.fr> <4680D1F3.803@freecharity.org.uk> <4683BC7E.9030207@free.fr> <87ved7b20y.fsf@wheatstone.g10code.de> Message-ID: <4684D9EF.8090204@free.fr> Werner Koch a ?crit : >>> 2007-06-28 15:32:31 scdaemon[4291] error sending PC/SC OPEN request: Relais bris? (pipe) > > /usr/local/lib/gnupg/pcsc-wrapper has a problem. Might be a problem > withy libpcsc. Would need debugging (kill scdaemon, run scdaemon > --server under strace -f to see what is going on). I apologize for the weight of this message. OK. Here goes: > yziquel at seldon:~$ ps fauxw | grep -B1 scdaemon > yziquel 4082 0.0 0.1 13996 940 ? Ss 11:25 0:00 /usr/bin/gpg-agent --daemon --enable-ssh-support --sh --log-file /home/yziquel/var/log/gpg-agent.log --debug-level basic > yziquel 4321 0.0 0.1 18788 1440 ? SL 11:27 0:00 \_ scdaemon --multi-server And: > yziquel at seldon:~$ kill -SIGTERM 4321 Then: > yziquel at seldon:~$ strace -f scdaemon --multi-server 2&> scdaemon.strace There's the output: > execve("/usr/bin/scdaemon", ["scdaemon", "--multi-server", "2"], [/* 38 vars */]) = 0 > brk(0) = 0x53e000 > mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b4f237a7000 > uname({sys="Linux", node="seldon", ...}) = 0 > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) > mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b4f237a8000 > access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) > open("tls/x86_64/libgcrypt.so.11", O_RDONLY) = -1 ENOENT (No such file or directory) > open("tls/libgcrypt.so.11", O_RDONLY) = -1 ENOENT (No such file or directory) > open("x86_64/libgcrypt.so.11", O_RDONLY) = -1 ENOENT (No such file or directory) > open("libgcrypt.so.11", O_RDONLY) = -1 ENOENT (No such file or directory) > open("/emul/ia32-linux/usr/lib/tls/x86_64/libgcrypt.so.11", O_RDONLY) = -1 ENOENT (No such file or directory) > stat("/emul/ia32-linux/usr/lib/tls/x86_64", 0x7fff8731cd70) = -1 ENOENT (No such file or directory) > open("/emul/ia32-linux/usr/lib/tls/libgcrypt.so.11", O_RDONLY) = -1 ENOENT (No such file or directory) > stat("/emul/ia32-linux/usr/lib/tls", 0x7fff8731cd70) = -1 ENOENT (No such file or directory) > open("/emul/ia32-linux/usr/lib/x86_64/libgcrypt.so.11", O_RDONLY) = -1 ENOENT (No such file or directory) > stat("/emul/ia32-linux/usr/lib/x86_64", 0x7fff8731cd70) = -1 ENOENT (No such file or directory) > open("/emul/ia32-linux/usr/lib/libgcrypt.so.11", O_RDONLY) = 3 > read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 ?\0\000"..., 832) = 832 > close(3) = 0 > stat("/emul/ia32-linux/usr/lib", {st_mode=S_IFDIR|0755, st_size=12288, ...}) = 0 > open("/etc/ld.so.cache", O_RDONLY) = 3 > fstat(3, {st_mode=S_IFREG|0644, st_size=84990, ...}) = 0 > mmap(NULL, 84990, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2b4f237aa000 > close(3) = 0 > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) > open("/usr/lib/libgcrypt.so.11", O_RDONLY) = 3 > read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0pa\0\0\0"..., 832) = 832 > fstat(3, {st_mode=S_IFREG|0644, st_size=309744, ...}) = 0 > mmap(NULL, 1357440, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x2b4f237bf000 > mprotect(0x2b4f23809000, 1044480, PROT_NONE) = 0 > mmap(0x2b4f23908000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x49000) = 0x2b4f23908000 > close(3) = 0 > open("tls/x86_64/libgpg-error.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) > open("tls/libgpg-error.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) > open("x86_64/libgpg-error.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) > open("libgpg-error.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) > open("/emul/ia32-linux/usr/lib/libgpg-error.so.0", O_RDONLY) = 3 > read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220\6\0"..., 832) = 832 > close(3) = 0 > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) > open("/usr/lib/libgpg-error.so.0", O_RDONLY) = 3 > read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0 \t\0\0\0"..., 832) = 832 > fstat(3, {st_mode=S_IFREG|0644, st_size=13168, ...}) = 0 > mmap(NULL, 1060032, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x2b4f239a8000 > mprotect(0x2b4f239ab000, 1044480, PROT_NONE) = 0 > mmap(0x2b4f23aaa000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x2b4f23aaa000 > close(3) = 0 > open("tls/x86_64/libksba.so.8", O_RDONLY) = -1 ENOENT (No such file or directory) > open("tls/libksba.so.8", O_RDONLY) = -1 ENOENT (No such file or directory) > open("x86_64/libksba.so.8", O_RDONLY) = -1 ENOENT (No such file or directory) > open("libksba.so.8", O_RDONLY) = -1 ENOENT (No such file or directory) > open("/emul/ia32-linux/usr/lib/libksba.so.8", O_RDONLY) = -1 ENOENT (No such file or directory) > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) > open("/usr/lib/libksba.so.8", O_RDONLY) = 3 > read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0@\303\0\0"..., 832) = 832 > fstat(3, {st_mode=S_IFREG|0644, st_size=225232, ...}) = 0 > mmap(NULL, 1271952, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x2b4f23aab000 > mprotect(0x2b4f23adb000, 1044480, PROT_NONE) = 0 > mmap(0x2b4f23bda000, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2f000) = 0x2b4f23bda000 > close(3) = 0 > open("tls/x86_64/libpth.so.20", O_RDONLY) = -1 ENOENT (No such file or directory) > open("tls/libpth.so.20", O_RDONLY) = -1 ENOENT (No such file or directory) > open("x86_64/libpth.so.20", O_RDONLY) = -1 ENOENT (No such file or directory) > open("libpth.so.20", O_RDONLY) = -1 ENOENT (No such file or directory) > open("/emul/ia32-linux/usr/lib/libpth.so.20", O_RDONLY) = -1 ENOENT (No such file or directory) > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) > open("/usr/lib/libpth.so.20", O_RDONLY) = 3 > read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0 I\0\0\0"..., 832) = 832 > fstat(3, {st_mode=S_IFREG|0644, st_size=73568, ...}) = 0 > mmap(NULL, 1130448, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x2b4f23be2000 > mprotect(0x2b4f23bf3000, 1048576, PROT_NONE) = 0 > mmap(0x2b4f23cf3000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x11000) = 0x2b4f23cf3000 > mmap(0x2b4f23cf4000, 8144, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2b4f23cf4000 > close(3) = 0 > open("tls/x86_64/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) > open("tls/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) > open("x86_64/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) > open("libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) > open("/emul/ia32-linux/usr/lib/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) > open("/lib/libdl.so.2", O_RDONLY) = 3 > read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0 \16\0\0"..., 832) = 832 > fstat(3, {st_mode=S_IFREG|0644, st_size=14624, ...}) = 0 > mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b4f23cf6000 > mmap(NULL, 2109728, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x2b4f23cf7000 > mprotect(0x2b4f23cf9000, 2097152, PROT_NONE) = 0 > mmap(0x2b4f23ef9000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x2b4f23ef9000 > close(3) = 0 > open("tls/x86_64/libnsl.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) > open("tls/libnsl.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) > open("x86_64/libnsl.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) > open("libnsl.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) > open("/emul/ia32-linux/usr/lib/libnsl.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) > open("/lib/libnsl.so.1", O_RDONLY) = 3 > read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\320?\0\0"..., 832) = 832 > fstat(3, {st_mode=S_IFREG|0644, st_size=88960, ...}) = 0 > mmap(NULL, 2193776, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x2b4f23efb000 > mprotect(0x2b4f23f10000, 2093056, PROT_NONE) = 0 > mmap(0x2b4f2410f000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x14000) = 0x2b4f2410f000 > mmap(0x2b4f24111000, 6512, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2b4f24111000 > close(3) = 0 > open("tls/x86_64/libusb-0.1.so.4", O_RDONLY) = -1 ENOENT (No such file or directory) > open("tls/libusb-0.1.so.4", O_RDONLY) = -1 ENOENT (No such file or directory) > open("x86_64/libusb-0.1.so.4", O_RDONLY) = -1 ENOENT (No such file or directory) > open("libusb-0.1.so.4", O_RDONLY) = -1 ENOENT (No such file or directory) > open("/emul/ia32-linux/usr/lib/libusb-0.1.so.4", O_RDONLY) = -1 ENOENT (No such file or directory) > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) > open("/lib/libusb-0.1.so.4", O_RDONLY) = 3 > read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\31\0\0"..., 832) = 832 > fstat(3, {st_mode=S_IFREG|0644, st_size=32352, ...}) = 0 > mmap(NULL, 1079240, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x2b4f24113000 > mprotect(0x2b4f24119000, 1048576, PROT_NONE) = 0 > mmap(0x2b4f24219000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6000) = 0x2b4f24219000 > close(3) = 0 > open("tls/x86_64/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) > open("tls/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) > open("x86_64/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) > open("libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) > open("/emul/ia32-linux/usr/lib/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) > open("/lib/libc.so.6", O_RDONLY) = 3 > read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\331"..., 832) = 832 > fstat(3, {st_mode=S_IFREG|0755, st_size=1367464, ...}) = 0 > mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b4f2421b000 > mmap(NULL, 3473592, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x2b4f2421c000 > mprotect(0x2b4f24364000, 2093056, PROT_NONE) = 0 > mmap(0x2b4f24563000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x147000) = 0x2b4f24563000 > mmap(0x2b4f24568000, 16568, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2b4f24568000 > close(3) = 0 > mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b4f2456d000 > mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b4f2456e000 > arch_prctl(ARCH_SET_FS, 0x2b4f2456db00) = 0 > mprotect(0x2b4f24563000, 12288, PROT_READ) = 0 > munmap(0x2b4f237aa000, 84990) = 0 > brk(0) = 0x53e000 > brk(0x55f000) = 0x55f000 > open("/usr/lib/locale/locale-archive", O_RDONLY) = 3 > fstat(3, {st_mode=S_IFREG|0644, st_size=1919296, ...}) = 0 > mmap(NULL, 1919296, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2b4f2456f000 > close(3) = 0 > pipe([3, 4]) = 0 > fcntl(3, F_GETFL) = 0 (flags O_RDONLY) > fcntl(3, F_SETFL, O_RDONLY|O_NONBLOCK) = 0 > fcntl(4, F_GETFL) = 0x1 (flags O_WRONLY) > fcntl(4, F_SETFL, O_WRONLY|O_NONBLOCK) = 0 > gettimeofday({1183111443, 187482}, NULL) = 0 > gettimeofday({1183111443, 187617}, NULL) = 0 > rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 > gettimeofday({1183111443, 187865}, NULL) = 0 > rt_sigprocmask(SIG_SETMASK, [], [], 8) = 0 > rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], NULL, 8) = 0 > gettimeofday({1183111443, 188176}, NULL) = 0 > gettimeofday({1183111443, 188273}, NULL) = 0 > rt_sigprocmask(SIG_SETMASK, [], ~[KILL STOP RTMIN RT_1], 8) = 0 > getrlimit(RLIMIT_CORE, {rlim_cur=0, rlim_max=RLIM_INFINITY}) = 0 > setrlimit(RLIMIT_CORE, {rlim_cur=0, rlim_max=RLIM_INFINITY}) = 0 > mmap(NULL, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b4f24744000 > getuid() = 1000 > mlock(0x2b4f24744000, 16384) = 0 > geteuid() = 1000 > open("/home/yziquel/.gnupg/scdaemon.conf", O_RDONLY) = 5 > fstat(5, {st_mode=S_IFREG|0644, st_size=96, ...}) = 0 > mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b4f24748000 > read(5, "multi-server\nlog-file /home/yziq"..., 4096) = 96 > read(5, "", 4096) = 0 > close(5) = 0 > munmap(0x2b4f24748000, 4096) = 0 > open("/home/yziquel/var/log/scdaemon.log", O_WRONLY|O_APPEND|O_CREAT, 0666) = 5 > rt_sigaction(SIGPIPE, {SIG_IGN}, NULL, 8) = 0 > gettimeofday({1183111443, 194517}, NULL) = 0 > getpid() = 5785 > mkdir("/tmp/gpg-ejRM9J", 0700) = 0 > socket(PF_FILE, SOCK_STREAM, 0) = 6 > bind(6, {sa_family=AF_FILE, path="/tmp/gpg-ejRM9J/S.scdaemon"}, 29) = 0 > listen(6, 5) = 0 > getuid() = 1000 > geteuid() = 1000 > getgid() = 1000 > getegid() = 1000 > open("/usr/share/locale/locale.alias", O_RDONLY) = 7 > fstat(7, {st_mode=S_IFREG|0644, st_size=2582, ...}) = 0 > mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b4f24748000 > read(7, "# Locale name alias data base.\n#"..., 4096) = 2582 > read(7, "", 4096) = 0 > close(7) = 0 > munmap(0x2b4f24748000, 4096) = 0 > open("/usr/share/locale/fr_CH.UTF-8/LC_MESSAGES/gnupg2.mo", O_RDONLY) = -1 ENOENT (No such file or directory) > open("/usr/share/locale/fr_CH.utf8/LC_MESSAGES/gnupg2.mo", O_RDONLY) = -1 ENOENT (No such file or directory) > open("/usr/share/locale/fr_CH/LC_MESSAGES/gnupg2.mo", O_RDONLY) = -1 ENOENT (No such file or directory) > open("/usr/share/locale/fr.UTF-8/LC_MESSAGES/gnupg2.mo", O_RDONLY) = -1 ENOENT (No such file or directory) > open("/usr/share/locale/fr.utf8/LC_MESSAGES/gnupg2.mo", O_RDONLY) = -1 ENOENT (No such file or directory) > open("/usr/share/locale/fr/LC_MESSAGES/gnupg2.mo", O_RDONLY) = -1 ENOENT (No such file or directory) > time(NULL) = 1183111443 > open("/etc/localtime", O_RDONLY) = 7 > fstat(7, {st_mode=S_IFREG|0644, st_size=685, ...}) = 0 > fstat(7, {st_mode=S_IFREG|0644, st_size=685, ...}) = 0 > mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b4f24748000 > read(7, "TZif\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\4\0\0\0\4\0"..., 4096) = 685 > close(7) = 0 > munmap(0x2b4f24748000, 4096) = 0 > mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b4f24748000 > write(5, "2007-06-29 12:04:03 scdaemon[578"..., 84) = 84 > mmap(NULL, 528384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b4f2474a000 > gettimeofday({1183111443, 198653}, NULL) = 0 > rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 > rt_sigprocmask(SIG_UNBLOCK, [], NULL, 8) = 0 > rt_sigprocmask(SIG_UNBLOCK, [HUP INT USR1 USR2 TERM], NULL, 8) = 0 > gettimeofday({1183111443, 199059}, NULL) = 0 > select(1024, [6], NULL, NULL, {0, 0}) = 0 (Timeout) > rt_sigprocmask(SIG_SETMASK, ~[KILL STOP RTMIN RT_1], [], 8) = 0 > gettimeofday({1183111443, 199490}, NULL) = 0 > rt_sigpending([]) = 0 > read(3, 0x54f0d0, 128) = -1 EAGAIN (Resource temporarily unavailable) > rt_sigaction(SIGHUP, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGINT, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGUSR1, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGUSR2, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGTERM, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigprocmask(SIG_SETMASK, [], ~[KILL STOP RTMIN RT_1], 8) = 0 > select(1024, [3 6], [], [], {0, 0}) = 0 (Timeout) > rt_sigprocmask(SIG_SETMASK, ~[KILL STOP RTMIN RT_1], NULL, 8) = 0 > rt_sigaction(SIGHUP, {SIG_DFL}, NULL, 8) = 0 > rt_sigaction(SIGINT, {SIG_DFL}, NULL, 8) = 0 > rt_sigaction(SIGUSR1, {SIG_DFL}, NULL, 8) = 0 > rt_sigaction(SIGUSR2, {SIG_DFL}, NULL, 8) = 0 > rt_sigaction(SIGTERM, {SIG_DFL}, NULL, 8) = 0 > gettimeofday({1183111443, 201336}, NULL) = 0 > rt_sigprocmask(SIG_SETMASK, [], ~[KILL STOP RTMIN RT_1], 8) = 0 > time(NULL) = 1183111443 > write(5, "2007-06-29 12:04:03 scdaemon[578"..., 61) = 61 > open("/dev/bus/usb", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 7 > fstat(7, {st_mode=S_IFDIR|0755, st_size=100, ...}) = 0 > fcntl(7, F_SETFD, FD_CLOEXEC) = 0 > getdents64(7, /* 5 entries */, 4096) = 120 > close(7) = 0 > open("/dev/bus/usb", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 7 > fstat(7, {st_mode=S_IFDIR|0755, st_size=100, ...}) = 0 > fcntl(7, F_SETFD, FD_CLOEXEC) = 0 > getdents64(7, /* 5 entries */, 4096) = 120 > getdents64(7, /* 0 entries */, 4096) = 0 > close(7) = 0 > open("/dev/bus/usb/002", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 7 > fstat(7, {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0 > fcntl(7, F_SETFD, FD_CLOEXEC) = 0 > getdents64(7, /* 3 entries */, 4096) = 72 > open("/dev/bus/usb/002/001", O_RDWR) = -1 EACCES (Permission denied) > open("/dev/bus/usb/002/001", O_RDONLY) = 8 > ioctl(8, USBDEVFS_CONNECTINFO, 0x2b4f247c9b90) = -1 EPERM (Operation not permitted) > read(8, "\22\1\20\1\t\0\0@\0\0\0\0\6\2\3\2\1\1", 18) = 18 > read(8, "\t\2\31\0\1\1\0\340", 8) = 8 > read(8, "\0\t\4\0\0\1\t\0\0\0\7\5\201\3\2\0\377", 17) = 17 > close(8) = 0 > getdents64(7, /* 0 entries */, 4096) = 0 > close(7) = 0 > open("/dev/bus/usb/002/001", O_RDWR) = -1 EACCES (Permission denied) > open("/dev/bus/usb/002/001", O_RDONLY) = 7 > ioctl(7, USBDEVFS_IOCTL, 0x2b4f247c9b90) = -1 EPERM (Operation not permitted) > close(7) = 0 > open("/dev/bus/usb/003", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 7 > fstat(7, {st_mode=S_IFDIR|0755, st_size=100, ...}) = 0 > fcntl(7, F_SETFD, FD_CLOEXEC) = 0 > getdents64(7, /* 5 entries */, 4096) = 120 > open("/dev/bus/usb/003/003", O_RDWR) = -1 EACCES (Permission denied) > open("/dev/bus/usb/003/003", O_RDONLY) = 8 > ioctl(8, USBDEVFS_CONNECTINFO, 0x2b4f247c9b90) = -1 EPERM (Operation not permitted) > read(8, "\22\1\0\2\0\0\0\20\346\4\25Q\30\5\1\2\5\1", 18) = 18 > read(8, "\t\2]\0\1\1\3\240", 8) = 8 > read(8, "2\t\4\0\0\3\v\0\0\0046!\0\1\0\1\3\0\0\0\240\17\0\0\340"..., 85) = 85 > close(8) = 0 > open("/dev/bus/usb/003/002", O_RDWR) = 8 > ioctl(8, USBDEVFS_CONNECTINFO, 0x2b4f247c9b90) = 0 > read(8, "\22\1\20\1\377\377\377\10\377\10\200%#\6\0\1\0\1", 18) = 18 > read(8, "\t\2 \0\1\1\0\240", 8) = 8 > read(8, "2\t\4\0\0\2\377\377\377\0\7\5\201\2 \0\0\7\5\2\2\10\0\0"..., 24) = 24 > close(8) = 0 > open("/dev/bus/usb/003/001", O_RDWR) = -1 EACCES (Permission denied) > open("/dev/bus/usb/003/001", O_RDONLY) = 8 > ioctl(8, USBDEVFS_CONNECTINFO, 0x2b4f247c9b90) = -1 EPERM (Operation not permitted) > read(8, "\22\1\20\1\t\0\0@\0\0\0\0\6\2\3\2\1\1", 18) = 18 > read(8, "\t\2\31\0\1\1\0\340", 8) = 8 > read(8, "\0\t\4\0\0\1\t\0\0\0\7\5\201\3\2\0\377", 17) = 17 > close(8) = 0 > getdents64(7, /* 0 entries */, 4096) = 0 > close(7) = 0 > open("/dev/bus/usb/003/003", O_RDWR) = -1 EACCES (Permission denied) > open("/dev/bus/usb/003/003", O_RDONLY) = 7 > ioctl(7, USBDEVFS_IOCTL, 0x2b4f247c9b90) = -1 EPERM (Operation not permitted) > close(7) = 0 > open("/dev/bus/usb/003/002", O_RDWR) = 7 > ioctl(7, USBDEVFS_IOCTL, 0x2b4f247c9b90) = -1 ENOTTY (Inappropriate ioctl for device) > close(7) = 0 > open("/dev/bus/usb/003/001", O_RDWR) = -1 EACCES (Permission denied) > open("/dev/bus/usb/003/001", O_RDONLY) = 7 > ioctl(7, USBDEVFS_IOCTL, 0x2b4f247c9b90) = -1 EPERM (Operation not permitted) > close(7) = 0 > open("/dev/bus/usb/001", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 7 > fstat(7, {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0 > fcntl(7, F_SETFD, FD_CLOEXEC) = 0 > getdents64(7, /* 3 entries */, 4096) = 72 > open("/dev/bus/usb/001/001", O_RDWR) = -1 EACCES (Permission denied) > open("/dev/bus/usb/001/001", O_RDONLY) = 8 > ioctl(8, USBDEVFS_CONNECTINFO, 0x2b4f247c9b90) = -1 EPERM (Operation not permitted) > read(8, "\22\1\0\2\t\0\1@\0\0\0\0\6\2\3\2\1\1", 18) = 18 > read(8, "\t\2\31\0\1\1\0\340", 8) = 8 > read(8, "\0\t\4\0\0\1\t\0\0\0\7\5\201\3\2\0\f", 17) = 17 > close(8) = 0 > getdents64(7, /* 0 entries */, 4096) = 0 > close(7) = 0 > open("/dev/bus/usb/001/001", O_RDWR) = -1 EACCES (Permission denied) > open("/dev/bus/usb/001/001", O_RDONLY) = 7 > ioctl(7, USBDEVFS_IOCTL, 0x2b4f247c9b90) = -1 EPERM (Operation not permitted) > close(7) = 0 > open("/dev/bus/usb/003/003", O_RDWR) = -1 EACCES (Permission denied) > open("/dev/bus/usb/003/003", O_RDONLY) = 7 > ioctl(7, USBDEVFS_CONTROL, 0x2b4f247c9c00) = -1 EPERM (Operation not permitted) > open("/usr/share/locale/locale.alias", O_RDONLY) = 8 > fstat(8, {st_mode=S_IFREG|0644, st_size=2582, ...}) = 0 > mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b4f247cb000 > read(8, "# Locale name alias data base.\n#"..., 4096) = 2582 > read(8, "", 4096) = 0 > close(8) = 0 > munmap(0x2b4f247cb000, 4096) = 0 > open("/usr/share/locale/fr_CH.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) > open("/usr/share/locale/fr_CH.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) > open("/usr/share/locale/fr_CH/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) > open("/usr/share/locale/fr.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) > open("/usr/share/locale/fr.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) > open("/usr/share/locale/fr/LC_MESSAGES/libc.mo", O_RDONLY) = 8 > fstat(8, {st_mode=S_IFREG|0644, st_size=120888, ...}) = 0 > mmap(NULL, 120888, PROT_READ, MAP_PRIVATE, 8, 0) = 0x2b4f247cb000 > close(8) = 0 > open("/usr/lib/gconv/gconv-modules.cache", O_RDONLY) = 8 > fstat(8, {st_mode=S_IFREG|0644, st_size=25486, ...}) = 0 > mmap(NULL, 25486, PROT_READ, MAP_SHARED, 8, 0) = 0x2b4f247e9000 > close(8) = 0 > open("/usr/lib/gconv/ISO8859-1.so", O_RDONLY) = 8 > read(8, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\300\4\0"..., 832) = 832 > fstat(8, {st_mode=S_IFREG|0644, st_size=10200, ...}) = 0 > mmap(NULL, 2105392, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 8, 0) = 0x2b4f247f0000 > mprotect(0x2b4f247f2000, 2093056, PROT_NONE) = 0 > mmap(0x2b4f249f1000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 8, 0x1000) = 0x2b4f249f1000 > close(8) = 0 > brk(0x586000) = 0x586000 > ioctl(7, USBDEVFS_CONTROL, 0x2b4f247c9c00) = -1 EPERM (Operation not permitted) > time(NULL) = 1183111443 > write(5, "2007-06-29 12:04:03 scdaemon[578"..., 92) = 92 > time(NULL) = 1183111443 > write(5, "2007-06-29 12:04:03 scdaemon[578"..., 102) = 102 > time(NULL) = 1183111443 > write(5, "2007-06-29 12:04:03 scdaemon[578"..., 84) = 84 > time(NULL) = 1183111443 > write(5, "2007-06-29 12:04:03 scdaemon[578"..., 81) = 81 > time(NULL) = 1183111443 > write(5, "2007-06-29 12:04:03 scdaemon[578"..., 81) = 81 > time(NULL) = 1183111443 > write(5, "2007-06-29 12:04:03 scdaemon[578"..., 81) = 81 > time(NULL) = 1183111443 > write(5, "2007-06-29 12:04:03 scdaemon[578"..., 81) = 81 > time(NULL) = 1183111443 > write(5, "2007-06-29 12:04:03 scdaemon[578"..., 87) = 87 > time(NULL) = 1183111443 > write(5, "2007-06-29 12:04:03 scdaemon[578"..., 90) = 90 > time(NULL) = 1183111443 > write(5, "2007-06-29 12:04:03 scdaemon[578"..., 81) = 81 > time(NULL) = 1183111443 > write(5, "2007-06-29 12:04:03 scdaemon[578"..., 81) = 81 > time(NULL) = 1183111443 > write(5, "2007-06-29 12:04:03 scdaemon[578"..., 81) = 81 > time(NULL) = 1183111443 > write(5, "2007-06-29 12:04:03 scdaemon[578"..., 85) = 85 > time(NULL) = 1183111443 > write(5, "2007-06-29 12:04:03 scdaemon[578"..., 85) = 85 > time(NULL) = 1183111443 > write(5, "2007-06-29 12:04:03 scdaemon[578"..., 81) = 81 > time(NULL) = 1183111443 > write(5, "2007-06-29 12:04:03 scdaemon[578"..., 81) = 81 > time(NULL) = 1183111443 > write(5, "2007-06-29 12:04:03 scdaemon[578"..., 82) = 82 > time(NULL) = 1183111443 > write(5, "2007-06-29 12:04:03 scdaemon[578"..., 82) = 82 > time(NULL) = 1183111443 > write(5, "2007-06-29 12:04:03 scdaemon[578"..., 81) = 81 > time(NULL) = 1183111443 > write(5, "2007-06-29 12:04:03 scdaemon[578"..., 89) = 89 > time(NULL) = 1183111443 > write(5, "2007-06-29 12:04:03 scdaemon[578"..., 80) = 80 > time(NULL) = 1183111443 > write(5, "2007-06-29 12:04:03 scdaemon[578"..., 75) = 75 > time(NULL) = 1183111443 > write(5, "2007-06-29 12:04:03 scdaemon[578"..., 79) = 79 > time(NULL) = 1183111443 > write(5, "2007-06-29 12:04:03 scdaemon[578"..., 79) = 79 > time(NULL) = 1183111443 > write(5, "2007-06-29 12:04:03 scdaemon[578"..., 77) = 77 > time(NULL) = 1183111443 > write(5, "2007-06-29 12:04:03 scdaemon[578"..., 81) = 81 > time(NULL) = 1183111443 > write(5, "2007-06-29 12:04:03 scdaemon[578"..., 81) = 81 > time(NULL) = 1183111443 > write(5, "2007-06-29 12:04:03 scdaemon[578"..., 81) = 81 > time(NULL) = 1183111443 > write(5, "2007-06-29 12:04:03 scdaemon[578"..., 81) = 81 > time(NULL) = 1183111443 > write(5, "2007-06-29 12:04:03 scdaemon[578"..., 82) = 82 > time(NULL) = 1183111443 > write(5, "2007-06-29 12:04:03 scdaemon[578"..., 81) = 81 > ioctl(7, USBDEVFS_CLAIMINTERFACE, 0x2b4f247c9e2c) = -1 EPERM (Operation not permitted) > time(NULL) = 1183111443 > write(5, "2007-06-29 12:04:03 scdaemon[578"..., 84) = 84 > close(7) = 0 > access("/usr/lib/gnupg2/pcsc-wrapper", X_OK) = 0 > pipe([7, 8]) = 0 > pipe([9, 10]) = 0 > clone(Process 5786 attached (waiting for parent) > Process 5786 resumed (parent 5785 ready) > child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x2b4f2456db90) = 5786 > [pid 5785] close(9) = 0 > [pid 5785] close(8) = 0 > [pid 5785] wait4(5786, NULL, WNOHANG, NULL) = 0 > [pid 5785] gettimeofday({1183111443, 225697}, NULL) = 0 > [pid 5785] rt_sigprocmask(SIG_SETMASK, ~[KILL STOP RTMIN RT_1], [], 8) = 0 > [pid 5785] gettimeofday({1183111443, 225972}, NULL) = 0 > [pid 5785] rt_sigpending([]) = 0 > [pid 5785] read(3, 0x54f0d0, 128) = -1 EAGAIN (Resource temporarily unavailable) > [pid 5785] rt_sigaction(SIGHUP, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > [pid 5785] rt_sigaction(SIGINT, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > [pid 5785] rt_sigaction(SIGUSR1, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > [pid 5785] rt_sigaction(SIGUSR2, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > [pid 5785] rt_sigaction(SIGTERM, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > [pid 5785] rt_sigprocmask(SIG_SETMASK, [], ~[KILL STOP RTMIN RT_1], 8) = 0 > [pid 5785] select(1024, [3 6], [], [], {0, 249725} > [pid 5786] clone(Process 5787 attached (waiting for parent) > Process 5787 resumed (parent 5786 ready) > child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x2b4f2456db90) = 5787 > [pid 5786] exit_group(0) = ? > Process 5786 detached > [pid 5785] <... select resumed> ) = ? ERESTARTNOHAND (To be restarted) > [pid 5785] --- SIGCHLD (Child exited) @ 0 (0) --- > [pid 5785] select(1024, [3 6], [], [], {0, 249725} > [pid 5787] dup2(9, 0) = 0 > [pid 5787] dup2(8, 1) = 1 > [pid 5787] open("/dev/null", O_WRONLY) = 11 > [pid 5787] dup2(11, 2) = 2 > [pid 5787] getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=1024}) = 0 > [pid 5787] close(3) = 0 > [pid 5787] close(4) = 0 > [pid 5787] close(5) = 0 > [pid 5787] close(6) = 0 > [pid 5787] close(7) = 0 > [pid 5787] close(8) = 0 > [pid 5787] close(9) = 0 > [pid 5787] close(10) = 0 > [pid 5787] close(11) = 0 > [pid 5787] close(12) = -1 EBADF (Bad file descriptor) > [pid 5787] close(13) = -1 EBADF (Bad file descriptor) > [pid 5787] close(14) = -1 EBADF (Bad file descriptor) > [pid 5787] close(15) = -1 EBADF (Bad file descriptor) > [pid 5787] close(16) = -1 EBADF (Bad file descriptor) > [pid 5787] close(17) = -1 EBADF (Bad file descriptor) > [pid 5787] close(18) = -1 EBADF (Bad file descriptor) > [pid 5787] close(19) = -1 EBADF (Bad file descriptor) > [pid 5787] close(20) = -1 EBADF (Bad file descriptor) > [pid 5787] close(21) = -1 EBADF (Bad file descriptor) > [pid 5787] close(22) = -1 EBADF (Bad file descriptor) > [pid 5787] close(23) = -1 EBADF (Bad file descriptor) > [pid 5787] close(24) = -1 EBADF (Bad file descriptor) > [pid 5787] close(25) = -1 EBADF (Bad file descriptor) > [pid 5787] close(26) = -1 EBADF (Bad file descriptor) > [pid 5787] close(27) = -1 EBADF (Bad file descriptor) > [pid 5787] close(28) = -1 EBADF (Bad file descriptor) > [pid 5787] close(29) = -1 EBADF (Bad file descriptor) > [pid 5787] close(30) = -1 EBADF (Bad file descriptor) > [pid 5787] close(31) = -1 EBADF (Bad file descriptor) > [pid 5787] close(32) = -1 EBADF (Bad file descriptor) > [pid 5787] close(33) = -1 EBADF (Bad file descriptor) > [pid 5787] close(34) = -1 EBADF (Bad file descriptor) > [pid 5787] close(35) = -1 EBADF (Bad file descriptor) > [pid 5787] close(36) = -1 EBADF (Bad file descriptor) > [pid 5787] close(37) = -1 EBADF (Bad file descriptor) > [pid 5787] close(38) = -1 EBADF (Bad file descriptor) > [pid 5787] close(39) = -1 EBADF (Bad file descriptor) > [pid 5787] close(40) = -1 EBADF (Bad file descriptor) > [pid 5787] close(41) = -1 EBADF (Bad file descriptor) > [pid 5787] close(42) = -1 EBADF (Bad file descriptor) > [pid 5787] close(43) = -1 EBADF (Bad file descriptor) > [pid 5787] close(44) = -1 EBADF (Bad file descriptor) > [pid 5787] close(45) = -1 EBADF (Bad file descriptor) > [pid 5787] close(46) = -1 EBADF (Bad file descriptor) > [pid 5787] close(47) = -1 EBADF (Bad file descriptor) > [pid 5787] close(48) = -1 EBADF (Bad file descriptor) > [pid 5787] close(49) = -1 EBADF (Bad file descriptor) > [pid 5787] close(50) = -1 EBADF (Bad file descriptor) > [pid 5787] close(51) = -1 EBADF (Bad file descriptor) > [pid 5787] close(52) = -1 EBADF (Bad file descriptor) > [pid 5787] close(53) = -1 EBADF (Bad file descriptor) > [pid 5787] close(54) = -1 EBADF (Bad file descriptor) > [pid 5787] close(55) = -1 EBADF (Bad file descriptor) > [pid 5787] close(56) = -1 EBADF (Bad file descriptor) > [pid 5787] close(57) = -1 EBADF (Bad file descriptor) > [pid 5787] close(58) = -1 EBADF (Bad file descriptor) > [pid 5787] close(59) = -1 EBADF (Bad file descriptor) > [pid 5787] close(60) = -1 EBADF (Bad file descriptor) > [pid 5787] close(61) = -1 EBADF (Bad file descriptor) > [pid 5787] close(62) = -1 EBADF (Bad file descriptor) > [pid 5787] close(63) = -1 EBADF (Bad file descriptor) > [pid 5787] close(64) = -1 EBADF (Bad file descriptor) > [pid 5787] close(65) = -1 EBADF (Bad file descriptor) > [pid 5787] close(66) = -1 EBADF (Bad file descriptor) > [pid 5787] close(67) = -1 EBADF (Bad file descriptor) > [pid 5787] close(68) = -1 EBADF (Bad file descriptor) > [pid 5787] close(69) = -1 EBADF (Bad file descriptor) > [pid 5787] close(70) = -1 EBADF (Bad file descriptor) > [pid 5787] close(71) = -1 EBADF (Bad file descriptor) > [pid 5787] close(72) = -1 EBADF (Bad file descriptor) > [pid 5787] close(73) = -1 EBADF (Bad file descriptor) > [pid 5787] close(74) = -1 EBADF (Bad file descriptor) > [pid 5787] close(75) = -1 EBADF (Bad file descriptor) > [pid 5787] close(76) = -1 EBADF (Bad file descriptor) > [pid 5787] close(77) = -1 EBADF (Bad file descriptor) > [pid 5787] close(78) = -1 EBADF (Bad file descriptor) > [pid 5787] close(79) = -1 EBADF (Bad file descriptor) > [pid 5787] close(80) = -1 EBADF (Bad file descriptor) > [pid 5787] close(81) = -1 EBADF (Bad file descriptor) > [pid 5787] close(82) = -1 EBADF (Bad file descriptor) > [pid 5787] close(83) = -1 EBADF (Bad file descriptor) > [pid 5787] close(84) = -1 EBADF (Bad file descriptor) > [pid 5787] close(85) = -1 EBADF (Bad file descriptor) > [pid 5787] close(86) = -1 EBADF (Bad file descriptor) > [pid 5787] close(87) = -1 EBADF (Bad file descriptor) > [pid 5787] close(88) = -1 EBADF (Bad file descriptor) > [pid 5787] close(89) = -1 EBADF (Bad file descriptor) > [pid 5787] close(90) = -1 EBADF (Bad file descriptor) > [pid 5787] close(91) = -1 EBADF (Bad file descriptor) > [pid 5787] close(92) = -1 EBADF (Bad file descriptor) > [pid 5787] close(93) = -1 EBADF (Bad file descriptor) > [pid 5787] close(94) = -1 EBADF (Bad file descriptor) > [pid 5787] close(95) = -1 EBADF (Bad file descriptor) > [pid 5787] close(96) = -1 EBADF (Bad file descriptor) > [pid 5787] close(97) = -1 EBADF (Bad file descriptor) > [pid 5787] close(98) = -1 EBADF (Bad file descriptor) > [pid 5787] close(99) = -1 EBADF (Bad file descriptor) > [pid 5787] close(100) = -1 EBADF (Bad file descriptor) > [pid 5787] close(101) = -1 EBADF (Bad file descriptor) > [pid 5787] close(102) = -1 EBADF (Bad file descriptor) > [pid 5787] close(103) = -1 EBADF (Bad file descriptor) > [pid 5787] close(104) = -1 EBADF (Bad file descriptor) > [pid 5787] close(105) = -1 EBADF (Bad file descriptor) > [pid 5787] close(106) = -1 EBADF (Bad file descriptor) > [pid 5787] close(107) = -1 EBADF (Bad file descriptor) > [pid 5787] close(108) = -1 EBADF (Bad file descriptor) > [pid 5787] close(109) = -1 EBADF (Bad file descriptor) > [pid 5787] close(110) = -1 EBADF (Bad file descriptor) > [pid 5787] close(111) = -1 EBADF (Bad file descriptor) > [pid 5787] close(112) = -1 EBADF (Bad file descriptor) > [pid 5787] close(113) = -1 EBADF (Bad file descriptor) > [pid 5787] close(114) = -1 EBADF (Bad file descriptor) > [pid 5787] close(115) = -1 EBADF (Bad file descriptor) > [pid 5787] close(116) = -1 EBADF (Bad file descriptor) > [pid 5787] close(117) = -1 EBADF (Bad file descriptor) > [pid 5787] close(118) = -1 EBADF (Bad file descriptor) > [pid 5787] close(119) = -1 EBADF (Bad file descriptor) > [pid 5787] close(120) = -1 EBADF (Bad file descriptor) > [pid 5787] close(121) = -1 EBADF (Bad file descriptor) > [pid 5787] close(122) = -1 EBADF (Bad file descriptor) > [pid 5787] close(123) = -1 EBADF (Bad file descriptor) > [pid 5787] close(124) = -1 EBADF (Bad file descriptor) > [pid 5787] close(125) = -1 EBADF (Bad file descriptor) > [pid 5787] close(126) = -1 EBADF (Bad file descriptor) > [pid 5787] close(127) = -1 EBADF (Bad file descriptor) > [pid 5787] close(128) = -1 EBADF (Bad file descriptor) > [pid 5787] close(129) = -1 EBADF (Bad file descriptor) > [pid 5787] close(130) = -1 EBADF (Bad file descriptor) > [pid 5787] close(131) = -1 EBADF (Bad file descriptor) > [pid 5787] close(132) = -1 EBADF (Bad file descriptor) > [pid 5787] close(133) = -1 EBADF (Bad file descriptor) > [pid 5787] close(134) = -1 EBADF (Bad file descriptor) > [pid 5787] close(135) = -1 EBADF (Bad file descriptor) > [pid 5787] close(136) = -1 EBADF (Bad file descriptor) > [pid 5787] close(137) = -1 EBADF (Bad file descriptor) > [pid 5787] close(138) = -1 EBADF (Bad file descriptor) > [pid 5787] close(139) = -1 EBADF (Bad file descriptor) > [pid 5787] close(140) = -1 EBADF (Bad file descriptor) > [pid 5787] close(141) = -1 EBADF (Bad file descriptor) > [pid 5787] close(142) = -1 EBADF (Bad file descriptor) > [pid 5787] close(143) = -1 EBADF (Bad file descriptor) > [pid 5787] close(144) = -1 EBADF (Bad file descriptor) > [pid 5787] close(145) = -1 EBADF (Bad file descriptor) > [pid 5787] close(146) = -1 EBADF (Bad file descriptor) > [pid 5787] close(147) = -1 EBADF (Bad file descriptor) > [pid 5787] close(148) = -1 EBADF (Bad file descriptor) > [pid 5787] close(149) = -1 EBADF (Bad file descriptor) > [pid 5787] close(150) = -1 EBADF (Bad file descriptor) > [pid 5787] close(151) = -1 EBADF (Bad file descriptor) > [pid 5787] close(152) = -1 EBADF (Bad file descriptor) > [pid 5787] close(153) = -1 EBADF (Bad file descriptor) > [pid 5787] close(154) = -1 EBADF (Bad file descriptor) > [pid 5787] close(155) = -1 EBADF (Bad file descriptor) > [pid 5787] close(156) = -1 EBADF (Bad file descriptor) > [pid 5787] close(157) = -1 EBADF (Bad file descriptor) > [pid 5787] close(158) = -1 EBADF (Bad file descriptor) > [pid 5787] close(159) = -1 EBADF (Bad file descriptor) > [pid 5787] close(160) = -1 EBADF (Bad file descriptor) > [pid 5787] close(161) = -1 EBADF (Bad file descriptor) > [pid 5787] close(162) = -1 EBADF (Bad file descriptor) > [pid 5787] close(163) = -1 EBADF (Bad file descriptor) > [pid 5787] close(164) = -1 EBADF (Bad file descriptor) > [pid 5787] close(165) = -1 EBADF (Bad file descriptor) > [pid 5787] close(166) = -1 EBADF (Bad file descriptor) > [pid 5787] close(167) = -1 EBADF (Bad file descriptor) > [pid 5787] close(168) = -1 EBADF (Bad file descriptor) > [pid 5787] close(169) = -1 EBADF (Bad file descriptor) > [pid 5787] close(170) = -1 EBADF (Bad file descriptor) > [pid 5787] close(171) = -1 EBADF (Bad file descriptor) > [pid 5787] close(172) = -1 EBADF (Bad file descriptor) > [pid 5787] close(173) = -1 EBADF (Bad file descriptor) > [pid 5787] close(174) = -1 EBADF (Bad file descriptor) > [pid 5787] close(175) = -1 EBADF (Bad file descriptor) > [pid 5787] close(176) = -1 EBADF (Bad file descriptor) > [pid 5787] close(177) = -1 EBADF (Bad file descriptor) > [pid 5787] close(178) = -1 EBADF (Bad file descriptor) > [pid 5787] close(179) = -1 EBADF (Bad file descriptor) > [pid 5787] close(180) = -1 EBADF (Bad file descriptor) > [pid 5787] close(181) = -1 EBADF (Bad file descriptor) > [pid 5787] close(182) = -1 EBADF (Bad file descriptor) > [pid 5787] close(183) = -1 EBADF (Bad file descriptor) > [pid 5787] close(184) = -1 EBADF (Bad file descriptor) > [pid 5787] close(185) = -1 EBADF (Bad file descriptor) > [pid 5787] close(186) = -1 EBADF (Bad file descriptor) > [pid 5787] close(187) = -1 EBADF (Bad file descriptor) > [pid 5787] close(188) = -1 EBADF (Bad file descriptor) > [pid 5787] close(189) = -1 EBADF (Bad file descriptor) > [pid 5787] close(190) = -1 EBADF (Bad file descriptor) > [pid 5787] close(191) = -1 EBADF (Bad file descriptor) > [pid 5787] close(192) = -1 EBADF (Bad file descriptor) > [pid 5787] close(193) = -1 EBADF (Bad file descriptor) > [pid 5787] close(194) = -1 EBADF (Bad file descriptor) > [pid 5787] close(195) = -1 EBADF (Bad file descriptor) > [pid 5787] close(196) = -1 EBADF (Bad file descriptor) > [pid 5787] close(197) = -1 EBADF (Bad file descriptor) > [pid 5787] close(198) = -1 EBADF (Bad file descriptor) > [pid 5787] close(199) = -1 EBADF (Bad file descriptor) > [pid 5787] close(200) = -1 EBADF (Bad file descriptor) > [pid 5787] close(201) = -1 EBADF (Bad file descriptor) > [pid 5787] close(202) = -1 EBADF (Bad file descriptor) > [pid 5787] close(203) = -1 EBADF (Bad file descriptor) > [pid 5787] close(204) = -1 EBADF (Bad file descriptor) > [pid 5787] close(205) = -1 EBADF (Bad file descriptor) > [pid 5787] close(206) = -1 EBADF (Bad file descriptor) > [pid 5787] close(207) = -1 EBADF (Bad file descriptor) > [pid 5787] close(208) = -1 EBADF (Bad file descriptor) > [pid 5787] close(209) = -1 EBADF (Bad file descriptor) > [pid 5787] close(210) = -1 EBADF (Bad file descriptor) > [pid 5787] close(211) = -1 EBADF (Bad file descriptor) > [pid 5787] close(212) = -1 EBADF (Bad file descriptor) > [pid 5787] close(213) = -1 EBADF (Bad file descriptor) > [pid 5787] close(214) = -1 EBADF (Bad file descriptor) > [pid 5787] close(215) = -1 EBADF (Bad file descriptor) > [pid 5787] close(216) = -1 EBADF (Bad file descriptor) > [pid 5787] close(217) = -1 EBADF (Bad file descriptor) > [pid 5787] close(218) = -1 EBADF (Bad file descriptor) > [pid 5787] close(219) = -1 EBADF (Bad file descriptor) > [pid 5787] close(220) = -1 EBADF (Bad file descriptor) > [pid 5787] close(221) = -1 EBADF (Bad file descriptor) > [pid 5787] close(222) = -1 EBADF (Bad file descriptor) > [pid 5787] close(223) = -1 EBADF (Bad file descriptor) > [pid 5787] close(224) = -1 EBADF (Bad file descriptor) > [pid 5787] close(225) = -1 EBADF (Bad file descriptor) > [pid 5787] close(226) = -1 EBADF (Bad file descriptor) > [pid 5787] close(227) = -1 EBADF (Bad file descriptor) > [pid 5787] close(228) = -1 EBADF (Bad file descriptor) > [pid 5787] close(229) = -1 EBADF (Bad file descriptor) > [pid 5787] close(230) = -1 EBADF (Bad file descriptor) > [pid 5787] close(231) = -1 EBADF (Bad file descriptor) > [pid 5787] close(232) = -1 EBADF (Bad file descriptor) > [pid 5787] close(233) = -1 EBADF (Bad file descriptor) > [pid 5787] close(234) = -1 EBADF (Bad file descriptor) > [pid 5787] close(235) = -1 EBADF (Bad file descriptor) > [pid 5787] close(236) = -1 EBADF (Bad file descriptor) > [pid 5787] close(237) = -1 EBADF (Bad file descriptor) > [pid 5787] close(238) = -1 EBADF (Bad file descriptor) > [pid 5787] close(239) = -1 EBADF (Bad file descriptor) > [pid 5787] close(240) = -1 EBADF (Bad file descriptor) > [pid 5787] close(241) = -1 EBADF (Bad file descriptor) > [pid 5787] close(242) = -1 EBADF (Bad file descriptor) > [pid 5787] close(243) = -1 EBADF (Bad file descriptor) > [pid 5787] close(244) = -1 EBADF (Bad file descriptor) > [pid 5787] close(245) = -1 EBADF (Bad file descriptor) > [pid 5787] close(246) = -1 EBADF (Bad file descriptor) > [pid 5787] close(247) = -1 EBADF (Bad file descriptor) > [pid 5787] close(248) = -1 EBADF (Bad file descriptor) > [pid 5787] close(249) = -1 EBADF (Bad file descriptor) > [pid 5787] close(250) = -1 EBADF (Bad file descriptor) > [pid 5787] close(251) = -1 EBADF (Bad file descriptor) > [pid 5787] close(252) = -1 EBADF (Bad file descriptor) > [pid 5787] close(253) = -1 EBADF (Bad file descriptor) > [pid 5787] close(254) = -1 EBADF (Bad file descriptor) > [pid 5787] close(255) = -1 EBADF (Bad file descriptor) > [pid 5787] close(256) = -1 EBADF (Bad file descriptor) > [pid 5787] close(257) = -1 EBADF (Bad file descriptor) > [pid 5787] close(258) = -1 EBADF (Bad file descriptor) > [pid 5787] close(259) = -1 EBADF (Bad file descriptor) > [pid 5787] close(260) = -1 EBADF (Bad file descriptor) > [pid 5787] close(261) = -1 EBADF (Bad file descriptor) > [pid 5787] close(262) = -1 EBADF (Bad file descriptor) > [pid 5787] close(263) = -1 EBADF (Bad file descriptor) > [pid 5787] close(264) = -1 EBADF (Bad file descriptor) > [pid 5787] close(265) = -1 EBADF (Bad file descriptor) > [pid 5787] close(266) = -1 EBADF (Bad file descriptor) > [pid 5787] close(267) = -1 EBADF (Bad file descriptor) > [pid 5787] close(268) = -1 EBADF (Bad file descriptor) > [pid 5787] close(269) = -1 EBADF (Bad file descriptor) > [pid 5787] close(270) = -1 EBADF (Bad file descriptor) > [pid 5787] close(271) = -1 EBADF (Bad file descriptor) > [pid 5787] close(272) = -1 EBADF (Bad file descriptor) > [pid 5787] close(273) = -1 EBADF (Bad file descriptor) > [pid 5787] close(274) = -1 EBADF (Bad file descriptor) > [pid 5787] close(275) = -1 EBADF (Bad file descriptor) > [pid 5787] close(276) = -1 EBADF (Bad file descriptor) > [pid 5787] close(277) = -1 EBADF (Bad file descriptor) > [pid 5787] close(278) = -1 EBADF (Bad file descriptor) > [pid 5787] close(279) = -1 EBADF (Bad file descriptor) > [pid 5787] close(280) = -1 EBADF (Bad file descriptor) > [pid 5787] close(281) = -1 EBADF (Bad file descriptor) > [pid 5787] close(282) = -1 EBADF (Bad file descriptor) > [pid 5787] close(283) = -1 EBADF (Bad file descriptor) > [pid 5787] close(284) = -1 EBADF (Bad file descriptor) > [pid 5787] close(285) = -1 EBADF (Bad file descriptor) > [pid 5787] close(286) = -1 EBADF (Bad file descriptor) > [pid 5787] close(287) = -1 EBADF (Bad file descriptor) > [pid 5787] close(288) = -1 EBADF (Bad file descriptor) > [pid 5787] close(289) = -1 EBADF (Bad file descriptor) > [pid 5787] close(290) = -1 EBADF (Bad file descriptor) > [pid 5787] close(291) = -1 EBADF (Bad file descriptor) > [pid 5787] close(292) = -1 EBADF (Bad file descriptor) > [pid 5787] close(293) = -1 EBADF (Bad file descriptor) > [pid 5787] close(294) = -1 EBADF (Bad file descriptor) > [pid 5787] close(295) = -1 EBADF (Bad file descriptor) > [pid 5787] close(296) = -1 EBADF (Bad file descriptor) > [pid 5787] close(297) = -1 EBADF (Bad file descriptor) > [pid 5787] close(298) = -1 EBADF (Bad file descriptor) > [pid 5787] close(299) = -1 EBADF (Bad file descriptor) > [pid 5787] close(300) = -1 EBADF (Bad file descriptor) > [pid 5787] close(301) = -1 EBADF (Bad file descriptor) > [pid 5787] close(302) = -1 EBADF (Bad file descriptor) > [pid 5787] close(303) = -1 EBADF (Bad file descriptor) > [pid 5787] close(304) = -1 EBADF (Bad file descriptor) > [pid 5787] close(305) = -1 EBADF (Bad file descriptor) > [pid 5787] close(306) = -1 EBADF (Bad file descriptor) > [pid 5787] close(307) = -1 EBADF (Bad file descriptor) > [pid 5787] close(308) = -1 EBADF (Bad file descriptor) > [pid 5787] close(309) = -1 EBADF (Bad file descriptor) > [pid 5787] close(310) = -1 EBADF (Bad file descriptor) > [pid 5787] close(311) = -1 EBADF (Bad file descriptor) > [pid 5787] close(312) = -1 EBADF (Bad file descriptor) > [pid 5787] close(313) = -1 EBADF (Bad file descriptor) > [pid 5787] close(314) = -1 EBADF (Bad file descriptor) > [pid 5787] close(315) = -1 EBADF (Bad file descriptor) > [pid 5787] close(316) = -1 EBADF (Bad file descriptor) > [pid 5787] close(317) = -1 EBADF (Bad file descriptor) > [pid 5787] close(318) = -1 EBADF (Bad file descriptor) > [pid 5787] close(319) = -1 EBADF (Bad file descriptor) > [pid 5787] close(320) = -1 EBADF (Bad file descriptor) > [pid 5787] close(321) = -1 EBADF (Bad file descriptor) > [pid 5787] close(322) = -1 EBADF (Bad file descriptor) > [pid 5787] close(323) = -1 EBADF (Bad file descriptor) > [pid 5787] close(324) = -1 EBADF (Bad file descriptor) > [pid 5787] close(325) = -1 EBADF (Bad file descriptor) > [pid 5787] close(326) = -1 EBADF (Bad file descriptor) > [pid 5787] close(327) = -1 EBADF (Bad file descriptor) > [pid 5787] close(328) = -1 EBADF (Bad file descriptor) > [pid 5787] close(329) = -1 EBADF (Bad file descriptor) > [pid 5787] close(330) = -1 EBADF (Bad file descriptor) > [pid 5787] close(331) = -1 EBADF (Bad file descriptor) > [pid 5787] close(332) = -1 EBADF (Bad file descriptor) > [pid 5787] close(333) = -1 EBADF (Bad file descriptor) > [pid 5787] close(334) = -1 EBADF (Bad file descriptor) > [pid 5787] close(335) = -1 EBADF (Bad file descriptor) > [pid 5787] close(336) = -1 EBADF (Bad file descriptor) > [pid 5787] close(337) = -1 EBADF (Bad file descriptor) > [pid 5787] close(338) = -1 EBADF (Bad file descriptor) > [pid 5787] close(339) = -1 EBADF (Bad file descriptor) > [pid 5787] close(340) = -1 EBADF (Bad file descriptor) > [pid 5787] close(341) = -1 EBADF (Bad file descriptor) > [pid 5787] close(342) = -1 EBADF (Bad file descriptor) > [pid 5787] close(343) = -1 EBADF (Bad file descriptor) > [pid 5787] close(344) = -1 EBADF (Bad file descriptor) > [pid 5787] close(345) = -1 EBADF (Bad file descriptor) > [pid 5787] close(346) = -1 EBADF (Bad file descriptor) > [pid 5787] close(347) = -1 EBADF (Bad file descriptor) > [pid 5787] close(348) = -1 EBADF (Bad file descriptor) > [pid 5787] close(349) = -1 EBADF (Bad file descriptor) > [pid 5787] close(350) = -1 EBADF (Bad file descriptor) > [pid 5787] close(351) = -1 EBADF (Bad file descriptor) > [pid 5787] close(352) = -1 EBADF (Bad file descriptor) > [pid 5787] close(353) = -1 EBADF (Bad file descriptor) > [pid 5787] close(354) = -1 EBADF (Bad file descriptor) > [pid 5787] close(355) = -1 EBADF (Bad file descriptor) > [pid 5787] close(356) = -1 EBADF (Bad file descriptor) > [pid 5787] close(357) = -1 EBADF (Bad file descriptor) > [pid 5787] close(358) = -1 EBADF (Bad file descriptor) > [pid 5787] close(359) = -1 EBADF (Bad file descriptor) > [pid 5787] close(360) = -1 EBADF (Bad file descriptor) > [pid 5787] close(361) = -1 EBADF (Bad file descriptor) > [pid 5787] close(362) = -1 EBADF (Bad file descriptor) > [pid 5787] close(363) = -1 EBADF (Bad file descriptor) > [pid 5787] close(364) = -1 EBADF (Bad file descriptor) > [pid 5787] close(365) = -1 EBADF (Bad file descriptor) > [pid 5787] close(366) = -1 EBADF (Bad file descriptor) > [pid 5787] close(367) = -1 EBADF (Bad file descriptor) > [pid 5787] close(368) = -1 EBADF (Bad file descriptor) > [pid 5787] close(369) = -1 EBADF (Bad file descriptor) > [pid 5787] close(370) = -1 EBADF (Bad file descriptor) > [pid 5787] close(371) = -1 EBADF (Bad file descriptor) > [pid 5787] close(372) = -1 EBADF (Bad file descriptor) > [pid 5787] close(373) = -1 EBADF (Bad file descriptor) > [pid 5787] close(374) = -1 EBADF (Bad file descriptor) > [pid 5787] close(375) = -1 EBADF (Bad file descriptor) > [pid 5787] close(376) = -1 EBADF (Bad file descriptor) > [pid 5787] close(377) = -1 EBADF (Bad file descriptor) > [pid 5787] close(378) = -1 EBADF (Bad file descriptor) > [pid 5787] close(379) = -1 EBADF (Bad file descriptor) > [pid 5787] close(380) = -1 EBADF (Bad file descriptor) > [pid 5787] close(381) = -1 EBADF (Bad file descriptor) > [pid 5787] close(382) = -1 EBADF (Bad file descriptor) > [pid 5787] close(383) = -1 EBADF (Bad file descriptor) > [pid 5787] close(384) = -1 EBADF (Bad file descriptor) > [pid 5787] close(385) = -1 EBADF (Bad file descriptor) > [pid 5787] close(386) = -1 EBADF (Bad file descriptor) > [pid 5787] close(387) = -1 EBADF (Bad file descriptor) > [pid 5787] close(388) = -1 EBADF (Bad file descriptor) > [pid 5787] close(389) = -1 EBADF (Bad file descriptor) > [pid 5787] close(390) = -1 EBADF (Bad file descriptor) > [pid 5787] close(391) = -1 EBADF (Bad file descriptor) > [pid 5787] close(392) = -1 EBADF (Bad file descriptor) > [pid 5787] close(393) = -1 EBADF (Bad file descriptor) > [pid 5787] close(394) = -1 EBADF (Bad file descriptor) > [pid 5787] close(395) = -1 EBADF (Bad file descriptor) > [pid 5787] close(396) = -1 EBADF (Bad file descriptor) > [pid 5787] close(397) = -1 EBADF (Bad file descriptor) > [pid 5787] close(398) = -1 EBADF (Bad file descriptor) > [pid 5787] close(399) = -1 EBADF (Bad file descriptor) > [pid 5787] close(400) = -1 EBADF (Bad file descriptor) > [pid 5787] close(401) = -1 EBADF (Bad file descriptor) > [pid 5787] close(402) = -1 EBADF (Bad file descriptor) > [pid 5787] close(403) = -1 EBADF (Bad file descriptor) > [pid 5787] close(404) = -1 EBADF (Bad file descriptor) > [pid 5787] close(405) = -1 EBADF (Bad file descriptor) > [pid 5787] close(406) = -1 EBADF (Bad file descriptor) > [pid 5787] close(407) = -1 EBADF (Bad file descriptor) > [pid 5787] close(408) = -1 EBADF (Bad file descriptor) > [pid 5787] close(409) = -1 EBADF (Bad file descriptor) > [pid 5787] close(410) = -1 EBADF (Bad file descriptor) > [pid 5787] close(411) = -1 EBADF (Bad file descriptor) > [pid 5787] close(412) = -1 EBADF (Bad file descriptor) > [pid 5787] close(413) = -1 EBADF (Bad file descriptor) > [pid 5787] close(414) = -1 EBADF (Bad file descriptor) > [pid 5787] close(415) = -1 EBADF (Bad file descriptor) > [pid 5787] close(416) = -1 EBADF (Bad file descriptor) > [pid 5787] close(417) = -1 EBADF (Bad file descriptor) > [pid 5787] close(418) = -1 EBADF (Bad file descriptor) > [pid 5787] close(419) = -1 EBADF (Bad file descriptor) > [pid 5787] close(420) = -1 EBADF (Bad file descriptor) > [pid 5787] close(421) = -1 EBADF (Bad file descriptor) > [pid 5787] close(422) = -1 EBADF (Bad file descriptor) > [pid 5787] close(423) = -1 EBADF (Bad file descriptor) > [pid 5787] close(424) = -1 EBADF (Bad file descriptor) > [pid 5787] close(425) = -1 EBADF (Bad file descriptor) > [pid 5787] close(426) = -1 EBADF (Bad file descriptor) > [pid 5787] close(427) = -1 EBADF (Bad file descriptor) > [pid 5787] close(428) = -1 EBADF (Bad file descriptor) > [pid 5787] close(429) = -1 EBADF (Bad file descriptor) > [pid 5787] close(430) = -1 EBADF (Bad file descriptor) > [pid 5787] close(431) = -1 EBADF (Bad file descriptor) > [pid 5787] close(432) = -1 EBADF (Bad file descriptor) > [pid 5787] close(433) = -1 EBADF (Bad file descriptor) > [pid 5787] close(434) = -1 EBADF (Bad file descriptor) > [pid 5787] close(435) = -1 EBADF (Bad file descriptor) > [pid 5787] close(436) = -1 EBADF (Bad file descriptor) > [pid 5787] close(437) = -1 EBADF (Bad file descriptor) > [pid 5787] close(438) = -1 EBADF (Bad file descriptor) > [pid 5787] close(439) = -1 EBADF (Bad file descriptor) > [pid 5787] close(440) = -1 EBADF (Bad file descriptor) > [pid 5787] close(441) = -1 EBADF (Bad file descriptor) > [pid 5787] close(442) = -1 EBADF (Bad file descriptor) > [pid 5787] close(443) = -1 EBADF (Bad file descriptor) > [pid 5787] close(444) = -1 EBADF (Bad file descriptor) > [pid 5787] close(445) = -1 EBADF (Bad file descriptor) > [pid 5787] close(446) = -1 EBADF (Bad file descriptor) > [pid 5787] close(447) = -1 EBADF (Bad file descriptor) > [pid 5787] close(448) = -1 EBADF (Bad file descriptor) > [pid 5787] close(449) = -1 EBADF (Bad file descriptor) > [pid 5787] close(450) = -1 EBADF (Bad file descriptor) > [pid 5787] close(451) = -1 EBADF (Bad file descriptor) > [pid 5787] close(452) = -1 EBADF (Bad file descriptor) > [pid 5787] close(453) = -1 EBADF (Bad file descriptor) > [pid 5787] close(454) = -1 EBADF (Bad file descriptor) > [pid 5787] close(455) = -1 EBADF (Bad file descriptor) > [pid 5787] close(456) = -1 EBADF (Bad file descriptor) > [pid 5787] close(457) = -1 EBADF (Bad file descriptor) > [pid 5787] close(458) = -1 EBADF (Bad file descriptor) > [pid 5787] close(459) = -1 EBADF (Bad file descriptor) > [pid 5787] close(460) = -1 EBADF (Bad file descriptor) > [pid 5787] close(461) = -1 EBADF (Bad file descriptor) > [pid 5787] close(462) = -1 EBADF (Bad file descriptor) > [pid 5787] close(463) = -1 EBADF (Bad file descriptor) > [pid 5787] close(464) = -1 EBADF (Bad file descriptor) > [pid 5787] close(465) = -1 EBADF (Bad file descriptor) > [pid 5787] close(466) = -1 EBADF (Bad file descriptor) > [pid 5787] close(467) = -1 EBADF (Bad file descriptor) > [pid 5787] close(468) = -1 EBADF (Bad file descriptor) > [pid 5787] close(469) = -1 EBADF (Bad file descriptor) > [pid 5787] close(470) = -1 EBADF (Bad file descriptor) > [pid 5787] close(471) = -1 EBADF (Bad file descriptor) > [pid 5787] close(472) = -1 EBADF (Bad file descriptor) > [pid 5787] close(473) = -1 EBADF (Bad file descriptor) > [pid 5787] close(474) = -1 EBADF (Bad file descriptor) > [pid 5787] close(475) = -1 EBADF (Bad file descriptor) > [pid 5787] close(476) = -1 EBADF (Bad file descriptor) > [pid 5787] close(477) = -1 EBADF (Bad file descriptor) > [pid 5787] close(478) = -1 EBADF (Bad file descriptor) > [pid 5787] close(479) = -1 EBADF (Bad file descriptor) > [pid 5787] close(480) = -1 EBADF (Bad file descriptor) > [pid 5787] close(481) = -1 EBADF (Bad file descriptor) > [pid 5787] close(482) = -1 EBADF (Bad file descriptor) > [pid 5787] close(483) = -1 EBADF (Bad file descriptor) > [pid 5787] close(484) = -1 EBADF (Bad file descriptor) > [pid 5787] close(485) = -1 EBADF (Bad file descriptor) > [pid 5787] close(486) = -1 EBADF (Bad file descriptor) > [pid 5787] close(487) = -1 EBADF (Bad file descriptor) > [pid 5787] close(488) = -1 EBADF (Bad file descriptor) > [pid 5787] close(489) = -1 EBADF (Bad file descriptor) > [pid 5787] close(490) = -1 EBADF (Bad file descriptor) > [pid 5787] close(491) = -1 EBADF (Bad file descriptor) > [pid 5787] close(492) = -1 EBADF (Bad file descriptor) > [pid 5787] close(493) = -1 EBADF (Bad file descriptor) > [pid 5787] close(494) = -1 EBADF (Bad file descriptor) > [pid 5787] close(495) = -1 EBADF (Bad file descriptor) > [pid 5787] close(496) = -1 EBADF (Bad file descriptor) > [pid 5787] close(497) = -1 EBADF (Bad file descriptor) > [pid 5787] close(498) = -1 EBADF (Bad file descriptor) > [pid 5787] close(499) = -1 EBADF (Bad file descriptor) > [pid 5787] close(500) = -1 EBADF (Bad file descriptor) > [pid 5787] close(501) = -1 EBADF (Bad file descriptor) > [pid 5787] close(502) = -1 EBADF (Bad file descriptor) > [pid 5787] close(503) = -1 EBADF (Bad file descriptor) > [pid 5787] close(504) = -1 EBADF (Bad file descriptor) > [pid 5787] close(505) = -1 EBADF (Bad file descriptor) > [pid 5787] close(506) = -1 EBADF (Bad file descriptor) > [pid 5787] close(507) = -1 EBADF (Bad file descriptor) > [pid 5787] close(508) = -1 EBADF (Bad file descriptor) > [pid 5787] close(509) = -1 EBADF (Bad file descriptor) > [pid 5787] close(510) = -1 EBADF (Bad file descriptor) > [pid 5787] close(511) = -1 EBADF (Bad file descriptor) > [pid 5787] close(512) = -1 EBADF (Bad file descriptor) > [pid 5787] close(513) = -1 EBADF (Bad file descriptor) > [pid 5787] close(514) = -1 EBADF (Bad file descriptor) > [pid 5787] close(515) = -1 EBADF (Bad file descriptor) > [pid 5787] close(516) = -1 EBADF (Bad file descriptor) > [pid 5787] close(517) = -1 EBADF (Bad file descriptor) > [pid 5787] close(518) = -1 EBADF (Bad file descriptor) > [pid 5787] close(519) = -1 EBADF (Bad file descriptor) > [pid 5787] close(520) = -1 EBADF (Bad file descriptor) > [pid 5787] close(521) = -1 EBADF (Bad file descriptor) > [pid 5787] close(522) = -1 EBADF (Bad file descriptor) > [pid 5787] close(523) = -1 EBADF (Bad file descriptor) > [pid 5787] close(524) = -1 EBADF (Bad file descriptor) > [pid 5787] close(525) = -1 EBADF (Bad file descriptor) > [pid 5787] close(526) = -1 EBADF (Bad file descriptor) > [pid 5787] close(527) = -1 EBADF (Bad file descriptor) > [pid 5787] close(528) = -1 EBADF (Bad file descriptor) > [pid 5787] close(529) = -1 EBADF (Bad file descriptor) > [pid 5787] close(530) = -1 EBADF (Bad file descriptor) > [pid 5787] close(531) = -1 EBADF (Bad file descriptor) > [pid 5787] close(532) = -1 EBADF (Bad file descriptor) > [pid 5787] close(533) = -1 EBADF (Bad file descriptor) > [pid 5787] close(534) = -1 EBADF (Bad file descriptor) > [pid 5787] close(535) = -1 EBADF (Bad file descriptor) > [pid 5787] close(536) = -1 EBADF (Bad file descriptor) > [pid 5787] close(537) = -1 EBADF (Bad file descriptor) > [pid 5787] close(538) = -1 EBADF (Bad file descriptor) > [pid 5787] close(539) = -1 EBADF (Bad file descriptor) > [pid 5787] close(540) = -1 EBADF (Bad file descriptor) > [pid 5787] close(541) = -1 EBADF (Bad file descriptor) > [pid 5787] close(542) = -1 EBADF (Bad file descriptor) > [pid 5787] close(543) = -1 EBADF (Bad file descriptor) > [pid 5787] close(544) = -1 EBADF (Bad file descriptor) > [pid 5787] close(545) = -1 EBADF (Bad file descriptor) > [pid 5787] close(546) = -1 EBADF (Bad file descriptor) > [pid 5787] close(547) = -1 EBADF (Bad file descriptor) > [pid 5787] close(548) = -1 EBADF (Bad file descriptor) > [pid 5787] close(549) = -1 EBADF (Bad file descriptor) > [pid 5787] close(550) = -1 EBADF (Bad file descriptor) > [pid 5787] close(551) = -1 EBADF (Bad file descriptor) > [pid 5787] close(552) = -1 EBADF (Bad file descriptor) > [pid 5787] close(553) = -1 EBADF (Bad file descriptor) > [pid 5787] close(554) = -1 EBADF (Bad file descriptor) > [pid 5787] close(555) = -1 EBADF (Bad file descriptor) > [pid 5787] close(556) = -1 EBADF (Bad file descriptor) > [pid 5787] close(557) = -1 EBADF (Bad file descriptor) > [pid 5787] close(558) = -1 EBADF (Bad file descriptor) > [pid 5787] close(559) = -1 EBADF (Bad file descriptor) > [pid 5787] close(560) = -1 EBADF (Bad file descriptor) > [pid 5787] close(561) = -1 EBADF (Bad file descriptor) > [pid 5787] close(562) = -1 EBADF (Bad file descriptor) > [pid 5787] close(563) = -1 EBADF (Bad file descriptor) > [pid 5787] close(564) = -1 EBADF (Bad file descriptor) > [pid 5787] close(565) = -1 EBADF (Bad file descriptor) > [pid 5787] close(566) = -1 EBADF (Bad file descriptor) > [pid 5787] close(567) = -1 EBADF (Bad file descriptor) > [pid 5787] close(568) = -1 EBADF (Bad file descriptor) > [pid 5787] close(569) = -1 EBADF (Bad file descriptor) > [pid 5787] close(570) = -1 EBADF (Bad file descriptor) > [pid 5787] close(571) = -1 EBADF (Bad file descriptor) > [pid 5787] close(572) = -1 EBADF (Bad file descriptor) > [pid 5787] close(573) = -1 EBADF (Bad file descriptor) > [pid 5787] close(574) = -1 EBADF (Bad file descriptor) > [pid 5787] close(575) = -1 EBADF (Bad file descriptor) > [pid 5787] close(576) = -1 EBADF (Bad file descriptor) > [pid 5787] close(577) = -1 EBADF (Bad file descriptor) > [pid 5787] close(578) = -1 EBADF (Bad file descriptor) > [pid 5787] close(579) = -1 EBADF (Bad file descriptor) > [pid 5787] close(580) = -1 EBADF (Bad file descriptor) > [pid 5787] close(581) = -1 EBADF (Bad file descriptor) > [pid 5787] close(582) = -1 EBADF (Bad file descriptor) > [pid 5787] close(583) = -1 EBADF (Bad file descriptor) > [pid 5787] close(584) = -1 EBADF (Bad file descriptor) > [pid 5787] close(585) = -1 EBADF (Bad file descriptor) > [pid 5787] close(586) = -1 EBADF (Bad file descriptor) > [pid 5787] close(587) = -1 EBADF (Bad file descriptor) > [pid 5787] close(588) = -1 EBADF (Bad file descriptor) > [pid 5787] close(589) = -1 EBADF (Bad file descriptor) > [pid 5787] close(590) = -1 EBADF (Bad file descriptor) > [pid 5787] close(591) = -1 EBADF (Bad file descriptor) > [pid 5787] close(592) = -1 EBADF (Bad file descriptor) > [pid 5787] close(593) = -1 EBADF (Bad file descriptor) > [pid 5787] close(594) = -1 EBADF (Bad file descriptor) > [pid 5787] close(595) = -1 EBADF (Bad file descriptor) > [pid 5787] close(596) = -1 EBADF (Bad file descriptor) > [pid 5787] close(597) = -1 EBADF (Bad file descriptor) > [pid 5787] close(598) = -1 EBADF (Bad file descriptor) > [pid 5787] close(599) = -1 EBADF (Bad file descriptor) > [pid 5787] close(600) = -1 EBADF (Bad file descriptor) > [pid 5787] close(601) = -1 EBADF (Bad file descriptor) > [pid 5787] close(602) = -1 EBADF (Bad file descriptor) > [pid 5787] close(603) = -1 EBADF (Bad file descriptor) > [pid 5787] close(604) = -1 EBADF (Bad file descriptor) > [pid 5787] close(605) = -1 EBADF (Bad file descriptor) > [pid 5787] close(606) = -1 EBADF (Bad file descriptor) > [pid 5787] close(607) = -1 EBADF (Bad file descriptor) > [pid 5787] close(608) = -1 EBADF (Bad file descriptor) > [pid 5787] close(609) = -1 EBADF (Bad file descriptor) > [pid 5787] close(610) = -1 EBADF (Bad file descriptor) > [pid 5787] close(611) = -1 EBADF (Bad file descriptor) > [pid 5787] close(612) = -1 EBADF (Bad file descriptor) > [pid 5787] close(613) = -1 EBADF (Bad file descriptor) > [pid 5787] close(614) = -1 EBADF (Bad file descriptor) > [pid 5787] close(615) = -1 EBADF (Bad file descriptor) > [pid 5787] close(616) = -1 EBADF (Bad file descriptor) > [pid 5787] close(617) = -1 EBADF (Bad file descriptor) > [pid 5787] close(618) = -1 EBADF (Bad file descriptor) > [pid 5787] close(619) = -1 EBADF (Bad file descriptor) > [pid 5787] close(620) = -1 EBADF (Bad file descriptor) > [pid 5787] close(621) = -1 EBADF (Bad file descriptor) > [pid 5787] close(622) = -1 EBADF (Bad file descriptor) > [pid 5787] close(623) = -1 EBADF (Bad file descriptor) > [pid 5787] close(624) = -1 EBADF (Bad file descriptor) > [pid 5787] close(625) = -1 EBADF (Bad file descriptor) > [pid 5787] close(626) = -1 EBADF (Bad file descriptor) > [pid 5787] close(627) = -1 EBADF (Bad file descriptor) > [pid 5787] close(628) = -1 EBADF (Bad file descriptor) > [pid 5787] close(629) = -1 EBADF (Bad file descriptor) > [pid 5787] close(630) = -1 EBADF (Bad file descriptor) > [pid 5787] close(631) = -1 EBADF (Bad file descriptor) > [pid 5787] close(632) = -1 EBADF (Bad file descriptor) > [pid 5787] close(633) = -1 EBADF (Bad file descriptor) > [pid 5787] close(634) = -1 EBADF (Bad file descriptor) > [pid 5787] close(635) = -1 EBADF (Bad file descriptor) > [pid 5787] close(636) = -1 EBADF (Bad file descriptor) > [pid 5787] close(637) = -1 EBADF (Bad file descriptor) > [pid 5787] close(638) = -1 EBADF (Bad file descriptor) > [pid 5787] close(639) = -1 EBADF (Bad file descriptor) > [pid 5787] close(640) = -1 EBADF (Bad file descriptor) > [pid 5787] close(641) = -1 EBADF (Bad file descriptor) > [pid 5787] close(642) = -1 EBADF (Bad file descriptor) > [pid 5787] close(643) = -1 EBADF (Bad file descriptor) > [pid 5787] close(644) = -1 EBADF (Bad file descriptor) > [pid 5787] close(645) = -1 EBADF (Bad file descriptor) > [pid 5787] close(646) = -1 EBADF (Bad file descriptor) > [pid 5787] close(647) = -1 EBADF (Bad file descriptor) > [pid 5787] close(648) = -1 EBADF (Bad file descriptor) > [pid 5787] close(649) = -1 EBADF (Bad file descriptor) > [pid 5787] close(650) = -1 EBADF (Bad file descriptor) > [pid 5787] close(651) = -1 EBADF (Bad file descriptor) > [pid 5787] close(652) = -1 EBADF (Bad file descriptor) > [pid 5787] close(653) = -1 EBADF (Bad file descriptor) > [pid 5787] close(654) = -1 EBADF (Bad file descriptor) > [pid 5787] close(655) = -1 EBADF (Bad file descriptor) > [pid 5787] close(656) = -1 EBADF (Bad file descriptor) > [pid 5787] close(657) = -1 EBADF (Bad file descriptor) > [pid 5787] close(658) = -1 EBADF (Bad file descriptor) > [pid 5787] close(659) = -1 EBADF (Bad file descriptor) > [pid 5787] close(660) = -1 EBADF (Bad file descriptor) > [pid 5787] close(661) = -1 EBADF (Bad file descriptor) > [pid 5787] close(662) = -1 EBADF (Bad file descriptor) > [pid 5787] close(663) = -1 EBADF (Bad file descriptor) > [pid 5787] close(664) = -1 EBADF (Bad file descriptor) > [pid 5787] close(665) = -1 EBADF (Bad file descriptor) > [pid 5787] close(666) = -1 EBADF (Bad file descriptor) > [pid 5787] close(667) = -1 EBADF (Bad file descriptor) > [pid 5787] close(668) = -1 EBADF (Bad file descriptor) > [pid 5787] close(669) = -1 EBADF (Bad file descriptor) > [pid 5787] close(670) = -1 EBADF (Bad file descriptor) > [pid 5787] close(671) = -1 EBADF (Bad file descriptor) > [pid 5787] close(672) = -1 EBADF (Bad file descriptor) > [pid 5787] close(673) = -1 EBADF (Bad file descriptor) > [pid 5787] close(674) = -1 EBADF (Bad file descriptor) > [pid 5787] close(675) = -1 EBADF (Bad file descriptor) > [pid 5787] close(676) = -1 EBADF (Bad file descriptor) > [pid 5787] close(677) = -1 EBADF (Bad file descriptor) > [pid 5787] close(678) = -1 EBADF (Bad file descriptor) > [pid 5787] close(679) = -1 EBADF (Bad file descriptor) > [pid 5787] close(680) = -1 EBADF (Bad file descriptor) > [pid 5787] close(681) = -1 EBADF (Bad file descriptor) > [pid 5787] close(682) = -1 EBADF (Bad file descriptor) > [pid 5787] close(683) = -1 EBADF (Bad file descriptor) > [pid 5787] close(684) = -1 EBADF (Bad file descriptor) > [pid 5787] close(685) = -1 EBADF (Bad file descriptor) > [pid 5787] close(686) = -1 EBADF (Bad file descriptor) > [pid 5787] close(687) = -1 EBADF (Bad file descriptor) > [pid 5787] close(688) = -1 EBADF (Bad file descriptor) > [pid 5787] close(689) = -1 EBADF (Bad file descriptor) > [pid 5787] close(690) = -1 EBADF (Bad file descriptor) > [pid 5787] close(691) = -1 EBADF (Bad file descriptor) > [pid 5787] close(692) = -1 EBADF (Bad file descriptor) > [pid 5787] close(693) = -1 EBADF (Bad file descriptor) > [pid 5787] close(694) = -1 EBADF (Bad file descriptor) > [pid 5787] close(695) = -1 EBADF (Bad file descriptor) > [pid 5787] close(696) = -1 EBADF (Bad file descriptor) > [pid 5787] close(697) = -1 EBADF (Bad file descriptor) > [pid 5787] close(698) = -1 EBADF (Bad file descriptor) > [pid 5787] close(699) = -1 EBADF (Bad file descriptor) > [pid 5787] close(700) = -1 EBADF (Bad file descriptor) > [pid 5787] close(701) = -1 EBADF (Bad file descriptor) > [pid 5787] close(702) = -1 EBADF (Bad file descriptor) > [pid 5787] close(703) = -1 EBADF (Bad file descriptor) > [pid 5787] close(704) = -1 EBADF (Bad file descriptor) > [pid 5787] close(705) = -1 EBADF (Bad file descriptor) > [pid 5787] close(706) = -1 EBADF (Bad file descriptor) > [pid 5787] close(707) = -1 EBADF (Bad file descriptor) > [pid 5787] close(708) = -1 EBADF (Bad file descriptor) > [pid 5787] close(709) = -1 EBADF (Bad file descriptor) > [pid 5787] close(710) = -1 EBADF (Bad file descriptor) > [pid 5787] close(711) = -1 EBADF (Bad file descriptor) > [pid 5787] close(712) = -1 EBADF (Bad file descriptor) > [pid 5787] close(713) = -1 EBADF (Bad file descriptor) > [pid 5787] close(714) = -1 EBADF (Bad file descriptor) > [pid 5787] close(715) = -1 EBADF (Bad file descriptor) > [pid 5787] close(716) = -1 EBADF (Bad file descriptor) > [pid 5787] close(717) = -1 EBADF (Bad file descriptor) > [pid 5787] close(718) = -1 EBADF (Bad file descriptor) > [pid 5787] close(719) = -1 EBADF (Bad file descriptor) > [pid 5787] close(720) = -1 EBADF (Bad file descriptor) > [pid 5787] close(721) = -1 EBADF (Bad file descriptor) > [pid 5787] close(722) = -1 EBADF (Bad file descriptor) > [pid 5787] close(723) = -1 EBADF (Bad file descriptor) > [pid 5787] close(724) = -1 EBADF (Bad file descriptor) > [pid 5787] close(725) = -1 EBADF (Bad file descriptor) > [pid 5787] close(726) = -1 EBADF (Bad file descriptor) > [pid 5787] close(727) = -1 EBADF (Bad file descriptor) > [pid 5787] close(728) = -1 EBADF (Bad file descriptor) > [pid 5787] close(729) = -1 EBADF (Bad file descriptor) > [pid 5787] close(730) = -1 EBADF (Bad file descriptor) > [pid 5787] close(731) = -1 EBADF (Bad file descriptor) > [pid 5787] close(732) = -1 EBADF (Bad file descriptor) > [pid 5787] close(733) = -1 EBADF (Bad file descriptor) > [pid 5787] close(734) = -1 EBADF (Bad file descriptor) > [pid 5787] close(735) = -1 EBADF (Bad file descriptor) > [pid 5787] close(736) = -1 EBADF (Bad file descriptor) > [pid 5787] close(737) = -1 EBADF (Bad file descriptor) > [pid 5787] close(738) = -1 EBADF (Bad file descriptor) > [pid 5787] close(739) = -1 EBADF (Bad file descriptor) > [pid 5787] close(740) = -1 EBADF (Bad file descriptor) > [pid 5787] close(741) = -1 EBADF (Bad file descriptor) > [pid 5787] close(742) = -1 EBADF (Bad file descriptor) > [pid 5787] close(743) = -1 EBADF (Bad file descriptor) > [pid 5787] close(744) = -1 EBADF (Bad file descriptor) > [pid 5787] close(745) = -1 EBADF (Bad file descriptor) > [pid 5787] close(746) = -1 EBADF (Bad file descriptor) > [pid 5787] close(747) = -1 EBADF (Bad file descriptor) > [pid 5787] close(748) = -1 EBADF (Bad file descriptor) > [pid 5787] close(749) = -1 EBADF (Bad file descriptor) > [pid 5787] close(750) = -1 EBADF (Bad file descriptor) > [pid 5787] close(751) = -1 EBADF (Bad file descriptor) > [pid 5787] close(752) = -1 EBADF (Bad file descriptor) > [pid 5787] close(753) = -1 EBADF (Bad file descriptor) > [pid 5787] close(754) = -1 EBADF (Bad file descriptor) > [pid 5787] close(755) = -1 EBADF (Bad file descriptor) > [pid 5787] close(756) = -1 EBADF (Bad file descriptor) > [pid 5787] close(757) = -1 EBADF (Bad file descriptor) > [pid 5787] close(758) = -1 EBADF (Bad file descriptor) > [pid 5787] close(759) = -1 EBADF (Bad file descriptor) > [pid 5787] close(760) = -1 EBADF (Bad file descriptor) > [pid 5787] close(761) = -1 EBADF (Bad file descriptor) > [pid 5787] close(762) = -1 EBADF (Bad file descriptor) > [pid 5787] close(763) = -1 EBADF (Bad file descriptor) > [pid 5787] close(764) = -1 EBADF (Bad file descriptor) > [pid 5787] close(765) = -1 EBADF (Bad file descriptor) > [pid 5787] close(766) = -1 EBADF (Bad file descriptor) > [pid 5787] close(767) = -1 EBADF (Bad file descriptor) > [pid 5787] close(768) = -1 EBADF (Bad file descriptor) > [pid 5787] close(769) = -1 EBADF (Bad file descriptor) > [pid 5787] close(770) = -1 EBADF (Bad file descriptor) > [pid 5787] close(771) = -1 EBADF (Bad file descriptor) > [pid 5787] close(772) = -1 EBADF (Bad file descriptor) > [pid 5787] close(773) = -1 EBADF (Bad file descriptor) > [pid 5787] close(774) = -1 EBADF (Bad file descriptor) > [pid 5787] close(775) = -1 EBADF (Bad file descriptor) > [pid 5787] close(776) = -1 EBADF (Bad file descriptor) > [pid 5787] close(777) = -1 EBADF (Bad file descriptor) > [pid 5787] close(778) = -1 EBADF (Bad file descriptor) > [pid 5787] close(779) = -1 EBADF (Bad file descriptor) > [pid 5787] close(780) = -1 EBADF (Bad file descriptor) > [pid 5787] close(781) = -1 EBADF (Bad file descriptor) > [pid 5787] close(782) = -1 EBADF (Bad file descriptor) > [pid 5787] close(783) = -1 EBADF (Bad file descriptor) > [pid 5787] close(784) = -1 EBADF (Bad file descriptor) > [pid 5787] close(785) = -1 EBADF (Bad file descriptor) > [pid 5787] close(786) = -1 EBADF (Bad file descriptor) > [pid 5787] close(787) = -1 EBADF (Bad file descriptor) > [pid 5787] close(788) = -1 EBADF (Bad file descriptor) > [pid 5787] close(789) = -1 EBADF (Bad file descriptor) > [pid 5787] close(790) = -1 EBADF (Bad file descriptor) > [pid 5787] close(791) = -1 EBADF (Bad file descriptor) > [pid 5787] close(792) = -1 EBADF (Bad file descriptor) > [pid 5787] close(793) = -1 EBADF (Bad file descriptor) > [pid 5787] close(794) = -1 EBADF (Bad file descriptor) > [pid 5787] close(795) = -1 EBADF (Bad file descriptor) > [pid 5787] close(796) = -1 EBADF (Bad file descriptor) > [pid 5787] close(797) = -1 EBADF (Bad file descriptor) > [pid 5787] close(798) = -1 EBADF (Bad file descriptor) > [pid 5787] close(799) = -1 EBADF (Bad file descriptor) > [pid 5787] close(800) = -1 EBADF (Bad file descriptor) > [pid 5787] close(801) = -1 EBADF (Bad file descriptor) > [pid 5787] close(802) = -1 EBADF (Bad file descriptor) > [pid 5787] close(803) = -1 EBADF (Bad file descriptor) > [pid 5787] close(804) = -1 EBADF (Bad file descriptor) > [pid 5787] close(805) = -1 EBADF (Bad file descriptor) > [pid 5787] close(806) = -1 EBADF (Bad file descriptor) > [pid 5787] close(807) = -1 EBADF (Bad file descriptor) > [pid 5787] close(808) = -1 EBADF (Bad file descriptor) > [pid 5787] close(809) = -1 EBADF (Bad file descriptor) > [pid 5787] close(810) = -1 EBADF (Bad file descriptor) > [pid 5787] close(811) = -1 EBADF (Bad file descriptor) > [pid 5787] close(812) = -1 EBADF (Bad file descriptor) > [pid 5787] close(813) = -1 EBADF (Bad file descriptor) > [pid 5787] close(814) = -1 EBADF (Bad file descriptor) > [pid 5787] close(815) = -1 EBADF (Bad file descriptor) > [pid 5787] close(816) = -1 EBADF (Bad file descriptor) > [pid 5787] close(817) = -1 EBADF (Bad file descriptor) > [pid 5787] close(818) = -1 EBADF (Bad file descriptor) > [pid 5787] close(819) = -1 EBADF (Bad file descriptor) > [pid 5787] close(820) = -1 EBADF (Bad file descriptor) > [pid 5787] close(821) = -1 EBADF (Bad file descriptor) > [pid 5787] close(822) = -1 EBADF (Bad file descriptor) > [pid 5787] close(823) = -1 EBADF (Bad file descriptor) > [pid 5787] close(824) = -1 EBADF (Bad file descriptor) > [pid 5787] close(825) = -1 EBADF (Bad file descriptor) > [pid 5787] close(826) = -1 EBADF (Bad file descriptor) > [pid 5787] close(827) = -1 EBADF (Bad file descriptor) > [pid 5787] close(828) = -1 EBADF (Bad file descriptor) > [pid 5787] close(829) = -1 EBADF (Bad file descriptor) > [pid 5787] close(830) = -1 EBADF (Bad file descriptor) > [pid 5787] close(831) = -1 EBADF (Bad file descriptor) > [pid 5787] close(832) = -1 EBADF (Bad file descriptor) > [pid 5787] close(833) = -1 EBADF (Bad file descriptor) > [pid 5787] close(834) = -1 EBADF (Bad file descriptor) > [pid 5787] close(835) = -1 EBADF (Bad file descriptor) > [pid 5787] close(836) = -1 EBADF (Bad file descriptor) > [pid 5787] close(837) = -1 EBADF (Bad file descriptor) > [pid 5787] close(838) = -1 EBADF (Bad file descriptor) > [pid 5787] close(839) = -1 EBADF (Bad file descriptor) > [pid 5787] close(840) = -1 EBADF (Bad file descriptor) > [pid 5787] close(841) = -1 EBADF (Bad file descriptor) > [pid 5787] close(842) = -1 EBADF (Bad file descriptor) > [pid 5787] close(843) = -1 EBADF (Bad file descriptor) > [pid 5787] close(844) = -1 EBADF (Bad file descriptor) > [pid 5787] close(845) = -1 EBADF (Bad file descriptor) > [pid 5787] close(846) = -1 EBADF (Bad file descriptor) > [pid 5787] close(847) = -1 EBADF (Bad file descriptor) > [pid 5787] close(848) = -1 EBADF (Bad file descriptor) > [pid 5787] close(849) = -1 EBADF (Bad file descriptor) > [pid 5787] close(850) = -1 EBADF (Bad file descriptor) > [pid 5787] close(851) = -1 EBADF (Bad file descriptor) > [pid 5787] close(852) = -1 EBADF (Bad file descriptor) > [pid 5787] close(853) = -1 EBADF (Bad file descriptor) > [pid 5787] close(854) = -1 EBADF (Bad file descriptor) > [pid 5787] close(855) = -1 EBADF (Bad file descriptor) > [pid 5787] close(856) = -1 EBADF (Bad file descriptor) > [pid 5787] close(857) = -1 EBADF (Bad file descriptor) > [pid 5787] close(858) = -1 EBADF (Bad file descriptor) > [pid 5787] close(859) = -1 EBADF (Bad file descriptor) > [pid 5787] close(860) = -1 EBADF (Bad file descriptor) > [pid 5787] close(861) = -1 EBADF (Bad file descriptor) > [pid 5787] close(862) = -1 EBADF (Bad file descriptor) > [pid 5787] close(863) = -1 EBADF (Bad file descriptor) > [pid 5787] close(864) = -1 EBADF (Bad file descriptor) > [pid 5787] close(865) = -1 EBADF (Bad file descriptor) > [pid 5787] close(866) = -1 EBADF (Bad file descriptor) > [pid 5787] close(867) = -1 EBADF (Bad file descriptor) > [pid 5787] close(868) = -1 EBADF (Bad file descriptor) > [pid 5787] close(869) = -1 EBADF (Bad file descriptor) > [pid 5787] close(870) = -1 EBADF (Bad file descriptor) > [pid 5787] close(871) = -1 EBADF (Bad file descriptor) > [pid 5787] close(872) = -1 EBADF (Bad file descriptor) > [pid 5787] close(873) = -1 EBADF (Bad file descriptor) > [pid 5787] close(874) = -1 EBADF (Bad file descriptor) > [pid 5787] close(875) = -1 EBADF (Bad file descriptor) > [pid 5787] close(876) = -1 EBADF (Bad file descriptor) > [pid 5787] close(877) = -1 EBADF (Bad file descriptor) > [pid 5787] close(878) = -1 EBADF (Bad file descriptor) > [pid 5787] close(879) = -1 EBADF (Bad file descriptor) > [pid 5787] close(880) = -1 EBADF (Bad file descriptor) > [pid 5787] close(881) = -1 EBADF (Bad file descriptor) > [pid 5787] close(882) = -1 EBADF (Bad file descriptor) > [pid 5787] close(883) = -1 EBADF (Bad file descriptor) > [pid 5787] close(884) = -1 EBADF (Bad file descriptor) > [pid 5787] close(885) = -1 EBADF (Bad file descriptor) > [pid 5787] close(886) = -1 EBADF (Bad file descriptor) > [pid 5787] close(887) = -1 EBADF (Bad file descriptor) > [pid 5787] close(888) = -1 EBADF (Bad file descriptor) > [pid 5787] close(889) = -1 EBADF (Bad file descriptor) > [pid 5787] close(890) = -1 EBADF (Bad file descriptor) > [pid 5787] close(891) = -1 EBADF (Bad file descriptor) > [pid 5787] close(892) = -1 EBADF (Bad file descriptor) > [pid 5787] close(893) = -1 EBADF (Bad file descriptor) > [pid 5787] close(894) = -1 EBADF (Bad file descriptor) > [pid 5787] close(895) = -1 EBADF (Bad file descriptor) > [pid 5787] close(896) = -1 EBADF (Bad file descriptor) > [pid 5787] close(897) = -1 EBADF (Bad file descriptor) > [pid 5787] close(898) = -1 EBADF (Bad file descriptor) > [pid 5787] close(899) = -1 EBADF (Bad file descriptor) > [pid 5787] close(900) = -1 EBADF (Bad file descriptor) > [pid 5787] close(901) = -1 EBADF (Bad file descriptor) > [pid 5787] close(902) = -1 EBADF (Bad file descriptor) > [pid 5787] close(903) = -1 EBADF (Bad file descriptor) > [pid 5787] close(904) = -1 EBADF (Bad file descriptor) > [pid 5787] close(905) = -1 EBADF (Bad file descriptor) > [pid 5787] close(906) = -1 EBADF (Bad file descriptor) > [pid 5787] close(907) = -1 EBADF (Bad file descriptor) > [pid 5787] close(908) = -1 EBADF (Bad file descriptor) > [pid 5787] close(909) = -1 EBADF (Bad file descriptor) > [pid 5787] close(910) = -1 EBADF (Bad file descriptor) > [pid 5787] close(911) = -1 EBADF (Bad file descriptor) > [pid 5787] close(912) = -1 EBADF (Bad file descriptor) > [pid 5787] close(913) = -1 EBADF (Bad file descriptor) > [pid 5787] close(914) = -1 EBADF (Bad file descriptor) > [pid 5787] close(915) = -1 EBADF (Bad file descriptor) > [pid 5787] close(916) = -1 EBADF (Bad file descriptor) > [pid 5787] close(917) = -1 EBADF (Bad file descriptor) > [pid 5787] close(918) = -1 EBADF (Bad file descriptor) > [pid 5787] close(919) = -1 EBADF (Bad file descriptor) > [pid 5787] close(920) = -1 EBADF (Bad file descriptor) > [pid 5787] close(921) = -1 EBADF (Bad file descriptor) > [pid 5787] close(922) = -1 EBADF (Bad file descriptor) > [pid 5787] close(923) = -1 EBADF (Bad file descriptor) > [pid 5787] close(924) = -1 EBADF (Bad file descriptor) > [pid 5787] close(925) = -1 EBADF (Bad file descriptor) > [pid 5787] close(926) = -1 EBADF (Bad file descriptor) > [pid 5787] close(927) = -1 EBADF (Bad file descriptor) > [pid 5787] close(928) = -1 EBADF (Bad file descriptor) > [pid 5787] close(929) = -1 EBADF (Bad file descriptor) > [pid 5787] close(930) = -1 EBADF (Bad file descriptor) > [pid 5787] close(931) = -1 EBADF (Bad file descriptor) > [pid 5787] close(932) = -1 EBADF (Bad file descriptor) > [pid 5787] close(933) = -1 EBADF (Bad file descriptor) > [pid 5787] close(934) = -1 EBADF (Bad file descriptor) > [pid 5787] close(935) = -1 EBADF (Bad file descriptor) > [pid 5787] close(936) = -1 EBADF (Bad file descriptor) > [pid 5787] close(937) = -1 EBADF (Bad file descriptor) > [pid 5787] close(938) = -1 EBADF (Bad file descriptor) > [pid 5787] close(939) = -1 EBADF (Bad file descriptor) > [pid 5787] close(940) = -1 EBADF (Bad file descriptor) > [pid 5787] close(941) = -1 EBADF (Bad file descriptor) > [pid 5787] close(942) = -1 EBADF (Bad file descriptor) > [pid 5787] close(943) = -1 EBADF (Bad file descriptor) > [pid 5787] close(944) = -1 EBADF (Bad file descriptor) > [pid 5787] close(945) = -1 EBADF (Bad file descriptor) > [pid 5787] close(946) = -1 EBADF (Bad file descriptor) > [pid 5787] close(947) = -1 EBADF (Bad file descriptor) > [pid 5787] close(948) = -1 EBADF (Bad file descriptor) > [pid 5787] close(949) = -1 EBADF (Bad file descriptor) > [pid 5787] close(950) = -1 EBADF (Bad file descriptor) > [pid 5787] close(951) = -1 EBADF (Bad file descriptor) > [pid 5787] close(952) = -1 EBADF (Bad file descriptor) > [pid 5787] close(953) = -1 EBADF (Bad file descriptor) > [pid 5787] close(954) = -1 EBADF (Bad file descriptor) > [pid 5787] close(955) = -1 EBADF (Bad file descriptor) > [pid 5787] close(956) = -1 EBADF (Bad file descriptor) > [pid 5787] close(957) = -1 EBADF (Bad file descriptor) > [pid 5787] close(958) = -1 EBADF (Bad file descriptor) > [pid 5787] close(959) = -1 EBADF (Bad file descriptor) > [pid 5787] close(960) = -1 EBADF (Bad file descriptor) > [pid 5787] close(961) = -1 EBADF (Bad file descriptor) > [pid 5787] close(962) = -1 EBADF (Bad file descriptor) > [pid 5787] close(963) = -1 EBADF (Bad file descriptor) > [pid 5787] close(964) = -1 EBADF (Bad file descriptor) > [pid 5787] close(965) = -1 EBADF (Bad file descriptor) > [pid 5787] close(966) = -1 EBADF (Bad file descriptor) > [pid 5787] close(967) = -1 EBADF (Bad file descriptor) > [pid 5787] close(968) = -1 EBADF (Bad file descriptor) > [pid 5787] close(969) = -1 EBADF (Bad file descriptor) > [pid 5787] close(970) = -1 EBADF (Bad file descriptor) > [pid 5787] close(971) = -1 EBADF (Bad file descriptor) > [pid 5787] close(972) = -1 EBADF (Bad file descriptor) > [pid 5787] close(973) = -1 EBADF (Bad file descriptor) > [pid 5787] close(974) = -1 EBADF (Bad file descriptor) > [pid 5787] close(975) = -1 EBADF (Bad file descriptor) > [pid 5787] close(976) = -1 EBADF (Bad file descriptor) > [pid 5787] close(977) = -1 EBADF (Bad file descriptor) > [pid 5787] close(978) = -1 EBADF (Bad file descriptor) > [pid 5787] close(979) = -1 EBADF (Bad file descriptor) > [pid 5787] close(980) = -1 EBADF (Bad file descriptor) > [pid 5787] close(981) = -1 EBADF (Bad file descriptor) > [pid 5787] close(982) = -1 EBADF (Bad file descriptor) > [pid 5787] close(983) = -1 EBADF (Bad file descriptor) > [pid 5787] close(984) = -1 EBADF (Bad file descriptor) > [pid 5787] close(985) = -1 EBADF (Bad file descriptor) > [pid 5787] close(986) = -1 EBADF (Bad file descriptor) > [pid 5787] close(987) = -1 EBADF (Bad file descriptor) > [pid 5787] close(988) = -1 EBADF (Bad file descriptor) > [pid 5787] close(989) = -1 EBADF (Bad file descriptor) > [pid 5787] close(990) = -1 EBADF (Bad file descriptor) > [pid 5787] close(991) = -1 EBADF (Bad file descriptor) > [pid 5787] close(992) = -1 EBADF (Bad file descriptor) > [pid 5787] close(993) = -1 EBADF (Bad file descriptor) > [pid 5787] close(994) = -1 EBADF (Bad file descriptor) > [pid 5787] close(995) = -1 EBADF (Bad file descriptor) > [pid 5787] close(996) = -1 EBADF (Bad file descriptor) > [pid 5787] close(997) = -1 EBADF (Bad file descriptor) > [pid 5787] close(998) = -1 EBADF (Bad file descriptor) > [pid 5787] close(999) = -1 EBADF (Bad file descriptor) > [pid 5787] close(1000) = -1 EBADF (Bad file descriptor) > [pid 5787] close(1001) = -1 EBADF (Bad file descriptor) > [pid 5787] close(1002) = -1 EBADF (Bad file descriptor) > [pid 5787] close(1003) = -1 EBADF (Bad file descriptor) > [pid 5787] close(1004) = -1 EBADF (Bad file descriptor) > [pid 5787] close(1005) = -1 EBADF (Bad file descriptor) > [pid 5787] close(1006) = -1 EBADF (Bad file descriptor) > [pid 5787] close(1007) = -1 EBADF (Bad file descriptor) > [pid 5787] close(1008) = -1 EBADF (Bad file descriptor) > [pid 5787] close(1009) = -1 EBADF (Bad file descriptor) > [pid 5787] close(1010) = -1 EBADF (Bad file descriptor) > [pid 5787] close(1011) = -1 EBADF (Bad file descriptor) > [pid 5787] close(1012) = -1 EBADF (Bad file descriptor) > [pid 5787] close(1013) = -1 EBADF (Bad file descriptor) > [pid 5787] close(1014) = -1 EBADF (Bad file descriptor) > [pid 5787] close(1015) = -1 EBADF (Bad file descriptor) > [pid 5787] close(1016) = -1 EBADF (Bad file descriptor) > [pid 5787] close(1017) = -1 EBADF (Bad file descriptor) > [pid 5787] close(1018) = -1 EBADF (Bad file descriptor) > [pid 5787] close(1019) = -1 EBADF (Bad file descriptor) > [pid 5787] close(1020) = -1 EBADF (Bad file descriptor) > [pid 5787] close(1021) = -1 EBADF (Bad file descriptor) > [pid 5787] close(1022) = -1 EBADF (Bad file descriptor) > [pid 5787] close(1023) = -1 EBADF (Bad file descriptor) > [pid 5787] execve("/usr/lib/gnupg2/pcsc-wrapper", ["pcsc-wrapper", "--", "1", "libpcsclite.so.1"], [/* 38 vars */]) = 0 > [pid 5787] brk(0) = 0x504000 > [pid 5787] mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2ad1f7e6a000 > [pid 5787] uname({sys="Linux", node="seldon", ...}) = 0 > [pid 5787] access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) > [pid 5787] mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2ad1f7e6b000 > [pid 5787] access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) > [pid 5787] open("tls/x86_64/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) > [pid 5787] open("tls/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) > [pid 5787] open("x86_64/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) > [pid 5787] open("libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) > [pid 5787] open("/emul/ia32-linux/usr/lib/tls/x86_64/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) > [pid 5787] stat("/emul/ia32-linux/usr/lib/tls/x86_64", 0x7fffb2c586a0) = -1 ENOENT (No such file or directory) > [pid 5787] open("/emul/ia32-linux/usr/lib/tls/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) > [pid 5787] stat("/emul/ia32-linux/usr/lib/tls", 0x7fffb2c586a0) = -1 ENOENT (No such file or directory) > [pid 5787] open("/emul/ia32-linux/usr/lib/x86_64/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) > [pid 5787] stat("/emul/ia32-linux/usr/lib/x86_64", 0x7fffb2c586a0) = -1 ENOENT (No such file or directory) > [pid 5787] open("/emul/ia32-linux/usr/lib/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) > [pid 5787] stat("/emul/ia32-linux/usr/lib", {st_mode=S_IFDIR|0755, st_size=12288, ...}) = 0 > [pid 5787] open("/etc/ld.so.cache", O_RDONLY) = 3 > [pid 5787] fstat(3, {st_mode=S_IFREG|0644, st_size=84990, ...}) = 0 > [pid 5787] mmap(NULL, 84990, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2ad1f7e6d000 > [pid 5787] close(3) = 0 > [pid 5787] access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) > [pid 5787] open("/lib/libdl.so.2", O_RDONLY) = 3 > [pid 5787] read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0 \16\0\0"..., 832) = 832 > [pid 5787] fstat(3, {st_mode=S_IFREG|0644, st_size=14624, ...}) = 0 > [pid 5787] mmap(NULL, 2109728, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x2ad1f806b000 > [pid 5787] mprotect(0x2ad1f806d000, 2097152, PROT_NONE) = 0 > [pid 5787] mmap(0x2ad1f826d000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x2ad1f826d000 > [pid 5787] close(3) = 0 > [pid 5787] open("tls/x86_64/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) > [pid 5787] open("tls/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) > [pid 5787] open("x86_64/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) > [pid 5787] open("libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) > [pid 5787] open("/emul/ia32-linux/usr/lib/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) > [pid 5787] access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) > [pid 5787] open("/lib/libc.so.6", O_RDONLY) = 3 > [pid 5787] read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\331"..., 832) = 832 > [pid 5787] fstat(3, {st_mode=S_IFREG|0755, st_size=1367464, ...}) = 0 > [pid 5787] mmap(NULL, 3473592, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x2ad1f826f000 > [pid 5787] mprotect(0x2ad1f83b7000, 2093056, PROT_NONE) = 0 > [pid 5787] mmap(0x2ad1f85b6000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x147000) = 0x2ad1f85b6000 > [pid 5787] mmap(0x2ad1f85bb000, 16568, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2ad1f85bb000 > [pid 5787] close(3) = 0 > [pid 5787] mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2ad1f85c0000 > [pid 5787] arch_prctl(ARCH_SET_FS, 0x2ad1f85c06f0) = 0 > [pid 5787] mprotect(0x2ad1f85b6000, 12288, PROT_READ) = 0 > [pid 5787] munmap(0x2ad1f7e6d000, 84990) = 0 > [pid 5787] open("tls/x86_64/libpcsclite.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) > [pid 5787] open("tls/libpcsclite.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) > [pid 5787] open("x86_64/libpcsclite.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) > [pid 5787] open("libpcsclite.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) > [pid 5787] open("/emul/ia32-linux/usr/lib/libpcsclite.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) > [pid 5787] open("/etc/ld.so.cache", O_RDONLY) = 3 > [pid 5787] fstat(3, {st_mode=S_IFREG|0644, st_size=84990, ...}) = 0 > [pid 5787] mmap(NULL, 84990, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2ad1f7e6d000 > [pid 5787] close(3) = 0 > [pid 5787] access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) > [pid 5787] open("/lib/tls/x86_64/libpcsclite.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) > [pid 5787] stat("/lib/tls/x86_64", 0x7fffb2c57a90) = -1 ENOENT (No such file or directory) > [pid 5787] open("/lib/tls/libpcsclite.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) > [pid 5787] stat("/lib/tls", 0x7fffb2c57a90) = -1 ENOENT (No such file or directory) > [pid 5787] open("/lib/x86_64/libpcsclite.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) > [pid 5787] stat("/lib/x86_64", 0x7fffb2c57a90) = -1 ENOENT (No such file or directory) > [pid 5787] open("/lib/libpcsclite.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) > [pid 5787] stat("/lib", {st_mode=S_IFDIR|0755, st_size=12288, ...}) = 0 > [pid 5787] open("/usr/lib/tls/x86_64/libpcsclite.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) > [pid 5787] stat("/usr/lib/tls/x86_64", 0x7fffb2c57a90) = -1 ENOENT (No such file or directory) > [pid 5787] open("/usr/lib/tls/libpcsclite.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) > [pid 5787] stat("/usr/lib/tls", 0x7fffb2c57a90) = -1 ENOENT (No such file or directory) > [pid 5787] open("/usr/lib/x86_64/libpcsclite.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) > [pid 5787] stat("/usr/lib/x86_64", 0x7fffb2c57a90) = -1 ENOENT (No such file or directory) > [pid 5787] open("/usr/lib/libpcsclite.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) > [pid 5787] stat("/usr/lib", {st_mode=S_IFDIR|0755, st_size=86016, ...}) = 0 > [pid 5787] open("/lib/x86_64-linux-gnu/tls/x86_64/libpcsclite.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) > [pid 5787] stat("/lib/x86_64-linux-gnu/tls/x86_64", 0x7fffb2c57a90) = -1 ENOENT (No such file or directory) > [pid 5787] open("/lib/x86_64-linux-gnu/tls/libpcsclite.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) > [pid 5787] stat("/lib/x86_64-linux-gnu/tls", 0x7fffb2c57a90) = -1 ENOENT (No such file or directory) > [pid 5787] open("/lib/x86_64-linux-gnu/x86_64/libpcsclite.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) > [pid 5787] stat("/lib/x86_64-linux-gnu/x86_64", 0x7fffb2c57a90) = -1 ENOENT (No such file or directory) > [pid 5787] open("/lib/x86_64-linux-gnu/libpcsclite.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) > [pid 5787] stat("/lib/x86_64-linux-gnu", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 > [pid 5787] open("/usr/lib/x86_64-linux-gnu/tls/x86_64/libpcsclite.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) > [pid 5787] stat("/usr/lib/x86_64-linux-gnu/tls/x86_64", 0x7fffb2c57a90) = -1 ENOENT (No such file or directory) > [pid 5787] open("/usr/lib/x86_64-linux-gnu/tls/libpcsclite.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) > [pid 5787] stat("/usr/lib/x86_64-linux-gnu/tls", 0x7fffb2c57a90) = -1 ENOENT (No such file or directory) > [pid 5787] open("/usr/lib/x86_64-linux-gnu/x86_64/libpcsclite.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) > [pid 5787] stat("/usr/lib/x86_64-linux-gnu/x86_64", 0x7fffb2c57a90) = -1 ENOENT (No such file or directory) > [pid 5787] open("/usr/lib/x86_64-linux-gnu/libpcsclite.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) > [pid 5787] stat("/usr/lib/x86_64-linux-gnu", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 > [pid 5787] brk(0) = 0x504000 > [pid 5787] brk(0x525000) = 0x525000 > [pid 5787] munmap(0x2ad1f7e6d000, 84990) = 0 > [pid 5787] write(2, "pcsc-wrapper: failed to open dri"..., 131) = 131 > [pid 5787] exit_group(1) = ? > Process 5787 detached > <... select resumed> ) = 0 (Timeout) > rt_sigprocmask(SIG_SETMASK, ~[KILL STOP RTMIN RT_1], NULL, 8) = 0 > rt_sigaction(SIGHUP, {SIG_DFL}, NULL, 8) = 0 > rt_sigaction(SIGINT, {SIG_DFL}, NULL, 8) = 0 > rt_sigaction(SIGUSR1, {SIG_DFL}, NULL, 8) = 0 > rt_sigaction(SIGUSR2, {SIG_DFL}, NULL, 8) = 0 > rt_sigaction(SIGTERM, {SIG_DFL}, NULL, 8) = 0 > gettimeofday({1183111443, 485121}, NULL) = 0 > rt_sigprocmask(SIG_SETMASK, [], ~[KILL STOP RTMIN RT_1], 8) = 0 > wait4(5786, NULL, WNOHANG, NULL) = 5786 > fcntl(10, F_GETFL) = 0x1 (flags O_WRONLY) > fcntl(10, F_GETFL) = 0x1 (flags O_WRONLY) > fcntl(10, F_SETFL, O_WRONLY|O_NONBLOCK) = 0 > select(11, NULL, [10], NULL, {0, 0}) = 1 (out [10], left {0, 0}) > write(10, "\1\0\0\0\0", 5) = -1 EPIPE (Broken pipe) > --- SIGPIPE (Broken pipe) @ 0 (0) --- > fcntl(10, F_GETFL) = 0x801 (flags O_WRONLY|O_NONBLOCK) > fcntl(10, F_SETFL, O_WRONLY) = 0 > time(NULL) = 1183111443 > write(5, "2007-06-29 12:04:03 scdaemon[578"..., 90) = 90 > close(10) = 0 > close(7) = 0 > kill(5786, SIGTERM) = -1 ESRCH (No such process) > write(5, "scdaemon[5785.0] DBG: -> OK GNU "..., 71) = 71 > fcntl(1, F_GETFL) = 0x8001 (flags O_WRONLY|O_LARGEFILE) > fcntl(1, F_GETFL) = 0x8001 (flags O_WRONLY|O_LARGEFILE) > fcntl(1, F_SETFL, O_WRONLY|O_NONBLOCK|O_LARGEFILE) = 0 > select(2, NULL, [1], NULL, {0, 0}) = 1 (out [1], left {0, 0}) > write(1, "OK GNU Privacy Guard\'s Smartcard"..., 45OK GNU Privacy Guard's Smartcard server ready) = 45 > fcntl(1, F_GETFL) = 0x8801 (flags O_WRONLY|O_NONBLOCK|O_LARGEFILE) > fcntl(1, F_SETFL, O_WRONLY|O_LARGEFILE) = 0 > fcntl(1, F_GETFL) = 0x8001 (flags O_WRONLY|O_LARGEFILE) > fcntl(1, F_GETFL) = 0x8001 (flags O_WRONLY|O_LARGEFILE) > fcntl(1, F_SETFL, O_WRONLY|O_NONBLOCK|O_LARGEFILE) = 0 > select(2, NULL, [1], NULL, {0, 0}) = 1 (out [1], left {0, 0}) > write(1, "\n", 1 > ) = 1 > fcntl(1, F_GETFL) = 0x8801 (flags O_WRONLY|O_NONBLOCK|O_LARGEFILE) > fcntl(1, F_SETFL, O_WRONLY|O_LARGEFILE) = 0 > fcntl(0, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE) > fcntl(0, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE) > select(1, [0], NULL, NULL, {0, 0}) = 0 (Timeout) > fcntl(0, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE) > rt_sigprocmask(SIG_SETMASK, ~[KILL STOP RTMIN RT_1], [], 8) = 0 > gettimeofday({1183111443, 488428}, NULL) = 0 > rt_sigpending([]) = 0 > read(3, 0x54f0d0, 128) = -1 EAGAIN (Resource temporarily unavailable) > rt_sigaction(SIGHUP, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGINT, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGUSR1, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGUSR2, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGTERM, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigprocmask(SIG_SETMASK, [], ~[KILL STOP RTMIN RT_1], 8) = 0 > select(1024, [0 3 6], [], [], {1, 710631}) = 0 (Timeout) > rt_sigprocmask(SIG_SETMASK, ~[KILL STOP RTMIN RT_1], NULL, 8) = 0 > rt_sigaction(SIGHUP, {SIG_DFL}, NULL, 8) = 0 > rt_sigaction(SIGINT, {SIG_DFL}, NULL, 8) = 0 > rt_sigaction(SIGUSR1, {SIG_DFL}, NULL, 8) = 0 > rt_sigaction(SIGUSR2, {SIG_DFL}, NULL, 8) = 0 > rt_sigaction(SIGTERM, {SIG_DFL}, NULL, 8) = 0 > gettimeofday({1183111445, 201193}, NULL) = 0 > rt_sigprocmask(SIG_SETMASK, [], ~[KILL STOP RTMIN RT_1], 8) = 0 > gettimeofday({1183111445, 201433}, NULL) = 0 > select(1024, [6], NULL, NULL, {0, 0}) = 0 (Timeout) > rt_sigprocmask(SIG_SETMASK, ~[KILL STOP RTMIN RT_1], [], 8) = 0 > gettimeofday({1183111445, 201764}, NULL) = 0 > rt_sigpending([]) = 0 > read(3, 0x54f0d0, 128) = -1 EAGAIN (Resource temporarily unavailable) > rt_sigaction(SIGHUP, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGINT, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGUSR1, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGUSR2, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGTERM, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigprocmask(SIG_SETMASK, [], ~[KILL STOP RTMIN RT_1], 8) = 0 > select(1024, [0 3 6], [], [], {1, 999669}) = 0 (Timeout) > rt_sigprocmask(SIG_SETMASK, ~[KILL STOP RTMIN RT_1], NULL, 8) = 0 > rt_sigaction(SIGHUP, {SIG_DFL}, NULL, 8) = 0 > rt_sigaction(SIGINT, {SIG_DFL}, NULL, 8) = 0 > rt_sigaction(SIGUSR1, {SIG_DFL}, NULL, 8) = 0 > rt_sigaction(SIGUSR2, {SIG_DFL}, NULL, 8) = 0 > rt_sigaction(SIGTERM, {SIG_DFL}, NULL, 8) = 0 > gettimeofday({1183111447, 205267}, NULL) = 0 > rt_sigprocmask(SIG_SETMASK, [], ~[KILL STOP RTMIN RT_1], 8) = 0 > gettimeofday({1183111447, 205460}, NULL) = 0 > select(1024, [6], NULL, NULL, {0, 0}) = 0 (Timeout) > rt_sigprocmask(SIG_SETMASK, ~[KILL STOP RTMIN RT_1], [], 8) = 0 > gettimeofday({1183111447, 205791}, NULL) = 0 > rt_sigpending([]) = 0 > read(3, 0x54f0d0, 128) = -1 EAGAIN (Resource temporarily unavailable) > rt_sigaction(SIGHUP, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGINT, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGUSR1, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGUSR2, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGTERM, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigprocmask(SIG_SETMASK, [], ~[KILL STOP RTMIN RT_1], 8) = 0 > select(1024, [0 3 6], [], [], {1, 999669}) = 0 (Timeout) > rt_sigprocmask(SIG_SETMASK, ~[KILL STOP RTMIN RT_1], NULL, 8) = 0 > rt_sigaction(SIGHUP, {SIG_DFL}, NULL, 8) = 0 > rt_sigaction(SIGINT, {SIG_DFL}, NULL, 8) = 0 > rt_sigaction(SIGUSR1, {SIG_DFL}, NULL, 8) = 0 > rt_sigaction(SIGUSR2, {SIG_DFL}, NULL, 8) = 0 > rt_sigaction(SIGTERM, {SIG_DFL}, NULL, 8) = 0 > gettimeofday({1183111449, 209364}, NULL) = 0 > rt_sigprocmask(SIG_SETMASK, [], ~[KILL STOP RTMIN RT_1], 8) = 0 > gettimeofday({1183111449, 209556}, NULL) = 0 > select(1024, [6], NULL, NULL, {0, 0}) = 0 (Timeout) > rt_sigprocmask(SIG_SETMASK, ~[KILL STOP RTMIN RT_1], [], 8) = 0 > gettimeofday({1183111449, 209886}, NULL) = 0 > rt_sigpending([]) = 0 > read(3, 0x54f0d0, 128) = -1 EAGAIN (Resource temporarily unavailable) > rt_sigaction(SIGHUP, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGINT, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGUSR1, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGUSR2, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGTERM, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigprocmask(SIG_SETMASK, [], ~[KILL STOP RTMIN RT_1], 8) = 0 > select(1024, [0 3 6], [], [], {1, 999670}) = 0 (Timeout) > rt_sigprocmask(SIG_SETMASK, ~[KILL STOP RTMIN RT_1], NULL, 8) = 0 > rt_sigaction(SIGHUP, {SIG_DFL}, NULL, 8) = 0 > rt_sigaction(SIGINT, {SIG_DFL}, NULL, 8) = 0 > rt_sigaction(SIGUSR1, {SIG_DFL}, NULL, 8) = 0 > rt_sigaction(SIGUSR2, {SIG_DFL}, NULL, 8) = 0 > rt_sigaction(SIGTERM, {SIG_DFL}, NULL, 8) = 0 > gettimeofday({1183111451, 213365}, NULL) = 0 > rt_sigprocmask(SIG_SETMASK, [], ~[KILL STOP RTMIN RT_1], 8) = 0 > gettimeofday({1183111451, 213560}, NULL) = 0 > select(1024, [6], NULL, NULL, {0, 0}) = 0 (Timeout) > rt_sigprocmask(SIG_SETMASK, ~[KILL STOP RTMIN RT_1], [], 8) = 0 > gettimeofday({1183111451, 213890}, NULL) = 0 > rt_sigpending([]) = 0 > read(3, 0x54f0d0, 128) = -1 EAGAIN (Resource temporarily unavailable) > rt_sigaction(SIGHUP, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGINT, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGUSR1, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGUSR2, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGTERM, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigprocmask(SIG_SETMASK, [], ~[KILL STOP RTMIN RT_1], 8) = 0 > select(1024, [0 3 6], [], [], {1, 999670}) = 0 (Timeout) > rt_sigprocmask(SIG_SETMASK, ~[KILL STOP RTMIN RT_1], NULL, 8) = 0 > rt_sigaction(SIGHUP, {SIG_DFL}, NULL, 8) = 0 > rt_sigaction(SIGINT, {SIG_DFL}, NULL, 8) = 0 > rt_sigaction(SIGUSR1, {SIG_DFL}, NULL, 8) = 0 > rt_sigaction(SIGUSR2, {SIG_DFL}, NULL, 8) = 0 > rt_sigaction(SIGTERM, {SIG_DFL}, NULL, 8) = 0 > gettimeofday({1183111453, 217407}, NULL) = 0 > rt_sigprocmask(SIG_SETMASK, [], ~[KILL STOP RTMIN RT_1], 8) = 0 > gettimeofday({1183111453, 217600}, NULL) = 0 > select(1024, [6], NULL, NULL, {0, 0}) = 0 (Timeout) > rt_sigprocmask(SIG_SETMASK, ~[KILL STOP RTMIN RT_1], [], 8) = 0 > gettimeofday({1183111453, 217934}, NULL) = 0 > rt_sigpending([]) = 0 > read(3, 0x54f0d0, 128) = -1 EAGAIN (Resource temporarily unavailable) > rt_sigaction(SIGHUP, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGINT, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGUSR1, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGUSR2, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGTERM, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigprocmask(SIG_SETMASK, [], ~[KILL STOP RTMIN RT_1], 8) = 0 > select(1024, [0 3 6], [], [], {1, 999666}) = 0 (Timeout) > rt_sigprocmask(SIG_SETMASK, ~[KILL STOP RTMIN RT_1], NULL, 8) = 0 > rt_sigaction(SIGHUP, {SIG_DFL}, NULL, 8) = 0 > rt_sigaction(SIGINT, {SIG_DFL}, NULL, 8) = 0 > rt_sigaction(SIGUSR1, {SIG_DFL}, NULL, 8) = 0 > rt_sigaction(SIGUSR2, {SIG_DFL}, NULL, 8) = 0 > rt_sigaction(SIGTERM, {SIG_DFL}, NULL, 8) = 0 > gettimeofday({1183111455, 221421}, NULL) = 0 > rt_sigprocmask(SIG_SETMASK, [], ~[KILL STOP RTMIN RT_1], 8) = 0 > gettimeofday({1183111455, 221614}, NULL) = 0 > select(1024, [6], NULL, NULL, {0, 0}) = 0 (Timeout) > rt_sigprocmask(SIG_SETMASK, ~[KILL STOP RTMIN RT_1], [], 8) = 0 > gettimeofday({1183111455, 221947}, NULL) = 0 > rt_sigpending([]) = 0 > read(3, 0x54f0d0, 128) = -1 EAGAIN (Resource temporarily unavailable) > rt_sigaction(SIGHUP, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGINT, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGUSR1, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGUSR2, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGTERM, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigprocmask(SIG_SETMASK, [], ~[KILL STOP RTMIN RT_1], 8) = 0 > select(1024, [0 3 6], [], [], {1, 999667}) = 0 (Timeout) > rt_sigprocmask(SIG_SETMASK, ~[KILL STOP RTMIN RT_1], NULL, 8) = 0 > rt_sigaction(SIGHUP, {SIG_DFL}, NULL, 8) = 0 > rt_sigaction(SIGINT, {SIG_DFL}, NULL, 8) = 0 > rt_sigaction(SIGUSR1, {SIG_DFL}, NULL, 8) = 0 > rt_sigaction(SIGUSR2, {SIG_DFL}, NULL, 8) = 0 > rt_sigaction(SIGTERM, {SIG_DFL}, NULL, 8) = 0 > gettimeofday({1183111457, 225511}, NULL) = 0 > rt_sigprocmask(SIG_SETMASK, [], ~[KILL STOP RTMIN RT_1], 8) = 0 > gettimeofday({1183111457, 225703}, NULL) = 0 > select(1024, [6], NULL, NULL, {0, 0}) = 0 (Timeout) > rt_sigprocmask(SIG_SETMASK, ~[KILL STOP RTMIN RT_1], [], 8) = 0 > gettimeofday({1183111457, 226033}, NULL) = 0 > rt_sigpending([]) = 0 > read(3, 0x54f0d0, 128) = -1 EAGAIN (Resource temporarily unavailable) > rt_sigaction(SIGHUP, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGINT, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGUSR1, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGUSR2, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGTERM, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigprocmask(SIG_SETMASK, [], ~[KILL STOP RTMIN RT_1], 8) = 0 > select(1024, [0 3 6], [], [], {1, 999670}) = 0 (Timeout) > rt_sigprocmask(SIG_SETMASK, ~[KILL STOP RTMIN RT_1], NULL, 8) = 0 > rt_sigaction(SIGHUP, {SIG_DFL}, NULL, 8) = 0 > rt_sigaction(SIGINT, {SIG_DFL}, NULL, 8) = 0 > rt_sigaction(SIGUSR1, {SIG_DFL}, NULL, 8) = 0 > rt_sigaction(SIGUSR2, {SIG_DFL}, NULL, 8) = 0 > rt_sigaction(SIGTERM, {SIG_DFL}, NULL, 8) = 0 > gettimeofday({1183111459, 229596}, NULL) = 0 > rt_sigprocmask(SIG_SETMASK, [], ~[KILL STOP RTMIN RT_1], 8) = 0 > gettimeofday({1183111459, 229793}, NULL) = 0 > select(1024, [6], NULL, NULL, {0, 0}) = 0 (Timeout) > rt_sigprocmask(SIG_SETMASK, ~[KILL STOP RTMIN RT_1], [], 8) = 0 > gettimeofday({1183111459, 230127}, NULL) = 0 > rt_sigpending([]) = 0 > read(3, 0x54f0d0, 128) = -1 EAGAIN (Resource temporarily unavailable) > rt_sigaction(SIGHUP, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGINT, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGUSR1, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGUSR2, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGTERM, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigprocmask(SIG_SETMASK, [], ~[KILL STOP RTMIN RT_1], 8) = 0 > select(1024, [0 3 6], [], [], {1, 999666}) = 0 (Timeout) > rt_sigprocmask(SIG_SETMASK, ~[KILL STOP RTMIN RT_1], NULL, 8) = 0 > rt_sigaction(SIGHUP, {SIG_DFL}, NULL, 8) = 0 > rt_sigaction(SIGINT, {SIG_DFL}, NULL, 8) = 0 > rt_sigaction(SIGUSR1, {SIG_DFL}, NULL, 8) = 0 > rt_sigaction(SIGUSR2, {SIG_DFL}, NULL, 8) = 0 > rt_sigaction(SIGTERM, {SIG_DFL}, NULL, 8) = 0 > gettimeofday({1183111461, 233634}, NULL) = 0 > rt_sigprocmask(SIG_SETMASK, [], ~[KILL STOP RTMIN RT_1], 8) = 0 > gettimeofday({1183111461, 233829}, NULL) = 0 > select(1024, [6], NULL, NULL, {0, 0}) = 0 (Timeout) > rt_sigprocmask(SIG_SETMASK, ~[KILL STOP RTMIN RT_1], [], 8) = 0 > gettimeofday({1183111461, 234161}, NULL) = 0 > rt_sigpending([]) = 0 > read(3, 0x54f0d0, 128) = -1 EAGAIN (Resource temporarily unavailable) > rt_sigaction(SIGHUP, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGINT, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGUSR1, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGUSR2, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGTERM, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigprocmask(SIG_SETMASK, [], ~[KILL STOP RTMIN RT_1], 8) = 0 > select(1024, [0 3 6], [], [], {1, 999668}) = 0 (Timeout) > rt_sigprocmask(SIG_SETMASK, ~[KILL STOP RTMIN RT_1], NULL, 8) = 0 > rt_sigaction(SIGHUP, {SIG_DFL}, NULL, 8) = 0 > rt_sigaction(SIGINT, {SIG_DFL}, NULL, 8) = 0 > rt_sigaction(SIGUSR1, {SIG_DFL}, NULL, 8) = 0 > rt_sigaction(SIGUSR2, {SIG_DFL}, NULL, 8) = 0 > rt_sigaction(SIGTERM, {SIG_DFL}, NULL, 8) = 0 > gettimeofday({1183111463, 237670}, NULL) = 0 > rt_sigprocmask(SIG_SETMASK, [], ~[KILL STOP RTMIN RT_1], 8) = 0 > gettimeofday({1183111463, 237862}, NULL) = 0 > select(1024, [6], NULL, NULL, {0, 0}) = 0 (Timeout) > rt_sigprocmask(SIG_SETMASK, ~[KILL STOP RTMIN RT_1], [], 8) = 0 > gettimeofday({1183111463, 238197}, NULL) = 0 > rt_sigpending([]) = 0 > read(3, 0x54f0d0, 128) = -1 EAGAIN (Resource temporarily unavailable) > rt_sigaction(SIGHUP, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGINT, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGUSR1, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGUSR2, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGTERM, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigprocmask(SIG_SETMASK, [], ~[KILL STOP RTMIN RT_1], 8) = 0 > select(1024, [0 3 6], [], [], {1, 999665}) = 0 (Timeout) > rt_sigprocmask(SIG_SETMASK, ~[KILL STOP RTMIN RT_1], NULL, 8) = 0 > rt_sigaction(SIGHUP, {SIG_DFL}, NULL, 8) = 0 > rt_sigaction(SIGINT, {SIG_DFL}, NULL, 8) = 0 > rt_sigaction(SIGUSR1, {SIG_DFL}, NULL, 8) = 0 > rt_sigaction(SIGUSR2, {SIG_DFL}, NULL, 8) = 0 > rt_sigaction(SIGTERM, {SIG_DFL}, NULL, 8) = 0 > gettimeofday({1183111465, 237743}, NULL) = 0 > rt_sigprocmask(SIG_SETMASK, [], ~[KILL STOP RTMIN RT_1], 8) = 0 > gettimeofday({1183111465, 237939}, NULL) = 0 > select(1024, [6], NULL, NULL, {0, 0}) = 0 (Timeout) > rt_sigprocmask(SIG_SETMASK, ~[KILL STOP RTMIN RT_1], [], 8) = 0 > gettimeofday({1183111465, 238271}, NULL) = 0 > rt_sigpending([]) = 0 > read(3, 0x54f0d0, 128) = -1 EAGAIN (Resource temporarily unavailable) > rt_sigaction(SIGHUP, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGINT, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGUSR1, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGUSR2, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGTERM, {0x2b4f23be79f0, ~[RTMIN RT_1], SA_RESTORER, 0x2b4f2424cca0}, {SIG_DFL}, 8) = 0 > rt_sigprocmask(SIG_SETMASK, [], ~[KILL STOP RTMIN RT_1], 8) = 0 > select(1024, [0 3 6], [], [], {1, 999668}