From gniibe at fsij.org Wed Jun 6 02:43:42 2012 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 06 Jun 2012 09:43:42 +0900 Subject: Gnuk version 0.19 Message-ID: <1338943422.1968.4.camel@latx1.gniibe.org> Hi, Well, I forgot to send announcements here for 0.17 and 0.18, but Gnuk version 0.19 is released today. Gnuk is software implementation of a USB token for GNU Privacy Guard. Gnuk supports OpenPGP card protocol version 2, and it runs on STM32F103 processor. In this release, new feature of "firmware upgrade", is added. It is no need to use JTAG debugger any more to update the firmware. While it is still experimental, this will be useful for hardware product. Highlights are (in gnuk-0.19/NEWS): * Firmware upgrade feature Firmware upgrade is now possible after the public key authentication using EXTERNAL AUTHENTICATE command of ISO 7816. Firmware upgrade is done together with reGNUal, the firmware upgrade program. * System service blocks at the beginning of flash ROM. Once flash ROM is protected, first 4-KiB cannot be modified. Gnuk use this area for "system service". Note that this area will not be able to be modified by firmware upgrade (or by any method). * New tool: gnuk_upgrade.py The tool gnuk_upgrade.py is to do public key authentication using gpg-agent and send reGNUal to Gnuk. Then, we put new Gnuk binary into the device with reGNUal. * USB strings for revision detail, configure options, and system service. USB strings now have more information. There are revision detail string, configure options string, system service version string, as well as vendor string and product string. These strings could be examined to check Gnuk Token. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part URL: From gniibe at fsij.org Wed Jun 6 07:30:27 2012 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 06 Jun 2012 14:30:27 +0900 Subject: scd: a race condition between scd_command_handler and handle_tick In-Reply-To: <87vclgs23o.fsf@latx1.gniibe.org> References: <87vclgs23o.fsf@latx1.gniibe.org> Message-ID: <1338960627.1968.10.camel@latx1.gniibe.org> On 2012-04-04 at 10:43 +0900, Niibe Yutaka wrote: > This is a bug report for GnuPG 2.0.19 (or 2.0.18). I have not yet > checked if there is this bug in the development version or not. The bug is in the master branch too. > For the BUG CASE, there is a race condition between two threads, the > command handler thread and handle_tick thread. > > COMMAND HANDLER THREAD's call-chain is like: > -> scd_command_handler > -> cmd_serialno > -> open_card > ->apdu_connect > > HANDLE_TICK THREAD's call-chain is like: > -> handle_tick > -> scd_update_reader_status_file > -> update_reader_status_file > -> get_reader_slot > -> apdu_open_reader > -> open_pcsc_reader > -> open_pcsc_reader_wrapper > -> new_reader_slot > Then, forking gnupg-pcsc-wrapper... I think that a patch like following is needed, at least at the lower layer. That is, success of new_reader_slot, it returns with the slot's lock. The lock will be released by caller. I haven't test it yet. diff --git a/scd/apdu.c b/scd/apdu.c index 7641e91..f88047a 100644 --- a/scd/apdu.c +++ b/scd/apdu.c @@ -346,8 +346,56 @@ static int pcsc_keypad_modify (int slot, int class, int ins, int p0, int p1, */ +static int +lock_slot (int slot) +{ +#ifdef USE_NPTH + int err; + + err = npth_mutex_lock (&reader_table[slot].lock); + if (err) + { + log_error ("failed to acquire apdu lock: %s\n", strerror (err)); + return SW_HOST_LOCKING_FAILED; + } +#endif /*USE_NPTH*/ + return 0; +} + +static int +trylock_slot (int slot) +{ +#ifdef USE_NPTH + int err; + + err = npth_mutex_trylock (&reader_table[slot].lock); + if (err == EBUSY) + return SW_HOST_BUSY; + else if (err) + { + log_error ("failed to acquire apdu lock: %s\n", strerror (err)); + return SW_HOST_LOCKING_FAILED; + } +#endif /*USE_NPTH*/ + return 0; +} + +static void +unlock_slot (int slot) +{ +#ifdef USE_NPTH + int err; + + err = npth_mutex_unlock (&reader_table[slot].lock); + if (err) + log_error ("failed to release apdu lock: %s\n", strerror (errno)); +#endif /*USE_NPTH*/ +} + + /* Find an unused reader slot for PORTSTR and put it into the reader - table. Return -1 on error or the index into the reader table. */ + table. Return -1 on error or the index into the reader table. + Acquire slot's lock on successful return. Caller needs to unlock it. */ static int new_reader_slot (void) { @@ -375,6 +423,12 @@ new_reader_slot (void) } reader_table[reader].lock_initialized = 1; } + + if (lock_slot (reader)) + { + log_error ("error locking mutex: %s\n", strerror (err)); + return -1; + } #endif /*USE_NPTH*/ reader_table[reader].connect_card = NULL; reader_table[reader].disconnect_card = NULL; @@ -660,6 +714,7 @@ open_ct_reader (int port) log_error ("apdu_open_ct_reader failed on port %d: %s\n", port, ct_error_string (rc)); reader_table[reader].used = 0; + unlock_slot (reader); return -1; } @@ -681,6 +736,7 @@ open_ct_reader (int port) reader_table[reader].keypad_modify = NULL; dump_reader_status (reader); + unlock_slot (reader); return reader; } @@ -1693,6 +1749,7 @@ open_pcsc_reader_direct (const char *portstr) reader_table[slot].used = 0; if (err == 0x8010001d) pcsc_no_service = 1; + unlock_slot (slot); return -1; } pcsc_no_service = 0; @@ -1707,6 +1764,7 @@ open_pcsc_reader_direct (const char *portstr) log_error ("error allocating memory for reader list\n"); pcsc_release_context (reader_table[slot].pcsc.context); reader_table[slot].used = 0; + unlock_slot (slot); return -1 /*SW_HOST_OUT_OF_CORE*/; } err = pcsc_list_readers (reader_table[slot].pcsc.context, @@ -1719,6 +1777,7 @@ open_pcsc_reader_direct (const char *portstr) pcsc_release_context (reader_table[slot].pcsc.context); reader_table[slot].used = 0; xfree (list); + unlock_slot (slot); return -1; } @@ -1745,6 +1804,7 @@ open_pcsc_reader_direct (const char *portstr) log_error ("error allocating memory for reader name\n"); pcsc_release_context (reader_table[slot].pcsc.context); reader_table[slot].used = 0; + unlock_slot (slot); return -1; } strcpy (reader_table[slot].rdrname, portstr? portstr : list); @@ -1764,6 +1824,7 @@ open_pcsc_reader_direct (const char *portstr) reader_table[slot].dump_status_reader = dump_pcsc_reader_status; dump_reader_status (slot); + unlock_slot (slot); return slot; } #endif /*!NEED_PCSC_WRAPPER */ @@ -1810,6 +1871,7 @@ open_pcsc_reader_wrapped (const char *portstr) { log_error ("error creating a pipe: %s\n", strerror (errno)); slotp->used = 0; + unlock_slot (slot); return -1; } if (pipe (wp) == -1) @@ -1818,6 +1880,7 @@ open_pcsc_reader_wrapped (const char *portstr) close (rp[0]); close (rp[1]); slotp->used = 0; + unlock_slot (slot); return -1; } @@ -1830,6 +1893,7 @@ open_pcsc_reader_wrapped (const char *portstr) close (wp[0]); close (wp[1]); slotp->used = 0; + unlock_slot (slot); return -1; } slotp->pcsc.pid = pid; @@ -1963,6 +2027,7 @@ open_pcsc_reader_wrapped (const char *portstr) pcsc_get_status (slot, &dummy_status); dump_reader_status (slot); + unlock_slot (slot); return slot; command_failed: @@ -1974,6 +2039,7 @@ open_pcsc_reader_wrapped (const char *portstr) kill (slotp->pcsc.pid, SIGTERM); slotp->pcsc.pid = (pid_t)(-1); slotp->used = 0; + unlock_slot (slot); /* There is no way to return SW. */ return -1; @@ -2412,6 +2478,7 @@ open_ccid_reader (const char *portstr) if (err) { slotp->used = 0; + unlock_slot (slot); return -1; } @@ -2446,6 +2513,7 @@ open_ccid_reader (const char *portstr) reader_table[slot].is_t0 = 0; dump_reader_status (slot); + unlock_slot (slot); return slot; } @@ -2684,6 +2752,7 @@ open_rapdu_reader (int portno, if (!slotp->rapdu.handle) { slotp->used = 0; + unlock_slot (slot); return -1; } @@ -2738,12 +2807,14 @@ open_rapdu_reader (int portno, dump_reader_status (slot); rapdu_msg_release (msg); + unlock_slot (slot); return slot; failure: rapdu_msg_release (msg); rapdu_release (slotp->rapdu.handle); slotp->used = 0; + unlock_slot (slot); return -1; } @@ -2756,53 +2827,6 @@ open_rapdu_reader (int portno, */ -static int -lock_slot (int slot) -{ -#ifdef USE_NPTH - int err; - - err = npth_mutex_lock (&reader_table[slot].lock); - if (err) - { - log_error ("failed to acquire apdu lock: %s\n", strerror (err)); - return SW_HOST_LOCKING_FAILED; - } -#endif /*USE_NPTH*/ - return 0; -} - -static int -trylock_slot (int slot) -{ -#ifdef USE_NPTH - int err; - - err = npth_mutex_trylock (&reader_table[slot].lock); - if (err == EBUSY) - return SW_HOST_BUSY; - else if (err) - { - log_error ("failed to acquire apdu lock: %s\n", strerror (err)); - return SW_HOST_LOCKING_FAILED; - } -#endif /*USE_NPTH*/ - return 0; -} - -static void -unlock_slot (int slot) -{ -#ifdef USE_NPTH - int err; - - err = npth_mutex_unlock (&reader_table[slot].lock); - if (err) - log_error ("failed to release apdu lock: %s\n", strerror (errno)); -#endif /*USE_NPTH*/ -} - - /* Open the reader and return an internal slot number or -1 on error. If PORTSTR is NULL we default to a suitable port (for ctAPI: the first USB reader. For PC/SC the first listed reader). */ -- From wk at gnupg.org Thu Jun 7 20:42:27 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 07 Jun 2012 20:42:27 +0200 Subject: scd: a race condition between scd_command_handler and handle_tick In-Reply-To: <1338960627.1968.10.camel@latx1.gniibe.org> (NIIBE Yutaka's message of "Wed, 06 Jun 2012 14:30:27 +0900") References: <87vclgs23o.fsf@latx1.gniibe.org> <1338960627.1968.10.camel@latx1.gniibe.org> Message-ID: <87d35b2cbw.fsf@vigenere.g10code.de> On Wed, 6 Jun 2012 07:30, gniibe at fsij.org said: > The bug is in the master branch too. Hmmm. >> -> open_pcsc_reader >> -> open_pcsc_reader_wrapper >> -> new_reader_slot >> Then, forking gnupg-pcsc-wrapper... There should be no pcsc wrapper in master anymore. We don't need it after the switch to npth. I guess we simply forgot to remove the need for the wrapper. The wrapper was needed because it is not possible to use Pth and pthread together. libpcsclite uses pthread. nPth solves the problem by internally using pthread. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Jun 12 07:34:51 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 12 Jun 2012 07:34:51 +0200 Subject: [rfc-editor@rfc-editor.org] RFC 6637 on Elliptic Curve Cryptography (ECC) in OpenPGP Message-ID: <87ehplw0sk.fsf@vigenere.g10code.de> An embedded message was scrubbed... From: rfc-editor at rfc-editor.org Subject: RFC 6637 on Elliptic Curve Cryptography (ECC) in OpenPGP Date: Mon, 11 Jun 2012 15:49:23 -0700 (PDT) Size: 5177 URL: -------------- next part -------------- -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ott at mirix.org Tue Jun 12 07:58:12 2012 From: ott at mirix.org (Matthias-Christian Ott) Date: Tue, 12 Jun 2012 07:58:12 +0200 Subject: [rfc-editor@rfc-editor.org] RFC 6637 on Elliptic Curve Cryptography (ECC) in OpenPGP In-Reply-To: <87ehplw0sk.fsf@vigenere.g10code.de> References: <87ehplw0sk.fsf@vigenere.g10code.de> Message-ID: <4FD6DA74.9080606@mirix.org> Apparently the Brainpool curves didn't make into the standard. You wrote (<8739bo51de.fsf at vigenere.g10code.de>) that you prefer them and that GnuPG is going to support them. Is that still the plan? If so, are they going to be included in GnuPG 2.1.0? Regards, Matthias-Christian From wk at gnupg.org Tue Jun 12 09:41:06 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 12 Jun 2012 09:41:06 +0200 Subject: [rfc-editor@rfc-editor.org] RFC 6637 on Elliptic Curve Cryptography (ECC) in OpenPGP In-Reply-To: <4FD6DA74.9080606@mirix.org> (Matthias-Christian Ott's message of "Tue, 12 Jun 2012 07:58:12 +0200") References: <87ehplw0sk.fsf@vigenere.g10code.de> <4FD6DA74.9080606@mirix.org> Message-ID: <871ullvuy5.fsf@vigenere.g10code.de> On Tue, 12 Jun 2012 07:58, ott at mirix.org said: > Apparently the Brainpool curves didn't make into the standard. You wrote > (<8739bo51de.fsf at vigenere.g10code.de>) that you prefer them and that > GnuPG is going to support them. Is that still the plan? If so, are they They are not excluded from the standard. The standard defines two things: a) An OpenPGP protocol extension. b) Two profiles for that extension. It is easy to support other curves and thus create a de-facto standard. Given the mystery-mongering of German and US governmental IT security bodies I didn't wanted to take either side. Thus I did not pursuit to have Brainpool listed as another profile. Or a Japanese, Russian, or Chinese one. If someone want that, they are free to work on another RFC to add their profile to rfc6637. This is the same as the addition of the Camellia cipher to OpenPGP. Why should I spend my own unpaid time on such a thing; I am anyway on the rocks. Adding Brainpool to GPG is still a good idea and I would like to prepare that. It is not that complicated and could go hand in hand with some little code restructuring needed anyway. The question is about GPG's interface: I am thinking of an extra prompt before asking for the size of the curve: Please select the type of curve: 1) OpenPGP (default) 2) SuiteB 3) Brainpool Your selection? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dshaw at jabberwocky.com Wed Jun 13 17:09:41 2012 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 13 Jun 2012 11:09:41 -0400 Subject: [rfc-editor@rfc-editor.org] RFC 6637 on Elliptic Curve Cryptography (ECC) in OpenPGP In-Reply-To: <87ehplw0sk.fsf@vigenere.g10code.de> References: <87ehplw0sk.fsf@vigenere.g10code.de> Message-ID: On Jun 12, 2012, at 1:34 AM, Werner Koch wrote: > RFC 6637 > > Title: Elliptic Curve Cryptography (ECC) in > OpenPGP > Author: A. Jivsov > Status: Standards Track > Stream: IETF > Date: June 2012 > Mailbox: Andrey_Jivsov at symantec.com > Pages: 15 > Characters: 31532 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-jivsov-openpgp-ecc-14.txt > > URL: http://www.rfc-editor.org/rfc/rfc6637.txt This is excellent. Congratulations Andrey! (Now I need to update paperkey to handle ECC keys?) David From ott at mirix.org Thu Jun 14 07:07:06 2012 From: ott at mirix.org (Matthias-Christian Ott) Date: Thu, 14 Jun 2012 07:07:06 +0200 Subject: [rfc-editor@rfc-editor.org] RFC 6637 on Elliptic Curve Cryptography (ECC) in OpenPGP In-Reply-To: <871ullvuy5.fsf@vigenere.g10code.de> References: <87ehplw0sk.fsf@vigenere.g10code.de> <4FD6DA74.9080606@mirix.org> <871ullvuy5.fsf@vigenere.g10code.de> Message-ID: <20120614050705.GA21253@a.mirix.org> On 2012-06-12 09:41, Werner Koch wrote: > On Tue, 12 Jun 2012 07:58, ott at mirix.org said: >> Apparently the Brainpool curves didn't make into the standard. You wrote >> (<8739bo51de.fsf at vigenere.g10code.de>) that you prefer them and that >> GnuPG is going to support them. Is that still the plan? If so, are they > > They are not excluded from the standard. The standard defines two > things: > > a) An OpenPGP protocol extension. > b) Two profiles for that extension. > > It is easy to support other curves and thus create a de-facto standard. If I understand it correctly, it's just a matter of inserting the Brainpool OIDs and using the respective parameters. > Given the mystery-mongering of German and US governmental IT security > bodies I didn't wanted to take either side. Thus I did not pursuit to > have Brainpool listed as another profile. Or a Japanese, Russian, or > Chinese one. If someone want that, they are free to work on another RFC > to add their profile to rfc6637. This is the same as the addition of > the Camellia cipher to OpenPGP. Why should I spend my own unpaid time > on such a thing; I am anyway on the rocks. You should at least have another specification other than the source code for interoperability purposes (not that there are other significant OpenPGP implementations, but perhaps in the future). > Adding Brainpool to GPG is still a good idea and I would like to prepare > that. It is not that complicated and could go hand in hand with some > little code restructuring needed anyway. The question is about GPG's > interface: I am thinking of an extra prompt before asking for the size > of the curve: > > Please select the type of curve: > 1) OpenPGP (default) > 2) SuiteB > 3) Brainpool > Your selection? That seems consistent with the rest of the user interface. Regards, Matthias-Christian From guninski at guninski.com Thu Jun 14 16:10:29 2012 From: guninski at guninski.com (Georgi Guninski) Date: Thu, 14 Jun 2012 17:10:29 +0300 Subject: Using second keyring may be misleading? Message-ID: <20120614141029.GC2776@sivokote.iziade.m$> I was investigating ubuntu's apt-key key management. Noticed that collision in the keyids lead to strange results. The first command claims ubuntu signed my key (false) and the second shows the key is selfsigned. Attached is a keyring and here is the output: $rm -rf /home/joro2/.gnupg/ ; gpg --import /usr/share/keyrings/ubuntu-master-keyring.gpg ; gpg --check-sigs --keyring /tmp/sec3 gpg: imported: 1 (RSA: 1) gpg: no ultimately trusted keys found /home/joro2/.gnupg/pubring.gpg ------------------------------ pub 4096R/3F272F5B 2007-11-09 uid Ubuntu Archive Master Signing Key sig!3 3F272F5B 2007-11-09 Ubuntu Archive Master Signing Key /tmp/sec3 --------- pub 1024R/B1C08810 2012-06-14 uid kkkkkkk5 sig!3 B1C08810 2012-06-14 [User ID not found] sig! 3F272F5B 2012-06-14 Ubuntu Archive Master Signing Key sig! 3F272F5B 2012-06-14 Ubuntu Archive Master Signing Key sub 1024R/0354AE88 2012-06-14 sig! B1C08810 2012-06-14 [User ID not found] sub 2179R/3F272F5B 2012-06-14 sig! B1C08810 2012-06-14 [User ID not found] 1 signature not checked due to a missing key $rm -rf /home/joro2/.gnupg/ ; gpg --import /usr/share/keyrings/ubuntu-master-keyring.gpg ; gpg --no-default-keyring --check-sigs --keyring /tmp/sec3 gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1) gpg: no ultimately trusted keys found /tmp/sec3 --------- pub 1024R/B1C08810 2012-06-14 uid kkkkkkk5 sig!3 B1C08810 2012-06-14 kkkkkkk5 sig! 3F272F5B 2012-06-14 kkkkkkk5 sig! 3F272F5B 2012-06-14 kkkkkkk5 sub 1024R/0354AE88 2012-06-14 sig! B1C08810 2012-06-14 kkkkkkk5 sub 2179R/3F272F5B 2012-06-14 sig! B1C08810 2012-06-14 kkkkkkk5 ubuntu's key importing is close to this, if interested check the bash file "apt-key". -------------- next part -------------- A non-text attachment was scrubbed... Name: sec3 Type: application/octet-stream Size: 2033 bytes Desc: not available URL: From wk at gnupg.org Fri Jun 15 14:04:44 2012 From: wk at gnupg.org (Werner Koch) Date: Fri, 15 Jun 2012 14:04:44 +0200 Subject: Using second keyring may be misleading? In-Reply-To: <20120614141029.GC2776@sivokote.iziade.m$> (Georgi Guninski's message of "Thu, 14 Jun 2012 17:10:29 +0300") References: <20120614141029.GC2776@sivokote.iziade.m$> Message-ID: <8762asvl0j.fsf@vigenere.g10code.de> On Thu, 14 Jun 2012 16:10, guninski at guninski.com said: > Noticed that collision in the keyids lead to strange results. > > The first command claims ubuntu signed my key (false) and the second > shows the key is selfsigned. That is one of the reasons of my remarks that the use several keyrings is not worth the trouble. Use one keyring and import the keys you need. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From guninski at guninski.com Fri Jun 15 14:30:56 2012 From: guninski at guninski.com (Georgi Guninski) Date: Fri, 15 Jun 2012 15:30:56 +0300 Subject: Using second keyring may be misleading? In-Reply-To: <8762asvl0j.fsf@vigenere.g10code.de> References: <20120614141029.GC2776@sivokote.iziade.m$> <8762asvl0j.fsf@vigenere.g10code.de> Message-ID: <20120615123056.GC2438@sivokote.iziade.m$> On Fri, Jun 15, 2012 at 02:04:44PM +0200, Werner Koch wrote: > That is one of the reasons of my remarks that the use several keyrings > is not worth the trouble. Use one keyring and import the keys you need. > > This is ubuntu's problem I don't care much about, but they need to verify the keys are signed. The k at k contains a subkey colliding with ubuntu's key 3F272F5B. The order of importing the keys seems important and in one case a self signature is reported as other user, in the other case a selfisg is reported as bad signature from wrong user. I suppose if the colliding key is first it makes the other key unusable. From rjh at sixdemonbag.org Fri Jun 15 15:55:44 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 15 Jun 2012 09:55:44 -0400 Subject: Configure error in GPGME Message-ID: <4FDB3EE0.9020800@sixdemonbag.org> On OS X 10.7.4 with the latest XCode bundle and GnuPG 2.0.17 provided via GPGtools, GPGME seems to have a problem with its configure script. I've excerpted part of it here, and the offending lines noted: ===== checking for setlocale... yes checking for gpg-error-config... /usr/local/MacGPG2/bin/gpg-error- config checking for GPG Error - version >= 1.8... yes (1.9) checking for libassuan-config... /usr/local/MacGPG2/bin/libassuan- config checking for LIBASSUAN - version >= 2.0.2... no checking for gpg... /usr/local/bin/gpg ==> checking for GPG >= 1.4.0... ./configure: line 18679: test: 2) 2: ==> integer expression expected ==> ./configure: line 18682: test: 2) 2: integer expression expected ==> no ==> configure: WARNING: GPG must be at least version 1.4.0 checking for gpgsm... /usr/local/MacGPG2/bin/gpgsm ==> checking for GPGSM >= 1.9.6... ./configure: line 18850: test: 2) ==> 2: integer expression expected ==> ./configure: line 18853: test: 2) 2: integer expression expected ==> no ==> configure: WARNING: GPGSM must be at least version 1.9.6 checking for gpgconf... /usr/local/MacGPG2/bin/gpgconf ==> checking for GPGCONF >= 2.0.4... ./configure: line 19020: test: 2) ==> 2: integer expression expected ==> ./configure: line 19023: test: 2) 2: integer expression expected ==> no configure: WARNING: GPGCONF must be at least version 2.0.4 checking for g13... no configure: WARNING: *** *** Could not find g13, install g13 or use --with-g13=PATH to *** enable it *** checking for funopen... yes ===== From themineo at googlemail.com Sat Jun 16 17:32:46 2012 From: themineo at googlemail.com (Wieland Hoffmann) Date: Sat, 16 Jun 2012 17:32:46 +0200 Subject: Two minor patches for doc/ Message-ID: <1339860768-29550-1-git-send-email-themineo@gmail.com> Hi, following are two patches for typos / c&p errors in doc/. They apply to both the master and STABLE-BRANCH-2-0 branches. PS: I had to use a mirror of the git repository on Gitorious as git.gnupg.org seems to refuse any connection. -- Wieland From themineo at googlemail.com Sat Jun 16 17:32:47 2012 From: themineo at googlemail.com (Wieland Hoffmann) Date: Sat, 16 Jun 2012 17:32:47 +0200 Subject: =?UTF-8?q?=5BPATCH=201/2=5D=20Remove=20a=20duplicate=20line=20in=20HACKING?= In-Reply-To: <1339860768-29550-1-git-send-email-themineo@gmail.com> References: <1339860768-29550-1-git-send-email-themineo@gmail.com> Message-ID: <1339860768-29550-2-git-send-email-themineo@gmail.com> --- doc/HACKING | 1 - 1 Datei ge?ndert, 1 Zeile entfernt(-) diff --git a/doc/HACKING b/doc/HACKING index 0ef5b89..fcf6765 100644 --- a/doc/HACKING +++ b/doc/HACKING @@ -59,7 +59,6 @@ Directory Layout ./ Readme, configure ./agent Gpg-agent and related tools ./doc Documentation - ./doc Documentation ./g10 Gpg program here called gpg2 ./jnlib Utility functions ./kbx Keybox library -- 1.7.10.4 From themineo at googlemail.com Sat Jun 16 17:32:48 2012 From: themineo at googlemail.com (Wieland Hoffmann) Date: Sat, 16 Jun 2012 17:32:48 +0200 Subject: =?UTF-8?q?=5BPATCH=202/2=5D=20gpg-agent=2Etexi=3A=20usualy=20-=3E=20usually?= In-Reply-To: <1339860768-29550-1-git-send-email-themineo@gmail.com> References: <1339860768-29550-1-git-send-email-themineo@gmail.com> Message-ID: <1339860768-29550-3-git-send-email-themineo@gmail.com> --- doc/gpg-agent.texi | 2 +- 1 Datei ge?ndert, 1 Zeile hinzugef?gt(+), 1 Zeile entfernt(-) diff --git a/doc/gpg-agent.texi b/doc/gpg-agent.texi index dcd96fb..eb24b66 100644 --- a/doc/gpg-agent.texi +++ b/doc/gpg-agent.texi @@ -53,7 +53,7 @@ independently from any protocol. It is used as a backend for utilities. @ifset gpgtwoone -The agent is usualy started on demand by @command{gpg}, @command{gpgsm}, +The agent is usually started on demand by @command{gpg}, @command{gpgsm}, @command{gpgconf} or @command{gpg-connect-agent}. Thus there is no reason to start it manually. In case you want to use the included Secure Shell Agent you may start the agent using: -- 1.7.10.4 From gniibe at fsij.org Tue Jun 19 03:29:27 2012 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 19 Jun 2012 10:29:27 +0900 Subject: Gnuk version 0.20 In-Reply-To: <1338943422.1968.4.camel@latx1.gniibe.org> References: <1338943422.1968.4.camel@latx1.gniibe.org> Message-ID: <1340069367.1914.7.camel@latx1.gniibe.org> Hi, Gnuk version 0.20 is released. Gnuk is software implementation of a USB token for GNU Privacy Guard. Gnuk supports OpenPGP card protocol version 2, and it runs on STM32F103 processor. I intend this release as a kind of "release candidate" to version 1.0. No new features will be added for version 1.0. Perhaps, some tool will be added though. In this release, key generation feature is added. Highlights are (in gnuk-0.20/NEWS): * Key generation feature added Finally, key generation is supported. Note that it may be very slow. It may take a few minutes (or more) to generate two or three keys, when you are unlucky. * DnD pinentry support is deprecated Once, DnD pinentry was considered a great feature, but it found that it is difficult to remember moves of folders. * gnuk_upgrade.py assumes using another token for authentication Use of another token for authentication is assumed now. This is incompatible change. Note that when you upgrade a token of version 0.19 to 0.20 (or later), you need gnuk_upgrade.py of version 0.19. * KDF (Key Derivation Function) is now SHA-256 Keystring is now computed by SHA-256 (it was SHA1 before). * Protection improvements (even when internal data is disclosed) Three improvements. (1) Even if PW1 and Reset-code is same, content of encrypted DEK is different now. (2) DEK is now encrypted and decrypted by keystring in ECB mode (it was just a kind of xor by single block CFB mode). (3) Key data plus checksum are encrypted in CFB mode with initial vector (it will be able to switch OCB mode easily). * LED display output change LED display output by Gnuk is now more reactive. It shows status code when it gets GET_STATUS message of CCID. When you communicate Gnuk by internal CCID driver of GnuPG (instead of PC/SC), and enable 'debug-disable-ticker' option in .gnupg/scdaemon.conf, it is more silent now. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part URL: From marius.hofert at math.ethz.ch Thu Jun 21 11:47:59 2012 From: marius.hofert at math.ethz.ch (Marius Hofert) Date: Thu, 21 Jun 2012 11:47:59 +0200 Subject: gpg: overwriting .pdf on encryption => decryption fails Message-ID: <87y5nh6lo0.fsf@math.ethz.ch> I'm not sure if I found a bug. I asked on stackoverflow where it was recommended to write to this mailing list. Here is the link to the problem: http://stackoverflow.com/questions/11134583/gpg-overwriting-pdf-on-encryption-decryption-fails For convenience, here is the problem description (as on stackoverflow): I use gpg (GnuPG) 1.4.11. to encrypt a file foo.pdf via gpg -c foo.pdf. The encrypted file is then foo.pdf.gpg and, additionally, the original file foo.pdf exists. I can then decrypt foo.pdf.gpg via gpg foo.pdf.gpg as expected. However, if I use gpg -o foo.pdf -c foo.pdf and choose to overwrite the existing file on encryption, then use gpg foo.pdf to decrypt the encrypted file, and finally choose to overwrite the existing file foo.pdf (again), the file is still protected and can't be viewed. I then tried to execute gpg foo.pdf again (I thought decrypting failed the first time, that's why I tried it again). Now the file seems to be corrupted: "gpg: [don't know]: 1st length byte missing" Cheers, Marius PS: I'm working on Xubuntu 12.04 From dshaw at jabberwocky.com Thu Jun 21 15:34:34 2012 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 21 Jun 2012 09:34:34 -0400 Subject: gpg: overwriting .pdf on encryption => decryption fails In-Reply-To: <87y5nh6lo0.fsf@math.ethz.ch> References: <87y5nh6lo0.fsf@math.ethz.ch> Message-ID: On Jun 21, 2012, at 5:47 AM, Marius Hofert wrote: > I'm not sure if I found a bug. I asked on stackoverflow where it was recommended > to write to this mailing list. Here is the link to the problem: > http://stackoverflow.com/questions/11134583/gpg-overwriting-pdf-on-encryption-decryption-fails > > For convenience, here is the problem description (as on stackoverflow): > > I use gpg (GnuPG) 1.4.11. to encrypt a file foo.pdf via gpg -c foo.pdf. The encrypted file is then foo.pdf.gpg and, additionally, the original file foo.pdf exists. I can then decrypt foo.pdf.gpg via gpg foo.pdf.gpg as expected. However, if I use gpg -o foo.pdf -c foo.pdf and choose to overwrite the existing file on encryption, then use gpg foo.pdf to decrypt the encrypted file, and finally choose to overwrite the existing file foo.pdf (again), the file is still protected and can't be viewed. > > I then tried to execute gpg foo.pdf again (I thought decrypting failed the first time, that's why I tried it again). Now the file seems to be corrupted: "gpg: [don't know]: 1st length byte missing" GPG is writing to the same file it's reading from (no temp files). As it reads plaintext to encrypt, that data is being clobbered by the already-encrypted data GPG is writing out (or vice versa on decryption). David From gniibe at fsij.org Fri Jun 22 04:49:40 2012 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 22 Jun 2012 11:49:40 +0900 Subject: scd-backport-2-0 branch Message-ID: <1340333380.2119.1.camel@latx1.gniibe.org> Hello, I backported SCD (scdaemon) related changes to scd-backport-2-0 branch. If it doesn't have any problem, I'd like to merge it into STABLE-BRANCH-2-0. Here are changes incorporated into scd-backport-2-0. commit a90f0fca554a679e1c09b0c11ed80311a9358a9d Author: NIIBE Yutaka Date: Fri Jun 22 10:51:12 2012 +0900 scd: Fix updating slot status. * scd/comman.c (do_reset): Let clear card_removed flag. commit ff40c05e8b563471278cb7c92df0310bc5967749 Author: NIIBE Yutaka Date: Mon Jun 18 15:08:01 2012 +0900 scd: acquire lock in new_reader_slot. * scd/apdu.c (new_reader_slot): Acquire lock. (open_ct_reader, open_pcsc_reader_direct, open_pcsc_reader_wrapped) (open_ccid_reader, open_rapdu_reader): Release lock. -- Fixes a test case of: No libpcsclite1 installed. Run gpg-agent Run command "gpg-connect-agent learn /bye" with no card/token Sometimes it fails: ERR 100663356 Not supported While it should be always: ERR 100663404 Card error commit 7f3ea446609355c96e90f0b6beb057daa1152643 Author: NIIBE Yutaka Date: Mon Jun 18 14:52:53 2012 +0900 scd: move lock_slot, trylock_slot, unlock_slot functions. * scd/apdu.c (lock_slot, trylock_slot, unlock_slot): Move. -- This is for upcoming changes. commit 29b431fcf97a9e615d34a7a40e570e63834b360a Merge: 3e39a9a cc13771 Author: NIIBE Yutaka Date: Fri Jun 15 16:50:45 2012 +0900 Merge branch 'scd-backport-2-0' of git+ssh://playfair.gnupg.org/git/gnupg into scd-backport-2-0 commit 3e39a9aeaadd9d4ea7ea578dc77504bd1fd6e30a Author: NIIBE Yutaka Date: Fri Jun 15 16:46:59 2012 +0900 scd: Fix merge mistake. * scd/iso7816.c (iso7816_reset_retry_counter): Implement. commit d138fe5c30c877856b4c397147bb0090705821f8 Author: Werner Koch Date: Thu Dec 15 21:45:35 2011 +0100 scd: Prefer application Geldkarte over DINSIG. * scd/app.c (select_application): Reorder application tests. -- Although the DINSIG application is available on most German cards, it is in reality not used. Thus showing the Geldkarte application is more desirable for a good user experience. commit 2586eac997911869008cb3ba57865a7d63a2afc3 Author: Werner Koch Date: Mon Dec 19 18:26:47 2011 +0100 scd: Fix for card change returning GPG_ERR_CARD_RESET. * scd/apdu.c (apdu_connect): Do not test for zero atrlen. -- When gpg-agent prompts for insertion of a card this error would be returned. Co-authored-by: Ben Kibbey commit 685955444823a5ca1190b109043ee773bf206bae Author: NIIBE Yutaka Date: Fri Jan 6 13:50:21 2012 +0900 Merge ccid_driver_improvement branch. (backport) * scd/apdu.c (ccid_keypad_operation): Rename from ccid_keypad_verify. (open_ccid_reader): Use ccid_keypad_operation for verify and modify. * scd/ccid-driver.c (VENDOR_VASCO, VASCO_920): New. (ccid_transceive_apdu_level): Permit sending packet where apdulen <= 289. Support receiving packets in a chain. (ccid_transceive_secure): Maximum is 15 for VASCO DIGIPASS 920. Support keypad_modify method such as CHANGE_REFERENCE_DATA: 0x24. commit f78cdf6d45708b67bc3d7bf7b90283254fdd23fd Author: NIIBE Yutaka Date: Tue Dec 20 13:34:27 2011 +0900 Add error log and debug log for pcsc_keypad_verify and pcsc_keypad_modify. * scd/apdu.c (pcsc_keypad_verify): Add debug log and error log. (pcsc_keypad_modify): Likewise. commit 1b0968ce9a642671f902ceddbafb5af4fe51535b Author: NIIBE Yutaka Date: Fri Dec 2 13:57:12 2011 +0900 Fix pinpad input support for passphrase modification. (backport) * apdu.c (pcsc_keypad_verify): Have dummy Lc field with value 0. (pcsc_keypad_modify): Likewise. (pcsc_keypad_modify): It's only for ISO7816_CHANGE_REFERENCE_DATA. bConfirmPIN value is determined by the parameter p0. * app-openpgp.c (do_change_pin): The flag use_keypad should be 0 when reset_mode is on, or resetcode is on. use_keypad only makes sense for iso7816_change_reference_data_kp. * iso7816.h (iso7816_put_data_kp): Remove. (iso7816_reset_retry_counter_kp): Remove. (iso7816_reset_retry_counter_with_rc_kp): Remove. (iso7816_change_reference_data_kp): Add an argument: IS_EXCHANGE. * iso7816.c (iso7816_put_data_kp): Remove. (iso7816_reset_retry_counter_kp): Remove. (iso7816_reset_retry_counter_with_rc_kp): Remove. (iso7816_change_reference_data_kp): Add an argument: IS_EXCHANGE. commit b480f18e1de71766fc6b4fb3c50e157d0abffda5 Author: NIIBE Yutaka Date: Thu Dec 1 11:09:51 2011 +0900 scd: Fix pinpad input support (backport from master) * app-openpgp.c (do_change_pin): Fix pincb messages when use_keypad == 1. commit 7cd8b12e25b6daabedf6fdc2f350327e2116fc78 Author: NIIBE Yutaka Date: Tue Nov 29 11:59:32 2011 +0900 scd: PC/SC pinpad support (pinpad input for modify pass phrase). (backport) * iso7816.h (iso7816_change_reference_data_kp): Remove arguments of OLDCHV, OLDCHVLEN, NEWCHV, and NEWCHVLEN. * iso7816.c (iso7816_change_reference_data_kp): Call apdu_keypad_modify. (iso7816_change_reference_data): Don't call iso7816_change_reference_data_kp. * apdu.h (apdu_keypad_modify): New. * apdu.c (pcsc_keypad_modify, apdu_keypad_modify): New. (struct reader_table_s): New memeber function keypad_modify. (new_reader_slot, open_ct_reader, open_ccid_reader) (open_rapdu_reader): Initialize keypad_modify. * app-openpgp.c (do_change_pin): Handle keypad and call iso7816_change_reference_data_kp if it is the case. commit 6dc187f2dbf3b5e7322fa40c7e085da12ad373d2 Author: NIIBE Yutaka Date: Mon Nov 28 16:16:38 2011 +0900 scd: PC/SC pinpad support. (Backported from master.) * iso7816.h (iso7816_verify_kp): Remove arguments of CHV and CHVLEN. * iso7816.c (iso7816_verify_kp): Call apdu_keypad_verify. Only handle thecase with PININFO. (iso7816_verify): Call apdu_send_simple. * app-openpgp.c (verify_a_chv, verify_chv3): Follow the change of iso7816_verify_kp. * app-nks.c (verify_pin): Likewise. * app-dinsig.c (verify_pin): Likewise. * apdu.c: Include "iso7816.h". (struct reader_table_s): New memeber function keypad_verify. Add fields verify_ioctl and modify_ioctl in pcsc. (CM_IOCTL_GET_FEATURE_REQUEST, FEATURE_VERIFY_PIN_DIRECT) (FEATURE_MODIFY_PIN_DIRECT): New. (pcsc_control): New. (control_pcsc_direct, control_pcsc_wrapped, control_pcsc) (check_pcsc_keypad, pcsc_keypad_verify): New. (ccid_keypad_verify, apdu_keypad_verify): New. (new_reader_slot): Initialize with check_pcsc_keypad, pcsc_keypad_verify, verify_ioctl and modify_ioctl. (open_ct_reader): Initialize keypad_verify with NULL. (open_ccid_reader): Initialize keypad_verify. (open_rapdu_reader): Initialize keypad_verify with NULL. (apdu_open_reader): Initialize pcsc_control. * pcsc-wrapper.c (load_pcsc_driver): Initialize pcsc_control. (handle_control): New. (main): Handle the case 6 of handle_control. commit cc13771675f83624a7d850b73f92e43e085b71c8 Author: Werner Koch Date: Wed Jun 13 09:35:41 2012 +0200 Fix generated ChangeLog entry. -- Finally Jim's git-fix-log thingy comes handy. commit a3ae21162ae14a6a1661ef1a6937601f6914528b Author: NIIBE Yutaka Date: Tue Jun 12 14:51:52 2012 +0900 scd fixes on error. * scd/apdu.c (open_pcsc_reader_wrapped): Show error number. * scd/command.c (get_reader_slot): Return -1 on error. commit 31584d3659497c0fff26f129c8c16a57a9e2330b Author: NIIBE Yutaka Date: Fri Jun 8 13:18:06 2012 +0900 scd: Fix the changes of scd/command.c * scd/command.c (do_reset): Assign slot after setting slot_table. commit ffd7ebf62963adb044ee56f0e1b87be837b8f179 Author: Werner Koch Date: Wed Dec 14 10:30:01 2011 +0100 scd: Fix resetting and closing of the reader. (Backported by gniibe) * scd/command.c (update_card_removed): Do no act on an invalid VRDR. (do_reset): Ignore apdu_reset error codes for no and inactive card. Close the reader before setting the slot to -1. (update_reader_status_file): Notify the application before closing the reader. -- With this change the scd now works as it did in the past. In particular there is no more endless loop trying to open the reader by the update_reader_status_file ticker function. That bug basically blocked all card operations until the scdaemon was killed. commit fae87058eac21b41e6ec0ad6dca1f4b4f806ab73 Author: Werner Koch Date: Mon Dec 12 21:02:54 2011 +0100 scd: Retry command SERIALNO for an inactive card. * scd/command.c (cmd_serialno): Retry once for an inactive card. commit 775a5f4b92fde3151d0faa88fae2b8ccfbea2928 Author: Werner Koch Date: Mon Dec 12 20:34:12 2011 +0100 Fix detection of card removal and insertion. * scd/apdu.c (apdu_connect): Return status codes for no card available and inactive card. * scd/command.c (TEST_CARD_REMOVAL): Also test for GPG_ERR_CARD_RESET. (open_card): Map apdu_connect status to GPG_ERR_CARD_RESET. commit 08178d1e130a856622c0b938a34eb109bde79262 Author: Werner Koch Date: Fri Dec 2 18:09:58 2011 +0100 Support the Cherry ST-2000 card reader. * scd/ccid-driver.c (SCM_SCR331, SCM_SCR331DI, SCM_SCR335) (SCM_SCR3320, SCM_SPR532, CHERRY_ST2000): New constants. (parse_ccid_descriptor): Use them. (scan_or_find_usb_device, ccid_transceive_secure): Handle Cherry ST-2000. Suggested by Matthias-Christian Ott. commit dafa7aa621dfe36c5c6cf462d3ec0d6c614ab105 Author: NIIBE Yutaka Date: Thu Jan 13 16:38:31 2011 +0900 fix wLangId in ccid-driver.c -- From gniibe at fsij.org Fri Jun 22 05:19:04 2012 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 22 Jun 2012 12:19:04 +0900 Subject: scd-backport-2-0 branch In-Reply-To: <1340333380.2119.1.camel@latx1.gniibe.org> References: <1340333380.2119.1.camel@latx1.gniibe.org> Message-ID: <1340335144.2119.3.camel@latx1.gniibe.org> On 2012-06-22 at 11:49 +0900, NIIBE Yutaka wrote: > I backported SCD (scdaemon) related changes to scd-backport-2-0 > branch. If it doesn't have any problem, I'd like to merge it into > STABLE-BRANCH-2-0. BTW, during the work of backport, I couldn't understand the reason why scdaemon remains after removal of card (or removal of card reader / token). I think that it is easier to just shutdown scdaemon when it detects removal of card. Please teach me about the design of scdaemon. -- From dkg at fifthhorseman.net Fri Jun 22 05:57:47 2012 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 21 Jun 2012 23:57:47 -0400 Subject: Using second keyring may be misleading? In-Reply-To: <20120615123056.GC2438@sivokote.iziade.m$> References: <20120614141029.GC2776@sivokote.iziade.m$> <8762asvl0j.fsf@vigenere.g10code.de> <20120615123056.GC2438@sivokote.iziade.m$> Message-ID: <4FE3ED3B.8070303@fifthhorseman.net> On 06/15/2012 08:30 AM, Georgi Guninski wrote: > This is ubuntu's problem I don't care much about, but they need to > verify the keys are signed. > > The k at k contains a subkey colliding with ubuntu's key 3F272F5B. colliding at how many trailing bits? what happens if you use "--keyid-format long"? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: From guninski at guninski.com Fri Jun 22 08:32:27 2012 From: guninski at guninski.com (Georgi Guninski) Date: Fri, 22 Jun 2012 09:32:27 +0300 Subject: Using second keyring may be misleading? In-Reply-To: <4FE3ED3B.8070303@fifthhorseman.net> References: <20120614141029.GC2776@sivokote.iziade.m$> <8762asvl0j.fsf@vigenere.g10code.de> <20120615123056.GC2438@sivokote.iziade.m$> <4FE3ED3B.8070303@fifthhorseman.net> Message-ID: <20120622063227.GA2777@sivokote.iziade.m$> On Thu, Jun 21, 2012 at 11:57:47PM -0400, Daniel Kahn Gillmor wrote: > On 06/15/2012 08:30 AM, Georgi Guninski wrote: > > This is ubuntu's problem I don't care much about, but they need to > > verify the keys are signed. > > > > The k at k contains a subkey colliding with ubuntu's key 3F272F5B. > > colliding at how many trailing bits? what happens if you use > "--keyid-format long"? > > --dkg > Sorry but I don't have time to waste on this. The colliding keyring is in this thread and ubuntu's master key is available in the distribution and on keyservers. The attack succeeded (ubuntu used --with-colons). For me |--keyid-format long| shows complete collision of 64 bits, same for |--with-colons|, as per design of the collision. From wk at gnupg.org Fri Jun 22 10:25:10 2012 From: wk at gnupg.org (Werner Koch) Date: Fri, 22 Jun 2012 10:25:10 +0200 Subject: scd-backport-2-0 branch In-Reply-To: <1340333380.2119.1.camel@latx1.gniibe.org> (NIIBE Yutaka's message of "Fri, 22 Jun 2012 11:49:40 +0900") References: <1340333380.2119.1.camel@latx1.gniibe.org> Message-ID: <877guzlpnd.fsf@vigenere.g10code.de> On Fri, 22 Jun 2012 04:49, gniibe at fsij.org said: > I backported SCD (scdaemon) related changes to scd-backport-2-0 > branch. If it doesn't have any problem, I'd like to merge it into > STABLE-BRANCH-2-0. I am fine with this. Shall I prepare a release candidate then? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Jun 22 10:32:36 2012 From: wk at gnupg.org (Werner Koch) Date: Fri, 22 Jun 2012 10:32:36 +0200 Subject: scd-backport-2-0 branch In-Reply-To: <1340335144.2119.3.camel@latx1.gniibe.org> (NIIBE Yutaka's message of "Fri, 22 Jun 2012 12:19:04 +0900") References: <1340333380.2119.1.camel@latx1.gniibe.org> <1340335144.2119.3.camel@latx1.gniibe.org> Message-ID: <87395nlpaz.fsf@vigenere.g10code.de> On Fri, 22 Jun 2012 05:19, gniibe at fsij.org said: > BTW, during the work of backport, I couldn't understand the reason why > scdaemon remains after removal of card (or removal of card reader / > token). I think that it is easier to just shutdown scdaemon when > it detects removal of card. One reason is that scdaemon monitors the card reader and tells other application about the presence of a card. The main mechanism for this are the "reader_N.status" files. There is also an option to run a script and meanwhile I may even agree to add d-bus support as an option. Another reason is that we eventually want to support RFID reader where the card presence is not as easy monitored as with USB tokens or card readers. What we should change is the baroque way of setting up channels between gpg-agent and scdaemon; i.e. a mix of pipe and socket servers. To streamline the system it would be better to use a well known socket for scdaemon in the same way as gpg-agent does it. But that is something for 2.1. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wking at tremily.us Fri Jun 22 11:10:58 2012 From: wking at tremily.us (W. Trevor King) Date: Fri, 22 Jun 2012 05:10:58 -0400 Subject: [GnuPG] Re: scd-backport-2-0 branch In-Reply-To: <87395nlpaz.fsf@vigenere.g10code.de> References: <1340333380.2119.1.camel@latx1.gniibe.org> <1340335144.2119.3.camel@latx1.gniibe.org> <87395nlpaz.fsf@vigenere.g10code.de> Message-ID: <20120622091058.GA4834@odin.tremily.us> On Fri, Jun 22, 2012 at 10:32:36AM +0200, Werner Koch wrote: > What we should change is the baroque way of setting up channels between > gpg-agent and scdaemon; i.e. a mix of pipe and socket servers. To > streamline the system it would be better to use a well known socket for > scdaemon in the same way as gpg-agent does it. But that is something > for 2.1. This seems like a good opportunity to bump my libassuan suggestions [1]. I've dropped this while I'm waiting on some my gpgme INPUT/OUTPUT handler patch [2], since I don't want to overwhelm you guys, but I'm happy to get back to work if your're ready to start reviewing my patches ;). Cheers, Trevor [1]: http://lists.gnupg.org/pipermail/gnupg-devel/2012-April/026670.html [2]: Which for some reason I cannot find in the archives on http://lists.gnupg.org/pipermail/gnupg-devel/ -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Fri Jun 22 11:10:35 2012 From: wk at gnupg.org (Werner Koch) Date: Fri, 22 Jun 2012 11:10:35 +0200 Subject: v3 subkeys and signatures (was: Using second keyring may be) In-Reply-To: <4FE3ED3B.8070303@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 21 Jun 2012 23:57:47 -0400") References: <20120614141029.GC2776@sivokote.iziade.m$> <8762asvl0j.fsf@vigenere.g10code.de> <20120615123056.GC2438@sivokote.iziade.m$> <4FE3ED3B.8070303@fifthhorseman.net> Message-ID: <87y5nfk8z8.fsf_-_@vigenere.g10code.de> On Fri, 22 Jun 2012 05:57, dkg at fifthhorseman.net said: > colliding at how many trailing bits? what happens if you use > "--keyid-format long"? The problem is that the colliding key is a v3 key (MD5 fingerprint). It is easy to create key id collissions for such keys; that is the reason that back in the time of PGP 2 folks were used to compare the creation date and key size. If we list 0BFB847F3F272F5 we see a couple of irregularities: pub 1024R/0BC39F3FB1C08810 2012-06-14 Key fingerprint = C42E F0DA 1A9C 27FA 5032 D7CB 0BC3 9F3F B1C0 8810 uid kkkkkkk5 sig!3 0BC39F3FB1C08810 2012-06-14 kkkkkkk5 sig% 0BFB847F3F272F5B 2012-06-14 [Time conflict] sig! 0BFB847F3F272F5B 2012-06-14 kkkkkkk5 sub 1024R/C3A7416F0354AE88 2012-06-14 Key fingerprint = 2F55 379F 8AB0 E8F1 D2BB 7EAF C3A7 416F 0354 AE88 sig! 0BC39F3FB1C08810 2012-06-14 kkkkkkk5 sub 2179R/0BFB847F3F272F5B 2012-06-14 Key fingerprint = 7F C0 FE A6 A0 11 78 5A 06 7A CA CE A4 D7 12 80 [Note: a v3 key with a uncommon key size!] sig! 0BC39F3FB1C08810 2012-06-14 kkkkkkk5 pub 4096R/0BFB847F3F272F5B 2007-11-09 Key fingerprint = 153F 1C9E F139 5FBF 0035 2E8D 0BFB 847F 3F27 2F5B uid Ubuntu Archive Master Signing Key pub 4096R/0BFB847F3F272F5B 2007-11-09 Key fingerprint = 153F 1C9E F139 5FBF 0035 2E8D 0BFB 847F 3F27 2F5B uid Ubuntu Archive Master Signing Key Because GPG uses the (long keyid) to lookup the key in its internal database it is prone to these errors. The first ?sig%? is due to checking against the wrong key. The double listing the Ubuntu key has a similar cause. To mitigate the problem we should consider to forbid v3 subkeys. That is to ignore v3 subkeys in cases where a subkey is expected. I have not checked the RFC whether they are allowed, but they make no sense. Actually it can be considered a bug: We have a strong (SHA-1) primary key but allow a week (MD5) subkey. We might also consider to ignore all v3 keys. After all MD5 is broken and such keys should not be used anymore. One exception is to allow decryption using a v3 key. Importing a v3 secret key will continue to work, but v3 public keys would be skipped during import. A complete solution to this problem would be a v5 signature packet format to put the entire fingerprint into the signature packet. However this breaks backward compatibility and thus will take a few years before those signatures become mainstream. If we expect v4 long key id collisions to occur more often in the future, we should implement a workaround. For example we could store the fingerprint for a signature packet in the meta data after we successfully verified a signature the first time. Key lookups would then use the fingerprint if available in the signature packet meta data. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dshaw at jabberwocky.com Fri Jun 22 14:24:39 2012 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 22 Jun 2012 08:24:39 -0400 Subject: Using second keyring may be misleading? In-Reply-To: <4FE3ED3B.8070303@fifthhorseman.net> References: <20120614141029.GC2776@sivokote.iziade.m$> <8762asvl0j.fsf@vigenere.g10code.de> <20120615123056.GC2438@sivokote.iziade.m$> <4FE3ED3B.8070303@fifthhorseman.net> Message-ID: On Jun 21, 2012, at 11:57 PM, Daniel Kahn Gillmor wrote: > On 06/15/2012 08:30 AM, Georgi Guninski wrote: >> This is ubuntu's problem I don't care much about, but they need to >> verify the keys are signed. >> >> The k at k contains a subkey colliding with ubuntu's key 3F272F5B. > > colliding at how many trailing bits? what happens if you use > "--keyid-format long"? It collides in all 64 bits. It's a v3 subkey on a v4 key, so presumably uses the standard DEADBEEF trick. David From guninski at guninski.com Fri Jun 22 14:48:07 2012 From: guninski at guninski.com (Georgi Guninski) Date: Fri, 22 Jun 2012 15:48:07 +0300 Subject: Forging key signatures with collisions Message-ID: <20120622124807.GB2777@sivokote.iziade.m$> Forging key signatures with collisions This is a fork of the keyring thread. Attached is fake1 key which seemingly appears signed by pub 1024D/40976EAF437D05B5 2004-09-12 uid Ubuntu Archive Automatic Signing Key which is certainly not the case (good selfsig if the above is not imported) Session: $gpg --recv-keys 0x437D05B5 $gpg --import /tmp/fake1 gpg: WARNING: digest algorithm MD5 is deprecated gpg: please see http://www.gnupg.org/faq/weak-digest-algos.html for more information gpg: key 79164387: public key "Ubuntu Archive Automatic Signing Key " imported #WRONG gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1) $gpg --check-sigs --keyid-f long /home/joro2/.gnupg/pubring.gpg ------------------------------ pub 1024D/40976EAF437D05B5 2004-09-12 uid Ubuntu Archive Automatic Signing Key sig!3 40976EAF437D05B5 2004-09-12 Ubuntu Archive Automatic Signing Key sub 2048g/251BEFF479164387 2004-09-12 sig! 40976EAF437D05B5 2004-09-12 Ubuntu Archive Automatic Signing Key pub 2047R/251BEFF479164387 2012-06-22 uid fake 3 sig!3 251BEFF479164387 2012-06-22 Ubuntu Archive Automatic Signing Key #WRONG sub 2047R/251BEFF479164387 2012-06-22 sig! 251BEFF479164387 2012-06-22 Ubuntu Archive Automatic Signing Key #WRONG 40 signatures not checked due to missing keys Stay assured the colliding keysize is completely under control... From guninski at guninski.com Fri Jun 22 14:55:39 2012 From: guninski at guninski.com (Georgi Guninski) Date: Fri, 22 Jun 2012 15:55:39 +0300 Subject: Forging key signatures with collisions In-Reply-To: <20120622124807.GB2777@sivokote.iziade.m$> References: <20120622124807.GB2777@sivokote.iziade.m$> Message-ID: <20120622125539.GC2777@sivokote.iziade.m$> Forgot the attachment. On Fri, Jun 22, 2012 at 03:48:07PM +0300, Georgi Guninski wrote: > Forging key signatures with collisions > > This is a fork of the keyring thread. > Attached is fake1 key which seemingly appears signed by > pub 1024D/40976EAF437D05B5 2004-09-12 > uid Ubuntu Archive Automatic Signing Key > > which is certainly not the case (good selfsig if the above is not imported) > > Session: > $gpg --recv-keys 0x437D05B5 > > $gpg --import /tmp/fake1 > gpg: WARNING: digest algorithm MD5 is deprecated > gpg: please see http://www.gnupg.org/faq/weak-digest-algos.html for more information > gpg: key 79164387: public key "Ubuntu Archive Automatic Signing Key " imported #WRONG > gpg: Total number processed: 1 > gpg: imported: 1 (RSA: 1) > $gpg --check-sigs --keyid-f long > /home/joro2/.gnupg/pubring.gpg > ------------------------------ > pub 1024D/40976EAF437D05B5 2004-09-12 > uid Ubuntu Archive Automatic Signing Key > sig!3 40976EAF437D05B5 2004-09-12 Ubuntu Archive Automatic Signing Key > sub 2048g/251BEFF479164387 2004-09-12 > sig! 40976EAF437D05B5 2004-09-12 Ubuntu Archive Automatic Signing Key > > pub 2047R/251BEFF479164387 2012-06-22 > uid fake 3 > sig!3 251BEFF479164387 2012-06-22 Ubuntu Archive Automatic Signing Key #WRONG > sub 2047R/251BEFF479164387 2012-06-22 > sig! 251BEFF479164387 2012-06-22 Ubuntu Archive Automatic Signing Key #WRONG > > 40 signatures not checked due to missing keys > > > Stay assured the colliding keysize is completely under control... > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: fake1 Type: application/octet-stream Size: 1124 bytes Desc: not available URL: From guninski at guninski.com Fri Jun 22 16:16:48 2012 From: guninski at guninski.com (Georgi Guninski) Date: Fri, 22 Jun 2012 17:16:48 +0300 Subject: Forging key signatures with collisions In-Reply-To: <20120622124807.GB2777@sivokote.iziade.m$> References: <20120622124807.GB2777@sivokote.iziade.m$> Message-ID: <20120622141648.GD2777@sivokote.iziade.m$> This is getting stranger... The primary colliding key appears unusable if it is imported second. But if i create a subkey in it (using tricks) the subkey appears signed by the wrong user. Have the private key for it, but can't make signatures yet (maybe gpg needs more patching). If i can make a signature with the subkey it might be reported by the wrong user (probably with the correct keyid): $gpg --import < /tmp/fake4 $gpg --check-sigs --keyid-f long pub 2047R/251BEFF479164387 2012-06-22 uid fake 4 sig!3 251BEFF479164387 2012-06-22 Ubuntu Archive Automatic Signing Key sub 2047R/251BEFF479164387 2012-06-22 sig! 251BEFF479164387 2012-06-22 Ubuntu Archive Automatic Signing Key sub 2048R/99270C331D426C85 2012-06-22 sig! 251BEFF479164387 2012-06-22 Ubuntu Archive Automatic Signing Key # 99... doesn't collide with anything to my knowledge and the secret key is available. -------------- next part -------------- A non-text attachment was scrubbed... Name: fake4 Type: application/octet-stream Size: 1679 bytes Desc: not available URL: From guninski at guninski.com Fri Jun 22 16:40:46 2012 From: guninski at guninski.com (Georgi Guninski) Date: Fri, 22 Jun 2012 17:40:46 +0300 Subject: Using second keyring may be misleading? In-Reply-To: References: <20120614141029.GC2776@sivokote.iziade.m$> <8762asvl0j.fsf@vigenere.g10code.de> <20120615123056.GC2438@sivokote.iziade.m$> <4FE3ED3B.8070303@fifthhorseman.net> Message-ID: <20120622144046.GF2777@sivokote.iziade.m$> On Fri, Jun 22, 2012 at 08:24:39AM -0400, David Shaw wrote: > > It collides in all 64 bits. It's a v3 subkey on a v4 key, so presumably uses the standard DEADBEEF trick. > is this trick documented somewhere? probably i rediscovered it. From dshaw at jabberwocky.com Fri Jun 22 17:23:20 2012 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 22 Jun 2012 11:23:20 -0400 Subject: Using second keyring may be misleading? In-Reply-To: <20120622144046.GF2777@sivokote.iziade.m$> References: <20120614141029.GC2776@sivokote.iziade.m$> <8762asvl0j.fsf@vigenere.g10code.de> <20120615123056.GC2438@sivokote.iziade.m$> <4FE3ED3B.8070303@fifthhorseman.net> <20120622144046.GF2777@sivokote.iziade.m$> Message-ID: <6D30623D-191E-4163-8120-CAEAF4867D70@jabberwocky.com> On Jun 22, 2012, at 10:40 AM, Georgi Guninski wrote: > On Fri, Jun 22, 2012 at 08:24:39AM -0400, David Shaw wrote: >> >> It collides in all 64 bits. It's a v3 subkey on a v4 key, so presumably uses the standard DEADBEEF trick. >> > > is this trick documented somewhere? > > probably i rediscovered it. A few people pointed it out in the mid-1990s (that long ago!) but I think it was first proposed by Paul Leyland at Oxford. Here's an old posting about it: http://groups.google.com/group/sci.crypt/browse_thread/thread/25248ce8d6dfc1e4/e5372a1bd972dc07 It was one of the many things that prompted the V4 key format. It doesn't break the web of trust, but can confuse people (and implementations) as to which key is which. David From dshaw at jabberwocky.com Fri Jun 22 17:23:22 2012 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 22 Jun 2012 11:23:22 -0400 Subject: Speaking of manipulated keys... Message-ID: What with all the talk about DEADBEEF and keys manipulated in one way or another, I thought I'd mention an amusing DEADBEEF-style key that I came across once: http://pool.sks-keyservers.net:11371/pks/lookup?search=0xC0DED00D&op=index So, he DEADBEEFed himself a "Code Dood" key ID? but now check out the ASCII armor of the whole key. David From dshaw at JABBERWOCKY.COM Fri Jun 22 17:23:22 2012 From: dshaw at JABBERWOCKY.COM (David Shaw) Date: Fri, 22 Jun 2012 11:23:22 -0400 Subject: Speaking of manipulated keys... Message-ID: What with all the talk about DEADBEEF and keys manipulated in one way or another, I thought I'd mention an amusing DEADBEEF-style key that I came across once: http://pool.sks-keyservers.net:11371/pks/lookup?search=0xC0DED00D&op=index So, he DEADBEEFed himself a "Code Dood" key ID? but now check out the ASCII armor of the whole key. David From guninski at guninski.com Fri Jun 22 18:12:42 2012 From: guninski at guninski.com (Georgi Guninski) Date: Fri, 22 Jun 2012 19:12:42 +0300 Subject: Using second keyring may be misleading? In-Reply-To: <6D30623D-191E-4163-8120-CAEAF4867D70@jabberwocky.com> References: <20120614141029.GC2776@sivokote.iziade.m$> <8762asvl0j.fsf@vigenere.g10code.de> <20120615123056.GC2438@sivokote.iziade.m$> <4FE3ED3B.8070303@fifthhorseman.net> <20120622144046.GF2777@sivokote.iziade.m$> <6D30623D-191E-4163-8120-CAEAF4867D70@jabberwocky.com> Message-ID: <20120622161242.GG2777@sivokote.iziade.m$> On Fri, Jun 22, 2012 at 11:23:20AM -0400, David Shaw wrote: > A few people pointed it out in the mid-1990s (that long ago!) but I think it was first proposed by Paul Leyland at Oxford. > > Here's an old posting about it: http://groups.google.com/group/sci.crypt/browse_thread/thread/25248ce8d6dfc1e4/e5372a1bd972dc07 > > It was one of the many things that prompted the V4 key format. It doesn't break the web of trust, but can confuse people (and implementations) as to which key is which. > So it still confuses implementations? :) I am doing something similar - fixed the lowest 64 bits of p,q and generated random high bits until 2 primes are found. Even (or maybe divisible by 4) v4 keyids would need more patching or using something other than gpg for key generation. From dshaw at JABBERWOCKY.COM Fri Jun 22 18:40:23 2012 From: dshaw at JABBERWOCKY.COM (David Shaw) Date: Fri, 22 Jun 2012 12:40:23 -0400 Subject: v3 subkeys and signatures (was: Using second keyring may be) In-Reply-To: <87y5nfk8z8.fsf_-_@vigenere.g10code.de> References: <20120614141029.GC2776@sivokote.iziade.m$> <8762asvl0j.fsf@vigenere.g10code.de> <20120615123056.GC2438@sivokote.iziade.m$> <4FE3ED3B.8070303@fifthhorseman.net> <87y5nfk8z8.fsf_-_@vigenere.g10code.de> Message-ID: <3AB48664-618B-4C95-A540-2A9E9751397B@JABBERWOCKY.COM> On Jun 22, 2012, at 5:10 AM, Werner Koch wrote: > Because GPG uses the (long keyid) to lookup the key in its internal > database it is prone to these errors. The first ?sig%? is due to > checking against the wrong key. The double listing the Ubuntu key has a > similar cause. > > To mitigate the problem we should consider to forbid v3 subkeys. That > is to ignore v3 subkeys in cases where a subkey is expected. I have not > checked the RFC whether they are allowed, but they make no sense. > Actually it can be considered a bug: We have a strong (SHA-1) primary > key but allow a week (MD5) subkey. It falls out like this - V3 keys can be a subkey on a V4 key (though a V3 can't be a primary and have subkeys of their own), but it's sort of moot since V3 keys are MUST NOT generate. So this key is legal format-wise (though obviously manipulated). > We might also consider to ignore all v3 keys. After all MD5 is broken > and such keys should not be used anymore. One exception is to allow > decryption using a v3 key. Importing a v3 secret key will continue to > work, but v3 public keys would be skipped during import. I strongly agree with this. It's legal to ignore V3 keys in the spec ("....MAY accept or reject them as it sees fit.") so that's fine. I'd have it ignore V3 keys by default (while still allowing decryption), but allow users to turn full V3 use back on if they must. David From wk at gnupg.org Fri Jun 22 19:33:03 2012 From: wk at gnupg.org (Werner Koch) Date: Fri, 22 Jun 2012 19:33:03 +0200 Subject: v3 subkeys and signatures In-Reply-To: <3AB48664-618B-4C95-A540-2A9E9751397B@JABBERWOCKY.COM> (David Shaw's message of "Fri, 22 Jun 2012 12:40:23 -0400") References: <20120614141029.GC2776@sivokote.iziade.m$> <8762asvl0j.fsf@vigenere.g10code.de> <20120615123056.GC2438@sivokote.iziade.m$> <4FE3ED3B.8070303@fifthhorseman.net> <87y5nfk8z8.fsf_-_@vigenere.g10code.de> <3AB48664-618B-4C95-A540-2A9E9751397B@JABBERWOCKY.COM> Message-ID: <87pq8rjlps.fsf@vigenere.g10code.de> On Fri, 22 Jun 2012 18:40, dshaw at JABBERWOCKY.COM said: > ("....MAY accept or reject them as it sees fit.") so that's fine. I'd > have it ignore V3 keys by default (while still allowing decryption), > but allow users to turn full V3 use back on if they must. I fully agree. We always provided compatibility switches. What do you think? Shall we use the --pgp2 option for this as well, or shall we add another one? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From lists-gnupgdev at lina.inka.de Fri Jun 22 19:01:26 2012 From: lists-gnupgdev at lina.inka.de (ecki@lina.inka.de) Date: Fri, 22 Jun 2012 19:01:26 +0200 Subject: v3 subkeys and signatures (was: Using second keyring may be) In-Reply-To: <87y5nfk8z8.fsf_-_@vigenere.g10code.de> References: <20120614141029.GC2776@sivokote.iziade.m$> <8762asvl0j.fsf@vigenere.g10code.de> <20120615123056.GC2438@sivokote.iziade.m$> <4FE3ED3B.8070303@fifthhorseman.net> <87y5nfk8z8.fsf_-_@vigenere.g10code.de> Message-ID: Am 22.06.2012, 11:10 Uhr, schrieb Werner Koch : > The problem is that the colliding key is a v3 key (MD5 fingerprint). It > is easy to create key id collissions for such keys Wonder if it would be possible to find all keys with this keyid with the API and in case of signature validation to try all of them? (and then in turn base the decision on the right one... hmm). Bernd -- http://bernd.eckenfels.net From dshaw at jabberwocky.com Fri Jun 22 20:06:56 2012 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 22 Jun 2012 14:06:56 -0400 Subject: Using second keyring may be misleading? In-Reply-To: <20120622161242.GG2777@sivokote.iziade.m$> References: <20120614141029.GC2776@sivokote.iziade.m$> <8762asvl0j.fsf@vigenere.g10code.de> <20120615123056.GC2438@sivokote.iziade.m$> <4FE3ED3B.8070303@fifthhorseman.net> <20120622144046.GF2777@sivokote.iziade.m$> <6D30623D-191E-4163-8120-CAEAF4867D70@jabberwocky.com> <20120622161242.GG2777@sivokote.iziade.m$> Message-ID: <9FB524C6-E9BF-43D7-94E5-E4FA9180ABDF@jabberwocky.com> On Jun 22, 2012, at 12:12 PM, Georgi Guninski wrote: > On Fri, Jun 22, 2012 at 11:23:20AM -0400, David Shaw wrote: >> A few people pointed it out in the mid-1990s (that long ago!) but I think it was first proposed by Paul Leyland at Oxford. >> >> Here's an old posting about it: http://groups.google.com/group/sci.crypt/browse_thread/thread/25248ce8d6dfc1e4/e5372a1bd972dc07 >> >> It was one of the many things that prompted the V4 key format. It doesn't break the web of trust, but can confuse people (and implementations) as to which key is which. >> > > So it still confuses implementations? :) Alas :) Unfortunately, it's pretty inherent in the design. The issuer subpacket that contains the key ID for a signature only has the 64-bit key ID. We'd need a new issuer subpacket that contained the whole fingerprint. > I am doing something similar - fixed the lowest 64 bits of p,q > and generated random high bits until 2 primes are found. > > Even (or maybe divisible by 4) v4 keyids would need more > patching or using something other than gpg for key generation. Yes, that's what I'm doing, with a similar limitation around even numbered key IDs. David From dshaw at jabberwocky.com Fri Jun 22 20:08:13 2012 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 22 Jun 2012 14:08:13 -0400 Subject: The two V3 attacks Message-ID: <42651FC3-F3DF-49D6-9616-191FEE311C42@jabberwocky.com> For the curious, I found pointers to the two big fingerprint/keyID spoofing attacks in V3: DEADBEEF (spoofs key IDs, but not fingerprints): http://groups.google.com/group/sci.crypt/browse_thread/thread/25248ce8d6dfc1e4/e5372a1bd972dc07 Bit sliding (spoofs fingerprints, but mangles the size in the process): http://groups.google.com/group/nl.comp.crypt/browse_thread/thread/770e8cc32fb222c7/175823454f2649dc So neither of these are terribly new attacks (both dating from the 1990s). I had a brainstorm last year about using a DEADBEEF V3 key to collide with a V4 key, as the only way to tell which key was required (for verifying a signature, for example) was via the 64-bit key ID and inside the signature, there was no way to tell if it was a V3 or V4 key making the signature. That may have been the first mention of that particular variant - I don't know. There was some discussion about this on the IETF WG list at the time, but it's really an implementation issue (by the spec, implementations are not required to accept V3 keys if they don't want to). Note one of the caveats about using DEADBEEF to collide with V4: even numbered keys. Since the key ID is the lower 64 bits of p*q, and p and q are large primes, the key ID for a valid key will always be odd. Offhand I can't think of a simple way around this without the key being either extremely weak, or invalid (a nice thing about DEADBEEF is that it's a collision, but it's a real usable key as well). I suppose if the intent is to just create trouble, then those restrictions are less important. The other thing to note about DEADBEEF is that this sort of collision can happen V4-V4 as well. It's just very unlikely. Someone astutely pointed out in the original discussion that the possibility of V3-V4 collisions sort of keeps us honest - that banning V3 may mean we won't fix the V4-V4 problem because it's so hard to cause. I look at banning V3 as buying us time to fix V4 (or go to V5). David From wk at gnupg.org Fri Jun 22 22:55:00 2012 From: wk at gnupg.org (Werner Koch) Date: Fri, 22 Jun 2012 22:55:00 +0200 Subject: v3 subkeys and signatures In-Reply-To: (lists-gnupgdev@lina.inka.de's message of "Fri, 22 Jun 2012 19:01:26 +0200") References: <20120614141029.GC2776@sivokote.iziade.m$> <8762asvl0j.fsf@vigenere.g10code.de> <20120615123056.GC2438@sivokote.iziade.m$> <4FE3ED3B.8070303@fifthhorseman.net> <87y5nfk8z8.fsf_-_@vigenere.g10code.de> Message-ID: <87lijfjcd7.fsf@vigenere.g10code.de> On Fri, 22 Jun 2012 19:01, lists-gnupgdev at lina.inka.de said: > Wonder if it would be possible to find all keys with this keyid with > the API and in case of signature validation to try all of them? (and Sure this is possible. The main problem will be to decide what error message to print in case no key results in a good signature. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dshaw at jabberwocky.com Sat Jun 23 04:51:25 2012 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 22 Jun 2012 22:51:25 -0400 Subject: v3 subkeys and signatures In-Reply-To: <87pq8rjlps.fsf@vigenere.g10code.de> References: <20120614141029.GC2776@sivokote.iziade.m$> <8762asvl0j.fsf@vigenere.g10code.de> <20120615123056.GC2438@sivokote.iziade.m$> <4FE3ED3B.8070303@fifthhorseman.net> <87y5nfk8z8.fsf_-_@vigenere.g10code.de> <3AB48664-618B-4C95-A540-2A9E9751397B@JABBERWOCKY.COM> <87pq8rjlps.fsf@vigenere.g10code.de> Message-ID: <1C071AD6-0AA1-4DEF-9B01-4FDF2D87FC0A@jabberwocky.com> On Jun 22, 2012, at 1:33 PM, Werner Koch wrote: > On Fri, 22 Jun 2012 18:40, dshaw at JABBERWOCKY.COM said: > >> ("....MAY accept or reject them as it sees fit.") so that's fine. I'd >> have it ignore V3 keys by default (while still allowing decryption), >> but allow users to turn full V3 use back on if they must. > > I fully agree. We always provided compatibility switches. What do you > think? Shall we use the --pgp2 option for this as well, or shall we add > another one? Hmm. I think a new option for this, which --pgp2 would also set. The reason is that if someone has to use a v3 key (either wisely or not) it seems better to not force them to take the algorithm restrictions like MD5 that come along with --pgp2. David From guninski at guninski.com Sat Jun 23 08:49:02 2012 From: guninski at guninski.com (Georgi Guninski) Date: Sat, 23 Jun 2012 09:49:02 +0300 Subject: v3 subkeys and signatures (was: Using second keyring may be) In-Reply-To: <3AB48664-618B-4C95-A540-2A9E9751397B@JABBERWOCKY.COM> References: <20120614141029.GC2776@sivokote.iziade.m$> <8762asvl0j.fsf@vigenere.g10code.de> <20120615123056.GC2438@sivokote.iziade.m$> <4FE3ED3B.8070303@fifthhorseman.net> <87y5nfk8z8.fsf_-_@vigenere.g10code.de> <3AB48664-618B-4C95-A540-2A9E9751397B@JABBERWOCKY.COM> Message-ID: <20120623064902.GA2552@sivokote.iziade.m$> On Fri, Jun 22, 2012 at 12:40:23PM -0400, David Shaw wrote: > > .... V3 can't be a primary and have subkeys of their own) This is not entirely correct. Technically v3 may have subkeys (after patching gpg) - check the keyring "fake4" that I posted on this list. Not sure if v3 subkeys are usable though - maybe gpg needs more patching to sign with them. From dshaw at jabberwocky.com Sat Jun 23 15:21:05 2012 From: dshaw at jabberwocky.com (David Shaw) Date: Sat, 23 Jun 2012 09:21:05 -0400 Subject: v3 subkeys and signatures (was: Using second keyring may be) In-Reply-To: <20120623064902.GA2552@sivokote.iziade.m$> References: <20120614141029.GC2776@sivokote.iziade.m$> <8762asvl0j.fsf@vigenere.g10code.de> <20120615123056.GC2438@sivokote.iziade.m$> <4FE3ED3B.8070303@fifthhorseman.net> <87y5nfk8z8.fsf_-_@vigenere.g10code.de> <3AB48664-618B-4C95-A540-2A9E9751397B@JABBERWOCKY.COM> <20120623064902.GA2552@sivokote.iziade.m$> Message-ID: <7AE01490-9640-4C46-BD60-014B5901963E@jabberwocky.com> On Jun 23, 2012, at 2:49 AM, Georgi Guninski wrote: > On Fri, Jun 22, 2012 at 12:40:23PM -0400, David Shaw wrote: >> >> .... V3 can't be a primary and have subkeys of their own) > > > This is not entirely correct. > > Technically v3 may have subkeys (after patching gpg) - check the > keyring "fake4" that I posted on this list. Yes. Werner and I were discussing this in the context of the OpenPGP spec. In OpenPGP, v3 keys cannot have subkeys (it's in section 11 - "V3 keys MUST NOT have subkeys"). GPG actually allowed this for a while until the spec was changed. If you patch the code, you can of course make it do anything you want :) > Not sure if v3 subkeys are usable though - maybe gpg needs more > patching to sign with them. They should be (at least in 1.4 they were). I haven't tried it in 2.x recently. David From guninski at guninski.com Sat Jun 23 15:23:00 2012 From: guninski at guninski.com (Georgi Guninski) Date: Sat, 23 Jun 2012 16:23:00 +0300 Subject: Using second keyring may be misleading? In-Reply-To: <9FB524C6-E9BF-43D7-94E5-E4FA9180ABDF@jabberwocky.com> References: <20120614141029.GC2776@sivokote.iziade.m$> <8762asvl0j.fsf@vigenere.g10code.de> <20120615123056.GC2438@sivokote.iziade.m$> <4FE3ED3B.8070303@fifthhorseman.net> <20120622144046.GF2777@sivokote.iziade.m$> <6D30623D-191E-4163-8120-CAEAF4867D70@jabberwocky.com> <20120622161242.GG2777@sivokote.iziade.m$> <9FB524C6-E9BF-43D7-94E5-E4FA9180ABDF@jabberwocky.com> Message-ID: <20120623132300.GB2552@sivokote.iziade.m$> On Fri, Jun 22, 2012 at 02:06:56PM -0400, David Shaw wrote: > > Even (or maybe divisible by 4) v4 keyids would need more > > patching or using something other than gpg for key generation. > > Yes, that's what I'm doing, with a similar limitation around even numbered key IDs. > > David Hm, with even numbered keyids do you have problems when exponentiating even naturals? Euler's theorems needs $a$ and $n$ to be coprime in a^phi(n) = 1 mod n ? From guninski at guninski.com Sat Jun 23 15:59:03 2012 From: guninski at guninski.com (Georgi Guninski) Date: Sat, 23 Jun 2012 16:59:03 +0300 Subject: v3 subkeys and signatures (was: Using second keyring may be) In-Reply-To: <7AE01490-9640-4C46-BD60-014B5901963E@jabberwocky.com> References: <20120614141029.GC2776@sivokote.iziade.m$> <8762asvl0j.fsf@vigenere.g10code.de> <20120615123056.GC2438@sivokote.iziade.m$> <4FE3ED3B.8070303@fifthhorseman.net> <87y5nfk8z8.fsf_-_@vigenere.g10code.de> <3AB48664-618B-4C95-A540-2A9E9751397B@JABBERWOCKY.COM> <20120623064902.GA2552@sivokote.iziade.m$> <7AE01490-9640-4C46-BD60-014B5901963E@jabberwocky.com> Message-ID: <20120623135903.GC2552@sivokote.iziade.m$> On Sat, Jun 23, 2012 at 09:21:05AM -0400, David Shaw wrote: > Yes. Werner and I were discussing this in the context of the OpenPGP spec. In OpenPGP, v3 keys cannot have subkeys (it's in section 11 - "V3 keys MUST NOT have subkeys"). GPG actually allowed this for a while until the spec was changed. If you patch the code, you can of course make it do anything you want :) > I meant patched gpg generated the keys, testing was done with vanilla gpg. For me fake4 *allows* v3 subkeys of v3 keys. Checked with vanilla 1.4.12 and 2.0.19. Have you tested fake4 (attached again)? I might be missing something. -------------- next part -------------- A non-text attachment was scrubbed... Name: fake4 Type: application/octet-stream Size: 1679 bytes Desc: not available URL: From dshaw at jabberwocky.com Sat Jun 23 22:41:19 2012 From: dshaw at jabberwocky.com (David Shaw) Date: Sat, 23 Jun 2012 16:41:19 -0400 Subject: v3 subkeys and signatures (was: Using second keyring may be) In-Reply-To: <20120623135903.GC2552@sivokote.iziade.m$> References: <20120614141029.GC2776@sivokote.iziade.m$> <8762asvl0j.fsf@vigenere.g10code.de> <20120615123056.GC2438@sivokote.iziade.m$> <4FE3ED3B.8070303@fifthhorseman.net> <87y5nfk8z8.fsf_-_@vigenere.g10code.de> <3AB48664-618B-4C95-A540-2A9E9751397B@JABBERWOCKY.COM> <20120623064902.GA2552@sivokote.iziade.m$> <7AE01490-9640-4C46-BD60-014B5901963E@jabberwocky.com> <20120623135903.GC2552@sivokote.iziade.m$> Message-ID: <38864BA7-CD0A-47EE-80E9-20AAAA93A600@jabberwocky.com> On Jun 23, 2012, at 9:59 AM, Georgi Guninski wrote: > On Sat, Jun 23, 2012 at 09:21:05AM -0400, David Shaw wrote: >> Yes. Werner and I were discussing this in the context of the OpenPGP spec. In OpenPGP, v3 keys cannot have subkeys (it's in section 11 - "V3 keys MUST NOT have subkeys"). GPG actually allowed this for a while until the spec was changed. If you patch the code, you can of course make it do anything you want :) >> > > > I meant patched gpg generated the keys, testing was done with vanilla gpg. Yes, this makes sense. GPG won't generate a subkey on a V3 key (or a V3 subkey at all), but might accept them if generated elsewhere. So you had to patch things to make the key, but no patch is needed to use the key. David From dkg at fifthhorseman.net Sun Jun 24 07:10:42 2012 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 24 Jun 2012 01:10:42 -0400 Subject: v3 subkeys and signatures In-Reply-To: <38864BA7-CD0A-47EE-80E9-20AAAA93A600@jabberwocky.com> References: <20120614141029.GC2776@sivokote.iziade.m$> <8762asvl0j.fsf@vigenere.g10code.de> <20120615123056.GC2438@sivokote.iziade.m$> <4FE3ED3B.8070303@fifthhorseman.net> <87y5nfk8z8.fsf_-_@vigenere.g10code.de> <3AB48664-618B-4C95-A540-2A9E9751397B@JABBERWOCKY.COM> <20120623064902.GA2552@sivokote.iziade.m$> <7AE01490-9640-4C46-BD60-014B5901963E@jabberwocky.com> <20120623135903.GC2552@sivokote.iziade.m$> <38864BA7-CD0A-47EE-80E9-20AAAA93A600@jabberwocky.com> Message-ID: <4FE6A152.8040004@fifthhorseman.net> On 06/23/2012 04:41 PM, David Shaw wrote: > Yes, this makes sense. GPG won't generate a subkey on a V3 key (or a V3 subkey at all), but might accept them if generated elsewhere. So you had to patch things to make the key, but no patch is needed to use the key. Of course, the opportunity for compromise comes when a victim *uses* of the key, not from its creation. So while i appreciate the refusal of GPG to generate these keys (which means one less tool available to an attacker for the creation of the colliding key), it doesn't really address the fact that users of GPG are at risk if they deal with keys generated elsewhere. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: From nicholas.cole at gmail.com Sun Jun 24 09:42:07 2012 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Sun, 24 Jun 2012 08:42:07 +0100 Subject: Using second keyring may be misleading? In-Reply-To: <9FB524C6-E9BF-43D7-94E5-E4FA9180ABDF@jabberwocky.com> References: <20120614141029.GC2776@sivokote.iziade.m$> <8762asvl0j.fsf@vigenere.g10code.de> <20120615123056.GC2438@sivokote.iziade.m$> <4FE3ED3B.8070303@fifthhorseman.net> <20120622144046.GF2777@sivokote.iziade.m$> <6D30623D-191E-4163-8120-CAEAF4867D70@jabberwocky.com> <20120622161242.GG2777@sivokote.iziade.m$> <9FB524C6-E9BF-43D7-94E5-E4FA9180ABDF@jabberwocky.com> Message-ID: >>> >> >> So it still confuses implementations? :) > > Alas :) > > Unfortunately, it's pretty inherent in the design. ?The issuer subpacket that contains the key ID for a signature only has the 64-bit key ID. ?We'd need a new issuer subpacket that contained the whole fingerprint. 1. I've never really understood why the full fingerprint *wasn't* used for this sort of thing. The key ID probably ought to be kept as much as possible as a human-only convenience. Is there no way to imagine the standard changing? (I guess this would need a new key format version, and possibly a new signature format?) 2. At least internally, could gpg get round the problem by indexing keys by fingerprint, and by checking the validity of the signature as well as just the key-id in the case of possible ambiguities (or at least spotting the ambiguity and printing a warning?) 3. I know this is a particular problem with version 3 key ids. How much stronger are version 4? Best wishes, Nicholas From dshaw at jabberwocky.com Sun Jun 24 15:08:45 2012 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 24 Jun 2012 09:08:45 -0400 Subject: v3 subkeys and signatures In-Reply-To: <4FE6A152.8040004@fifthhorseman.net> References: <20120614141029.GC2776@sivokote.iziade.m$> <8762asvl0j.fsf@vigenere.g10code.de> <20120615123056.GC2438@sivokote.iziade.m$> <4FE3ED3B.8070303@fifthhorseman.net> <87y5nfk8z8.fsf_-_@vigenere.g10code.de> <3AB48664-618B-4C95-A540-2A9E9751397B@JABBERWOCKY.COM> <20120623064902.GA2552@sivokote.iziade.m$> <7AE01490-9640-4C46-BD60-014B5901963E@jabberwocky.com> <20120623135903.GC2552@sivokote.iziade.m$> <38864BA7-CD0A-47EE-80E9-20AAAA93A600@jabberwocky.com> <4FE6A152.8040004@fifthhorseman.net> Message-ID: <9D851B00-F210-4941-8E18-E6A194054599@jabberwocky.com> On Jun 24, 2012, at 1:10 AM, Daniel Kahn Gillmor wrote: > On 06/23/2012 04:41 PM, David Shaw wrote: >> Yes, this makes sense. GPG won't generate a subkey on a V3 key (or a V3 subkey at all), but might accept them if generated elsewhere. So you had to patch things to make the key, but no patch is needed to use the key. > > Of course, the opportunity for compromise comes when a victim *uses* of > the key, not from its creation. So while i appreciate the refusal of > GPG to generate these keys (which means one less tool available to an > attacker for the creation of the colliding key), it doesn't really > address the fact that users of GPG are at risk if they deal with keys > generated elsewhere. I don't think anyone is arguing that it does. Georgi and I were just discussing why he was able to get the results he did, using a hacked GPG to create keys and an unpacked one to use them. Werner suggested one real fix at the top of this thread - ignore all v3 keys by default. Alternately, there are checks that can be done when there are multiple possible matching keys. The latter fix also addresses a possible v4-v4 collision, which is a nice benefit, but is a more invasive change. Either way, a fix is being discussed. David From dkg at fifthhorseman.net Sun Jun 24 22:00:21 2012 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 24 Jun 2012 16:00:21 -0400 Subject: Using second keyring may be misleading? In-Reply-To: References: <20120614141029.GC2776@sivokote.iziade.m$> <8762asvl0j.fsf@vigenere.g10code.de> <20120615123056.GC2438@sivokote.iziade.m$> <4FE3ED3B.8070303@fifthhorseman.net> <20120622144046.GF2777@sivokote.iziade.m$> <6D30623D-191E-4163-8120-CAEAF4867D70@jabberwocky.com> <20120622161242.GG2777@sivokote.iziade.m$> <9FB524C6-E9BF-43D7-94E5-E4FA9180ABDF@jabberwocky.com> Message-ID: <4FE771D5.7000606@fifthhorseman.net> On 06/24/2012 03:42 AM, Nicholas Cole wrote: >>>> >>> >>> So it still confuses implementations? :) >> >> Alas :) >> >> Unfortunately, it's pretty inherent in the design. The issuer subpacket that contains the key ID for a signature only has the 64-bit key ID. We'd need a new issuer subpacket that contained the whole fingerprint. > > 1. I've never really understood why the full fingerprint *wasn't* > used for this sort of thing. The key ID probably ought to be kept as > much as possible as a human-only convenience. Is there no way to > imagine the standard changing? (I guess this would need a new key > format version, and possibly a new signature format?) There was a discussion about how this could be accomplished on the IETF's OpenPGP WG list about this, starting here: http://www.imc.org/ietf-openpgp/mail-archive/msg09915.html One interesting outcome was the proposal (which i have failed to implement) of using an OpenPGP "notation" subpacket with a well-defined name, and a value of the full fingerprint of the issuer. Compatible signing applications could insert this subpacket in addition to the "issuer" subpacket, and compatible verifying applications could use it to disambiguate between colliding keyids. --dkg [0] https://tools.ietf.org/html/rfc4880#section-5.2.3.16 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: From gniibe at fsij.org Mon Jun 25 03:13:43 2012 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 25 Jun 2012 10:13:43 +0900 Subject: scd-backport-2-0 branch In-Reply-To: <877guzlpnd.fsf@vigenere.g10code.de> References: <1340333380.2119.1.camel@latx1.gniibe.org> <877guzlpnd.fsf@vigenere.g10code.de> Message-ID: <1340586823.2074.7.camel@latx1.gniibe.org> On 2012-06-22 at 10:25 +0200, Werner Koch wrote: > On Fri, 22 Jun 2012 04:49, gniibe at fsij.org said: > > > I backported SCD (scdaemon) related changes to scd-backport-2-0 > > branch. If it doesn't have any problem, I'd like to merge it into > > STABLE-BRANCH-2-0. > > I am fine with this. Shall I prepare a release candidate then? I added one more change of following (I will add this change to master branch too). Then, rebase and merge scd-backport-2-0 branch into STABLE-BRANCH-2-0. I think that changes fix problems, and has no regression. But, I still have a concern about how scdaemon should run. I am writing about this in the next mail. commit 34b78c7d82f3923052e36d405ba403787ae9df16 Author: NIIBE Yutaka Date: Sun Jun 24 10:45:49 2012 +0900 scd: handle reader/token removal. * scd/apdu.c (pcsc_error_to_sw): PCSC_E_UNKNOWN_READER means SW_HOST_NO_READER. diff --git a/scd/apdu.c b/scd/apdu.c index a343307..0ce1c51 100644 --- a/scd/apdu.c +++ b/scd/apdu.c @@ -841,6 +841,7 @@ pcsc_error_to_sw (long ec) case PCSC_E_CANCELLED: rc = SW_HOST_ABORTED; break; case PCSC_E_NO_MEMORY: rc = SW_HOST_OUT_OF_CORE; break; case PCSC_E_TIMEOUT: rc = SW_HOST_CARD_IO_ERROR; break; + case PCSC_E_UNKNOWN_READER: rc = SW_HOST_NO_READER; break; case PCSC_E_SHARING_VIOLATION: rc = SW_HOST_LOCKING_FAILED; break; case PCSC_E_NO_SMARTCARD: rc = SW_HOST_NO_CARD; break; case PCSC_W_REMOVED_CARD: rc = SW_HOST_NO_CARD; break; From gniibe at fsij.org Mon Jun 25 03:30:08 2012 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 25 Jun 2012 10:30:08 +0900 Subject: scd-backport-2-0 branch In-Reply-To: <87395nlpaz.fsf@vigenere.g10code.de> References: <1340333380.2119.1.camel@latx1.gniibe.org> <1340335144.2119.3.camel@latx1.gniibe.org> <87395nlpaz.fsf@vigenere.g10code.de> Message-ID: <1340587808.2074.8.camel@latx1.gniibe.org> Thanks for your explanation about scdaemon. I understand the background. Let me explain my concern. There is a use case for Gnuk Token like this: (1) Use the token for OpenSSH authentication through gpg-agent as ssh-agent (2) User inserts the token before login (3) ... and remove the token after authentication Currently, scdaemon keeps watching (and open and get status). In the use case above, a user doesn't expect scdaemon keeps watching for insertion. My concern is that this results shorter battery power life for laptop. For the use case above, a patch like following makes sense. The scdaemon doesn't need to open by itself. Once it will be open by another foreground thread, it will get status, and keep watching to detect removal. diff --git a/scd/command.c b/scd/command.c index 227057e..a4b3c08 100644 --- a/scd/command.c +++ b/scd/command.c @@ -2200,11 +2200,6 @@ update_reader_status_file (int set_card_removed_flag) int idx; unsigned int status, changed; - /* Make sure that the reader has been opened. Like get_reader_slot, - this part of the code assumes that there is only one reader. */ - if (!slot_table[0].valid) - (void)get_reader_slot (); - /* Note, that we only try to get the status, because it does not make sense to wait here for a operation to complete. If we are busy working with a card, delays in the status file update should From guninski at guninski.com Mon Jun 25 07:22:18 2012 From: guninski at guninski.com (Georgi Guninski) Date: Mon, 25 Jun 2012 08:22:18 +0300 Subject: The two V3 attacks In-Reply-To: <42651FC3-F3DF-49D6-9616-191FEE311C42@jabberwocky.com> References: <42651FC3-F3DF-49D6-9616-191FEE311C42@jabberwocky.com> Message-ID: <20120625052218.GA2370@sivokote.iziade.m$> On Fri, Jun 22, 2012 at 02:08:13PM -0400, David Shaw wrote: > > So neither of these are terribly new attacks (both dating from the 1990s). I had a brainstorm last year about using a DEADBEEF V3 key to collide with a V4 key, as the only way to tell which key was required (for verifying a signature, for example) was via the 64-bit key ID and inside the signature, there was no way to tell if it was a V3 or V4 key making the signature. That may have been the first mention of that particular variant - I don't know. There was some discussion about this on the IETF WG list at the time, but it's really an implementation issue (by the spec, implementations are not required to accept V3 keys if they don't want to). > If they are not new why they are not fixed yet? From wk at gnupg.org Mon Jun 25 09:08:58 2012 From: wk at gnupg.org (Werner Koch) Date: Mon, 25 Jun 2012 09:08:58 +0200 Subject: The two V3 attacks In-Reply-To: <20120625052218.GA2370@sivokote.iziade.m$> (Georgi Guninski's message of "Mon, 25 Jun 2012 08:22:18 +0300") References: <42651FC3-F3DF-49D6-9616-191FEE311C42@jabberwocky.com> <20120625052218.GA2370@sivokote.iziade.m$> Message-ID: <87ipefj2b9.fsf@vigenere.g10code.de> On Mon, 25 Jun 2012 07:22, guninski at guninski.com said: > If they are not new why they are not fixed yet? There was no rough consensus to drop v3 packets. Meanwhile there is no WG anymore because the IETF decided that OpenPGP has been done. The outcome of a v5 key format discussion was to wait for SHA-3 and then to start the discussion again. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Jun 25 09:06:19 2012 From: wk at gnupg.org (Werner Koch) Date: Mon, 25 Jun 2012 09:06:19 +0200 Subject: Using second keyring may be misleading? In-Reply-To: <4FE771D5.7000606@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Sun, 24 Jun 2012 16:00:21 -0400") References: <20120614141029.GC2776@sivokote.iziade.m$> <8762asvl0j.fsf@vigenere.g10code.de> <20120615123056.GC2438@sivokote.iziade.m$> <4FE3ED3B.8070303@fifthhorseman.net> <20120622144046.GF2777@sivokote.iziade.m$> <6D30623D-191E-4163-8120-CAEAF4867D70@jabberwocky.com> <20120622161242.GG2777@sivokote.iziade.m$> <9FB524C6-E9BF-43D7-94E5-E4FA9180ABDF@jabberwocky.com> <4FE771D5.7000606@fifthhorseman.net> Message-ID: <87mx3rj2fo.fsf@vigenere.g10code.de> On Sun, 24 Jun 2012 22:00, dkg at fifthhorseman.net said: > One interesting outcome was the proposal (which i have failed to > implement) of using an OpenPGP "notation" subpacket with a well-defined Time to read that discussion again. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From guninski at guninski.com Mon Jun 25 09:32:41 2012 From: guninski at guninski.com (Georgi Guninski) Date: Mon, 25 Jun 2012 10:32:41 +0300 Subject: The two V3 attacks In-Reply-To: <87ipefj2b9.fsf@vigenere.g10code.de> References: <42651FC3-F3DF-49D6-9616-191FEE311C42@jabberwocky.com> <20120625052218.GA2370@sivokote.iziade.m$> <87ipefj2b9.fsf@vigenere.g10code.de> Message-ID: <20120625073241.GB2370@sivokote.iziade.m$> On Mon, Jun 25, 2012 at 09:08:58AM +0200, Werner Koch wrote: > On Mon, 25 Jun 2012 07:22, guninski at guninski.com said: > > > If they are not new why they are not fixed yet? > > There was no rough consensus to drop v3 packets. Meanwhile there is no > WG anymore because the IETF decided that OpenPGP has been done. > > The outcome of a v5 key format discussion was to wait for SHA-3 and then > to start the discussion again. > > You *knowingly* distribute vulnerable warez for a long time? From rjh at sixdemonbag.org Mon Jun 25 10:52:08 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 25 Jun 2012 04:52:08 -0400 Subject: The two V3 attacks In-Reply-To: <20120625073241.GB2370@sivokote.iziade.m$> References: <42651FC3-F3DF-49D6-9616-191FEE311C42@jabberwocky.com> <20120625052218.GA2370@sivokote.iziade.m$> <87ipefj2b9.fsf@vigenere.g10code.de> <20120625073241.GB2370@sivokote.iziade.m$> Message-ID: <4FE826B8.5000700@sixdemonbag.org> On 06/25/2012 03:32 AM, Georgi Guninski wrote: > You *knowingly* distribute vulnerable warez for a long time? Listen, I'm about as strident of a "PGP 2.6 and V3 must both die" voice as they come. If I were any stronger on the subject I'd be ending each email with the sigline "MD5, PGP 2.6 et V3 delenda est!" [1] But even then, I think this statement is way overdone. PGP 2.6 support, MD5 in general, and V3 keys are all inferior technologies that should have been replaced a long time ago. However, there's still a need to read existing files that predate these attacks and there's still a need to provide a migration path from the known-vulnerable to the believed-good. Any system that provides both migration tools and read support for PGP 2.6 is going to fall under your definition of "vulnerable warez." Me, I call it providing a migration path and support for interoperating with legacy systems, while loudly begging, pleading, cajoling and pathetically whining in the hopes that people will stop using these old systems. [1] http://en.wikipedia.org/wiki/Carthago_delenda_est -- Robert J. Hansen MD5, PGP 2.6 et V3 delenda est! From wk at gnupg.org Mon Jun 25 11:17:45 2012 From: wk at gnupg.org (Werner Koch) Date: Mon, 25 Jun 2012 11:17:45 +0200 Subject: The two V3 attacks In-Reply-To: <20120625073241.GB2370@sivokote.iziade.m$> (Georgi Guninski's message of "Mon, 25 Jun 2012 10:32:41 +0300") References: <42651FC3-F3DF-49D6-9616-191FEE311C42@jabberwocky.com> <20120625052218.GA2370@sivokote.iziade.m$> <87ipefj2b9.fsf@vigenere.g10code.de> <20120625073241.GB2370@sivokote.iziade.m$> Message-ID: <87zk7rhhs6.fsf@vigenere.g10code.de> On Mon, 25 Jun 2012 09:32, guninski at guninski.com said: > You *knowingly* distribute vulnerable warez for a long time? Do you mean the v5 format or the use of MD5 (ie. PGP2 compatible v3 keys). The v5 format will allow to migrate form a SHA-1 fingerprint to a SHA-{2,3} fingerprint. It will take many years but there is likely enough time left. We currently don't expect to see a SHA-1 second second pre-image any time soon. Collision attacks on the fingerprint might have some bad consequences but the they won't lower the security of the signatures. New keys use SHA-2 for signatures - this is in contrast to PGP2 which uses MD5 for everything. Waiting for the outcome of the SHA-3 competition is just the Right Thing to do given that there are no SHA-1 attacks on the horizon. Regarding the v3 format: Well, I'd love to drop it and actually we now agreed to implement that as the default - along with an option to revert this default. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Jun 25 11:32:52 2012 From: wk at gnupg.org (Werner Koch) Date: Mon, 25 Jun 2012 11:32:52 +0200 Subject: scd-backport-2-0 branch In-Reply-To: <1340587808.2074.8.camel@latx1.gniibe.org> (NIIBE Yutaka's message of "Mon, 25 Jun 2012 10:30:08 +0900") References: <1340333380.2119.1.camel@latx1.gniibe.org> <1340335144.2119.3.camel@latx1.gniibe.org> <87395nlpaz.fsf@vigenere.g10code.de> <1340587808.2074.8.camel@latx1.gniibe.org> Message-ID: <87pq8nhh2z.fsf@vigenere.g10code.de> On Mon, 25 Jun 2012 03:30, gniibe at fsij.org said: > Currently, scdaemon keeps watching (and open and get status). In the > use case above, a user doesn't expect scdaemon keeps watching for > insertion. My concern is that this results shorter battery power life > for laptop. You mean, we should replace polling by a proper method to do so. IIRC, it was not possible to do this with libusb or pcscd back when I wrote it. On Linux we might find a way to sleep on reader changes; in general I prefer portable solutions, though. > For the use case above, a patch like following makes sense. The > scdaemon doesn't need to open by itself. Once it will be open by > another foreground thread, it will get status, and keep watching to What foreground thread do you have in mind? A new one sleeping on USB events? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nicholas.cole at gmail.com Mon Jun 25 10:19:14 2012 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Mon, 25 Jun 2012 09:19:14 +0100 Subject: The two V3 attacks In-Reply-To: <87ipefj2b9.fsf@vigenere.g10code.de> References: <42651FC3-F3DF-49D6-9616-191FEE311C42@jabberwocky.com> <20120625052218.GA2370@sivokote.iziade.m$> <87ipefj2b9.fsf@vigenere.g10code.de> Message-ID: On Mon, Jun 25, 2012 at 8:08 AM, Werner Koch wrote: > On Mon, 25 Jun 2012 07:22, guninski at guninski.com said: > >> If they are not new why they are not fixed yet? > > There was no rough consensus to drop v3 packets. ?Meanwhile there is no > WG anymore because the IETF decided that OpenPGP has been done. > > The outcome of a v5 key format discussion was to wait for SHA-3 and then > to start the discussion again. Fortunately, that may be as early as the end of this year: http://csrc.nist.gov/groups/ST/hash/timeline.html As an aside: one of the problems of any key system is that the security advantages of changing keys often (and using new formats) have to be weighed against the inconvenience of distribution and re-certification. Best wishes, N. From wk at gnupg.org Mon Jun 25 16:31:55 2012 From: wk at gnupg.org (Werner Koch) Date: Mon, 25 Jun 2012 16:31:55 +0200 Subject: The two V3 attacks In-Reply-To: <87zk7rhhs6.fsf@vigenere.g10code.de> (Werner Koch's message of "Mon, 25 Jun 2012 11:17:45 +0200") References: <42651FC3-F3DF-49D6-9616-191FEE311C42@jabberwocky.com> <20120625052218.GA2370@sivokote.iziade.m$> <87ipefj2b9.fsf@vigenere.g10code.de> <20120625073241.GB2370@sivokote.iziade.m$> <87zk7rhhs6.fsf@vigenere.g10code.de> Message-ID: <874npzh38k.fsf@vigenere.g10code.de> On Mon, 25 Jun 2012 11:17, wk at gnupg.org said: > Regarding the v3 format: Well, I'd love to drop it and actually we now > agreed to implement that as the default - along with an option to revert > this default. There is now a new branch "disallow-v3-keys" which implements the v3 removal for 2.1. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Tue Jun 26 03:17:16 2012 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 26 Jun 2012 10:17:16 +0900 Subject: scd-backport-2-0 branch In-Reply-To: <87pq8nhh2z.fsf@vigenere.g10code.de> References: <1340333380.2119.1.camel@latx1.gniibe.org> <1340335144.2119.3.camel@latx1.gniibe.org> <87395nlpaz.fsf@vigenere.g10code.de> <1340587808.2074.8.camel@latx1.gniibe.org> <87pq8nhh2z.fsf@vigenere.g10code.de> Message-ID: <1340673436.1908.2.camel@latx1.gniibe.org> On 2012-06-25 at 11:32 +0200, Werner Koch wrote: > On Mon, 25 Jun 2012 03:30, gniibe at fsij.org said: > > > Currently, scdaemon keeps watching (and open and get status). In the > > use case above, a user doesn't expect scdaemon keeps watching for > > insertion. My concern is that this results shorter battery power life > > for laptop. > > You mean, we should replace polling by a proper method to do so. There are two things: (1) Polling for "get status" for existing token and (2) Polling for detecting insertion of token. Let me talk about latter, at first. My question here is: Is polling for detecting insertion needed? The patch I sent yesterday is to show this issue (for token insertion. The patch is not yet complete to handle card insertion, though). Open new connection will be done only by the thread of scd_command_handler -> assuan_process (which I said "foreground"). After that, polling will be done with "get status" for new connection. With no polling of detecting insertion, status file will not be updated immediately, script won't be executed immediately. It will only updated and executed after user will do some action to use token. But, it seems for me that it's OK. > > For the use case above, a patch like following makes sense. The > > scdaemon doesn't need to open by itself. Once it will be open by > > another foreground thread, it will get status, and keep watching to > > What foreground thread do you have in mind? A new one sleeping on > USB events? In the previous mail, I talked about to stop polling for detecting insertion, and "foreground thread" meant the one of scd_command_handler, which accepts request from gpg-agent. Let's talk about (1) Polling for "get status". > IIRC, it was not possible to do this with libusb or pcscd back when > I wrote it. On Linux we might find a way to sleep on reader > changes; in general I prefer portable solutions, though. There is no good general way other than polling to get status of reader/token. But, if CCID reader/token supports interrupt transfer for status, it is possible to use this for it, instead of polling. Now, newer libusb (libusbx.org) has support for event driven asynchronous model, it is possible to use single interrupt transfer URB. I think that it is portable, provided newer libusb is good enough for portability. When CCID reader/token with interrupt transfer will be common, it will be good to support this way, in future. BTW, Gnuk does not (yet) support interrupt transfer. -- From mca_debu at yahoo.co.in Wed Jun 27 03:41:03 2012 From: mca_debu at yahoo.co.in (Debabrata Das) Date: Wed, 27 Jun 2012 09:41:03 +0800 (SGT) Subject: No subject Message-ID: <1340761263.64145.YahooMailNeo@web192503.mail.sg3.yahoo.com> http://pintatuvida.com/xxklfd.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcus.brinkmann at ruhr-uni-bochum.de Thu Jun 28 11:32:54 2012 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 28 Jun 2012 11:32:54 +0200 Subject: leave of absence for werner Message-ID: <4FEC24C6.8050105@ruhr-uni-bochum.de> Hi, werner asked me to let you know that he is on leave for compassionate grounds at the moment and thus can't take part in the current ongoing discussions. If you are currently waiting for his response, please accept his apologies for dropping out of the discussion like that for a while. Thanks, Marcus