From klaus at flittner.org Sun Nov 8 15:46:52 2009 From: klaus at flittner.org (Klaus Flittner) Date: Sun, 8 Nov 2009 15:46:52 +0100 Subject: [PATCH] change decrypt to support larger keys with openpgp card (was: OpenPGP card and 4096 bit keys) In-Reply-To: <87oco27c06.fsf@vigenere.g10code.de> References: <20091019195513.3bd0f90d@earth.lan> <87oco27c06.fsf@vigenere.g10code.de> Message-ID: <20091108154652.7abc0503@moon> Werner Koch said: > On Mon, 19 Oct 2009 19:55, klaus at flittner.org said: > > 2. Change the protocol used for genkey and decrypt > > - genkey would then return the publich key like readkey as s-expression > > - decrypt would inquire the encrypted message instead of a setdata > > before the call of decrypt > > Right. However, the change will be easier: We send the key using > several status lines. > > This will go into GnuPG 2.1 as time permits. Attached you find a patch which addresses the decrypt issue. It changes the setdata command of scdaemon to support chaining. The first part of the data is transfered like before. If there is more data it can be concatenated to the first using SETDATA --more [data] The two callers of PKDECRYPT (in g10/call-agent.c and agent/call-scd.c) are changed to use this chaining mechanism. Regards Klaus Flittner -------------- next part -------------- A non-text attachment was scrubbed... Name: pkdecrypt.patch Type: text/x-patch Size: 3804 bytes Desc: not available URL: From wk at gnupg.org Mon Nov 9 17:53:51 2009 From: wk at gnupg.org (Werner Koch) Date: Mon, 09 Nov 2009 17:53:51 +0100 Subject: [PATCH] change decrypt to support larger keys with openpgp card In-Reply-To: <20091108154652.7abc0503@moon> (Klaus Flittner's message of "Sun, 8 Nov 2009 15:46:52 +0100") References: <20091019195513.3bd0f90d@earth.lan> <87oco27c06.fsf@vigenere.g10code.de> <20091108154652.7abc0503@moon> Message-ID: <87vdhjvduo.fsf@vigenere.g10code.de> On Sun, 8 Nov 2009 15:46, klaus at flittner.org said: > Attached you find a patch which addresses the decrypt issue. > It changes the setdata command of scdaemon to support chaining. Sorry, I can't apply such a patch without having a copyright assigment to the FSF. It is not an urgent feature, though. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From hoangvietphan at yahoo.com Wed Nov 11 18:20:19 2009 From: hoangvietphan at yahoo.com (Viet H. Phan) Date: Wed, 11 Nov 2009 09:20:19 -0800 (PST) Subject: Error importing public key Message-ID: <824649.13873.qm@web50801.mail.re2.yahoo.com> Hi, My partner sent me an ASCII-armored PGP public key (the attached file) that had been generated using GnuPG v2.0.12. Then I failed to import that key to the GnuPG 2.0.12 at my side (I used the GPA 0.9.0 interface in the Gpg4win package 2.0.1) - I got the error message "No OpenPGP data". Could you take a look at the issue to see what happened? Thanks, Viet -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: TPV-Error.pgp Type: application/octet-stream Size: 1736 bytes Desc: not available URL: From John at Mozilla-Enigmail.org Wed Nov 11 20:38:17 2009 From: John at Mozilla-Enigmail.org (John Clizbe) Date: Wed, 11 Nov 2009 13:38:17 -0600 Subject: Error importing public key In-Reply-To: <824649.13873.qm@web50801.mail.re2.yahoo.com> References: <824649.13873.qm@web50801.mail.re2.yahoo.com> Message-ID: <4AFB12A9.90309@Mozilla-Enigmail.org> Viet H. Phan wrote: > Hi, > > My partner sent me an ASCII-armored PGP public key (the attached file) > that had been generated using GnuPG v2.0.12. Then I failed to import > that key to the GnuPG 2.0.12 at my side (I used the GPA 0.9.0 interface > in the Gpg4win package 2.0.1) - I got the error message "No OpenPGP data". > > Could you take a look at the issue to see what happened? > > Thanks, > Viet Well, what I had when I saved it was one long line of unicode with embedded CRs. Breaking up the lines and removing the unicode header I got a file that would import. Was the original key sent from a Mac? -- John P. Clizbe Inet:John (a) Mozilla-Enigmail.org You can't spell fiasco without SCO. hkp://keyserver.gingerbear.net or mailto:pgp-public-keys at gingerbear.net?subject=HELP Q:"Just how do the residents of Haiku, Hawai'i hold conversations?" A:"An odd melody / island voices on the winds / surplus of vowels" -------------- next part -------------- A non-text attachment was scrubbed... Name: TPV-Error.asc Type: application/pgp-signature Size: 1733 bytes Desc: not available URL: From hoangvietphan at yahoo.com Thu Nov 12 04:03:54 2009 From: hoangvietphan at yahoo.com (Viet H. Phan) Date: Wed, 11 Nov 2009 19:03:54 -0800 (PST) Subject: Error importing public key In-Reply-To: <4AFB12A9.90309@Mozilla-Enigmail.org> Message-ID: <427124.59820.qm@web50807.mail.re2.yahoo.com> Hi, I don't know if the original key was from a Mac. I got no issues when I imported the original key to PGP Desktop (v9.8). The original key can be also read by the PGPdump tool (http://www.pgpdump.net/) without any issues. Might there be any bugs in GnuPG 2.0.12? As the key was generated by GnuPG 2.0.12, but then couldn't be imported to GnuPG 2.0.12 ... Regards, Viet --- On Thu, 11/12/09, John Clizbe wrote: From: John Clizbe Subject: Re: Error importing public key To: "GnuPG-Devel >> GnuPG Developers" Cc: "Viet H. Phan" Date: Thursday, November 12, 2009, 2:38 AM Viet H. Phan wrote: > Hi, > > My partner sent me an ASCII-armored PGP public key (the attached file) > that had been generated using GnuPG v2.0.12. Then I failed to import > that key to the GnuPG 2.0.12 at my side (I used the GPA 0.9.0 interface > in the Gpg4win package 2.0.1) - I got the error message "No OpenPGP data". > > Could you take a look at the issue to see what happened? > > Thanks, > Viet Well, what I had when I saved it was one long line of unicode with embedded CRs. Breaking up the lines and removing the unicode header I got a file that would import. Was the original key sent from a Mac? -- John P. Clizbe? ? ? ? ? ? ? ? ? ? ? Inet:John (a) Mozilla-Enigmail.org You can't spell fiasco without SCO. hkp://keyserver.gingerbear.net? or ? ???mailto:pgp-public-keys at gingerbear.net?subject=HELP Q:"Just how do the residents of Haiku, Hawai'i hold conversations?" A:"An odd melody / island voices on the winds / surplus of vowels" -------------- next part -------------- An HTML attachment was scrubbed... URL: From bernhard at intevation.de Thu Nov 12 18:24:08 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 12 Nov 2009 18:24:08 +0100 Subject: keyserver scheme http broken? Message-ID: <200911121824.11818.bernhard@intevation.de> I might miss something here, but for me on gnupg 2.0.13 (and 2.0.11) retrieving keys via the "http://" scheme seems to be broken. (Also it seem that --search-keys does not work with "http", although a lot of people claim that "http" is just "hkp" over port 80. ) Any ideas? gpg2 --keyserver hkp://pgp.surfnet.nl --keyserver-options verbose,verbose,verbose,debug --recv-keys DA4A1116 gpg: fordere Schl?ssel DA4A1116 von hkp-Server pgp.surfnet.nl an gpgkeys: curl version = libcurl/7.15.5 GnuTLS/1.4.4 zlib/1.2.3 libidn/0.6.5 Host: pgp.surfnet.nl Command: GET gpgkeys: HTTP URL is `http://pgp.surfnet.nl:11371/pks/lookup?op=get&options=mr&search=0xDA4A1116' * About to connect() to pgp.surfnet.nl port 11371 [..] -> works! gpg2 --keyserver http://http-keys.gnupg.net --keyserver-options verbose,verbose,verbose,debug --recv-keys DA4A1116 gpg: fordere Schl?ssel DA4A1116 von http-Server http-keys.gnupg.net an gpgkeys: curl version = libcurl/7.15.5 GnuTLS/1.4.4 zlib/1.2.3 libidn/0.6.5 Scheme: http Host: http-keys.gnupg.net Path: / Command: GET * About to connect() to http-keys.gnupg.net port 80 * Trying 194.171.167.98... * connected * Connected to http-keys.gnupg.net (194.171.167.98) port 80 > GET / HTTP/1.1 Host: http-keys.gnupg.net Accept: */* Pragma: no-cache Cache-Control: no-cache < HTTP/1.0 200 OK < Server: sks_www/1.1.0 < Content-type: text/html; charset=UTF-8 * Closing connection #0 gpgkeys: no key data found for http://http-keys.gnupg.net/ gpg: Keine g?ltigen OpenPGP-Daten gefunden. gpg: Anzahl insgesamt bearbeiteter Schl?ssel: 0 random usage: poolsize=600 mixed=0 polls=0/0 added=0/0 outmix=0 getlvl1=0/0 getlvl2=0/0 secmem usage: 0/32768 bytes in 0 blocks bernhard at ploto:~$ gpg2 --keyserver http://pgp.surfnet.nl --keyserver-options verbose,verbose,verbose,debug --recv-keys DA4A1116 gpg: fordere Schl?ssel DA4A1116 von http-Server pgp.surfnet.nl an gpgkeys: curl version = libcurl/7.15.5 GnuTLS/1.4.4 zlib/1.2.3 libidn/0.6.5 Scheme: http Host: pgp.surfnet.nl Path: / Command: GET * About to connect() to pgp.surfnet.nl port 80 * Trying 194.171.167.98... * connected * Connected to pgp.surfnet.nl (194.171.167.98) port 80 > GET / HTTP/1.1 Host: pgp.surfnet.nl Accept: */* Pragma: no-cache Cache-Control: no-cache < HTTP/1.0 200 OK < Server: sks_www/1.1.0 < Content-type: text/html; charset=UTF-8 * Closing connection #0 gpgkeys: no key data found for http://pgp.surfnet.nl/ gpg: Keine g?ltigen OpenPGP-Daten gefunden. gpg: Anzahl insgesamt bearbeiteter Schl?ssel: 0 random usage: poolsize=600 mixed=0 polls=0/0 added=0/0 outmix=0 getlvl1=0/0 getlvl2=0/0 secmem usage: 0/32768 bytes in 0 blocks (I've also tried this with the other http-key servers from http://keystats.gnupg.net/) Best, Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From dshaw at jabberwocky.com Thu Nov 12 19:17:00 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 12 Nov 2009 13:17:00 -0500 Subject: keyserver scheme http broken? In-Reply-To: <200911121824.11818.bernhard@intevation.de> References: <200911121824.11818.bernhard@intevation.de> Message-ID: On Nov 12, 2009, at 12:24 PM, Bernhard Reiter wrote: > I might miss something here, but for me on gnupg 2.0.13 (and 2.0.11) > retrieving keys via the "http://" scheme seems to be broken. > > (Also it seem that --search-keys does not work with "http", although > a lot of > people claim that "http" is just "hkp" over port 80. ) That is not correct. hkp is basically a convention for a keyserver that runs over HTTP on a different port (11371). If you want hkp on port 80, you'd do "hkp:// whatever.example.com:80". The hkp protocol specifies how keys are to be searched for a retrieved, using HTTP as the transport. That's hkp. There isn't really a *http* keyserver (in the sense of being a database of many keys that can be queried). If you specify a http URL with the --keyserver command, you're really describing a the path to a particular file to fetch. It's not really indended for that use, and you can't --search-keys or --recv-keys a web server. David From bernhard at intevation.de Thu Nov 12 21:19:41 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 12 Nov 2009 21:19:41 +0100 Subject: keyserver scheme http broken? In-Reply-To: References: <200911121824.11818.bernhard@intevation.de> Message-ID: <200911122119.46759.bernhard@intevation.de> David, On Thursday 12 November 2009, David Shaw wrote: > On Nov 12, 2009, at 12:24 PM, Bernhard Reiter wrote: > > I might miss something here, but for me on gnupg 2.0.13 (and 2.0.11) > > retrieving keys via the "http://" scheme seems to be broken. > > > > (Also it seem that --search-keys does not work with "http", although > > a lot of > > people claim that "http" is just "hkp" over port 80. ) > > That is not correct. > > hkp is basically a convention for a keyserver that runs over HTTP on a > different port (11371). If you want hkp on port 80, you'd do "hkp:// > whatever.example.com:80". The hkp protocol specifies how keys are to > be searched for a retrieved, using HTTP as the transport. > > That's hkp. thanks for the clarification, as I've hinted upon, I believe this is underdocumented somehow. > There isn't really a *http* keyserver (in the sense of > being a database of many keys that can be queried). If you specify a > http URL with the --keyserver command, you're really describing a the > path to a particular file to fetch. It's not really indended for that > use, and you can't --search-keys or --recv-keys a web server. http://gpg4win.de/doc/gpg4win-compendium-de_21.html at least is confusing on this part (and I think Werner read over it as well). It makes the reader believer that http://keyserver.pramberger.at and http://gpg-keyserver.de could be viable "keyserver" for use with --keyserver. We (as in the Gpg4win Team, especially Emanuel) must change that. http://keystats.gnupg.net/ did not put that idea to rest, neither did the --keyserver section of gpg.texi. Na, now I know. The different port can be a problem for enterprise firewalls, though. Best, Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Deputy Germany Coordinator: fsfeurope.org. Coordinator: Kolab-Konsortium.com. Intevation GmbH, Neuer Graben 17, Osnabr?ck, DE; AG Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From dshaw at jabberwocky.com Fri Nov 13 05:12:30 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 12 Nov 2009 23:12:30 -0500 Subject: keyserver scheme http broken? In-Reply-To: <200911122119.46759.bernhard@intevation.de> References: <200911121824.11818.bernhard@intevation.de> <200911122119.46759.bernhard@intevation.de> Message-ID: On Nov 12, 2009, at 3:19 PM, Bernhard Reiter wrote: >> There isn't really a *http* keyserver (in the sense of >> being a database of many keys that can be queried). If you specify a >> http URL with the --keyserver command, you're really describing a the >> path to a particular file to fetch. It's not really indended for >> that >> use, and you can't --search-keys or --recv-keys a web server. > > http://gpg4win.de/doc/gpg4win-compendium-de_21.html at least is > confusing > on this part (and I think Werner read over it as well). It makes the > reader > believer that http://keyserver.pramberger.at and http://gpg-keyserver.de > could be viable "keyserver" for use with --keyserver. > We (as in the Gpg4win Team, especially Emanuel) must change that. The rule of thumb is that things that you can use with --keyserver are protocols where you can tell it which key you want (like hkp, ldap, or mailto) http can't do this, as there is no standard way to specify the key ID (the path to the key could be different on my web server compared to yours). It also doesn't help that the PGP product calls them "http keyservers" ! > http://keystats.gnupg.net/ did not put that idea to rest, neither did > the --keyserver section of gpg.texi. Na, now I know. The different > port can be > a problem for enterprise firewalls, though. Some keyservers run hkp over port 80 to deal with firewalls (so it's hkp://keyserver.example.com:80 in those cases). I'm not sure why 11371 was chosen instead of 80. It was set a long time ago. It might be something as simple as they needed a port >1024 so non-root could bind it, but I don't really know. Incidentally, newer (1.4.10 + 2.0.13) versions of GPG can use DNS service discovery to detect the port number for hkp automatically. I'll take a look at gpg.texi and see if I can make this a bit clearer. David From bernhard at intevation.de Fri Nov 13 09:40:14 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 13 Nov 2009 09:40:14 +0100 Subject: keyserver scheme http broken? In-Reply-To: References: <200911121824.11818.bernhard@intevation.de> <200911122119.46759.bernhard@intevation.de> Message-ID: <200911130940.17763.bernhard@intevation.de> Am Freitag, 13. November 2009 05:12:30 schrieb David Shaw: > Some keyservers run hkp over port 80 to deal with firewalls (so it's ? > hkp://keyserver.example.com:80 in those cases). ? Is there a list of those, similiar to keys.gnupg.net or http-keys.gnupg.net from http://keystats.gnupg.net/? > I'll take a look at gpg.texi and see if I can make this a bit clearer. That would be wonderful. If you are at it: I belive the "scheme" part of the example in the --keyserver option should marked as optional. It should be said which the default is then (probably hkp). I've noticed because "--keyserver keys.gnupg.net" just works and it probably uses hkp. :) Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Fri Nov 13 15:43:08 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 13 Nov 2009 15:43:08 +0100 Subject: Minor fix for dirmngr.texi Message-ID: <200911131543.11587.bernhard@intevation.de> --- dirmngr.texi-r321 2009-11-13 15:41:14.541212500 +0100 +++ dirmngr.texi.new 2009-11-13 15:42:24.009554000 +0100 @@ -307,7 +307,7 @@ @opindex options Reads configuration from @var{file} instead of from the default per-user configuration file. The default configuration file is named - at file{gpgsm.conf} and expected in the home directory. + at file{dirmngr.conf} and expected in the home directory. @item --homedir @var{dir} @opindex options -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From John at Mozilla-Enigmail.org Fri Nov 13 17:06:50 2009 From: John at Mozilla-Enigmail.org (John Clizbe) Date: Fri, 13 Nov 2009 10:06:50 -0600 Subject: keyserver scheme http broken? In-Reply-To: <200911130940.17763.bernhard@intevation.de> References: <200911121824.11818.bernhard@intevation.de> <200911122119.46759.bernhard@intevation.de> <200911130940.17763.bernhard@intevation.de> Message-ID: <4AFD841A.4040300@Mozilla-Enigmail.org> Bernhard Reiter wrote: > Am Freitag, 13. November 2009 05:12:30 schrieb David Shaw: >> Some keyservers run hkp over port 80 to deal with firewalls (so it's >> hkp://keyserver.example.com:80 in those cases). > > Is there a list of those, similiar to keys.gnupg.net or http-keys.gnupg.net > from http://keystats.gnupg.net/? See Peter Pramberger's SKS Status page, http://www.pramberger.at/peter/services/keyserver/network/ . Port 80 support is shown for both IPv4 and IPv6. -- John P. Clizbe Inet:John (a) Mozilla-Enigmail.org You can't spell fiasco without SCO. hkp://keyserver.gingerbear.net or mailto:pgp-public-keys at gingerbear.net?subject=HELP Q:"Just how do the residents of Haiku, Hawai'i hold conversations?" A:"An odd melody / island voices on the winds / surplus of vowels" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 679 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Wed Nov 18 15:47:47 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 18 Nov 2009 09:47:47 -0500 Subject: DSA2 default status Message-ID: <3A3ECE26-ECF1-417A-913C-B6FF728DC974@jabberwocky.com> The default for DSA2 in GPG is currently "off" - that is, by default, we fix the size of a DSA key at 1024 bits, and the q size (to specify the hash) at 160 bits. We've supported DSA2 since mid-2006 (v1.4.4 - a year later in GPG2: v2.0.7), but it has always been restricted behind a --enable-dsa2 option to prevent people from shooting themselves and others in the foot by making keys that could not be widely used. By passing --enable-dsa2, they "opt-in" to that risk, and can generate whatever key type they like. Proposal: I think it's time to make --enable-dsa2 the default. It's been supported for 3 years in GPG and almost as long in PGP. Plus, the DSA key type is no longer the default in GPG anyway - it takes an explicit decision by a user to use DSA in the first place, which acts as the "opt-in". Thoughts? David From wk at gnupg.org Wed Nov 18 17:28:55 2009 From: wk at gnupg.org (Werner Koch) Date: Wed, 18 Nov 2009 17:28:55 +0100 Subject: DSA2 default status In-Reply-To: <3A3ECE26-ECF1-417A-913C-B6FF728DC974@jabberwocky.com> (David Shaw's message of "Wed, 18 Nov 2009 09:47:47 -0500") References: <3A3ECE26-ECF1-417A-913C-B6FF728DC974@jabberwocky.com> Message-ID: <87tywryeyg.fsf@vigenere.g10code.de> On Wed, 18 Nov 2009 15:47, dshaw at jabberwocky.com said: > Proposal: I think it's time to make --enable-dsa2 the default. It's been supported for 3 years in GPG and almost as long in PGP. Plus, the DSA key type is no longer the default in GPG anyway - it takes an explicit decision by a user to use DSA in the first place, which acts as the "opt-in". I did quite some key signing last week for my DSA-2048 key. In the past I regulary received complaints that people were not able to sign it. Let's see whether this is still the case or if almost all folks will be able to sign my key. I guess they are. After that make --enable-dsa2 the default. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From rjh at sixdemonbag.org Wed Nov 18 19:50:30 2009 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 18 Nov 2009 13:50:30 -0500 Subject: DSA2 default status In-Reply-To: <3A3ECE26-ECF1-417A-913C-B6FF728DC974@jabberwocky.com> References: <3A3ECE26-ECF1-417A-913C-B6FF728DC974@jabberwocky.com> Message-ID: <4B0441F6.1040700@sixdemonbag.org> David Shaw wrote: > Thoughts? Depending on how soon the V5 key spec is ready, we may want to fold everything in all at once. Changing defaults isn't a big deal, but it tends to get pushback from users who seem to think their old keys are somehow broken or defective (since otherwise, "they wouldn't have changed the defaults"). If V5 is going to be more than six months or so, though, then I think enabling DSA2 by default should be done now. From dkg at fifthhorseman.net Wed Nov 18 20:08:33 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 18 Nov 2009 14:08:33 -0500 Subject: DSA2 default status In-Reply-To: <4B0441F6.1040700@sixdemonbag.org> References: <3A3ECE26-ECF1-417A-913C-B6FF728DC974@jabberwocky.com> <4B0441F6.1040700@sixdemonbag.org> Message-ID: <4B044631.2060609@fifthhorseman.net> On 11/18/2009 01:50 PM, Robert J. Hansen wrote: > If V5 is going to be more than six months or so, though, then I think > enabling DSA2 by default should be done now. I seriously doubt that v5 is going to be ready in 6 months. my sense of the OpenPGP WG was that v5 would probably wait on the results of the NIST hash competition for a successor to SHA-1, and that won't be ready in 6 months, since the Second SHA-3 Candidate Conference is in August of next year: http://csrc.nist.gov/groups/ST/hash/sha-3/Round2/index.html i could be mistaken about this, of course. Maybe the WG will want to update the spec before SHA-3 is chosen. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 891 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Wed Nov 18 20:02:08 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 18 Nov 2009 14:02:08 -0500 Subject: DSA2 default status In-Reply-To: <4B0441F6.1040700@sixdemonbag.org> References: <3A3ECE26-ECF1-417A-913C-B6FF728DC974@jabberwocky.com> <4B0441F6.1040700@sixdemonbag.org> Message-ID: <35D05143-872F-4B17-9295-DBDF85B2554F@jabberwocky.com> On Nov 18, 2009, at 1:50 PM, Robert J. Hansen wrote: > David Shaw wrote: >> Thoughts? > > Depending on how soon the V5 key spec is ready, we may want to fold > everything in all at once. Changing defaults isn't a big deal, but it > tends to get pushback from users who seem to think their old keys are > somehow broken or defective (since otherwise, "they wouldn't have > changed the defaults"). I think we've already paid the user-confusion bill when we made the switch from DSA to RSA. > If V5 is going to be more than six months or so, though, then I think > enabling DSA2 by default should be done now. V5 is nowhere near 6 months away. I'd be shocked if it happened before 2011. There just isn't much to talk about for V5 until SHA-3, and even the preliminary results for that aren't due until 2010. David From dshaw at jabberwocky.com Wed Nov 18 20:07:02 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 18 Nov 2009 14:07:02 -0500 Subject: DSA2 default status In-Reply-To: <87tywryeyg.fsf@vigenere.g10code.de> References: <3A3ECE26-ECF1-417A-913C-B6FF728DC974@jabberwocky.com> <87tywryeyg.fsf@vigenere.g10code.de> Message-ID: <801C68AF-E697-4DE1-A36B-2E7E4C3E257F@jabberwocky.com> On Nov 18, 2009, at 11:28 AM, Werner Koch wrote: > On Wed, 18 Nov 2009 15:47, dshaw at jabberwocky.com said: > >> Proposal: I think it's time to make --enable-dsa2 the default. It's been supported for 3 years in GPG and almost as long in PGP. Plus, the DSA key type is no longer the default in GPG anyway - it takes an explicit decision by a user to use DSA in the first place, which acts as the "opt-in". > > I did quite some key signing last week for my DSA-2048 key. In the past > I regulary received complaints that people were not able to sign it. > Let's see whether this is still the case or if almost all folks will be > able to sign my key. I guess they are. After that make --enable-dsa2 > the default. Sounds good to me. David From wk at gnupg.org Thu Nov 19 08:57:02 2009 From: wk at gnupg.org (Werner Koch) Date: Thu, 19 Nov 2009 08:57:02 +0100 Subject: DSA2 default status In-Reply-To: <35D05143-872F-4B17-9295-DBDF85B2554F@jabberwocky.com> (David Shaw's message of "Wed, 18 Nov 2009 14:02:08 -0500") References: <3A3ECE26-ECF1-417A-913C-B6FF728DC974@jabberwocky.com> <4B0441F6.1040700@sixdemonbag.org> <35D05143-872F-4B17-9295-DBDF85B2554F@jabberwocky.com> Message-ID: <87iqd7ueup.fsf@vigenere.g10code.de> On Wed, 18 Nov 2009 20:02, dshaw at jabberwocky.com said: > V5 is nowhere near 6 months away. I'd be shocked if it happened before 2011. There just isn't much to talk about for V5 until SHA-3, and even the preliminary results for that aren't due until 2010. It is much more likely that GnuPG will implement the ECC draft before thinking about v5. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dshaw at jabberwocky.com Thu Nov 19 15:17:06 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 19 Nov 2009 09:17:06 -0500 Subject: DSA2 default status In-Reply-To: <87iqd7ueup.fsf@vigenere.g10code.de> References: <3A3ECE26-ECF1-417A-913C-B6FF728DC974@jabberwocky.com> <4B0441F6.1040700@sixdemonbag.org> <35D05143-872F-4B17-9295-DBDF85B2554F@jabberwocky.com> <87iqd7ueup.fsf@vigenere.g10code.de> Message-ID: <3B977428-A821-4411-9F0B-DB5D0B2C2805@jabberwocky.com> On Nov 19, 2009, at 2:57 AM, Werner Koch wrote: > On Wed, 18 Nov 2009 20:02, dshaw at jabberwocky.com said: > >> V5 is nowhere near 6 months away. I'd be shocked if it happened before 2011. There just isn't much to talk about for V5 until SHA-3, and even the preliminary results for that aren't due until 2010. > > It is much more likely that GnuPG will implement the ECC draft before > thinking about v5. Indeed. ECC is fairly straightforward - we have a key format, we know how to do things with it, we know what a ECC fingerprint would be, etc. V5 (or at least a V5 worth doing) changes some fundamental things, so needs a lot more thought and planning. David From philcerf at googlemail.com Sat Nov 21 15:47:34 2009 From: philcerf at googlemail.com (Philippe Cerfon) Date: Sat, 21 Nov 2009 15:47:34 +0100 Subject: some questions on using gpg in scripting Message-ID: <6e7da8720911210647ycd0d471lbd44256d24760be9@mail.gmail.com> Hi. I'd like to use gpg in some scripts for decryption only. The encrypted files are mainly symmetrically encrypted (I mean the session key), but it could also happen, that there appear some asymmetrically encrypted files. I want to prevent gpg to try writing to disk (especially ~/.gnupg) as this might be read only. What I do now is: { echo $passphrsae; cat message; } | gpg --batch --no-options --no-random-seed-file --no-default-keyring --keyring /dev/null --secret-keyring /dev/null --trust-db-name /dev/null --passphrase-fd 0 --decrypt | doFurtherStuff With --no-options I prevent the creation of ~/.gnupg and usage gpg.conf, which is exactly what I want. With --keyring /dev/null --secret-keyring /dev/null I give it some (empty) keyrings With --no-default-keyring I prevent that it fails because no ~/.gnupg/pub|secring.gpg exist. So far so good. I would however like to let is use ~/.gnupg/pub|secring.gpg but only if they exist (it should not create them) and it should never use gnupg.conf. Is this possible? Regards, Philippe btw: The manpage says, with --no-tty, gnugp would never ever write to the terminal. It does hoewever (e.g. error messages that no keyrings exists, or no MDC was found.) From philcerf at googlemail.com Sat Nov 21 15:38:54 2009 From: philcerf at googlemail.com (Philippe Cerfon) Date: Sat, 21 Nov 2009 15:38:54 +0100 Subject: does gpg ever write to stdout in if a file could not be decrypted? Message-ID: <6e7da8720911210638v7ccd6a70x1ce9d4ba73a69444@mail.gmail.com> Hi. Minor question: Say I use gpg in batch mode to decrypt a file to stdout. Of course this might fail (the passphrase might be wrong, or the message corrupted). In this case, the exist status will be != 0, right? But could it EVER happen, that gpg still printed something to stdout? I mean imagine very big files... I cannot believe that gpg caches them until it knows whether decryption has successful or not?! And I also speak of such encrypted files which don't have this check value set. Best wishes, Philippe From lists at lina.inka.de Sat Nov 21 17:14:22 2009 From: lists at lina.inka.de (Bernd Eckenfels) Date: Sat, 21 Nov 2009 17:14:22 +0100 Subject: some questions on using gpg in scripting In-Reply-To: <6e7da8720911210647ycd0d471lbd44256d24760be9@mail.gmail.com> References: <6e7da8720911210647ycd0d471lbd44256d24760be9@mail.gmail.com> Message-ID: <20091121161422.GA32703@lina.inka.de> On Sat, Nov 21, 2009 at 03:47:34PM +0100, Philippe Cerfon wrote: > So far so good. I would however like to let is use > ~/.gnupg/pub|secring.gpg but only if they exist (it should not create > them) and it should never use gnupg.conf. > Is this possible? Well, if you start if from a script, why dont you set the options depending on the existence of the files? > btw: The manpage says, with --no-tty, gnugp would never ever write to > the terminal. It does hoewever (e.g. error messages that no keyrings > exists, or no MDC was found.) Are you sure it is tty and not stderr? Gruss Bernd From ikrabbe.ask at gmail.com Mon Nov 23 10:10:15 2009 From: ikrabbe.ask at gmail.com (Ingo Krabbe) Date: Mon, 23 Nov 2009 10:10:15 +0100 Subject: Where is >libassuan-1.1.0 Message-ID: <20091123091015.GB11283@ask> Hi, when I try to compile gnupg and gpgme from trunk I need a libassuan with a new API version, that should be available from version 1.1.0 on. But on the ftp server are only libassuan versions up to 1.0.5, which means that gnupg and gpgme in the svn-trunk revisions don't compile anymore. I wonder how you do it. Maybe it would be best to keep all those things together in the svn repositories or even better I would recommend to use git repositories, which are much better for distributed development. bye ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From wk at gnupg.org Mon Nov 23 11:59:20 2009 From: wk at gnupg.org (Werner Koch) Date: Mon, 23 Nov 2009 11:59:20 +0100 Subject: does gpg ever write to stdout in if a file could not be decrypted? In-Reply-To: <6e7da8720911210638v7ccd6a70x1ce9d4ba73a69444@mail.gmail.com> (Philippe Cerfon's message of "Sat, 21 Nov 2009 15:38:54 +0100") References: <6e7da8720911210638v7ccd6a70x1ce9d4ba73a69444@mail.gmail.com> Message-ID: <87iqd1pkvr.fsf@vigenere.g10code.de> On Sat, 21 Nov 2009 15:38, philcerf at googlemail.com said: > But could it EVER happen, that gpg still printed something to stdout? Sure, if gpg detects that the file was corrupt it might have even wirtten the whole plaintext out before it has the oppurtunity to check the MIC (message integrity code) or the signature. You can't avoid that. The exit code will be not 0 in that case. > I mean imagine very big files... I cannot believe that gpg caches them > until it knows whether decryption has successful or not?! Right, it does noch cache a file so that it can be used in a pipeline. To see what really went fron you should check the status code emitted to the file descriptor given by --status-FD N. Or use GPGME, which does return anice stat about the decryption process. Anyway, you need to throw away the failed decrypted text yourself. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Nov 23 15:15:33 2009 From: wk at gnupg.org (Werner Koch) Date: Mon, 23 Nov 2009 15:15:33 +0100 Subject: Where is >libassuan-1.1.0 In-Reply-To: <20091123091015.GB11283@ask> (Ingo Krabbe's message of "Mon, 23 Nov 2009 10:10:15 +0100") References: <20091123091015.GB11283@ask> Message-ID: <87fx85nx8a.fsf@vigenere.g10code.de> On Mon, 23 Nov 2009 10:10, ikrabbe.ask at gmail.com said: > when I try to compile gnupg and gpgme from trunk I need a libassuan with a new > API version, that should be available from version 1.1.0 on. You need to use libassuan from the SVN as well. We are currently in the process of changing quite soem things and until this has settled down we won't do any regular release. The main factor is the cleanup of the libassuan API while truning it into a DSO. It is basicaly finished and as soon as this has been done we will do a libassuan release so that other software can migrate to the new API. > together in the svn repositories or even better I would recommend to use git > repositories, which are much better for distributed development. We settled for CVS/SVN a long time ago and won't change every few years for the then en-vogue VCS. Further we don't have a distributed development model but a closely controlled one for legal and security reasons. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ikrabbe.ask at gmail.com Mon Nov 23 17:12:35 2009 From: ikrabbe.ask at gmail.com (Ingo Krabbe) Date: Mon, 23 Nov 2009 17:12:35 +0100 Subject: Where is >libassuan-1.1.0 In-Reply-To: <87fx85nx8a.fsf@vigenere.g10code.de> References: <20091123091015.GB11283@ask> <87fx85nx8a.fsf@vigenere.g10code.de> Message-ID: <20091123161235.GA14548@ask> On Mon, Nov 23, 2009 at 03:15:33PM +0100, Werner Koch wrote: > On Mon, 23 Nov 2009 10:10, ikrabbe.ask at gmail.com said: > > > when I try to compile gnupg and gpgme from trunk I need a libassuan with a new > > API version, that should be available from version 1.1.0 on. > > You need to use libassuan from the SVN as well. > > We are currently in the process of changing quite soem things and until > this has settled down we won't do any regular release. The main factor > is the cleanup of the libassuan API while truning it into a DSO. It is > basicaly finished and as soon as this has been done we will do a > libassuan release so that other software can migrate to the new API. > > > together in the svn repositories or even better I would recommend to use git > > repositories, which are much better for distributed development. > > We settled for CVS/SVN a long time ago and won't change every few years > for the then en-vogue VCS. Further we don't have a distributed > development model but a closely controlled one for legal and security > reasons. > Hi Werner, Actually there are strong reasons to use git, not just that it might be "en-vouge" and its possible to read in all the previously known tags and branches in svn or cvs into a new git repository, but finally its your selection. On the other hand, It might be a problem that you don't have a distributed model, as you should have, having the GnuPG Project in the open source domain, though I think, I understand your reasons. It would finally be quite helpfull if you would put the references of all basic svn paths on a central place on gnupg.org, as I failed to find the libassuan one for example and I don't think there is a way to access them, without knowing their names (libassuan might have been called Assuan or just assuan, as it was as the internal path of gpgme). But with I now found that version on your server and I'm happy with it, for now. bye ingo > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -- i don't do signatures -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From dkg at fifthhorseman.net Mon Nov 23 17:45:49 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 23 Nov 2009 11:45:49 -0500 Subject: Where is >libassuan-1.1.0 In-Reply-To: <87fx85nx8a.fsf@vigenere.g10code.de> References: <20091123091015.GB11283@ask> <87fx85nx8a.fsf@vigenere.g10code.de> Message-ID: <4B0ABC3D.3060502@fifthhorseman.net> On 11/23/2009 09:15 AM, Werner Koch wrote: > We settled for CVS/SVN a long time ago and won't change every few years > for the then en-vogue VCS. Further we don't have a distributed > development model but a closely controlled one for legal and security > reasons. This is entirely reasonable, and there is no reason that the two approaches should be mutually exclusive. Ingo, git-svn actually provides a pretty good workflow for people using git to interact with a centralized svn repository (and then also with other people using git). I can set up a git repo that mirrors the upstream svn if you'd prefer to work from that. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 891 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Mon Nov 23 20:59:00 2009 From: wk at gnupg.org (Werner Koch) Date: Mon, 23 Nov 2009 20:59:00 +0100 Subject: Where is >libassuan-1.1.0 In-Reply-To: <20091123161235.GA14548@ask> (Ingo Krabbe's message of "Mon, 23 Nov 2009 17:12:35 +0100") References: <20091123091015.GB11283@ask> <87fx85nx8a.fsf@vigenere.g10code.de> <20091123161235.GA14548@ask> Message-ID: <87tywlm2rf.fsf@vigenere.g10code.de> On Mon, 23 Nov 2009 17:12, ikrabbe.ask at gmail.com said: > Actually there are strong reasons to use git, not just that it might be > "en-vouge" and its possible to read in all the previously known tags and > branches in svn or cvs into a new git repository, but finally its your .. as well as changing the history without any traces left. Anyway, I won't start a holy war on VCS stuff. > svn paths on a central place on gnupg.org, as I failed to find the libassuan one > for example and I don't think there is a way to access them, without knowing What is wrong with http://cvs.gnupg.org as stated on http://www.gnupg.org (download->cvs access). Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ikrabbe.ask at gmail.com Mon Nov 23 22:51:44 2009 From: ikrabbe.ask at gmail.com (Ingo Krabbe) Date: Mon, 23 Nov 2009 22:51:44 +0100 Subject: Where is >libassuan-1.1.0 In-Reply-To: <87tywlm2rf.fsf@vigenere.g10code.de> References: <20091123091015.GB11283@ask> <87fx85nx8a.fsf@vigenere.g10code.de> <20091123161235.GA14548@ask> <87tywlm2rf.fsf@vigenere.g10code.de> Message-ID: <20091123215144.GA19205@ask> On Mon, Nov 23, 2009 at 08:59:00PM +0100, Werner Koch wrote: > On Mon, 23 Nov 2009 17:12, ikrabbe.ask at gmail.com said: > > > svn paths on a central place on gnupg.org, as I failed to find the libassuan one > > for example and I don't think there is a way to access them, without knowing > > What is wrong with http://cvs.gnupg.org as stated on > http://www.gnupg.org (download->cvs access). Some links are missing there: libassuan and libgpg-error as far as I can see now. bye ingo From bernhard at intevation.de Thu Nov 26 12:05:47 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 26 Nov 2009 12:05:47 +0100 Subject: SCM dicussion (Re: Where is >libassuan-1.1.0) In-Reply-To: <20091123215144.GA19205@ask> References: <20091123091015.GB11283@ask> <87tywlm2rf.fsf@vigenere.g10code.de> <20091123215144.GA19205@ask> Message-ID: <200911261205.47821.bernhard@intevation.de> Am Montag, 23. November 2009 22:51:44 schrieb Ingo Krabbe: > > What is wrong with http://cvs.gnupg.org as stated on > > http://www.gnupg.org ?(download->cvs access). > > Some links are missing there: libassuan and libgpg-error as far as I can > see now. The links on cvs.gnupg.org are just shortcusts and not complete, check the selection box on top right of http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/ (An improvement could be to mention that the list of shortcuts is not complete and to point the reader towards the selection box of the fulll version.) -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2620 bytes Desc: not available URL: From ikrabbe.ask at gmail.com Thu Nov 26 19:51:09 2009 From: ikrabbe.ask at gmail.com (Ingo Krabbe) Date: Thu, 26 Nov 2009 19:51:09 +0100 Subject: SCM dicussion (Re: Where is >libassuan-1.1.0) In-Reply-To: <200911261205.47821.bernhard@intevation.de> References: <20091123091015.GB11283@ask> <87tywlm2rf.fsf@vigenere.g10code.de> <20091123215144.GA19205@ask> <200911261205.47821.bernhard@intevation.de> Message-ID: <20091126185109.GA30495@ask> On Thu, Nov 26, 2009 at 12:05:47PM +0100, Bernhard Reiter wrote: > Am Montag, 23. November 2009 22:51:44 schrieb Ingo Krabbe: > > > What is wrong with http://cvs.gnupg.org as stated on > > > http://www.gnupg.org ?(download->cvs access). > > > > Some links are missing there: libassuan and libgpg-error as far as I can > > see now. > > The links on cvs.gnupg.org are just shortcusts and not complete, check the > selection box on top right of http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/ > (An improvement could be to mention that the list of shortcuts is not complete > and to point the reader towards the selection box of the fulll version.) Yes, thats the one I searched for. Thanks. > > -- > Managing Director - Owner: www.intevation.net (Free Software Company) > Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. > Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 > Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel -- i don't do signatures From dshaw at JABBERWOCKY.COM Mon Nov 30 16:29:08 2009 From: dshaw at JABBERWOCKY.COM (David Shaw) Date: Mon, 30 Nov 2009 10:29:08 -0500 Subject: Change s2k count? Message-ID: Hi everyone, The discussion around s2k-count on gnupg-users made me think a bit about our current default there. The default s2k count has been 65536 iterations for (as best I can tell) pretty near the entire lifespan of GnuPG. Certainly it is at least 11 years as I see it in a code checkin from 1998. There are a number of factors: obviously we must take care with the setting here - too high and it can make decrypting with a passphrase (either a secret key decryption or a passphrase protected message) unacceptably slow. In addition, there are other factors to consider, like uses today that didn't exist as much 11 years ago - slow CPUs in cell phones and the like, which would have a hard time with a large iteration count. Even so, most smartphone processors today are on par with or even faster than the average processor from 1998 (my own phone is roughly 2x faster than my 1998-era computer). It could be argued that cell phone usage actually needs the iterated hash even more as typing a long high-entropy passphrase is extremely difficult on a cell phone. The bottom line is that the speed of the average processor today is vastly faster than what it was then, and so the cushion against passphrase guessers that the iterated hash was giving us is steadily dropping. If 65536 was the right value for 11 years ago, we probably could do with a brief discussion on whether we should raise it for today (and if so, how much). David