From orangeprince at hushmail.com Mon Feb 2 14:57:06 2015 From: orangeprince at hushmail.com (orangeprince at hushmail.com) Date: Mon, 02 Feb 2015 13:57:06 +0000 Subject: Access denied: ftp.gnupg.org In-Reply-To: Message-ID: <20150202135706.E4FE4400AF@smtp.hushmail.com> Hello, Anybody know what's up with this? $ wget ftp://ftp.gnupg.org/gcrypt/libgpg-error/libgpg-error-1.17.tar.bz2 --2015-02-02 14:53:54-- ftp://ftp.gnupg.org/gcrypt/libgpg-error/libgpg-error-1.17.tar.bz2 (try: 4) => `libgpg-error-1.17.tar.bz2' ==> CWD not required. ==> SIZE libgpg-error-1.17.tar.bz2 ... 669914 ==> PASV ... done. ==> RETR libgpg-error-1.17.tar.bz2 ... done. Length: 669914 (654K) (unauthoritative) 0% [ ] 0 --.-K/s in 0s 2015-02-02 14:53:54 (0.00 B/s) - Data transfer aborted. Retrying. Getting the same for all the other files as well. Thanks! OP From kristian.fiskerstrand at sumptuouscapital.com Mon Feb 2 18:32:22 2015 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Mon, 02 Feb 2015 18:32:22 +0100 Subject: Access denied: ftp.gnupg.org In-Reply-To: <20150202135706.E4FE4400AF@smtp.hushmail.com> References: <20150202135706.E4FE4400AF@smtp.hushmail.com> Message-ID: <54CFB4A6.4030405@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 02/02/2015 02:57 PM, orangeprince at hushmail.com wrote: > Hello, > > Anybody know what's up with this? Not sure about your issue specifically, but please note that you can find the necessary files on the mirrors listed on [0] References: [0] https://gnupg.org/download/mirrors.html - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- Qui audet vincit Who dares wins -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJUz7SiAAoJEP7VAChXwav6DhsH/RET02xlvrBm/+bkLttCyapg 7eb7P/L7s4VAZxDczvy+eRen6m8UiWfORgdc69DbW8k4hyW+fGPw085Ldo13FY1k zCkHi98/JfoHauDVt4Z70FS7PIhg6Q5Yy8lxZ8/wRkZTImDk7Q/n7HPZ8eg3WULD l+7xp25WzLmCIBMU8dWVVqA9KSQXvfVPPBcOVezFMquMvTtbUb0AAZD8NPhPbHVX iBeuT91uaKiAsHCg0wIt24Tz5qcnyq9FbuJWWqRj+FESUH/LOKxVlCYYe0jeWK+p FAggMNFLgKmvc3xLEMiV1MmAKT3iL2RBxPoBleT+UktLG158jk5Jnx5vV+Tu/jw= =GP2g -----END PGP SIGNATURE----- From ciprian.craciun at gmail.com Mon Feb 2 21:49:22 2015 From: ciprian.craciun at gmail.com (Ciprian Dorin Craciun) Date: Mon, 2 Feb 2015 22:49:22 +0200 Subject: Prioritizing secret keys when deciphering Message-ID: I encounter a very anoing issue... If a certain "packet" is encrypted to multiple private keys, and I happen to have two (or multiple) of them in my secret keychain, then when decrypting, although GPG always tries them in the same order, the order is not the one I would prefer... Thus, is it possible to tell GPG in which order to try the secret keys in case it finds multiple of them that are in the secret key ring? Thanks, Ciprian. P.S.: Why do I have two secret keys that I own in the same "packet"? Because one of the keys is the one put by the default `encrypt-to` option, and the other one is a shared private key used by me and my colleagues. From orangeprince at hushmail.com Tue Feb 3 14:02:57 2015 From: orangeprince at hushmail.com (orangeprince at hushmail.com) Date: Tue, 03 Feb 2015 13:02:57 +0000 Subject: Problem linking libgcrypt to libgpg-error In-Reply-To: <87d25sgw51.fsf@alice.fifthhorseman.net> References: <20150123080629.96D85A00E6@smtp.hushmail.com> <010101d036fe$f3e998f0$dbbccad0$@com> <20150123131502.18D90A00E6@smtp.hushmail.com> <011401d03710$98f8c8f0$caea5ad0$@com> <20150127130354.B356CE03D7@smtp.hushmail.com> <004a01d03a3f$c57f7680$507e6380$@com> <20150127145314.94699E03D7@smtp.hushmail.com> <005101d03a41$ad4993f0$07dcbbd0$@com> <20150127152942.A2608E03D8@smtp.hushmail.com> <005a01d03a49$31074cd0$9315e670$@com> <20150129210427.AF5ACC0392@smtp.hushmail.com> <000001d03c27$76069b80$6213d280$@com> <20150130142357.5EC7DC0392@smtp.hushmail.com> <006401d03cd5$a455ee60$ed01cb20$@com> <20150131130210.26EC4400AF@smtp.hushmail.com> <002701d03d56$ee15eb00$ca41c100$@com> <20150202013255.52F134037E@smtp.hushmail.com> <00c401d03e93$89086dd0$9b194970$@com> <20150202123220.19934200CD@smtp.hushmail.com> <87d25sgw51.fsf@alice.fifthhorseman.net> Message-ID: <20150203130258.35630A0112@smtp.hushmail.com> Hi! Can anybody tell what went wrong here? % cd libgpg-error-1.18 % ./configure --prefix="/home/orangeprince/libgpg-error" % make % make install % ls /home/orangeprince/libgpg-error bin include lib share Success. But now: % cd libgcrypt-1.6.2 % ./configure --with-libgpg-error-prefix="/home/orangeprince/libgpg-error" ... checking for gpg-error-config... /usr/bin/gpg-error-config checking for GPG Error - version >= 1.11... no configure: error: libgpg-error is needed. See ftp://ftp.gnupg.org/gcrypt/libgpg-error/ Many thanks! OP From wk at gnupg.org Tue Feb 3 15:07:52 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 03 Feb 2015 15:07:52 +0100 Subject: Problem linking libgcrypt to libgpg-error In-Reply-To: <20150203130258.35630A0112@smtp.hushmail.com> (orangeprince@hushmail.com's message of "Tue, 03 Feb 2015 13:02:57 +0000") References: <20150123080629.96D85A00E6@smtp.hushmail.com> <010101d036fe$f3e998f0$dbbccad0$@com> <20150123131502.18D90A00E6@smtp.hushmail.com> <011401d03710$98f8c8f0$caea5ad0$@com> <20150127130354.B356CE03D7@smtp.hushmail.com> <004a01d03a3f$c57f7680$507e6380$@com> <20150127145314.94699E03D7@smtp.hushmail.com> <005101d03a41$ad4993f0$07dcbbd0$@com> <20150127152942.A2608E03D8@smtp.hushmail.com> <005a01d03a49$31074cd0$9315e670$@com> <20150129210427.AF5ACC0392@smtp.hushmail.com> <000001d03c27$76069b80$6213d280$@com> <20150130142357.5EC7DC0392@smtp.hushmail.com> <006401d03cd5$a455ee60$ed01cb20$@com> <20150131130210.26EC4400AF@smtp.hushmail.com> <002701d03d56$ee15eb00$ca41c100$@com> <20150202013255.52F134037E@smtp.hushmail.com> <00c401d03e93$89086dd0$9b194970$@com> <20150202123220.19934200CD@smtp.hushmail.com> <87d25sgw51.fsf@alice.fifthhorseman.net> <20150203130258.35630A0112@smtp.hushmail.com> Message-ID: <877fvznl53.fsf@vigenere.g10code.de> On Tue, 3 Feb 2015 14:02, orangeprince at hushmail.com said: > % cd libgcrypt-1.6.2 > % ./configure --with-libgpg-error-prefix="/home/orangeprince/libgpg-error" Try ./configure --with-gpg-error-prefix="/home/orangeprince/libgpg-error" Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Feb 3 20:43:22 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 03 Feb 2015 20:43:22 +0100 Subject: Talking about Cryptodevices... which one? In-Reply-To: <54C51A4A.8060403@mirix.org> (Matthias-Christian Ott's message of "Sun, 25 Jan 2015 16:31:06 +0000") References: <54C1BF3A.2040903@gmail.com> <87iofxck7h.fsf@vigenere.g10code.de> <54C2D3AD.9080608@mirix.org> <54C3CEEB.7030406@cardcontact.de> <54C51A4A.8060403@mirix.org> Message-ID: <87y4oen5lx.fsf@vigenere.g10code.de> On Sun, 25 Jan 2015 17:31, ott at mirix.org said: > I don't think that such discussion belongs on this mailing list but I I think such a discussion is important and belongs here. I see no reason to discuss the need for 8k or even 4k keys if we neglect to discuss hardware or malware based attacks. In fact the immediate need for very large keys is mostly an academic exercise while the latter are real threats. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Feb 3 20:46:28 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 03 Feb 2015 20:46:28 +0100 Subject: Talking about Cryptodevices... which one? In-Reply-To: <54C563BB.7060200@digitalbrains.com> (Peter Lebbing's message of "Sun, 25 Jan 2015 22:44:27 +0100") References: <54C1BF3A.2040903@gmail.com> <87iofxck7h.fsf@vigenere.g10code.de> <8F0B09FC6339FA439524099BFCABC11F2D3AA7F9@IRVEXCHMB11.corp.ad.broadcom.com> <54C563BB.7060200@digitalbrains.com> Message-ID: <87twz2n5gr.fsf@vigenere.g10code.de> On Sun, 25 Jan 2015 22:44, peter at digitalbrains.com said: > sure of the latter type number). I forgot what that reader Werner > uses is called. SCT3512 (http://werner.eifzilla.de/sct3512.jpg) for carrying around and an SCR3310 full size reader glued below the monitor. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From michard.antoine at gmail.com Tue Feb 3 20:54:01 2015 From: michard.antoine at gmail.com (Antoine Michard) Date: Tue, 3 Feb 2015 20:54:01 +0100 Subject: Talking about Cryptodevices... which one? In-Reply-To: <87twz2n5gr.fsf@vigenere.g10code.de> References: <54C1BF3A.2040903@gmail.com> <87iofxck7h.fsf@vigenere.g10code.de> <8F0B09FC6339FA439524099BFCABC11F2D3AA7F9@IRVEXCHMB11.corp.ad.broadcom.com> <54C563BB.7060200@digitalbrains.com> <87twz2n5gr.fsf@vigenere.g10code.de> Message-ID: I've heard about NitroKey with his crowfounding is in 2-4 weeks. https://www.nitrokey.com/ What do you think about it? Envoy? de mon Nexus 5 Le 3 f?vr. 2015 20:51, "Werner Koch" a ?crit : > On Sun, 25 Jan 2015 22:44, peter at digitalbrains.com said: > > > sure of the latter type number). I forgot what that reader Werner > > uses is called. > > SCT3512 (http://werner.eifzilla.de/sct3512.jpg) for carrying around and > an SCR3310 full size reader glued below the monitor. > > > Shalom-Salam, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From orangeprince at hushmail.com Tue Feb 3 23:01:07 2015 From: orangeprince at hushmail.com (orangeprince at hushmail.com) Date: Tue, 03 Feb 2015 22:01:07 +0000 Subject: Problem linking libgcrypt to libgpg-error In-Reply-To: <877fvznl53.fsf@vigenere.g10code.de> References: <20150123080629.96D85A00E6@smtp.hushmail.com> <010101d036fe$f3e998f0$dbbccad0$@com> <20150123131502.18D90A00E6@smtp.hushmail.com> <011401d03710$98f8c8f0$caea5ad0$@com> <20150127130354.B356CE03D7@smtp.hushmail.com> <004a01d03a3f$c57f7680$507e6380$@com> <20150127145314.94699E03D7@smtp.hushmail.com> <005101d03a41$ad4993f0$07dcbbd0$@com> <20150127152942.A2608E03D8@smtp.hushmail.com> <005a01d03a49$31074cd0$9315e670$@com> <20150129210427.AF5ACC0392@smtp.hushmail.com> <000001d03c27$76069b80$6213d280$@com> <20150130142357.5EC7DC0392@smtp.hushmail.com> <006401d03cd5$a455ee60$ed01cb20$@com> <20150131130210.26EC4400AF@smtp.hushmail.com> <002701d03d56$ee15eb00$ca41c100$@com> <20150202013255.52F134037E@smtp.hushmail.com> <00c401d03e93$89086dd0$9b194970$@com> <20150202123220.19934200CD@smtp.hushmail.com> <87d25sgw51.fsf@alice.fifthhorseman.net> <20150203130258.35630A0112@smtp.hushmail.com> <877fvznl53.fsf@vigenere.g10code.de> Message-ID: <20150203220107.E116DE0397@smtp.hushmail.com> On 3. februar 2015 at 2:11 PM, "Werner Koch" wrote: > >Try > > ./configure --with-gpg-error-prefix="/home/orangeprince/libgpg- >error" Oh yes indeed! That did the trick - thanks man! How come it's not listed in `./configure --help` though? All the best, OP > > >Shalom-Salam, > > Werner > >-- >Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From georgeorwellhardwired at riseup.net Wed Feb 4 07:50:30 2015 From: georgeorwellhardwired at riseup.net (georgeorwellhardwired at riseup.net) Date: Wed, 04 Feb 2015 06:50:30 +0000 Subject: Anonymous payment for hardware tokens Message-ID: Hello. Is there anyone that knows where you can buy yubikeys or smartcards anonymously? From wk at gnupg.org Wed Feb 4 08:32:59 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 04 Feb 2015 08:32:59 +0100 Subject: Problem linking libgcrypt to libgpg-error In-Reply-To: <20150203220107.E116DE0397@smtp.hushmail.com> (orangeprince@hushmail.com's message of "Tue, 03 Feb 2015 22:01:07 +0000") References: <20150123080629.96D85A00E6@smtp.hushmail.com> <011401d03710$98f8c8f0$caea5ad0$@com> <20150127130354.B356CE03D7@smtp.hushmail.com> <004a01d03a3f$c57f7680$507e6380$@com> <20150127145314.94699E03D7@smtp.hushmail.com> <005101d03a41$ad4993f0$07dcbbd0$@com> <20150127152942.A2608E03D8@smtp.hushmail.com> <005a01d03a49$31074cd0$9315e670$@com> <20150129210427.AF5ACC0392@smtp.hushmail.com> <000001d03c27$76069b80$6213d280$@com> <20150130142357.5EC7DC0392@smtp.hushmail.com> <006401d03cd5$a455ee60$ed01cb20$@com> <20150131130210.26EC4400AF@smtp.hushmail.com> <002701d03d56$ee15eb00$ca41c100$@com> <20150202013255.52F134037E@smtp.hushmail.com> <00c401d03e93$89086dd0$9b194970$@com> <20150202123220.19934200CD@smtp.hushmail.com> <87d25sgw51.fsf@alice.fifthhorseman.net> <20150203130258.35630A0112@smtp.hushmail.com> <877fvznl53.fsf@vigenere.g10code.de> <20150203220107.E116DE0397@smtp.hushmail.com> Message-ID: <878ugem8r8.fsf@vigenere.g10code.de> On Tue, 3 Feb 2015 23:01, orangeprince at hushmail.com said: > How come it's not listed in `./configure --help` though? There was some hickup with the name of that option. With the latest versions (possible not yet released) both names should work. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From mirimir at riseup.net Wed Feb 4 08:40:22 2015 From: mirimir at riseup.net (Mirimir) Date: Wed, 04 Feb 2015 00:40:22 -0700 Subject: Anonymous payment for hardware tokens In-Reply-To: References: Message-ID: <54D1CCE6.9080501@riseup.net> On 02/03/2015 11:50 PM, georgeorwellhardwired at riseup.net wrote: > Hello. > > Is there anyone that knows where you can buy yubikeys or smartcards > anonymously? Doing anything "anonymously" in physical space is hard. You could buy with cash in a store, in a city where you are not known, and take precautions to reduce the risk of surveillance. Or you could pay someone to do that for you. But then they know about it :( You can buy online, but then there's the need for a shipping address. Obtaining an "anonymous" shipping addresses is nontrivial. There's the gambit of shipping to a randomly chosen address with an unsecured mailbox. With tracking information, you can know when the package will be delivered, and show up right after delivery. But that's iffy, and vulnerable to surveillance. For example, one can anonymously buy from Amazon. First buy some Bitcoins. Then anonymize them by transferring through mixing services, using Multibit wallets in Whonix instances. Then convert them to an Amazon giftcard, and order. From wk at gnupg.org Wed Feb 4 08:35:21 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 04 Feb 2015 08:35:21 +0100 Subject: Talking about Cryptodevices... which one? In-Reply-To: (Antoine Michard's message of "Tue, 3 Feb 2015 20:54:01 +0100") References: <54C1BF3A.2040903@gmail.com> <87iofxck7h.fsf@vigenere.g10code.de> <8F0B09FC6339FA439524099BFCABC11F2D3AA7F9@IRVEXCHMB11.corp.ad.broadcom.com> <54C563BB.7060200@digitalbrains.com> <87twz2n5gr.fsf@vigenere.g10code.de> Message-ID: <874mr2m8na.fsf@vigenere.g10code.de> On Tue, 3 Feb 2015 20:54, michard.antoine at gmail.com said: > I've heard about NitroKey with his crowfounding is in 2-4 weeks. > > https://www.nitrokey.com/ > > What do you think about it? I talked with the folks at 31C3 and it sounds fine to me. The cheaper version will be very simlar to gnuk. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Wed Feb 4 09:56:25 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 04 Feb 2015 17:56:25 +0900 Subject: Anonymous payment for hardware tokens In-Reply-To: References: Message-ID: <54D1DEB9.8090909@fsij.org> On 02/04/2015 03:50 PM, georgeorwellhardwired at riseup.net wrote: > Is there anyone that knows where you can buy yubikeys or smartcards > anonymously? I'm afraid it's not practical for you... You can buy Gnuk Token in Maebashi, Gunma, Japan by cash from me. Buy FST-01 with Gnuk 1.1.4 (in Japanese): http://www.gniibe.org/shop/gnuk_1_1_x-on-fst-01.html I can speak Japanese (native) and English, and I can read/write Chinese a little. Some people bought it in Tokyo by cash when I visited there. When I join some conference and it is allowed, I can sell it by cash. I am considering to join LibrePlanet 2015 and Debconf15, this year. In case it is difficult for you to trust the product, you can compile Gnuk 1.1.4 by yourself and install it to other supported hardware: Olimex STM32-H103, STBee, or STBee Mini. (Porting Gnuk to some board of STM32F103 is not that difficult, too.) In either cases, it is recommended to compile and install Gnuk to your board by yourself, as there is some risk where some malicious (possibly middle) person has installed fake firmware already. (I don't know some technology to prevent such an attack to MCU. It would be good if MCU has a built-in feature to show it's SHA256 hash somehow for its program so that user can check it.) When/if enough people can gather together, it would be great to have some hands-on workshop for building Gnuk Token (hardware-wise and compiling/installing the firmware) and/or one for using Gnuk Token. Once, we had an event in Tokyo for using Gnuk Token (a session of two hours) by FSIJ, and a handful people joined. -- From telegraph at gmx.net Wed Feb 4 10:30:01 2015 From: telegraph at gmx.net (Gregor Zattler) Date: Wed, 4 Feb 2015 10:30:01 +0100 Subject: Talking about Cryptodevices... which one? In-Reply-To: <87twz2n5gr.fsf@vigenere.g10code.de> References: <54C1BF3A.2040903@gmail.com> <87iofxck7h.fsf@vigenere.g10code.de> <8F0B09FC6339FA439524099BFCABC11F2D3AA7F9@IRVEXCHMB11.corp.ad.broadcom.com> <54C563BB.7060200@digitalbrains.com> <87twz2n5gr.fsf@vigenere.g10code.de> Message-ID: <20150204093001.GA24678@boo.workgroup> Hi Werner, * Werner Koch [03. Feb. 2015]: > On Sun, 25 Jan 2015 22:44, peter at digitalbrains.com said: >> sure of the latter type number). I forgot what that reader Werner >> uses is called. > > SCT3512 (http://werner.eifzilla.de/sct3512.jpg) for carrying around and > an SCR3310 full size reader glued below the monitor. Do you know of a still available mobile card reader with pinpad which works with OpenPGP Card and gnupg under linux? Ciao, Gregor -- -... --- .-. . -.. ..--.. ...-.- From brian at minton.name Wed Feb 4 12:59:05 2015 From: brian at minton.name (Brian Minton) Date: Wed, 04 Feb 2015 11:59:05 +0000 Subject: Anonymous payment for hardware tokens References: <54D1DEB9.8090909@fsij.org> Message-ID: Showing a hash wouldn't prevent a malicious entity from making a fake token that prints whatever hash the user expects. There's no way to verify that the hash is if code actually on the device, or that the hashed code is the only code on the device. The only way I could see to prevent it is to have the tokens encrypted be the manufacturer with a well known public key pair, but that does present key distribution problems (see for example, every DRM system). On Wed, Feb 4, 2015, 3:58 AM NIIBE Yutaka wrote: > On 02/04/2015 03:50 PM, georgeorwellhardwired at riseup.net wrote: > > Is there anyone that knows where you can buy yubikeys or smartcards > > anonymously? > > I'm afraid it's not practical for you... > > You can buy Gnuk Token in Maebashi, Gunma, Japan by cash from me. > > Buy FST-01 with Gnuk 1.1.4 (in Japanese): > http://www.gniibe.org/shop/gnuk_1_1_x-on-fst-01.html > > I can speak Japanese (native) and English, and I can read/write > Chinese a little. > > Some people bought it in Tokyo by cash when I visited there. > > When I join some conference and it is allowed, I can sell it by cash. > I am considering to join LibrePlanet 2015 and Debconf15, this year. > > In case it is difficult for you to trust the product, you can compile > Gnuk 1.1.4 by yourself and install it to other supported hardware: > Olimex STM32-H103, STBee, or STBee Mini. (Porting Gnuk to some board > of STM32F103 is not that difficult, too.) > > In either cases, it is recommended to compile and install Gnuk to your > board by yourself, as there is some risk where some malicious > (possibly middle) person has installed fake firmware already. (I > don't know some technology to prevent such an attack to MCU. It would > be good if MCU has a built-in feature to show it's SHA256 hash somehow > for its program so that user can check it.) > > When/if enough people can gather together, it would be great to have > some hands-on workshop for building Gnuk Token (hardware-wise and > compiling/installing the firmware) and/or one for using Gnuk Token. > Once, we had an event in Tokyo for using Gnuk Token (a session of two > hours) by FSIJ, and a handful people joined. > -- > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gniibe at fsij.org Wed Feb 4 13:56:57 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 04 Feb 2015 21:56:57 +0900 Subject: Anonymous payment for hardware tokens In-Reply-To: References: <54D1DEB9.8090909@fsij.org> Message-ID: <54D21719.3060408@fsij.org> On 02/04/2015 08:59 PM, Brian Minton wrote: > Showing a hash wouldn't prevent a malicious entity from making a > fake token that prints whatever hash the user expects. There's no > way to verify that the hash is if code actually on the device, or > that the hashed code is the only code on the device. Thank you for your insight. Yes, if "show"-ing is by its program, it could be also fake. I meant, something in a JTAG/SWD protocol layer (not by user program), built-in _hardware_ feature by semiconductor manufacturer to show hash of flash blocks. Scenario is like: (1) Firmware is written to flash ROM on MCU, by a firmware author. Possibly it's protected to be read. (2) It is possible for an end-user to send command to MCU by JTAG/SWD channel (even if flash ROM is protected). Like: show_hash (3) An end user can confirm that the hash is the correct one as the firmware author says. Does it make sense? Sorry, I should have written down clearly, in the previous mail. -- From peter at digitalbrains.com Wed Feb 4 14:34:29 2015 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 04 Feb 2015 14:34:29 +0100 Subject: Anonymous payment for hardware tokens In-Reply-To: <54D21719.3060408@fsij.org> References: <54D1DEB9.8090909@fsij.org> <54D21719.3060408@fsij.org> Message-ID: <54D21FE5.9030504@digitalbrains.com> On 04/02/15 13:56, NIIBE Yutaka wrote: > I meant, something in a JTAG/SWD protocol layer (not by user > program), built-in _hardware_ feature by semiconductor manufacturer to > show hash of flash blocks. But Gnuk is not secret, so the flash doesn't need to be read-protected. And if you need a JTAG programmer to read the hash, you might as well reflash the MCU to your known-good Gnuk. I'm trying to think of a way to have the actual hardware present a hash to a user who doesn't own a JTAG programmer, but it's tricky :). I thought of something like dedicated pins connected to a shift register (so you don't need 256 pins), where only the hardware can shift out the actual hash; using the pins from the firmware would be prevented. But then you need a display on your token. Having four 7-segment LED displays on your token that displays the hash in groups of 4 hex digits won't exactly make for a compact arrangement :). Perhaps it could use a serial format as used by the serial port on a PC (asynchronous start/stop). Then you could connect a USB-to-serial converter to the pins on the token and see what the MCU is reporting as its hash. All nicely academic musings, in the sense that I don't see an MCU with this feature coming to the market soon... Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From gniibe at fsij.org Wed Feb 4 16:07:42 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 05 Feb 2015 00:07:42 +0900 Subject: Anonymous payment for hardware tokens In-Reply-To: <54D21FE5.9030504@digitalbrains.com> References: <54D1DEB9.8090909@fsij.org> <54D21719.3060408@fsij.org> <54D21FE5.9030504@digitalbrains.com> Message-ID: <54D235BE.9010009@fsij.org> Thank you for your exact comment and discussion. On 2015-02-04 21:56 +0900, NIIBE Yutaka wrote: > I meant, something in a JTAG/SWD protocol layer (not by user > program), built-in _hardware_ feature by semiconductor manufacturer to > show hash of flash blocks. On 2015-02-04 14:34:29 +0100, Peter Lebbing wrote: > But Gnuk is not secret, so the flash doesn't need to be read-protected. True. For Gnuk, the code is not needed to be read-protected. The reason why Gnuk is used with flash read-protection is that: the granularity of flash protection of (cheaper versions of) STM32F103 is all or nothing, and we use the read-protection for private keys. In some sense, Gnuk users depend on the existence of (the practice of) non-free software. (This view matches our Buddhism view, by the way. :-) > And if you need a JTAG programmer to read the hash, you might as > well reflash the MCU to your known-good Gnuk. Yes, I'd rather do that for myself (with/without checking its hash). Besides, I'd like to promote everyone has programmer (possibly with free firmware). My point of built-in hardware feature is not particularly for Gnuk, but for general purpose. It's OK not everyone checks its hash for every product, but, it is important for an MCU to have this feature, so that the existence of this feature can lower the possibility of effective attacks. The fact "we can validate the product" itself makes sense, I guess. > All nicely academic musings, in the sense that I don't see an MCU with this > feature coming to the market soon... Thank you for your interesting examples. Morse code by piezo speaker would be good for me, if not patented. Well, I'm always wrong, but I believe that engineers in semiconductor industry is clever in general, and silicon real estate is getting cheaper to have some room for the feature. No, I don't bet, though. ;-) -- From ott at mirix.org Wed Feb 4 21:44:56 2015 From: ott at mirix.org (Matthias-Christian Ott) Date: Wed, 04 Feb 2015 21:44:56 +0100 Subject: Talking about Cryptodevices... which one? In-Reply-To: <87y4oen5lx.fsf@vigenere.g10code.de> References: <54C1BF3A.2040903@gmail.com> <87iofxck7h.fsf@vigenere.g10code.de> <54C2D3AD.9080608@mirix.org> <54C3CEEB.7030406@cardcontact.de> <54C51A4A.8060403@mirix.org> <87y4oen5lx.fsf@vigenere.g10code.de> Message-ID: <54D284C8.4060508@mirix.org> On 2015-02-03 20:43, Werner Koch wrote: > On Sun, 25 Jan 2015 17:31, ott at mirix.org said: > >> I don't think that such discussion belongs on this mailing list but I > > I think such a discussion is important and belongs here. I see no If I remember correctly, that statement refers to speculations about backdoors that were speculated to be implanted or exploited by intelligence agencies. You speculated that Rainer SCT might cooperate with the German intelligence agency BND. You gave the following reason for your suspicion: "microcontrollers are smaller and writing malware for them is harder". You know much better than me that just because a microcontroller is smaller it doesn't mean that it is hard to exploit it by uploading modified firmware. In fact the scenario you mentioned, saving the PIN, could probably be implemented with just a few hundred additional instructions. Moreover, Rainer SCT is not the only German vendor that has firmware that can be updated: SCM PC-Card also allows the firmware of its SPR532 card reader to be updated from the USB host. You construct the same story for SCM PC-Card and more broadly any other proprietary hardware or software. There are enough examples of vendors that introduced government backdoors in their proprietary products to come to the conclusion that it is probably not a good idea to use proprietary software or hardware if your threat model includes government backdoors and you want to defend against them (of course that doesn't mean that it is impossible to verify that a proprietary product does not contain a backdoor but it is unarguably a lot harder). So I don't know how speculating that a particular vendor of proprietary hardware and software implants backdoors in its products does move the discussion forward. > reason to discuss the need for 8k or even 4k keys if we neglect to > discuss hardware or malware based attacks. In fact the immediate need > for very large keys is mostly an academic exercise while the latter are > real threats. I mostly agree with you here and I think what has been revealed over the last years confirms your statement. But will a smartcard solve the problem that the host computer might be infected with malware? I don't think so but invite you to proof me wrong. I think that sandboxing mechanisms like SELinux, AppArmor, grsecurity, seccomp etc. would help more to not let the computer become infected in the first place. I would like to give the following example to prove/illustrate this: Suppose that your web browser has an exploitable security vulnerability, you visit a website that manages to execute code on your computer and that code wants to steal your OpenPGP key. If you would run SELinux and properly label the .gnupg folder in your home directory and your system's GnuPG binaries, you could have prevented this attack. Without SELinux but with a smartcard the exploit code could have controlled the smartcard even though it might not have the smartcard's PIN and the attacker would probably be able to do something with the key on the card next time you want to use it. Moreover, SELinux is just a piece of software that costs nothing and could be rolled out to millions of computers over night whereas the smartcard costs money and requires no additional knowledge (see for example Fedora's default SELinux policy), whereas equipping and educating millions of users with an OpenPGP smartcard and a reader is not trivial and inexpensive. There is probably a lot more to say and to consider about this whole topic and this topic is most likely also beyond the scope of GnuPG but I think one can look at the enterprise software market as a good example that shows why adding hardware to an existing insecure system is not really effective. At least as far as I know running software like IDS, DPI firewalls, transparent/intercepting proxies, anti-virus software and so on does not solve the problem of Microsoft Windows or application software running on Microsoft Windows being insecure. Regards, Matthias-Christian From peter at digitalbrains.com Wed Feb 4 23:07:18 2015 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 04 Feb 2015 23:07:18 +0100 Subject: Talking about Cryptodevices... which one? In-Reply-To: <54D284C8.4060508@mirix.org> References: <54C1BF3A.2040903@gmail.com> <87iofxck7h.fsf@vigenere.g10code.de> <54C2D3AD.9080608@mirix.org> <54C3CEEB.7030406@cardcontact.de> <54C51A4A.8060403@mirix.org> <87y4oen5lx.fsf@vigenere.g10code.de> <54D284C8.4060508@mirix.org> Message-ID: <54D29816.3050308@digitalbrains.com> On 04/02/15 21:44, Matthias-Christian Ott wrote: > There are enough examples of vendors that introduced government backdoors in > their proprietary products to come to the conclusion that it is probably not > a good idea to use proprietary software or hardware if your threat model > includes government backdoors and you want to defend against them (of course > that doesn't mean that it is impossible to verify that a proprietary product > does not contain a backdoor but it is unarguably a lot harder). So I don't > know how speculating that a particular vendor of proprietary hardware and > software implants backdoors in its products does move the discussion > forward. What about non-governmental attackers who are able to update your reader firmware through an evil maid attack or the like? You seem to imply that hacked reader firmware is necessarily by a government or the manufacturer. I don't think "it's easier to hack than comparable equipment from competitors" is a particularly compelling argument, though, to be honest. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From ott at mirix.org Wed Feb 4 23:12:04 2015 From: ott at mirix.org (Matthias-Christian Ott) Date: Wed, 04 Feb 2015 23:12:04 +0100 Subject: Talking about Cryptodevices... which one? In-Reply-To: <54D29816.3050308@digitalbrains.com> References: <54C1BF3A.2040903@gmail.com> <87iofxck7h.fsf@vigenere.g10code.de> <54C2D3AD.9080608@mirix.org> <54C3CEEB.7030406@cardcontact.de> <54C51A4A.8060403@mirix.org> <87y4oen5lx.fsf@vigenere.g10code.de> <54D284C8.4060508@mirix.org> <54D29816.3050308@digitalbrains.com> Message-ID: <54D29934.6000504@mirix.org> On 2015-02-04 23:07, Peter Lebbing wrote: > On 04/02/15 21:44, Matthias-Christian Ott wrote: >> There are enough examples of vendors that introduced government backdoors in >> their proprietary products to come to the conclusion that it is probably not >> a good idea to use proprietary software or hardware if your threat model >> includes government backdoors and you want to defend against them (of course >> that doesn't mean that it is impossible to verify that a proprietary product >> does not contain a backdoor but it is unarguably a lot harder). So I don't >> know how speculating that a particular vendor of proprietary hardware and >> software implants backdoors in its products does move the discussion >> forward. > > What about non-governmental attackers who are able to update your reader > firmware through an evil maid attack or the like? You seem to imply that hacked > reader firmware is necessarily by a government or the manufacturer. You could protect against this scenario by signing the firmware. In some countries "the government" can legally force the manufacturer to sign "the government's" firmware. > I don't think "it's easier to hack than comparable equipment from competitors" > is a particularly compelling argument, though, to be honest. I didn't make this argument. Regards, Matthias-Christian From peter at digitalbrains.com Thu Feb 5 10:38:29 2015 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 05 Feb 2015 10:38:29 +0100 Subject: Talking about Cryptodevices... which one? In-Reply-To: <54D29934.6000504@mirix.org> References: <54C1BF3A.2040903@gmail.com> <87iofxck7h.fsf@vigenere.g10code.de> <54C2D3AD.9080608@mirix.org> <54C3CEEB.7030406@cardcontact.de> <54C51A4A.8060403@mirix.org> <87y4oen5lx.fsf@vigenere.g10code.de> <54D284C8.4060508@mirix.org> <54D29816.3050308@digitalbrains.com> <54D29934.6000504@mirix.org> Message-ID: <54D33A15.5050907@digitalbrains.com> On 04/02/15 23:12, Matthias-Christian Ott wrote: > You could protect against this scenario by signing the firmware. Yes, you /could/. However, we were talking about Rainer smartcard readers, which /don't/. I think we're really not having the same discussion here... > I didn't make this argument. ... as I didn't intend to say you did, but I thought we were discussing this argument made by Werner. I think I see some source of confusion. You wrote: > You speculated that Rainer SCT might cooperate with the German intelligence > agency BND. You gave the following reason for your suspicion: > "microcontrollers are smaller and writing malware for them is harder". I never read it that way. To me, it were two spearate arguments, one on how trustworthy Rainer appears in its dealings, and the other on the hackability of their hardware. So I might have misinterpreted what you wrote following that. Oh, by the way: > But will a smartcard solve the problem that the host computer might be > infected with malware? I'm absolutely sure nobody made that claim. More miscommunication galore? ;) Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From matthew.garman at gmail.com Thu Feb 5 17:38:13 2015 From: matthew.garman at gmail.com (Matt Garman) Date: Thu, 5 Feb 2015 10:38:13 -0600 Subject: pinentry-curses unusable with gpg-agent --no-detach Message-ID: This might be a bug, but could also be user-error, so I thought I'd check the mailing list. I'm using gpg-agent v2.0.14 (this ships with CentOS/RHEL 6.5). This distribution ships pinentry-0.7.6, but I also see this behavior with the latest pinentry-0.9.0 from gnupg.org source. Steps to demonstrate issue: (1) Start gpg-agent with --no-detach option (2) Make sure $DISPLAY is not set to force pinentry to fallback to curses (3) Attempt to decode a gpg-encrypted file to trigger pinentry In the stock RHEL pinentry version (0.7.6), the input is automatically and continuously "crammed" with asterisks ('*'). That is, it's as if someone is typing in an infinite-length password as quickly as possible. This also consumes 100% of CPU and requires kill -9. With the latest pinentry (0.9.0), the behavior is the same, except the asterisks don't fill as quickly, maybe one or two per second. Still unusable, just not as severe as the older pinentry-curses. (I realize the gpg-agent --no-detach option is meant for debugging, but we are intending to modify gpg to not use the agent if it's not running on the same TTY as gpg. Without --no-detach, agent runs without a TTY, and our gpg modification renders agent useless. But the behavior described above occurs without any gpg modification.) Thanks! From 2014-667rhzu3dc-lists-groups at riseup.net Thu Feb 5 20:00:51 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Thu, 5 Feb 2015 19:00:51 +0000 Subject: Talking about Cryptodevices... which one? In-Reply-To: <54D33A15.5050907@digitalbrains.com> References: <54C1BF3A.2040903@gmail.com> <87iofxck7h.fsf@vigenere.g10code.de> <54C2D3AD.9080608@mirix.org> <54C3CEEB.7030406@cardcontact.de> <54C51A4A.8060403@mirix.org> <87y4oen5lx.fsf@vigenere.g10code.de> <54D284C8.4060508@mirix.org> <54D29816.3050308@digitalbrains.com> <54D29934.6000504@mirix.org> <54D33A15.5050907@digitalbrains.com> Message-ID: <9110484125.20150205190051@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Thursday 5 February 2015 at 9:38:29 AM, in , Peter Lebbing wrote: > Oh, by the way: >> But will a smartcard solve the problem that the host >> computer might be infected with malware? > I'm absolutely sure nobody made that claim. I've seen the question several times before, usually answered in the negative. - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net Time flies like an arrow. Fruit flies like a banana. -- Groucho Marx -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJU0735XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwyz0H/RWTEWTwusKZ6ikeclFz0fMM q8qZl6M7+j3dwRRuZP0OFYwiemJx/E3D+rqmHW2p0f09EwWM7IMcLeAAlWlt6LS9 djicXYXv22byKzbVP42cV9gnJvgl/dBKUz7kMJjxDNrTvCNiNp+PfNrkUPZeaMTX 9v030yTRd1dH0ob7CZC1b1ozQX8w2jdQ1vK8oCqjA9k90DvVoJU661NJ1k6Hatcu UGIl5DB1HNVmy+T3M9jr7b9nbmbnkLrpvUOvh4Ihx2qSpyxXAmG11Hl9Lqm5+61b rwDUOpxPp9N1elqLMXP6Mib5J/4mL4pGn0cnSE77B/E/lgddjWi0lyVaBVn8WKqI vgQBFgoAZgUCVNO9/18UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45OX1AQAhOI4+o/tv9UdygrSNJw7BckaC m0F0CDhI6pUubiBZEwEAxyeL8nBzBw3R3ZjACktiu61HOwRFOo6qqMgtdfuy5ww= =sJVJ -----END PGP SIGNATURE----- From faramir.cl at gmail.com Fri Feb 6 00:32:53 2015 From: faramir.cl at gmail.com (Faramir) Date: Thu, 05 Feb 2015 20:32:53 -0300 Subject: Talking about Cryptodevices... which one? In-Reply-To: <9110484125.20150205190051@my_localhost> References: <54C1BF3A.2040903@gmail.com> <87iofxck7h.fsf@vigenere.g10code.de> <54C2D3AD.9080608@mirix.org> <54C3CEEB.7030406@cardcontact.de> <54C51A4A.8060403@mirix.org> <87y4oen5lx.fsf@vigenere.g10code.de> <54D284C8.4060508@mirix.org> <54D29816.3050308@digitalbrains.com> <54D29934.6000504@mirix.org> <54D33A15.5050907@digitalbrains.com> <9110484125.20150205190051@my_localhost> Message-ID: <54D3FDA5.5060108@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 05-02-2015 a las 16:00, MFPA escibi?: > Hi > > > On Thursday 5 February 2015 at 9:38:29 AM, in > , Peter Lebbing wrote: > > >> Oh, by the way: > >>> But will a smartcard solve the problem that the host computer >>> might be infected with malware? > >> I'm absolutely sure nobody made that claim. > > I've seen the question several times before, usually answered in > the negative. Well... I remember usually the answer is you shouldn't try to keep using a compromised computer, and that instead of trying to find a way to keep using a compromised computer, you should fix it. But I still have the impression about smartcards are supposed to prevent an attacker from stealing the private keys from the cards, right? Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJU0/2lAAoJEMV4f6PvczxAgpoH/2CkUateERiw78WUCnKaUjuZ QJXMi14zPqVMlj/od4ctVqZ4P8q/dM6AvcVHQELxmyolGub5bQK441N+wm6HIvSc lhhqf5JFoGmDYJ39OFsIZdZ7/aokPezOww+0Q+Da9Db6XmIuuar0Fq4puawWDr36 GE46VIT0waGGfMTQgcF+Jj5tiF2HZXConhr9juObyuz/fYj8pD1tYRfoPdip8CVZ JY3jYp2UGX9xQa89yw8dGKncoUxryjiSSpaK110NASD+z5M2+kIUNTdhFNIP3EXO O+/njMPkq+cD+ghwgx34qYPTd7gnb3weq+DsW6AAQBNiufumb6NhAh7RczLMDnA= =Xm/Q -----END PGP SIGNATURE----- From ott at mirix.org Fri Feb 6 01:21:28 2015 From: ott at mirix.org (Matthias-Christian Ott) Date: Fri, 06 Feb 2015 01:21:28 +0100 Subject: Talking about Cryptodevices... which one? In-Reply-To: <54D33A15.5050907@digitalbrains.com> References: <54C1BF3A.2040903@gmail.com> <87iofxck7h.fsf@vigenere.g10code.de> <54C2D3AD.9080608@mirix.org> <54C3CEEB.7030406@cardcontact.de> <54C51A4A.8060403@mirix.org> <87y4oen5lx.fsf@vigenere.g10code.de> <54D284C8.4060508@mirix.org> <54D29816.3050308@digitalbrains.com> <54D29934.6000504@mirix.org> <54D33A15.5050907@digitalbrains.com> Message-ID: <54D40908.2020609@mirix.org> On 2015-02-05 10:38, Peter Lebbing wrote: > On 04/02/15 23:12, Matthias-Christian Ott wrote: >> You could protect against this scenario by signing the firmware. > > Yes, you /could/. However, we were talking about Rainer smartcard readers, which > /don't/. Do you have evidence for this? If they provably don't sign their firmware or incorrectly check the signature and are not responsive, perhaps it would be helpful to talk to them through third parties like BSI or S-CERT (Deutscher Sparkassen Verlag exclusively sells Reiner SCT readers for HBCI and I'm sure that it would be in their interest to only allow firmware updates that are signed) with Reiner SCT instead of speculating about backdoors. Moreover, why should the readers accept unsigned firmware if "the government" requested the ability to install "modified" firmware? The manufacturer could simply handover the keys. At least the cyberJack RFID komfort conforms to BSI-TR 03119 [1,2] and is in the reader category that requires signed firmware updates (see sections 3.1 and A.8) and the certification report also mentions this. You can of course speculate what "authorised persons or systems" means. However, I think it is safe to assume that the German government is not outright crazy and does not try to undermine the security of their eID cards because fake eID cards are not in their interest and they can issue themselves fake eID cards without the need to compromise a smartcard reader. So at least for this particular model your statement seems wrong and the fact that Werner Koch claimed this doesn't make it right. Of course without the source code it requires a major reverse engineering effort to verify that the statements of the certification companies are correct or that the code is bug-free. Moreover, the certification report does not mention that the certification companies verified the source code or even looked at it. > I think I see some source of confusion. You wrote: > >> You speculated that Rainer SCT might cooperate with the German intelligence >> agency BND. You gave the following reason for your suspicion: >> "microcontrollers are smaller and writing malware for them is harder". > > I never read it that way. To me, it were two spearate arguments, one on how > trustworthy Rainer appears in its dealings, and the other on the hackability of > their hardware. So I might have misinterpreted what you wrote following that. Only Werner Koch knows how this statement was meant. I read it the way I described it and think that there is no contradiction between both aspects. > Oh, by the way: > >> But will a smartcard solve the problem that the host computer might be >> infected with malware? > > I'm absolutely sure nobody made that claim. More miscommunication galore? ;) Werner Koch suggested it (<87y4oen5lx.fsf at vigenere.g10code.de>). If I'm not mistaken the OpenPGP card is proprietary software and runs on a proprietary operating system (BasicCard). If this is true, why should you trust it and why does the FSFE distribute these cards even though they conflict with their core values? What is the threat model in which a smartcard is an effective defense and what are attacks that smartcards protect against? How are smartcards supposed to protect against malware on the host computer? If somebody wants to discuss or answer these questions that I'm asking myself for years, I will be happy to continue the discussion otherwise I'm out of it. Regards, Matthias-Christian [1] https://www.bsi.bund.de/DE/Publikationen/TechnischeRichtlinien/tr03119/index_htm.html [2] https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Zertifizierung/Konformitaetsreporte/BSI-K-TR-0068-2011.pdf?__blob=publicationFile From ciprian.craciun at gmail.com Fri Feb 6 07:54:05 2015 From: ciprian.craciun at gmail.com (Ciprian Dorin Craciun) Date: Fri, 6 Feb 2015 08:54:05 +0200 Subject: pinentry-curses unusable with gpg-agent --no-detach In-Reply-To: References: Message-ID: On Thu, Feb 5, 2015 at 6:38 PM, Matt Garman wrote: > Steps to demonstrate issue: > (1) Start gpg-agent with --no-detach option > (2) Make sure $DISPLAY is not set to force pinentry to fallback to curses > (3) Attempt to decode a gpg-encrypted file to trigger pinentry > > [...] > > (I realize the gpg-agent --no-detach option is meant for debugging, > but we are intending to modify gpg to not use the agent if it's not > running on the same TTY as gpg. Without --no-detach, agent runs > without a TTY, and our gpg modification renders agent useless. But > the behavior described above occurs without any gpg modification.) Welcome to my worst nightmare: trying to make GnuPG agent (and for that matter the SSH agent) runnable in the foreground. (My purpose was to run it under a process supervisor like `runit` or `s6`, but regardless...) Short answer: you can't convince any of these agents to behave and run in the foreground. What is worse is that no matter how you configure GnuPG agent or `pinentry-curses` to use a certain TTY, it will always "finds" the "current" TTY your GnuPG is running on. (And I've tried to write my own `pinentry-curses` wrapper that was set to GnuPG agent with `--pinentry-program`, and the wrapper calls `pinentry-curses` with all the right parameters like `--ttyname`.) However hope is not lost... I did modify that wrapper script to actually mangle the protocol and always replace the `OPTION ttyname` (and others) commands with hardcoded values. Below is the portion of the wrapper script you might find useful. (Just replace `/dev/tty` with a proper value. In my case the uses some tricks to open it on the 11th virtual console). Thus run `gpg-agent` like you would normaly do (i.e. let it fork into the background), and use this trick. ~~~~ pinentry-curses \ --timeout 6 \ --display __none__ \ --ttyname /dev/tty \ --ttytype linux \ --lc-ctype en_US.utf8 \ --lc-messages en_US.utf8 \ < <( exec sed -u -r \ -e 's|^OPTION display=.*$|OPTION display=__none__|' \ -e 's|^OPTION ttyname=.*$|OPTION ttyname=/dev/tty|' \ -e 's|^OPTION ttytype=.*$|OPTION ttytype=linux|' \ -e 's|^OPTION lc-ctype=.*$|OPTION lc-ctype=en_US.utf8|' \ -e 's|^OPTION lc-messages=.*$|OPTION lc-messages=en_US.utf8|' ) ~~~~ For the record I've opened a similar thread on this subject in 2009 and then 2010 without any real solution: https://www.mail-archive.com/gnupg-users at gnupg.org/msg12323.html Hopefully you are more lucky, Ciprian. P.S.: I really like GnuPG, and I salute the developers effort. However the way the GnuPG agent integrates with other software (mainly process supervisors) and the PIN entry, are really abysmal... Some updates in this regard are welcome and in fact quite easy. Below is a patch I did in 2009 to add a new option `--daemon-fg` which makes GnuPG agent behave like in `--daemon` mode but without forking into the background. (Although the patch was trivial was not accepted...) https://www.mail-archive.com/gnupg-users at gnupg.org/msg12323.html From andreas.schwier.ml at cardcontact.de Fri Feb 6 09:12:22 2015 From: andreas.schwier.ml at cardcontact.de (Andreas Schwier) Date: Fri, 06 Feb 2015 09:12:22 +0100 Subject: Talking about Cryptodevices... which one? In-Reply-To: <54D40908.2020609@mirix.org> References: <54C1BF3A.2040903@gmail.com> <87iofxck7h.fsf@vigenere.g10code.de> <54C2D3AD.9080608@mirix.org> <54C3CEEB.7030406@cardcontact.de> <54C51A4A.8060403@mirix.org> <87y4oen5lx.fsf@vigenere.g10code.de> <54D284C8.4060508@mirix.org> <54D29816.3050308@digitalbrains.com> <54D29934.6000504@mirix.org> <54D33A15.5050907@digitalbrains.com> <54D40908.2020609@mirix.org> Message-ID: <54D47766.4000806@cardcontact.de> On 02/06/2015 01:21 AM, Matthias-Christian Ott wrote: > If I'm not mistaken the OpenPGP card is proprietary software and runs on > a proprietary operating system (BasicCard). If this is true, why should > you trust it and why does the FSFE distribute these cards even though > they conflict with their core values? And it doesn't even have undergone any independent security evaluation. > > What is the threat model in which a smartcard is an effective defense > and what are attacks that smartcards protect against? How are smartcards > supposed to protect against malware on the host computer? Smart cards (if done well) protect from unwanted key duplication or disclosure. It's much harder to break into someones home to steal the card than it is to steal a file and a number of key strokes. Of course a smart card can not protect against malware on the host computer, but it can prevent that the key is gone after malware has infected the host. If my card is suddenly missing from my desk, than that is much easier to spot than an illegal copy of my key file - which I can't really detect. And we are talking about the average user that can not easily control what processes are running on their computer and if it's good or bad. For them it's much easier to lock important keys away in their desk than it is to keep a computer free from malware. > > If somebody wants to discuss or answer these questions that I'm asking > myself for years, I will be happy to continue the discussion otherwise > I'm out of it. > > Regards, > Matthias-Christian > > [1] > https://www.bsi.bund.de/DE/Publikationen/TechnischeRichtlinien/tr03119/index_htm.html > [2] > https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Zertifizierung/Konformitaetsreporte/BSI-K-TR-0068-2011.pdf?__blob=publicationFile > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -- --------- CardContact Software & System Consulting |.##> <##.| Andreas Schwier |# #| Sch?lerweg 38 |# #| 32429 Minden, Germany |'##> <##'| Phone +49 571 56149 --------- http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org http://www.smartcard-hsm.com From peter at digitalbrains.com Fri Feb 6 12:09:35 2015 From: peter at digitalbrains.com (Peter Lebbing) Date: Fri, 06 Feb 2015 12:09:35 +0100 Subject: Talking about Cryptodevices... which one? In-Reply-To: <54D40908.2020609@mirix.org> References: <54C1BF3A.2040903@gmail.com> <87iofxck7h.fsf@vigenere.g10code.de> <54C2D3AD.9080608@mirix.org> <54C3CEEB.7030406@cardcontact.de> <54C51A4A.8060403@mirix.org> <87y4oen5lx.fsf@vigenere.g10code.de> <54D284C8.4060508@mirix.org> <54D29816.3050308@digitalbrains.com> <54D29934.6000504@mirix.org> <54D33A15.5050907@digitalbrains.com> <54D40908.2020609@mirix.org> Message-ID: <54D4A0EF.6020502@digitalbrains.com> On 06/02/15 01:21, Matthias-Christian Ott wrote: > If they provably don't sign their firmware or incorrectly check the signature > and are not responsive, perhaps it would be helpful to talk to them through > third parties like BSI or S-CERT Why?! Why would I do that?! I do like to think of myself as a bit altruistic, but seriously, why would I go through all that effort? Thanks for making me smile. It does a person good. Furthermore, I am a bit tired of this subject, forgive me for not answering most of what you say. I get the impression you're not picking up on what I'm trying to say, and that becomes a bit tiresome. >> I'm absolutely sure nobody made that claim. More miscommunication galore? >> ;) > > Werner Koch suggested it (<87y4oen5lx.fsf at vigenere.g10code.de>). If you would link[1] to the mailing list archives I wouldn't have to open the (what Thunderbird calls) "message source" to visually compare the Message-ID on a likely message. Anyway, that wasn't such a long mail. It sure doesn't contain your suggestion. You're really doing a lot of extra interpretation and inference if you take that suggestion from: > I think such a discussion is important and belongs here. I see no > reason to discuss the need for 8k or even 4k keys if we neglect to > discuss hardware or malware based attacks. In fact the immediate need > for very large keys is mostly an academic exercise while the latter are > real threats. To me, it says that 4k or 8k keys are not the weak spot of a cryptosystem. And that we should discuss weak spots on this list. Thank you for your contribution in that. But it sure as hell doesn't say that a smartcard keeps you safe when you're working on a compromised system. > If somebody wants to discuss or answer these questions that I'm asking myself > for years, I will be happy to continue the discussion otherwise I'm out of > it. Glad we agree on that at least. Cheers, Peter. [1] http://lists.gnupg.org/pipermail/gnupg-users/2015-February/052344.html -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From peter at digitalbrains.com Fri Feb 6 12:09:44 2015 From: peter at digitalbrains.com (Peter Lebbing) Date: Fri, 06 Feb 2015 12:09:44 +0100 Subject: Talking about Cryptodevices... which one? In-Reply-To: <54D3FDA5.5060108@gmail.com> References: <54C1BF3A.2040903@gmail.com> <87iofxck7h.fsf@vigenere.g10code.de> <54C2D3AD.9080608@mirix.org> <54C3CEEB.7030406@cardcontact.de> <54C51A4A.8060403@mirix.org> <87y4oen5lx.fsf@vigenere.g10code.de> <54D284C8.4060508@mirix.org> <54D29816.3050308@digitalbrains.com> <54D29934.6000504@mirix.org> <54D33A15.5050907@digitalbrains.com> <9110484125.20150205190051@my_localhost> <54D3FDA5.5060108@gmail.com> Message-ID: <54D4A0F8.1010500@digitalbrains.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/02/15 00:32, Faramir wrote: > But I still have the impression about smartcards are supposed to prevent an > attacker from stealing the private keys from the cards, right? Yes, I agree. Peter. - -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From peter at digitalbrains.com Fri Feb 6 12:17:15 2015 From: peter at digitalbrains.com (Peter Lebbing) Date: Fri, 06 Feb 2015 12:17:15 +0100 Subject: Talking about Cryptodevices... which one? In-Reply-To: <54D40908.2020609@mirix.org> References: <54C1BF3A.2040903@gmail.com> <87iofxck7h.fsf@vigenere.g10code.de> <54C2D3AD.9080608@mirix.org> <54C3CEEB.7030406@cardcontact.de> <54C51A4A.8060403@mirix.org> <87y4oen5lx.fsf@vigenere.g10code.de> <54D284C8.4060508@mirix.org> <54D29816.3050308@digitalbrains.com> <54D29934.6000504@mirix.org> <54D33A15.5050907@digitalbrains.com> <54D40908.2020609@mirix.org> Message-ID: <54D4A2BB.8040808@digitalbrains.com> On 06/02/15 01:21, Matthias-Christian Ott wrote: >> Yes, you /could/. However, we were talking about Rainer smartcard readers, >> which /don't/. > > Do you have evidence for this? To st the record straight: no, I don't know this, I might myself have inferred a bit too much from Werner stating that: On 23/01/15 21:31, Werner Koch wrote: > Further, the Cyberjack readers run a lot of code not necessary for accessing > the card and the firmware can easily be updated from the host (if you know > how to do that). So I was wrong to make that statement, sorry. I might have no love for a company that seems to shun the free software world, but it is wrong to make statements that are simply not supported by evidence. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From ott at mirix.org Fri Feb 6 15:06:04 2015 From: ott at mirix.org (Matthias-Christian Ott) Date: Fri, 06 Feb 2015 15:06:04 +0100 Subject: Talking about Cryptodevices... which one? In-Reply-To: <54D47766.4000806@cardcontact.de> References: <54C1BF3A.2040903@gmail.com> <87iofxck7h.fsf@vigenere.g10code.de> <54C2D3AD.9080608@mirix.org> <54C3CEEB.7030406@cardcontact.de> <54C51A4A.8060403@mirix.org> <87y4oen5lx.fsf@vigenere.g10code.de> <54D284C8.4060508@mirix.org> <54D29816.3050308@digitalbrains.com> <54D29934.6000504@mirix.org> <54D33A15.5050907@digitalbrains.com> <54D40908.2020609@mirix.org> <54D47766.4000806@cardcontact.de> Message-ID: <54D4CA4C.80800@mirix.org> On 2015-02-06 09:12, Andreas Schwier wrote: > On 02/06/2015 01:21 AM, Matthias-Christian Ott wrote: >> What is the threat model in which a smartcard is an effective defense >> and what are attacks that smartcards protect against? How are smartcards >> supposed to protect against malware on the host computer? > Smart cards (if done well) protect from unwanted key duplication or > disclosure. It's much harder to break into someones home to steal the > card than it is to steal a file and a number of key strokes. If you use Schneier's attack tree for PGP encryption [1] as the threat model (for the lack of something better), a smartcard would protect against 1.4.2 ("Get private key from recipient's key ring") and 1.4.3 ("Monitor recipient's memory"). But if your goal is 1 ("Read a message encrypted with PGP") and you have infected the host computer (as you scenario says) you can't protect against 1.2.1 ("Fool sender into encrypting message using public key whose private key is known"), 1.2.3 ("Monitor sender's computer memory") and 1.2.4 ("Monitor receiver's computer memory"), any of which suffices to achieve the goal. A similar argument can be made for digital signatures. Maybe smartcards can increase the costs of an attack but security economics are a really dangerous field that equates people to money and works by the "garbage in garbage out" principle which is also dangerous if you are non-critical. Peter Gutmann reports in the draft of his book "Engineering Security" [2] that there is in fact malware that steals keys and certificates. Perhaps a smartcard could have prevented some current malware from stealing your keys from the smartcard but stealing the keys is just a means to an end and the ultimate goal is to either break confidentiality (decrypt messages) or impersonation (sign messages of the attackers choice). Perhaps one can say that smartcards can improve the usability, especially for average computer users who know how to protect bank cards and want portable key storage. Perhaps this in itself improves security because these users would better understand the system. I have setup some users with smartcards for HBCI banking and noticed that they applied more "security measures" and caution with the card than logging into the website of their bank with username and password. > Of course a smart card can not protect against malware on the host > computer, but it can prevent that the key is gone after malware has > infected the host. If my card is suddenly missing from my desk, than > that is much easier to spot than an illegal copy of my key file - which > I can't really detect. That is definitely a usability advantage, especially if you consider ransomware that wants to get money from the user for decrypting their files. However, randsomware could also destroy your smartcard by entering a wrong PIN and PUK (or whatever they are called) too many times. > And we are talking about the average user that can not easily control > what processes are running on their computer and if it's good or bad. > For them it's much easier to lock important keys away in their desk than > it is to keep a computer free from malware. I agree. But if your adversary is more powerful than an average cybercriminal that won't help you either because such adversary could intercept the communication between smartcard and host computer and would trick you into performing a key rollover or decrypt or sign other messages that you did not intend to decrypt or sign. Of course you would notice this at some point and perhaps notice it more likely with a smartcard (if you can trust it) than with a key file but if you notice it, it might be already too late: Imagine for example a journalist communicating with a source (just too use an example that has been used too many times ;)) and an adversary who wants to find the source. The adversary could feed the smartcard a different message that the journalist wanted to sign and for example sign the message "meet me at t at l". Instead of the journalist the adversary would wait at l at time t to arrest the source. Another example would be malware that wants to get another piece of malware signed (see Gutmann's book for examples) that infects computer of a software developer or company and instead of signing the new release of a software it signs a new release that also contains malware because it is able to control the communication between host computer and smartcard (this would also work with source code only releases). You can also see this problem when you look at online banking. When German banks employed indexed TAN lists there was malware that simply substituted the recipient fields of wire transfer forms but displayed the original recipient fields to the user. German banks had to take the extreme measure of distributing air-gapped devices to their customers that display the entire contents of the wire transfer form on their tiny screen to prevent this attack (this doesn't help if the attacker also manipulates the bill that you received via email and want to pay). For OpenPGP this is simply infeasible to display the entire message in hexdecimal on a tiny one line screen and a hash value won't help either. For example the attack on the German eID card, where users signed PDFs with embedded data that the eID PDF reader could not display, demonstrated this. In all of these cases it does not matter for the attacker whether the attacker is in possession of the private keys. Moreover, sandboxing and update mechanisms like those employed by the Google Chrome and Chromium web browsers have probably saved more average users from malware than any smartcards combined (see more lengthy description in previous emails). So from the perspective of security economics (if you want to apply it and have given up absolute security) such mechanisms are a cheaper and more effective countermeasure for the average user. Regards, Matthias-Christian [1] https://www.schneier.com/attacktrees.pdf [2] https://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf From peter at digitalbrains.com Fri Feb 6 20:41:08 2015 From: peter at digitalbrains.com (Peter Lebbing) Date: Fri, 06 Feb 2015 20:41:08 +0100 Subject: Talking about Cryptodevices... which one? In-Reply-To: <54D4CA4C.80800@mirix.org> References: <54C1BF3A.2040903@gmail.com> <87iofxck7h.fsf@vigenere.g10code.de> <54C2D3AD.9080608@mirix.org> <54C3CEEB.7030406@cardcontact.de> <54C51A4A.8060403@mirix.org> <87y4oen5lx.fsf@vigenere.g10code.de> <54D284C8.4060508@mirix.org> <54D29816.3050308@digitalbrains.com> <54D29934.6000504@mirix.org> <54D33A15.5050907@digitalbrains.com> <54D40908.2020609@mirix.org> <54D47766.4000806@cardcontact.de> <54D4CA4C.80800@mirix.org> Message-ID: <54D518D4.1080507@digitalbrains.com> You know, if you had just said right from the start "I know that a smartcard is supposed to protect theft of the private key but what is the use of that given that they can still sign and decrypt", the discussion might have progressed a /lot/ quicker. Also, it doesn't help that you eloquently refute things people never said in the first place, and hence didn't need to be refuted. I think the answer to it is the timespan, by the way. If I'm working on a compromised computer with a smartcard now, hackers can access my encrypted files and sign stuff with my key. But let's say in a week I will be using a new computer, then they will lose the ability to sign and can no longer decrypt any new documents encrypted to me. If they had compromised my PC with the keys on disk, they would have copied them, and as long as I use the key, they can access the data and sign new stuff as well. And given the many escalate-to-root security bugs that are constantly found and fixed, I do not think any software measure is going to prevent a determined attacker from gaining full control of your system once they get a hold of your user account. Your scenario of the attacker doing a key rollover, revoking your actual key and substituting their own, can be prevented by using an offline master key so the attacker only has access to the subkeys. Also, if I'm concerned this might have happened, I can check with my correspondents to see if they are under the impression I recently changed keys. Given a secure channel to them, I can detect this. It's not nearly as stealthy as simply copying the key material. The attack form popularized by the BadUSB people is a genuine problem; what if, by plugging in the card reader I used on a compromised PC into a clean PC, it immediately compromised that clean PC? Similarly, if I think I'm cleaning my PC from infection by wiping the hard disk, but the attacker modified the firmware of the hard disk, I'm still screwed, as shown by Sprite_TM on OHM2013. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From 2014-667rhzu3dc-lists-groups at riseup.net Fri Feb 6 22:25:55 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Fri, 6 Feb 2015 21:25:55 +0000 Subject: Talking about Cryptodevices... which one? In-Reply-To: <54D4A0F8.1010500@digitalbrains.com> References: <54C1BF3A.2040903@gmail.com> <87iofxck7h.fsf@vigenere.g10code.de> <54C2D3AD.9080608@mirix.org> <54C3CEEB.7030406@cardcontact.de> <54C51A4A.8060403@mirix.org> <87y4oen5lx.fsf@vigenere.g10code.de> <54D284C8.4060508@mirix.org> <54D29816.3050308@digitalbrains.com> <54D29934.6000504@mirix.org> <54D33A15.5050907@digitalbrains.com> <9110484125.20150205190051@my_localhost> <54D3FDA5.5060108@gmail.com> <54D4A0F8.1010500@digitalbrains.com> Message-ID: <1786349870.20150206212555@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Friday 6 February 2015 at 11:09:44 AM, in , Peter Lebbing wrote: > On 06/02/15 00:32, Faramir wrote: >> But I still have the impression about smartcards are supposed to prevent an >> attacker from stealing the private keys from the cards, right? > Yes, I agree. > Peter. But the threat is not fully mitigated if, as you said yourself in another message on this thread, the attacker can potentially sign/decrypt using the key on the smartcard. - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net One morning I shot an elephant in my pajamas. How he got in my pajamas, I don't know. -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJU1TF4XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwnisH/24nxEh/OkW1Q1EMR91kXPe9 DV0xutQzChaMHdCu288r7aXazg+hvMumo0cyNVNMjgB++OtVTa0GP97UK1f6DpZT deXNUms+OPiyArwVAjlwUiHZ51uIIrZbXQLQkEHQ9Ap4O5mHLE51swz7nHmJxvkR SBW+u5gRm3beMRlvH9G3Xt3nHpz14LsD+Rqp7bs+/jCPJF3Xlzh3SkrGD7qx+101 jIgae5PHV0fNAm9dB6FkhbArYc+E0WUNh4B1XI+zlU92mgfjyZ02q1Dfv1aW5awD 2FCDBJT+mjUtmt1joqpJciYgh11HBBKzf9IC/jUYHpFT9TPojTqVVmuawnVPvc2I vgQBFgoAZgUCVNUxgl8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45DaMAQCCidoTzCEsrxVM9+1RlddHH62C 4TGvUr5u2BIYXL2FngEA5bjYH9G4M/tCvBmKgG1Fwgcae4VH0GzzcPwNi5SIKgw= =yIq7 -----END PGP SIGNATURE----- From johannes at zarl.at Sat Feb 7 00:59:41 2015 From: johannes at zarl.at (Johannes Zarl) Date: Sat, 07 Feb 2015 00:59:41 +0100 Subject: Talking about Cryptodevices... which one? In-Reply-To: <1786349870.20150206212555@my_localhost> References: <54C1BF3A.2040903@gmail.com> <54D4A0F8.1010500@digitalbrains.com> <1786349870.20150206212555@my_localhost> Message-ID: <1840536.GW9g4AXMVe@mani> > >> But I still have the impression about smartcards are supposed to prevent > >> an > >> > >> attacker from stealing the private keys from the cards, right? > > > > Yes, I agree. > > > > Peter. > > But the threat is not fully mitigated if, as you said yourself in > another message on this thread, the attacker can potentially > sign/decrypt using the key on the smartcard. You're conflating two different threats here. A smartcard *does* protect you from anyone trying to steal your private keys. It does not prevent an attacker from stealing the pin. It does not prevent an attacker from deleting your key. It does not prevent an attacker from tricking you into signing or decrypting a message. Under some circumstances it does not even protect against key- revocation. Having said all that, I still think it is a worthwhile goal to protect the key-material itself using smartcard-like hardware / an HSM. The protection against key-theft does radically decrease your attack surface in many cases. Johannes From gnupg2 at ddm.wox.org Fri Feb 6 22:59:02 2015 From: gnupg2 at ddm.wox.org (Dave Chapeskie) Date: Fri, 6 Feb 2015 16:59:02 -0500 Subject: Talking about Cryptodevices... which one? In-Reply-To: <54D4CA4C.80800@mirix.org> References: <54C3CEEB.7030406@cardcontact.de> <54C51A4A.8060403@mirix.org> <87y4oen5lx.fsf@vigenere.g10code.de> <54D284C8.4060508@mirix.org> <54D29816.3050308@digitalbrains.com> <54D29934.6000504@mirix.org> <54D33A15.5050907@digitalbrains.com> <54D40908.2020609@mirix.org> <54D47766.4000806@cardcontact.de> <54D4CA4C.80800@mirix.org> Message-ID: <20150206215902.GA31598@ddm.wox.org> On Fri, Feb 06, 2015 at 03:06:04PM +0100, Matthias-Christian Ott wrote: > On 2015-02-06 09:12, Andreas Schwier wrote: > If you use Schneier's attack tree for PGP encryption [1] as the threat > model (for the lack of something better) > [1] https://www.schneier.com/attacktrees.pdf For those interested, I think better links would be to an article Schneier wrote and the PGP figure rather than to a PDF of slides: https://www.schneier.com/paper-attacktrees-ddj-ft.html and https://www.schneier.com/paper-attacktrees-fig7.html -- Dave Chapeskie From mail at rainerkeller.de Sat Feb 7 18:39:31 2015 From: mail at rainerkeller.de (Rainer Keller) Date: Sat, 07 Feb 2015 18:39:31 +0100 Subject: How to reset the PIN counter Message-ID: <1963543.HiQhT7D78u@green.grummel.netz> Hello, while trying to setup gpg smart card to be used for SSH authentication the PIN retry counter reached 0. I tried several things using the admin PIN in order to reset the counter: 1. "unblock PIN" 2. "change PIN" 3. Setting a "Reset Code" and using that afterwards 4. Change admin PIN Unfortunately none of these works. If I now try to "unblock PIN" I get the error message "Error unblocking the PIN: Conditions of use not satisfied". What is the official intended way to reset all PIN counters? Regards, Rainer gpg (GnuPG) 2.0.26 gpg --card-edit Application ID ...: D276 Version ..........: 2.0 Manufacturer .....: ZeitControl Name of cardholder: Rainer Keller Language prefs ...: de Sex ..............: male URL of public key : [not set] Login data .......: [not set] Signature PIN ....: forced Key attributes ...: 2048R 2048R 4096R Max. PIN lengths .: 32 32 32 PIN retry counter : 0 3 3 Signature counter : 0 Signature key ....: [none] Encryption key....: [none] Authentication key: XXX From 2014-667rhzu3dc-lists-groups at riseup.net Sat Feb 7 19:20:06 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Sat, 7 Feb 2015 18:20:06 +0000 Subject: Talking about Cryptodevices... which one? In-Reply-To: <1840536.GW9g4AXMVe@mani> References: <54C1BF3A.2040903@gmail.com> <54D4A0F8.1010500@digitalbrains.com> <1786349870.20150206212555@my_localhost> <1840536.GW9g4AXMVe@mani> Message-ID: <84548571.20150207182006@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Friday 6 February 2015 at 11:59:41 PM, in , Johannes Zarl wrote: > You're conflating two different threats here. I was referring to the threat "the host computer might be infected with malware". > A > smartcard *does* protect you from anyone trying to > steal your private keys. If they have control of your computer, do they really need to steal the private keys? Maybe they can achieve their aims remotely, using the keys in situ on the smartcard. And, of course, a smartcard is a physical item that can be stolen. > It does not prevent an attacker from stealing the pin. I guess a smartcard reader that can only accept the key via its own keypad would help here. If we can be sure it cannot be modified to cache the PIN or accept it via the host computer. > It does not prevent an attacker from deleting your key. Always best practice to keep a backup. Even without foul-play it would be needed if the smartcard was lost or broken. > It does not prevent an attacker from tricking you into > signing or decrypting a message. Or making your system sign/decrypt more than one message at a time, when you were aware of just the one? > Under some > circumstances it does not even protect against key- > revocation. As has already been mentioned, an "offline" main key stops this. > Having said all that, I still think it is a worthwhile > goal to protect the key-material itself using > smartcard-like hardware / an HSM. Protecting the private key material is the goal. Use of smartcard and reader is an example of a strategy to follow in pursuit of that goal. Use of an offline main key is another example. > The protection > against key-theft does radically decrease your attack > surface in many cases. As always, it depends on your threat model. - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net A candle loses nothing by lighting another candle -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJU1ldmXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXw9DIH/jd5vIExJcCZcuODT3q+1kGg v4qYLqGq+bUHVsDLKs6J5cBQtwF1BuSL1ZSBDO1O6HIoyAG116ZAsrKn1hH6VdRG Gwbtv2PrU6oITj4/nopRigI4xnYno0ucVr4zX0jx9HmCHlfv62rBcPv+lan2qQAb 279aUK5GBXhrOXKfY0q5LghHGDdzSUK+LM4gJXRdXKC64J0XdBZ1cm/K2NSfzUuk 2bEVnvnVIl3WX/sah4ZP7A1O+Ab6s0G8DH1917C/cbF9jZn47Anpq4H9BL2wEsu5 lH1hAI8NbosyYMVOSNQBSFs40tklkEHIdPrvSSaRohXZ3W0UR7sbEub2QGHFKpaI vgQBFgoAZgUCVNZXbV8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45BxvAQBu7ZiYSsTv1WMS5vpKyDv2mcw3 J0EwXN+R1X3NrOEdbgEA34NCRHoJGud4DSbXZrUFMc4j5dIPDW08L4JDqg97GAc= =dpIz -----END PGP SIGNATURE----- From pete at heypete.com Sat Feb 7 21:16:03 2015 From: pete at heypete.com (Pete Stephenson) Date: Sat, 7 Feb 2015 21:16:03 +0100 Subject: How to reset the PIN counter In-Reply-To: <1963543.HiQhT7D78u@green.grummel.netz> References: <1963543.HiQhT7D78u@green.grummel.netz> Message-ID: On Feb 7, 2015 6:42 PM, "Rainer Keller" wrote: > > Hello, > > while trying to setup gpg smart card to be used for SSH authentication the PIN > retry counter reached 0. > > I tried several things using the admin PIN in order to reset the counter: > 1. "unblock PIN" > 2. "change PIN" > 3. Setting a "Reset Code" and using that afterwards > 4. Change admin PIN > > Unfortunately none of these works. If I now try to "unblock PIN" I get the > error message "Error unblocking the PIN: Conditions of use not satisfied". > > What is the official intended way to reset all PIN counters? http://lists.gnupg.org/pipermail/gnupg-users/2013-March/046261.html should have the info you need. I save the reset code block to a text file ("reset.txt") and then run " gpg-connect-agent < reset.txt". Remove and reinsert the card and it should be back to factory defaults. It is worth pointing out that this completely nukes any keys on the card. Cheers! -Pete -------------- next part -------------- An HTML attachment was scrubbed... URL: From hugo at barrera.io Sat Feb 7 20:43:14 2015 From: hugo at barrera.io (Hugo Osvaldo Barrera) Date: Sat, 7 Feb 2015 16:43:14 -0300 Subject: Key keeps showing unknown trust Message-ID: <20150207194314.GA1381@athena.barrera.io> Hi. I'm trying to edit one of my key's trust, but it keeps showing unknown even after changing it: $ gpg --edit-key 1BFBED44 gpg (GnuPG) 2.1.1; Copyright (C) 2014 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Secret key is available. pub rsa2048/1BFBED44 created: 2010-10-07 expires: never usage: SCA trust: full validity: unknown sub rsa2048/28C61189 created: 2010-10-07 expires: never usage: E [ unknown] (1). Hugo Osvaldo Barrera [ revoked] (2) Hugo Osvaldo Barrera [ revoked] (3) Hugo Osvaldo Barrera [ revoked] (4) Hugo Osvaldo Barrera (Work Account) gpg> trust pub rsa2048/1BFBED44 created: 2010-10-07 expires: never usage: SCA trust: full validity: unknown sub rsa2048/28C61189 created: 2010-10-07 expires: never usage: E [ unknown] (1). Hugo Osvaldo Barrera [ revoked] (2) Hugo Osvaldo Barrera [ revoked] (3) Hugo Osvaldo Barrera [ revoked] (4) Hugo Osvaldo Barrera (Work Account) Please decide how far you trust this user to correctly verify other users' keys (by looking at passports, checking fingerprints from different sources, etc.) 1 = I don't know or won't say 2 = I do NOT trust 3 = I trust marginally 4 = I trust fully 5 = I trust ultimately m = back to the main menu Your decision? 4 pub rsa2048/1BFBED44 created: 2010-10-07 expires: never usage: SCA trust: full validity: unknown sub rsa2048/28C61189 created: 2010-10-07 expires: never usage: E [ unknown] (1). Hugo Osvaldo Barrera [ revoked] (2) Hugo Osvaldo Barrera [ revoked] (3) Hugo Osvaldo Barrera [ revoked] (4) Hugo Osvaldo Barrera (Work Account) gpg> save Key not changed so no update needed. $ gpg --list-secret-keys gpg: checking the trustdb gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u /home/hugo/.gnupg/pubring.kbx ----------------------------- sec rsa4096/2B98C0CD 2014-10-22 uid [ultimate] Hugo Osvaldo Barrera ssb rsa4096/F6AB63C3 2014-10-22 sec rsa2048/1BFBED44 2010-10-07 uid [ unknown] Hugo Osvaldo Barrera ssb rsa2048/28C61189 2010-10-07 I don't think I'm doing something wrong, but: Am I? Did I miss something? Thanks, -- Hugo Osvaldo Barrera A: Because we read from top to bottom, left to right. Q: Why should I start my reply below the quoted text? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From mail at rainerkeller.de Sat Feb 7 21:45:20 2015 From: mail at rainerkeller.de (Rainer Keller) Date: Sat, 07 Feb 2015 21:45:20 +0100 Subject: How to reset the PIN counter In-Reply-To: References: <1963543.HiQhT7D78u@green.grummel.netz> Message-ID: <17819177.UQ9mO5IL47@green.grummel.netz> > I save the reset code block to a text file ("reset.txt") and then run " > gpg-connect-agent < reset.txt". Remove and reinsert the card and it should > be back to factory defaults. Unfortunatly this seemed to brick the card. "gpg: OpenPGP card not available: Not supported" Gnupg does not detect the card anymore. Regards, Rainer From duplicitymailinglist at mail.ru Sat Feb 7 22:35:24 2015 From: duplicitymailinglist at mail.ru (Duplicity Mailing List) Date: Sat, 07 Feb 2015 21:35:24 +0000 Subject: How to reset the PIN counter In-Reply-To: <17819177.UQ9mO5IL47@green.grummel.netz> References: <1963543.HiQhT7D78u@green.grummel.netz> <17819177.UQ9mO5IL47@green.grummel.netz> Message-ID: <54D6851C.9010702@mail.ru> On 07/02/15 20:45, Rainer Keller wrote: >> I save the reset code block to a text file ("reset.txt") and then run " >> gpg-connect-agent < reset.txt". Remove and reinsert the card and it should >> be back to factory defaults. > Unfortunatly this seemed to brick the card. > "gpg: OpenPGP card not available: Not supported" > Gnupg does not detect the card anymore. > > Regards, > Rainer What version was your card? It should work fine on a 2.0 smart card, but, it's by design made to brick 1.X cards. Pete probably should have warned you about this first. Also, if it was a 2.0 smart card, what key was it? From pete at heypete.com Sun Feb 8 07:35:44 2015 From: pete at heypete.com (Pete Stephenson) Date: Sun, 8 Feb 2015 07:35:44 +0100 Subject: How to reset the PIN counter In-Reply-To: <54D6851C.9010702@mail.ru> References: <1963543.HiQhT7D78u@green.grummel.netz> <17819177.UQ9mO5IL47@green.grummel.netz> <54D6851C.9010702@mail.ru> Message-ID: On Feb 7, 2015 10:36 PM, "Duplicity Mailing List" < duplicitymailinglist at mail.ru> wrote: > > On 07/02/15 20:45, Rainer Keller wrote: > >> I save the reset code block to a text file ("reset.txt") and then run " > >> gpg-connect-agent < reset.txt". Remove and reinsert the card and it should > >> be back to factory defaults. > > Unfortunatly this seemed to brick the card. > > "gpg: OpenPGP card not available: Not supported" > > Gnupg does not detect the card anymore. > > > > Regards, > > Rainer > > What version was your card? It should work fine on a 2.0 smart card, > but, it's by design made to brick 1.X cards. Pete probably should have > warned you about this first. In retrospect I should have, but the output of gpg --card-edit Rainer posted showed he was using a version 2 card so it should be ok. My apologies for any confusion. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at rainerkeller.de Sun Feb 8 09:45:53 2015 From: mail at rainerkeller.de (Rainer Keller) Date: Sun, 08 Feb 2015 09:45:53 +0100 Subject: How to reset the PIN counter In-Reply-To: <54D6851C.9010702@mail.ru> References: <1963543.HiQhT7D78u@green.grummel.netz> <17819177.UQ9mO5IL47@green.grummel.netz> <54D6851C.9010702@mail.ru> Message-ID: <3390254.Wk3AdmiV33@green.grummel.netz> > What version was your card? It should work fine on a 2.0 smart card, > but, it's by design made to brick 1.X cards. It should be a 2.0 card. At least I bought is as such. > Also, if it was a 2.0 smart card, what key was it? What do you mean with "key"? I had a 4096bit authentication key on the card, the other slots were empty. The output is included in my first mail. From peter at digitalbrains.com Sun Feb 8 09:51:33 2015 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 08 Feb 2015 09:51:33 +0100 Subject: Key keeps showing unknown trust In-Reply-To: <20150207194314.GA1381@athena.barrera.io> References: <20150207194314.GA1381@athena.barrera.io> Message-ID: <54D72395.7030307@digitalbrains.com> On 07/02/15 20:43, Hugo Osvaldo Barrera wrote: > I don't think I'm doing something wrong, but: Am I? Did I miss something? Yes, you have interpreted it wrong. What you are doing now is this statement: "I trust Hugo Osvaldo Barrera checks identities carefully before signing keys. However, I do not know whether 1BFBED44 is really his key". So the statement doesn't actually get you anywhere. And the fact that you're speaking in the third person about yourself is lost on GnuPG, which doesn't know that. Since it is your own key (right?), what you want here is "trust: ultimate". Normally, what makes a key valid is that it is signed by a /trusted/ key. Note the difference: key B is /valid/ because key A, which is /trusted/, signed it. But this has to start out somewhere. This is usually your own key(s), which are assigned "ultimate" trust, which means: this key is also valid, even though it is not necessarily signed by a trusted key. The option to use for your /own/ keys therefore, is usually "5 = I trust ultimately". And when you are convinced someone is actually the legitimate owner of a key, you would sign their key. Whether you would assign them any trust depends on whether you think this person is trustworthy enough to rely on their signatures on other people's keys. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From peter at digitalbrains.com Sun Feb 8 10:40:56 2015 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 08 Feb 2015 10:40:56 +0100 Subject: How to reset the PIN counter In-Reply-To: <17819177.UQ9mO5IL47@green.grummel.netz> References: <1963543.HiQhT7D78u@green.grummel.netz> <17819177.UQ9mO5IL47@green.grummel.netz> Message-ID: <54D72F28.9070403@digitalbrains.com> On 07/02/15 21:45, Rainer Keller wrote: > Unfortunatly this seemed to brick the card. > "gpg: OpenPGP card not available: Not supported" > Gnupg does not detect the card anymore. Fortunately, your card is not bricked. But GnuPG can't access it anymore. If you have a recent enough version of GnuPG, there is a new command that helps in getting low-level access to the card even though opening the OpenPGP application on the card no longer works: scd serialno undefined. This gpg-connect-agent script ought to get your card back on its feet: /hex scd serialno undefined scd apdu 00 a4 04 00 06 d2 76 00 01 24 01 scd apdu 00 44 00 00 scd apdu 00 e6 00 00 If it doesn't, you could try swapping the order of the last two lines. There's a bug in the OpenPGP card related to those two commands, but it was fixed in a minor revision to the card, so it depends on your specific card. It's not clear to me how this works out for the exact commands to send. For me it looked like this (with an intentionally "bricked" test card): $ gpg-connect-agent > /hex > scd serialno undefined S SERIALNO FF7F00 0 OK > scd apdu 00 a4 04 00 06 d2 76 00 01 24 01 D[0000] 62 85 b. OK > scd apdu 00 44 00 00 D[0000] 90 00 .. OK > scd apdu 00 e6 00 00 D[0000] 69 85 i. OK If you don't get a 90 00 back with the second to last command, that would probably be an indicator you need to swap the two. In any case, I'm interested in what it outputs for you, as it helps me learn about the OpenPGP card. The two bytes returned for every command sent are a status code, and they give information on what the card thought of the command. HTH, Peter. PS: For people who are interested in what it all *means*: the large-ish APDU I send first is the command to select the OpenPGP application on the card; it's exactly the same as GnuPG normally does. However, the card returns an error 62 85 "Selected file in termination state", and GnuPG is not so happy about that, so it won't go on after that. We, however, know this is as expected and simply continue with the following commands. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From kristian.fiskerstrand at sumptuouscapital.com Sun Feb 8 14:14:36 2015 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Sun, 08 Feb 2015 14:14:36 +0100 Subject: HKPS issue with static build of gnupg 2.0.26: checking whether curl is usable: no Message-ID: <54D7613C.4070700@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Dear list, A Gentoo user has run into an issue[0] with using HKPS from a static build of GnuPG 2.0.26. I seem to be able to replicate this behavior in a virtual machine, but my debugging seems to stop around the configure detection of curl being usable. As seen in the configure output in [1], curl is detected but determined to not be usable: checking for curl-config... /usr/bin/curl-config checking for the version of libcurl... 7.39.0 checking for libcurl >= version 7.10... yes checking whether libcurl is usable... no ^^^^^ I see this same behavior in my VM for multiple versions of curl; Using shared linking everything works, but as soon as I try to use static linking, curl is reported as unusable and gnupg reverts back to using curl-shim, not supporting HKPS. Any ideas as to why libcurl is not reported as usable by gnupg despite having been built to support static linking? gpg --keyserver hkps://hkps.pool.sks-keyservers.net - --keyserver-options verbose,debug --search foo gpgkeys: HTTP search error 1: unsupported protocol gpgkeys: curl version = GnuPG curl-shim .. Some info about curl: curl-config --version libcurl 7.40.0 curl-config --static-libs /usr/lib64/libcurl.a -Wl,-O1 -Wl,--as-needed -lcares -lidn -lssl - -lcrypto -lssl -lcrypto -llber -lldap -lz curl-config --protocols # (filtered list) HTTP HTTPS LDAP LDAPS curl-config --features SSL IPv6 UnixSockets libz AsynchDNS IDN NTLM NTLM_WB TLS-SRP References: [0] https://bugs.gentoo.org/show_bug.cgi?id=538852 [1] https://538852.bugs.gentoo.org/attachment.cgi?id=395722 - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- Primum ego, tum ego, deinde ego First I, then I, thereafter I. -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJU12E4AAoJEP7VAChXwav6T0UH/RKZOtHyq3izDwJ5XN5BFOVi Fg5YSj8itEY47c3ODrW9V1s0nrYxKdB73NVZ9WtZb1nyTNwWW37/yGN/izQswtXe GoxfXtAIFIjjL+EjDV73ic+r7toMNRx6nqAZbEjwdiVARXSvYqCTFKILpI4JrWN6 It8ZHWXSOgMTye92JqhxdmTh/eqphE88sWOBz/MzXE8Oyzi6aEP69vlomP38tCsS LdVI35lPVS2la/0K8qnhFx3JOlTVsbS7lvtmV/y1Y3MQcHqe9QFFFKzaWmmY2Kig 6UhTVW7BqVm9f5BLZRPbdD2ys6OR/OXqlYcmisjxuSNM3IRNbpaIm1Y1amT5Nok= =BUFs -----END PGP SIGNATURE----- From mail at rainerkeller.de Sun Feb 8 18:41:15 2015 From: mail at rainerkeller.de (Rainer Keller) Date: Sun, 08 Feb 2015 18:41:15 +0100 Subject: gpg-agent does not authenticate ssh connections Message-ID: <2120060.4oWDU2pi9h@green.grummel.netz> Hello, I am trying to use gnupg smart card for ssh connections. According to the error message gpg-agent is unable to sign using the card: > ssh user at server > Agent admitted failure to sign using the key. > Permission denied (publickey,keyboard-interactive). In .gnupg/sshcontrol I have added the correct keygrip and "ssh-add -l" shows the right key: > 4096 XX:XX:XX cardno:XXXX (RSA) The pinentry dialog also appears. I started the gpg-agent with logging enabled which shows some errors when trying to use ssh: > gpg-agent ~/.gnupg/sshcontrol:1: key 'XXXX' skipped: No such file or directory > gpg-agent DBG: detected card with S/N XXXX > gpg-agent smartcard signing failed: Bad PIN It sounds like the PIN entered was wrong, but I am sure it is correct. The PIN retry counters are still at 3. Application ID ...: XXX Version ..........: 2.0 Manufacturer .....: ZeitControl Serial number ....: XXX Name of cardholder: Rainer Keller Language prefs ...: de Sex ..............: male URL of public key : [not set] Login data .......: [not set] Signature PIN ....: forced Key attributes ...: 2048R 2048R 4096R Max. PIN lengths .: 32 32 32 PIN retry counter : 3 0 3 Signature counter : 0 Signature key ....: [none] Encryption key....: [none] Authentication key: XXXX created ....: XXX Any idea why gpg-agent assumes the PIN is wrong? Regards, Rainer From mail at rainerkeller.de Sun Feb 8 18:26:52 2015 From: mail at rainerkeller.de (Rainer Keller) Date: Sun, 08 Feb 2015 18:26:52 +0100 Subject: How to reset the PIN counter In-Reply-To: <54D72F28.9070403@digitalbrains.com> References: <1963543.HiQhT7D78u@green.grummel.netz> <17819177.UQ9mO5IL47@green.grummel.netz> <54D72F28.9070403@digitalbrains.com> Message-ID: <3904797.SLEamXGvZj@green.grummel.netz> > This gpg-connect-agent script ought to get your card back on its feet. Thanks very much. It worked and my card seems to operate again. Just out of curiosity is there a way to reset the PIN user counter without resetting the card? From hugo at barrera.io Sun Feb 8 20:06:52 2015 From: hugo at barrera.io (Hugo Osvaldo Barrera) Date: Sun, 8 Feb 2015 16:06:52 -0300 Subject: Revoked keys and past signatures Message-ID: <20150208190652.GA9440@athena.barrera.io> I revoked my gpg key yesterday because it was superceded by a newer one. Now recepients of my messages during the last few years are getting a warning that the key is invalid - even though it was perfectly valid the date the messages were signed: gpg: Signature made 2015-02-05T19:28:21 ART using RSA key ID 1BFBED44 gpg: Good signature from "Hugo Osvaldo Barrera " [unknown] gpg: WARNING: This key has been revoked by its owner! gpg: This could mean that the signature is forged. gpg: reason for revocation: Key is superseded gpg: revocation comment: Superseded by 0x28C61189. gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: AA73 5C33 E081 E0D2 C945 5B12 873C F207 1BFB ED44 Did I do something wrong? Isn't the revokation date compared to the signature date? Does this mean that if someone revokes their key today, *all past* signatures become invalid? -- Hugo Osvaldo Barrera A: Because we read from top to bottom, left to right. Q: Why should I start my reply below the quoted text? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From hugo at barrera.io Mon Feb 9 10:24:50 2015 From: hugo at barrera.io (Hugo Osvaldo Barrera) Date: Mon, 9 Feb 2015 06:24:50 -0300 Subject: Key keeps showing unknown trust In-Reply-To: <54D873C7.50007@mailbox.org> References: <20150207194314.GA1381@athena.barrera.io> <54D873C7.50007@mailbox.org> Message-ID: <20150209092450.GA12071@athena.barrera.io> On 2015-02-09 09:45, Stephan Beck wrote: > Hi, Osvaldo, > > Am 07.02.2015 um 20:43 schrieb Hugo Osvaldo Barrera: > > Hi. > > > > I'm trying to edit one of my key's trust, but it keeps showing unknown even > > after changing it: > > > [...] > > > $ gpg --list-secret-keys > > gpg: checking the trustdb > > gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model > > gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u > > /home/hugo/.gnupg/pubring.kbx > > ----------------------------- > [...] > > I wonder why the --list-secret-keys command option, in your case, outputs a > storage location called pubring.kbx. It is supposed to be ~/.gnupg/secring.gpg, > isn't it? > > Kind regards > > Stephan > > Only on older versions of gpg, according to the man pages: ~/.gnupg/secring.gpg A secret keyring as used by GnuPG versions before 2.1. It is not used by GnuPG 2.1 and later. Cheers, -- Hugo Osvaldo Barrera A: Because we read from top to bottom, left to right. Q: Why should I start my reply below the quoted text? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From hugo at barrera.io Mon Feb 9 10:27:26 2015 From: hugo at barrera.io (Hugo Osvaldo Barrera) Date: Mon, 9 Feb 2015 06:27:26 -0300 Subject: Key keeps showing unknown trust In-Reply-To: <54D72395.7030307@digitalbrains.com> References: <20150207194314.GA1381@athena.barrera.io> <54D72395.7030307@digitalbrains.com> Message-ID: <20150209092726.GB12071@athena.barrera.io> On 2015-02-08 09:51, Peter Lebbing wrote: > On 07/02/15 20:43, Hugo Osvaldo Barrera wrote: > > I don't think I'm doing something wrong, but: Am I? Did I miss something? > > Yes, you have interpreted it wrong. What you are doing now is this statement: > > "I trust Hugo Osvaldo Barrera checks identities carefully before signing keys. > However, I do not know whether 1BFBED44 is really his key". So the statement > doesn't actually get you anywhere. And the fact that you're speaking in the > third person about yourself is lost on GnuPG, which doesn't know that. > > Since it is your own key (right?), what you want here is "trust: ultimate". > > Normally, what makes a key valid is that it is signed by a /trusted/ key. Note > the difference: key B is /valid/ because key A, which is /trusted/, signed it. > But this has to start out somewhere. This is usually your own key(s), which > are assigned "ultimate" trust, which means: this key is also valid, even > though it is not necessarily signed by a trusted key. > > The option to use for your /own/ keys therefore, is usually "5 = I trust > ultimately". And when you are convinced someone is actually the legitimate > owner of a key, you would sign their key. Whether you would assign them any > trust depends on whether you think this person is trustworthy enough to rely > on their signatures on other people's keys. > > HTH, > > Peter. > > -- > I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. > You can send me encrypted mail if you want some privacy. > My key is available at Yes, you're right in that sense. I just wanted to put it in slightly less trust so as to recognize it more easily. I don't want to sign my *old* key with my new one either. I'll have to rethink how I organize myself a bit in that aspect. However, the issue at hand is another: even if I set a trust of 5 (ultimate), the next screen still shows it as unknown and that doesn't change. If I delete my keyring, and re-import both secret keys, only the first of both that I set to ultimate is actually shown as ultimate, and the second is always shown as unknown. -- Hugo Osvaldo Barrera A: Because we read from top to bottom, left to right. Q: Why should I start my reply below the quoted text? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From niobos at dest-unreach.be Mon Feb 9 11:07:35 2015 From: niobos at dest-unreach.be (Niobos) Date: Mon, 09 Feb 2015 11:07:35 +0100 Subject: Pin-pad on SPR332 smartcard reader does not work under OSX Message-ID: <54D886E7.3060007@dest-unreach.be> Hi, I'm trying to get my smartcard to work under Mac OS X (OSX 10.9, Mavricks) with GnuPG 2.1.1. It mostly works out of the box, but there is one minor issue that I can't get to work: the pinpad on my SmartCard reader (SPR332). (Pin is asked by the pinentry program, not by the card reader itself) I've tried to debug this myself. This is what I found: I can see scdaemon doing pcsc_vendor_specific_init(), but failing: > pcsc_vendor_specific_init: GET_FEATURE_REQUEST failed: 65538 How should I proceed to get this to work? Is it even supposed to work under OSX? What additional info do you need? Additional info: Card reader & card work fine under Linux; Card is the ZeitControl card from g10code.com Thanks in advance, Niobos From peter at digitalbrains.com Mon Feb 9 14:20:57 2015 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 09 Feb 2015 14:20:57 +0100 Subject: Key keeps showing unknown trust In-Reply-To: <20150209092726.GB12071@athena.barrera.io> References: <20150207194314.GA1381@athena.barrera.io> <54D72395.7030307@digitalbrains.com> <20150209092726.GB12071@athena.barrera.io> Message-ID: <54D8B439.3070709@digitalbrains.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/02/15 10:27, Hugo Osvaldo Barrera wrote: > However, the issue at hand is another: even if I set a trust of 5 > (ultimate), the next screen still shows it as unknown and that doesn't > change. Also not when you quit and edit the key again? It should do a new trust database calculation in between, unless it has been specifically told not to. > If I delete my keyring, and re-import both secret keys, only the first of > both that I set to ultimate is actually shown as ultimate, and the second > is always shown as unknown. Then it might be related to [1] perhaps? I'm not sure, just throwing it out there as a pointer. HTH, Peter. [1] https://bugs.g10code.com/gnupg/issue1794 - -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From peter at digitalbrains.com Mon Feb 9 14:28:19 2015 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 09 Feb 2015 14:28:19 +0100 Subject: Revoked keys and past signatures In-Reply-To: <20150208190652.GA9440@athena.barrera.io> References: <20150208190652.GA9440@athena.barrera.io> Message-ID: <54D8B5F3.7060806@digitalbrains.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/02/15 20:06, Hugo Osvaldo Barrera wrote: > Does this mean that if someone revokes their key today, *all past* > signatures become invalid? I believe so, yes. You should probably have expired it instead, sorry. Suppose it is revoked because someone stole the key; then that person could fake signatures set in the past; faking the time. If GnuPG accepted them because at that time the key wasn't revoked yet, that would create a security issue. And GnuPG, AFAIK, doesn't do anything with the "revocation reason", so it will see all revocations the same. If you haven't uploaded the revocation to a key server, it is possible to have it unrevoked; your correspondents would need to delete their copy of your public key and only after that import your new unrevoked key. Say so if you want me to explain how to surgically alter a key to no longer be revoked. This however doesn't help when it's already on a keyserver; they will still keep it revoked no matter what you do. HTH, Peter. - -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From gniibe at fsij.org Mon Feb 9 14:31:06 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 09 Feb 2015 22:31:06 +0900 Subject: Pin-pad on SPR332 smartcard reader does not work under OSX In-Reply-To: <54D886E7.3060007@dest-unreach.be> References: <54D886E7.3060007@dest-unreach.be> Message-ID: <54D8B69A.90008@fsij.org> On 02/09/2015 07:07 PM, Niobos wrote: > I've tried to debug this myself. This is what I found: > I can see scdaemon doing pcsc_vendor_specific_init(), but failing: > >> pcsc_vendor_specific_init: GET_FEATURE_REQUEST failed: 65538 It means: In order to use pinpad input, scdaemon asked PC/SC service to get code of FEATURE_VERIFY_PIN_DIRECT and FEATURE_MODIFY_PIN_DIRECT, by GET_FEATURE_REQUEST command. But failed. In this point, scdaemon had no way to use pinpad input. > How should I proceed to get this to work? Is it even supposed to work > under OSX? What additional info do you need? I haven't got any report for OS X about pinpad input. I think that scdaemon's apdu.c assumes using PC/SC-lite on OS X. If not, I think that we need to fix the line 248-259 of apdu.c, which defines CM_IOCTL_GET_FEATURE_REQUEST. Could you please check your PC/SC service and version? -- From niobos at dest-unreach.be Mon Feb 9 15:07:22 2015 From: niobos at dest-unreach.be (Niobos) Date: Mon, 09 Feb 2015 15:07:22 +0100 Subject: Pin-pad on SPR332 smartcard reader does not work under OSX In-Reply-To: <54D8B69A.90008@fsij.org> References: <54D886E7.3060007@dest-unreach.be> <54D8B69A.90008@fsij.org> Message-ID: <54D8BF1A.2020108@dest-unreach.be> On 2015-02-09 14:31, NIIBE Yutaka wrote: > On 02/09/2015 07:07 PM, Niobos wrote: >> I've tried to debug this myself. This is what I found: >> I can see scdaemon doing pcsc_vendor_specific_init(), but failing: >> >>> pcsc_vendor_specific_init: GET_FEATURE_REQUEST failed: 65538 > > It means: > In order to use pinpad input, scdaemon asked PC/SC service to get code > of FEATURE_VERIFY_PIN_DIRECT and FEATURE_MODIFY_PIN_DIRECT, by > GET_FEATURE_REQUEST command. But failed. > > In this point, scdaemon had no way to use pinpad input. That is what I guessed it would mean, thank you for confirming that. >> How should I proceed to get this to work? Is it even supposed to work >> under OSX? What additional info do you need? > > I haven't got any report for OS X about pinpad input. > > I think that scdaemon's apdu.c assumes using PC/SC-lite on OS X. > If not, I think that we need to fix the line 248-259 of apdu.c, > which defines CM_IOCTL_GET_FEATURE_REQUEST. > > Could you please check your PC/SC service and version? How should I do that? Here is what I've found so far: % /usr/sbin/pcscd -v PCSC Framework version 1.4.0. Copyright (C) 1999-2002 by David Corcoran . Copyright (C) 2001-2005 by Ludovic Rousseau . Copyright (C) 2003-2004 by Damien Sauveron . Portions Copyright (C) 2000-2007 by Apple Inc. Report bugs to . % readlink /usr/libexec/SmartCardServices//drivers/ifd-ccid.bundle/Contents/MacOS/libccid.dylib libccid.dylib.1.3.11 Niobos From gniibe at fsij.org Mon Feb 9 15:33:08 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 09 Feb 2015 23:33:08 +0900 Subject: Pin-pad on SPR332 smartcard reader does not work under OSX In-Reply-To: <54D8BF1A.2020108@dest-unreach.be> References: <54D886E7.3060007@dest-unreach.be> <54D8B69A.90008@fsij.org> <54D8BF1A.2020108@dest-unreach.be> Message-ID: <54D8C524.60209@fsij.org> On 02/09/2015 11:07 PM, Niobos wrote: > How should I do that? Here is what I've found so far: > > % /usr/sbin/pcscd -v > PCSC Framework version 1.4.0. > Copyright (C) 1999-2002 by David Corcoran . > Copyright (C) 2001-2005 by Ludovic Rousseau . > Copyright (C) 2003-2004 by Damien Sauveron . > Portions Copyright (C) 2000-2007 by Apple Inc. > Report bugs to . Thanks for the information. In case of GNU/Linux, we have header files for PC/SC. In those files, we have definitions like: https://sources.debian.net/src/pcsc-lite/1.8.13-1/src/PCSC/reader.h/#L120 https://sources.debian.net/src/pcsc-lite/1.8.13-1/src/PCSC/reader.h/#L125 In gnupg/scd/apdu.c, we use that value (the reason not to include the file is avoiding build dependency). IIUC, the value would be different in OS X's PCSC Framework, or it's not supported. -- From matthew.garman at gmail.com Mon Feb 9 15:51:51 2015 From: matthew.garman at gmail.com (Matt Garman) Date: Mon, 9 Feb 2015 08:51:51 -0600 Subject: pinentry-curses unusable with gpg-agent --no-detach In-Reply-To: References: Message-ID: On Fri, Feb 6, 2015 at 12:54 AM, Ciprian Dorin Craciun wrote: > Welcome to my worst nightmare: trying to make GnuPG agent (and for > that matter the SSH agent) runnable in the foreground. (My purpose > was to run it under a process supervisor like `runit` or `s6`, but > regardless...) > > Short answer: you can't convince any of these agents to behave and > run in the foreground. Have you tried the --no-detach option? That seems to be similar to your --daemon-fg option. Also, what do you mean by "behave"? With the exception of the pinentry-curses issue I described, all my other use-cases appear to work OK. Our workaround for that is to just require X so that a graphical pinentry will work. Not ideal, but at least we can get this going in the meantime. From niobos at dest-unreach.be Mon Feb 9 16:25:39 2015 From: niobos at dest-unreach.be (Niobos) Date: Mon, 09 Feb 2015 16:25:39 +0100 Subject: Pin-pad on SPR332 smartcard reader does not work under OSX In-Reply-To: <54D8C524.60209@fsij.org> References: <54D886E7.3060007@dest-unreach.be> <54D8B69A.90008@fsij.org> <54D8BF1A.2020108@dest-unreach.be> <54D8C524.60209@fsij.org> Message-ID: <54D8D173.8020605@dest-unreach.be> On 2015-02-09 15:33, NIIBE Yutaka wrote: > On 02/09/2015 11:07 PM, Niobos wrote: >> How should I do that? Here is what I've found so far: >> >> % /usr/sbin/pcscd -v >> PCSC Framework version 1.4.0. >> Copyright (C) 1999-2002 by David Corcoran . >> Copyright (C) 2001-2005 by Ludovic Rousseau . >> Copyright (C) 2003-2004 by Damien Sauveron . >> Portions Copyright (C) 2000-2007 by Apple Inc. >> Report bugs to . > > Thanks for the information. > > In case of GNU/Linux, we have header files for PC/SC. In those files, > we have definitions like: > > https://sources.debian.net/src/pcsc-lite/1.8.13-1/src/PCSC/reader.h/#L120 > https://sources.debian.net/src/pcsc-lite/1.8.13-1/src/PCSC/reader.h/#L125 > > In gnupg/scd/apdu.c, we use that value (the reason not to include the > file is avoiding build dependency). > > IIUC, the value would be different in OS X's PCSC Framework, or it's > not supported. I have searched my system for reader.h, but didn't find that file. Next, I grepped through the better part of my filesystem (/usr, /System, /Library) for GET_FEATURE_REQUEST, and also came up empty. I have found a website [1] which might mean more to you that it does to me. From what I understand, OSX uses the same constants that GNU/Linux: > #define SCARD_CTL_CODE(code) (0x42000000 + (code)) > #define CM_IOCTL_GET_FEATURE_REQUEST SCARD_CTL_CODE(3400) How can I debug this further? N [1] http://ludovicrousseau.blogspot.be/2013_10_01_archive.html From hugo at barrera.io Mon Feb 9 18:54:33 2015 From: hugo at barrera.io (Hugo Osvaldo Barrera) Date: Mon, 9 Feb 2015 14:54:33 -0300 Subject: Revoked keys and past signatures In-Reply-To: <54D8B5F3.7060806@digitalbrains.com> References: <20150208190652.GA9440@athena.barrera.io> <54D8B5F3.7060806@digitalbrains.com> Message-ID: <20150209175433.GA27378@athena.barrera.io> On 2015-02-09 14:28, Peter Lebbing wrote: > On 08/02/15 20:06, Hugo Osvaldo Barrera wrote: > > Does this mean that if someone revokes their key today, *all past* > > signatures become invalid? > > I believe so, yes. You should probably have expired it instead, sorry. > > Suppose it is revoked because someone stole the key; then that person could > fake signatures set in the past; faking the time. If GnuPG accepted them > because at that time the key wasn't revoked yet, that would create a security > issue. > > And GnuPG, AFAIK, doesn't do anything with the "revocation reason", so it will > see all revocations the same. > > If you haven't uploaded the revocation to a key server, it is possible to have > it unrevoked; your correspondents would need to delete their copy of your > public key and only after that import your new unrevoked key. Say so if you > want me to explain how to surgically alter a key to no longer be revoked. This > however doesn't help when it's already on a keyserver; they will still keep it > revoked no matter what you do. > > HTH, > > Peter. > > -- > I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. > You can send me encrypted mail if you want some privacy. > My key is available at Oh, that was informative. It's a shame, but I seem to have asked too late and this is already on keyservers. I had not thought that the time could just be forged if it had been stolen. Out of curiosity: is the revocation reason even saved? Would it be possible for gpg to actually use it in future? Thanks -- Hugo Osvaldo Barrera From wk at gnupg.org Mon Feb 9 20:27:09 2015 From: wk at gnupg.org (Werner Koch) Date: Mon, 09 Feb 2015 20:27:09 +0100 Subject: Some thoughts on working with GnuPG Message-ID: <871tly9982.fsf@vigenere.g10code.de> Hi! Back in October Sm?ri posted an article with the problems he encountered while integrating GnuPG into mailpile. See https://www.mailpile.is/blog/2014-10-07_Some_Thoughts_on_GnuPG.html . I asked him whether I may comment on this over at gnupg-user and with 2.1.0 out of the way I started to draft a response. However, I then figured that 2.1 bug fixes are more important and thus I did not finished that response. Find below what I already wrote. I yanked the text from the browser, thus there may be formatting issues; I also skipped parts which are not relevant for my comments. > support. Financially supporting the GnuPG project is also something > people should be doing. Thanks. > One of the things I'm largely to blame for in Mailpile is the GnuPG > interface. It's a chunk of Python code that executes the GnuPG binary, > tosses information at it, and figures out what to do with the > output. There are lots of libraries for doing this, but after a great > deal of exploration I found that all of the Python libraries that did > this were insufficient for our needs, and the only thing crazier than > manually forking out GnuPG in our situation would be to use the PGPME > library. Well, it is called GPGME and that was what I suggest a year ago. I have not much experience with Python bindings. Back when we did the Freenigma thing (crypto gateway) the folks who were responsible for the code also used direct calls to gpg instead of writing or using a Python binding. I arrived only later to the project. PYME (https://bitbucket.org/malb/pyme) is a SWIG generated interface to GPGME and actively developed. It is not a high level interface which integrates into some Python coding patters but it should be a solid interface to GPGME and thus GnuPG. To make it more visible it would be nice to have it in the GPGME distribution, much like we have a CL binding there too. However, this requires a person who takes care of it (and one feeling responsible for CL would also be appreciated). I definitely can't take care about language bindings in addition to the core GPGME maintenance. > PGPME is almost as confusing and annoying as calling GnuPG directly, but > it also requires us to ship architecture-specific libraries to > everybody, something we're actively avoiding. Having to ship GnuPG That are two issues. Confusing? Obviously I have a different opinion. Architecture specific stuff - sure it is and I would wish we good have a better distribution system. I may have remarked on this in the past already: I wish we can work on a separate GnuPG core system including the core utils and libraries which is installed on Windows at a standard place so it may be used by any software not just GnuPG/Gpg4win/Whatever. That is something we should really improve on. > we're not, so it isn't. On top of that, the available Python bindings > for PGPME are very flaky (last updated in 2008!), and not developed or > maintained by the GnuPG team. I noticed that there is new activity since January this year. Too late for Mailpile, but fixing PYME would probably be better than running in all problems again. GPGME is well maintaoned with new releases hand in hand with new GnuPG features. > As a result, we've got a roughly 1200 line chunk of code in Mailpile > that has the fun and useful task of chatting with GnuPG, and the > stupifyingly annoying task of working around all of GnuPG's > inconsistencies. Your choice ;-) > The problems with GnuPG seem to fall roughly into two broad categories: > inconsistent output structure, inconsistent interfaces. These are both > ripe with surprising behaviour and confusing failure modes. In addition > to these categories, it appears that the larger meta problem is that no > single statement about its problems is going to remain a stable > statement, as these problems disappear and reappear at odd intervals as Marcus (the former GPGME maintainer) and me put a lot of work in APIs which are backward compatible. If there is an occassional bug, it will be fixed - but we need to know about it. > wit, I have over the course of Mailpile development added, removed, and > readded a workaround for a bug, although I think I'm safe to say that it > does not exist post GnuPG 2.1. The comment of that workaround in the > code illustrates the issue perfectly: > > def list_secret_keys(self): > # > # Note: The "." parameter that is passed is to work around a bug > # in GnuPG < 2.1, where --list-secret-keys does not list > # details about key capabilities or expiry for > # --list-secret-keys unless a selector is provided. A dot > # is reasonably likely to appear in all PGP keys, as it is > # a common component of e-mail addresses (and @ does not > # work as a selector for some reason...) This has been reported in 2008 as bug 945. It is in general not a problem because most key managers work by listing the public keys and then check whether a correspondig secret key exists. Actually this is how 2.1 works internally. Fixing this bug is hard becuase thesecring.gpg is not an identical copy of pubring.gpg and thus you will run into a lot of problems even with the missing details fixed. You can't use '@' as a selector because: * - If the username starts with an '@', we assume it is a part of an * email address It must have got lost from the man page - sorry for that. But did I see a bug report? > # BRE: Put --fingerprint at the front and added selectors > # for the worlds MOST POPULAR LETTERS! Yaaay! But the output might still be totally wrong. > First, a word on discoverability. If you ever intend to do anything with > GnuPG, you first need to read and internalize a document aptly titled > DETAILS, which contains a lot of the details about what's going on with or you use GPGME ;-) > GnuPG output. I have dutifully read, memorized chunks of, and bookmarked > this file for posterity. It is immensely helpful. For example, it gives [...] > Now here comes issue the first: this is essentially a colon separated > value (CSV!) data structure, but the data being provided is a) > inconsistent, and b) structured. You mean that there is no top-down design? Right that is how life is. GnuPG stated as a PGP 2 replacement and soon I figured that a machine readable interface is useful to avoid problems with localization and changing output intended for humans. Over the years more and more status information has been added to this interface - in a compatible way. This makes it a bit hard to use but it does not break existing applications. If you can start from scratch, you can do a nice API design but we were not able to do that. > Notably, the first output line says "there is a public key," and the > line after it says "here is a fingerprint." Naively one might think that > these are unrelated. But in fact, all of the lines from the one starting It basically reflects the OpenPGP key structure. You can't put everything into one line - it would be be too hard to debug and extend. > with pub up to the next one that starts with either pub or sec are > actually details about the nature of the public key mentioned in the pub > line - although to make things worse, the fpr lines after the sub lines > refer to the sub line but not the pub line. Confused yet? Sure they do. The fingerprint lines for the subkeys refer to the subkeys - how could that be different? > In reality, parsing this isn't too terrible, but it can only be done in Right, it can be done robustly on the command line using awk. > the handy DETAILS document, my first version of a parser was overly > generic and terribly inefficient, because I kept trying to avoid > inconsistencies. For a reason we put a lot of thought into the GPGME API. Designing an API for a complicated protocol is a tough job. Thus we do not even have an API for key signing - it is just too hard to come up with a generic solution. The idea was to look what people are using and when we see the same pattern over and over we can introduce such an API. > Some of the columns are meaningless for some of the output lines, but > more shockingly, some of the columns are MISSING sometimes. Three of the Missing? They are empty! > columns just simply evaporate if the line is an fpr-type line. On top of > that, there's no really good reason why the fingerprint needs to be a > separate output line rather than just being added in at the right There is one. Computing a fingerprint takes some time and back in 1998 we tried to avoid that overhead and require the use of --fingerprint for including such lines. That is actually PGP 2 design. The fingerprint is also long which would make a "pub" line longer than good for easy debugging. > place. According to the DETAILS file, field 10 is for "User ID" - which > is to say, the name, e-mail address, and comment associated with the > key. Things that the fingerprint emphatically is not. It is a different record type and re-using a field which can be used to search for a key should not be the worst idea. > It this point you'll notice that field 5 contains the Key ID. And for > added pain, the key ID is variously the last 8 or the last 16 nibbles > (hexadecimal digits) of the fingerprint. That is only true for v4 keys. v3 key ids are different - you can't derive the key id from the fingerprint. Sorry, I had to stop commenting here. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Mon Feb 9 20:34:07 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 09 Feb 2015 14:34:07 -0500 Subject: Revoked keys and past signatures In-Reply-To: <20150209175433.GA27378@athena.barrera.io> References: <20150208190652.GA9440@athena.barrera.io> <54D8B5F3.7060806@digitalbrains.com> <20150209175433.GA27378@athena.barrera.io> Message-ID: <87pp9iubf4.fsf@alice.fifthhorseman.net> On Mon 2015-02-09 12:54:33 -0500, Hugo Osvaldo Barrera wrote: > Out of curiosity: is the revocation reason even saved? Would it be possible for > gpg to actually use it in future? Yes, the revocation reason *is* stored in the revocation signature, in the "reason for revocation" subpacket: https://tools.ietf.org/html/rfc4880#section-5.2.3.23 My understanding was that gpg actually does use the revocation reason, but i'm aware that this disagrees with what Peter Lebbing said. i haven't gone ahead and tested this lately. For example, here's an old key of mine that was revoced with the reason "superseded": 0 dkg at alice:~$ gpg --export-options export-minimal --export 0x8974E514A54B6365 | gpg --list-packets | grep revocation\ reason hashed subpkt 29 len 205 (revocation reason 0x01 (This key has been superseded by D21739E9\nMy new key's fingerprint is: 0EE5 BE97 9282 D80B 9F75 40F1 CCD2 ED94 D217 39E9\nPlease see http://fifthhorseman.net/key-transition-2007-06-15.txt for more details.)) 0 dkg at alice:~$ the *date* of your "key was superceded" revocation is relevant, though. Any certifications that claim to have happened after the date of the revocation *should* be considered invalid, whereas revocations that happen before that date (but after the key creation date) should retain their validity. --dkg From kloecker at kde.org Mon Feb 9 21:12:54 2015 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Mon, 9 Feb 2015 21:12:54 +0100 Subject: Some thoughts on working with GnuPG In-Reply-To: <871tly9982.fsf@vigenere.g10code.de> References: <871tly9982.fsf@vigenere.g10code.de> Message-ID: <2777874.sm2CG5gGqI@collossus.ingo-kloecker.de> On Monday 09 February 2015 20:27:09 Werner Koch wrote: > Back in October Sm?ri posted an article with the problems he encountered > while integrating GnuPG into mailpile. See > https://www.mailpile.is/blog/2014-10-07_Some_Thoughts_on_GnuPG.html . > > I asked him whether I may comment on this over at gnupg-user and with > 2.1.0 out of the way I started to draft a response. However, I then > figured that 2.1 bug fixes are more important and thus I did not > finished that response. Find below what I already wrote. I yanked the > text from the browser, thus there may be formatting issues; I also > skipped parts which are not relevant for my comments. > > > One of the things I'm largely to blame for in Mailpile is the GnuPG > > interface. It's a chunk of Python code that executes the GnuPG binary, > > tosses information at it, and figures out what to do with the > > output. There are lots of libraries for doing this, but after a great > > deal of exploration I found that all of the Python libraries that did > > this were insufficient for our needs, and the only thing crazier than > > manually forking out GnuPG in our situation would be to use the PGPME > > library. Hehe. This reminds me of the time when I improved KMail's support for GnuPG, PGP 2, PGP 5 and PGP 6 parsing the human readable output (with LANG=C to avoid breakage due to i18n). But that was more than 15 years ago. I wish there would have been something like gpgme back then. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From gniibe at fsij.org Tue Feb 10 03:02:43 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 10 Feb 2015 11:02:43 +0900 Subject: Pin-pad on SPR332 smartcard reader does not work under OSX In-Reply-To: <54D8D173.8020605@dest-unreach.be> References: <54D886E7.3060007@dest-unreach.be> <54D8B69A.90008@fsij.org> <54D8BF1A.2020108@dest-unreach.be> <54D8C524.60209@fsij.org> <54D8D173.8020605@dest-unreach.be> Message-ID: <54D966C3.4060408@fsij.org> On 02/10/2015 12:25 AM, Niobos wrote: > I have searched my system for reader.h, but didn't find that file. Next, > I grepped through the better part of my filesystem (/usr, /System, > /Library) for GET_FEATURE_REQUEST, and also came up empty. > > I have found a website [1] which might mean more to you that it does to > me. From what I understand, OSX uses the same constants that GNU/Linux: > >> #define SCARD_CTL_CODE(code) (0x42000000 + (code)) >> #define CM_IOCTL_GET_FEATURE_REQUEST SCARD_CTL_CODE(3400) [...] > [1] http://ludovicrousseau.blogspot.be/2013_10_01_archive.html Thank you. It seems for me that pcscd itself is modern and up-to-date on OS X. But, I'm afraid libccid is not so up to date on OS X. And I'm afraid if pinpad input is supported on OS X (not only for your specific card reader, but in general). > How can I debug this further? I think that it is better to ask Apple if pinpad input is supported (and update of libccid, if not). Well, I don't think this is the matter of gnupg-users, but I'm writing as an possible answer. Sorry in advance, if it's irrelevant. My script would help. I wrote a Python script for testing pinpad input with OpenPGPcard using PC/SC service. By using this script, I have enhanced support of some card readers into GnuPG. http://git.gniibe.org/gitweb/?p=gnuk/gnuk.git;a=blob;f=tool/pinpadtest.py The script uses PySCard: http://pyscard.sourceforge.net/ I have no knowledge/experience if PySCard works on OS X, but it works on GNU/Linux. Please note that the purpose of my script is for testing card readers, basically, and it's not for testing PC/SC service or operating system. Usefulness depends. -- From peter at digitalbrains.com Tue Feb 10 12:28:22 2015 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 10 Feb 2015 12:28:22 +0100 Subject: Revoked keys and past signatures In-Reply-To: <87pp9iubf4.fsf@alice.fifthhorseman.net> References: <20150208190652.GA9440@athena.barrera.io> <54D8B5F3.7060806@digitalbrains.com> <20150209175433.GA27378@athena.barrera.io> <87pp9iubf4.fsf@alice.fifthhorseman.net> Message-ID: <54D9EB56.9090200@digitalbrains.com> On 09/02/15 20:34, Daniel Kahn Gillmor wrote: > the *date* of your "key was superceded" revocation is relevant, > though. Any certifications that claim to have happened after the date > of the revocation *should* be considered invalid, whereas revocations > that happen before that date (but after the key creation date) should > retain their validity. (By the way, I'm going to treat data signatures, not certifications, since I believe that was what Hugo reported) I started to think you were right and I was mistaken, but I can reproduce Hugo's scenario: $ gpg2 --verify test.gpg gpg: Signature made Tue 10 Feb 2015 11:53:47 CET using RSA key ID B2F1C0D8 gpg: Good signature from "Testkey 3" [full] Note how verify-options show-uid-validity notes it is fully valid. It is signed by an ultimately trusted key. Now I revoke it: $ gpg2 --edit-key B2F1C0D8 gpg (GnuPG) 2.0.26; Copyright (C) 2013 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Secret key is available. pub 1024R/B2F1C0D8 created: 2014-02-24 expires: 2015-02-17 usage: SC trust: never validity: full sub 1024R/98AC4DFA created: 2014-02-24 expired: 2014-03-03 usage: E [ full ] (1). Testkey 3 gpg> revkey Do you really want to revoke the entire key? (y/N) y Please select the reason for the revocation: 0 = No reason specified 1 = Key has been compromised 2 = Key is superseded 3 = Key is no longer used Q = Cancel Your decision? 2 Enter an optional description; end it with an empty line: > Test revocation > Reason for revocation: Key is superseded Test revocation Is this okay? (y/N) y The following key was revoked on 2015-02-10 by RSA key B2F1C0D8 Testkey 3 pub 1024R/B2F1C0D8 created: 2014-02-24 revoked: 2015-02-10 usage: SC trust: never validity: revoked The following key was revoked on 2015-02-10 by RSA key B2F1C0D8 Testkey 3 sub 1024R/98AC4DFA created: 2014-02-24 revoked: 2015-02-10 usage: E [ revoked] (1). Testkey 3 gpg> save $ Now let's check that signature again: $ gpg2 --verify test.gpg gpg: Signature made Tue 10 Feb 2015 11:53:47 CET using RSA key ID B2F1C0D8 gpg: Good signature from "Testkey 3" [unknown] gpg: WARNING: This key has been revoked by its owner! gpg: This could mean that the signature is forged. gpg: reason for revocation: Key is superseded gpg: revocation comment: Test revocation gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: EFF1 596F 1A68 F708 8699 579D 0815 4E55 B2F1 C0D8 $ The dates for signature and revocation are the same, but the times are reasonably far apart: $ gpg2 --export B2F1C0D8|gpg2 --list-packets :public key packet: version 4, algo 1, created 1393271747, expires 0 pkey[0]: [1024 bits] pkey[1]: [17 bits] keyid: 08154E55B2F1C0D8 :signature packet: algo 1, keyid 08154E55B2F1C0D8 version 4, created 1423566838, md5len 0, sigclass 0x20 digest algo 8, begin of digest 9c c5 hashed subpkt 2 len 4 (sig created 2015-02-10) hashed subpkt 29 len 16 (revocation reason 0x01 (Test revocation)) subpkt 16 len 8 (issuer key ID 08154E55B2F1C0D8) data: [1024 bits] [...] $ date -d "1970-01-01 +1423566838 secs UTC" Tue 10 Feb 12:13:58 CET 2015 $ That's twenty minutes later. I don't see a reason for GnuPG to round to full days when it has resolution down to the second for the times the signatures (data, revocation) are made... is there? The RFC clearly states "key superseded" doesn't invalidate old signatures: > However, if it was merely superseded or retired, old signatures are > still valid. But using GnuPG 2.0.26 on Debian jessie/testing, package 2.0.26-4, I can reproduce signatures becoming invalid... what's going on? Does GnuPG not implement the RFC here or is it a bug? HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From isdtor at gmail.com Tue Feb 10 11:28:49 2015 From: isdtor at gmail.com (isdtor) Date: Tue, 10 Feb 2015 10:28:49 +0000 Subject: HKPS issue with static build of gnupg 2.0.26: checking whether curl is usable: no In-Reply-To: <54D7613C.4070700@sumptuouscapital.com> References: <54D7613C.4070700@sumptuouscapital.com> Message-ID: Not a gnupg problem. If the root cause for this behaviour is the failure to link against libcurl, it's either the openssl ebuild or openssl's own build system. I suspect the latter ... # equery u openssl [ Legend : U - final flag setting for installation] [ : I - package is installed with flag ] [ Colors : set, unset ] * Found these USE flags for dev-libs/openssl-1.0.1k: U I - - bindist : Disable EC/RC5 algorithms (as they seem to be patented) -- note: changes the ABI - - gmp : Add support for dev-libs/gmp (GNU MP library) - - kerberos : Add kerberos support - - rfc3779 : Enable support for RFC 3779 (X.509 Extensions for IP Addresses and AS Identifiers) + + static-libs : Build static versions of dynamic libraries as well - - test : Workaround to pull in packages needed to run with FEATURES=test. Portage-2.1.2 handles this internally, so don't set it in make.conf/package.use anymore + + tls-heartbeat : Enable the Heartbeat Extension in TLS and DTLS - - vanilla : Do not add extra patches which change default behaviour; DO NOT USE THIS ON A GLOBAL SCALE as the severity of the meaning changes drastically + + zlib : Add support for zlib (de)compression # gnupg ebuild config.log: ... configure:9593: x86_64-pc-linux-gnu-gcc -o conftest -O2 -march=native -pipe -fomit-frame-pointer -Wl,-O1 -Wl,--as-needed -static conftest.c -lcurl -lssl -lcrypto -lssl -lcrypto -lz >&5 /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64/libcurl.a(libcurl_la-netrc.o): In function `Curl_parsenetrc': (.text+0x3b1): warning: Using 'getpwuid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64/libcurl.a(libcurl_la-curl_addrinfo.o): In function `Curl_getaddrinfo_ex': (.text+0x6e): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64/libcrypto.a(dso_dlfcn.o): In function `dlfcn_globallookup': (.text+0x11): undefined reference to `dlopen' /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64/libcrypto.a(dso_dlfcn.o): In function `dlfcn_globallookup': (.text+0x24): undefined reference to `dlsym' /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64/libcrypto.a(dso_dlfcn.o): In function `dlfcn_globallookup': (.text+0x2f): undefined reference to `dlclose' /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64/libcrypto.a(dso_dlfcn.o): In function `dlfcn_bind_func': (.text+0x334): undefined reference to `dlsym' /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64/libcrypto.a(dso_dlfcn.o): In function `dlfcn_bind_func': (.text+0x3f2): undefined reference to `dlerror' /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64/libcrypto.a(dso_dlfcn.o): In function `dlfcn_bind_var': (.text+0x464): undefined reference to `dlsym' /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64/libcrypto.a(dso_dlfcn.o): In function `dlfcn_bind_var': (.text+0x522): undefined reference to `dlerror' /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64/libcrypto.a(dso_dlfcn.o): In function `dlfcn_load': (.text+0x589): undefined reference to `dlopen' /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64/libcrypto.a(dso_dlfcn.o): In function `dlfcn_load': (.text+0x5ed): undefined reference to `dlclose' /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64/libcrypto.a(dso_dlfcn.o): In function `dlfcn_load': (.text+0x625): undefined reference to `dlerror' /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64/libcrypto.a(dso_dlfcn.o): In function `dlfcn_pathbyaddr': (.text+0x6b1): undefined reference to `dladdr' /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64/libcrypto.a(dso_dlfcn.o): In function `dlfcn_pathbyaddr': (.text+0x711): undefined reference to `dlerror' /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64/libcrypto.a(dso_dlfcn.o): In function `dlfcn_unload': (.text+0x772): undefined reference to `dlclose' collect2: error: ld returned 1 exit status ... From hugo at barrera.io Tue Feb 10 12:38:39 2015 From: hugo at barrera.io (Hugo Osvaldo Barrera) Date: Tue, 10 Feb 2015 08:38:39 -0300 Subject: Revoked keys and past signatures In-Reply-To: <54D9EB56.9090200@digitalbrains.com> References: <20150208190652.GA9440@athena.barrera.io> <54D8B5F3.7060806@digitalbrains.com> <20150209175433.GA27378@athena.barrera.io> <87pp9iubf4.fsf@alice.fifthhorseman.net> <54D9EB56.9090200@digitalbrains.com> Message-ID: <20150210113839.GA23225@athena.barrera.io> On 2015-02-10 12:28, Peter Lebbing wrote: > On 09/02/15 20:34, Daniel Kahn Gillmor wrote: > > the *date* of your "key was superceded" revocation is relevant, > > though. Any certifications that claim to have happened after the date > > of the revocation *should* be considered invalid, whereas revocations > > that happen before that date (but after the key creation date) should > > retain their validity. > > (By the way, I'm going to treat data signatures, not certifications, > since I believe that was what Hugo reported) > > I started to think you were right and I was mistaken, but I can > reproduce Hugo's scenario: > > $ gpg2 --verify test.gpg > gpg: Signature made Tue 10 Feb 2015 11:53:47 CET using RSA key ID B2F1C0D8 > gpg: Good signature from "Testkey 3" [full] > > Note how verify-options show-uid-validity notes it is fully valid. It is > signed by an ultimately trusted key. > > Now I revoke it: > > $ gpg2 --edit-key B2F1C0D8 > gpg (GnuPG) 2.0.26; Copyright (C) 2013 Free Software Foundation, Inc. > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > > Secret key is available. > > pub 1024R/B2F1C0D8 created: 2014-02-24 expires: 2015-02-17 usage: SC > trust: never validity: full > sub 1024R/98AC4DFA created: 2014-02-24 expired: 2014-03-03 usage: E > [ full ] (1). Testkey 3 > > gpg> revkey > Do you really want to revoke the entire key? (y/N) y > Please select the reason for the revocation: > 0 = No reason specified > 1 = Key has been compromised > 2 = Key is superseded > 3 = Key is no longer used > Q = Cancel > Your decision? 2 > Enter an optional description; end it with an empty line: > > Test revocation > > > Reason for revocation: Key is superseded > Test revocation > Is this okay? (y/N) y > > The following key was revoked on 2015-02-10 by RSA key B2F1C0D8 Testkey 3 > pub 1024R/B2F1C0D8 created: 2014-02-24 revoked: 2015-02-10 usage: SC > trust: never validity: revoked > The following key was revoked on 2015-02-10 by RSA key B2F1C0D8 Testkey 3 > sub 1024R/98AC4DFA created: 2014-02-24 revoked: 2015-02-10 usage: E > [ revoked] (1). Testkey 3 > > gpg> save > $ > > Now let's check that signature again: > $ gpg2 --verify test.gpg > gpg: Signature made Tue 10 Feb 2015 11:53:47 CET using RSA key ID B2F1C0D8 > gpg: Good signature from "Testkey 3" [unknown] > gpg: WARNING: This key has been revoked by its owner! > gpg: This could mean that the signature is forged. > gpg: reason for revocation: Key is superseded > gpg: revocation comment: Test revocation > gpg: WARNING: This key is not certified with a trusted signature! > gpg: There is no indication that the signature belongs to the > owner. > Primary key fingerprint: EFF1 596F 1A68 F708 8699 579D 0815 4E55 B2F1 C0D8 > $ > > The dates for signature and revocation are the same, but the times are > reasonably far apart: > $ gpg2 --export B2F1C0D8|gpg2 --list-packets > :public key packet: > version 4, algo 1, created 1393271747, expires 0 > pkey[0]: [1024 bits] > pkey[1]: [17 bits] > keyid: 08154E55B2F1C0D8 > :signature packet: algo 1, keyid 08154E55B2F1C0D8 > version 4, created 1423566838, md5len 0, sigclass 0x20 > digest algo 8, begin of digest 9c c5 > hashed subpkt 2 len 4 (sig created 2015-02-10) > hashed subpkt 29 len 16 (revocation reason 0x01 (Test > revocation)) > subpkt 16 len 8 (issuer key ID 08154E55B2F1C0D8) > data: [1024 bits] > [...] > $ date -d "1970-01-01 +1423566838 secs UTC" > Tue 10 Feb 12:13:58 CET 2015 > $ > > That's twenty minutes later. I don't see a reason for GnuPG to round to > full days when it has resolution down to the second for the times the > signatures (data, revocation) are made... is there? > > The RFC clearly states "key superseded" doesn't invalidate old signatures: > > > However, if it was merely superseded or retired, old signatures are > > still valid. > > But using GnuPG 2.0.26 on Debian jessie/testing, package 2.0.26-4, I can > reproduce signatures becoming invalid... what's going on? Does GnuPG not > implement the RFC here or is it a bug? > > HTH, > > Peter. > > -- > I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. > You can send me encrypted mail if you want some privacy. > My key is available at I haven't read the RFC, so I don't know if something is define in this exact scenario, but it does sound like a bug. I imagine that recipients of all my emails for the past four years now looking at their archives will find that my messages have no valid signature, and that must be slightly disturbing. I'll read the RFC if I have time and see if something specific is defined. Thanks for testing this thuroughly. Also, thanks Daniel for confirming that the reason *is* stored. Cheers, -- Hugo Osvaldo Barrera A: Because we read from top to bottom, left to right. Q: Why should I start my reply below the quoted text? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From kristian.fiskerstrand at sumptuouscapital.com Tue Feb 10 12:52:41 2015 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Tue, 10 Feb 2015 12:52:41 +0100 Subject: Revoked keys and past signatures In-Reply-To: <54D9EB56.9090200@digitalbrains.com> References: <20150208190652.GA9440@athena.barrera.io> <54D8B5F3.7060806@digitalbrains.com> <20150209175433.GA27378@athena.barrera.io> <87pp9iubf4.fsf@alice.fifthhorseman.net> <54D9EB56.9090200@digitalbrains.com> Message-ID: <54D9F109.2090101@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 02/10/2015 12:28 PM, Peter Lebbing wrote: > On 09/02/15 20:34, Daniel Kahn Gillmor wrote: >> the *date* of your "key was superceded" revocation is relevant, >> though. Any certifications that claim to have happened after the >> date of the revocation *should* be considered invalid, whereas >> revocations that happen before that date (but after the key >> creation date) should retain their validity. > ... > > That's twenty minutes later. I don't see a reason for GnuPG to > round to full days when it has resolution down to the second for > the times the signatures (data, revocation) are made... is there? No > > The RFC clearly states "key superseded" doesn't invalidate old > signatures: And it doesn't > >> However, if it was merely superseded or retired, old signatures >> are still valid. > > But using GnuPG 2.0.26 on Debian jessie/testing, package 2.0.26-4, > I can reproduce signatures becoming invalid... what's going on? > Does GnuPG not implement the RFC here or is it a bug? No, the signature is still valid: > $ gpg2 --verify test.gpg gpg: Signature made Tue 10 Feb 2015 > 11:53:47 CET using RSA key ID B2F1C0D8 > gpg: Good signature from "Testkey 3" [unknown] ^^^^^^^^^^^^^^^^^^^^^^ > gpg: WARNING: This key has been revoked by its owner! gpg: > This could mean that the signature is forged. gpg: reason for > revocation: Key is superseded gpg: revocation comment: Test > revocation gpg: WARNING: This key is not certified with a trusted > signature! gpg: There is no indication that the signature > belongs to the owner. Primary key fingerprint: EFF1 596F 1A68 F708 > 8699 579D 0815 4E55 B2F1 C0D8 ... However you have an unknown situation wrt the validity of the key having issued the signature, you get the additional information and you need to make your own considerations as to the validity of the key at the present stage - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- Credo quia absurdum I believe it because it is absurd -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJU2fECAAoJEP7VAChXwav6ou8IAK9zhGomCj7qmpBgo2DOn0BM fLTJXb3iUvDQgzuzYi+UIrj5L+2CaCllSQlFdDkcZfaH0FbT184j39VAhhc73liR VhLqn2kSByi8OQTMjR0A7OdMCKDExgcI98jr5GF4v4KsSnwk61BYnrTtGVb7/h0L kqQwIFxwVSrbxxFouv5nG5dQeAWW26YyDpPmUDTyaF3ANuCeDEtpfE1UrI9NBRMH T6xUoHW45OxkZkodDIbTwT8FpUZpM24d5oYqO+Fmyy7JcNUW8Z+iHhFhtv+6Xvpy dPISOnkXI8hstPrFDmKB8nYleU4vhlf5LEqCcaqcnxNvbczGUPIV+1rjAcJ5+TA= =MCEY -----END PGP SIGNATURE----- From peter at digitalbrains.com Tue Feb 10 13:24:58 2015 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 10 Feb 2015 13:24:58 +0100 Subject: (bug?) Revoked keys and past signatures In-Reply-To: <54D9F109.2090101@sumptuouscapital.com> References: <20150208190652.GA9440@athena.barrera.io> <54D8B5F3.7060806@digitalbrains.com> <20150209175433.GA27378@athena.barrera.io> <87pp9iubf4.fsf@alice.fifthhorseman.net> <54D9EB56.9090200@digitalbrains.com> <54D9F109.2090101@sumptuouscapital.com> Message-ID: <54D9F89A.8070104@digitalbrains.com> On 10/02/15 12:52, Kristian Fiskerstrand wrote: > No, the signature is still valid: > >> $ gpg2 --verify test.gpg gpg: Signature made Tue 10 Feb 2015 >> 11:53:47 CET using RSA key ID > B2F1C0D8 >> gpg: Good signature from "Testkey 3" [unknown] > ^^^^^^^^^^^^^^^^^^^^^^ > In my opinion, the signature might be /good/, but it is not /valid/. A /good/ signature is just as good as any signature from a key you downloaded off the internet. Here's the status-fd output: $ gpg2 --status-fd 1 --verify test.gpg 2>/dev/null [GNUPG:] SIG_ID mIjaz0UJC1cgEmJHXntwKHhdiuI 2015-02-10 1423565627 [GNUPG:] REVKEYSIG 08154E55B2F1C0D8 Testkey 3 [GNUPG:] VALIDSIG EFF1596F1A68F7088699579D08154E55B2F1C0D8 2015-02-10 1423565627 0 4 0 1 8 00 EFF1596F1A68F7088699579D08154E55B2F1C0D8 [GNUPG:] KEYREVOKED [GNUPG:] TRUST_UNDEFINED $ Note that unfortunately 'good' and 'valid' are slightly mixed up, perhaps that's where the confusion comes from. > VALIDSIG > > [ ] > > The signature with the keyid is good. This is the same as > GOODSIG but has the fingerprint as the argument. Both status > lines are emitted for a good signature. [...] What you'd like to see, though, is TRUST_FULLY or better: > TRUST_UNDEFINED > TRUST_NEVER > TRUST_MARGINAL [0 []] > TRUST_FULLY [0 []] > TRUST_ULTIMATE [0 []] > For good signatures one of these status lines are emitted to > indicate the validity of the key used to create the signature. Note how it says /validity of the key/. It's not ownertrust it is talking about![1] >> gpg: WARNING: This key has been revoked by its owner! gpg: >> This could mean that the signature is forged. gpg: reason for >> revocation: Key is superseded gpg: revocation comment: Test >> revocation gpg: WARNING: This key is not certified with a trusted >> signature! This is exactly what a "superseded" or "retired" revocation is /not/. It has not been stolen; the signature could not have been forged. The key /is/ certified with a trusted signature as I've indicated in my previous post. It's just that the key has since been revoked. The RFC clearly says this doesn't invalidate past signatures, but this message is the message you get for an invalid data signature. >> gpg: There is no indication that the signature >> belongs to the owner. No indication that the signature belongs to the owner... the exact same message you get for any invalid key you just got from somewhere. > ... However you have an unknown situation wrt the validity of the key > having issued the signature Why? The key was revoked because it was superseded or has been retired, not because it was stolen or compromised. If you're convinced you're not mistaken, could you please take the time to show me where this data signature from a revoked key is any different than a signature from any random invalid key? Peter. PS: I've tagged the subject line so it stands out more, since it seems like a bug to me. [1] For certifications the terminology "trust" makes sense, for data signatures not so much, in my opinion. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From peter at digitalbrains.com Tue Feb 10 13:30:05 2015 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 10 Feb 2015 13:30:05 +0100 Subject: (bug?) Revoked keys and past signatures In-Reply-To: <54D9F89A.8070104@digitalbrains.com> References: <20150208190652.GA9440@athena.barrera.io> <54D8B5F3.7060806@digitalbrains.com> <20150209175433.GA27378@athena.barrera.io> <87pp9iubf4.fsf@alice.fifthhorseman.net> <54D9EB56.9090200@digitalbrains.com> <54D9F109.2090101@sumptuouscapital.com> <54D9F89A.8070104@digitalbrains.com> Message-ID: <54D9F9CD.9030806@digitalbrains.com> On 10/02/15 13:24, Peter Lebbing wrote: > If you're convinced you're not mistaken, could you please take the time > to show me where this data signature from a revoked key is any different > than a signature from any random invalid key? Quick correction: If you're convinced you're not mistaken, could you please take the time to show me where this data signature from a revoked, but certified key is any different than a signature from any random revoked invalid key? The key difference (heh...) is that the key has been certified with a trusted signature. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From kristian.fiskerstrand at sumptuouscapital.com Tue Feb 10 13:30:28 2015 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Tue, 10 Feb 2015 13:30:28 +0100 Subject: (bug?) Revoked keys and past signatures In-Reply-To: <54D9F89A.8070104@digitalbrains.com> References: <20150208190652.GA9440@athena.barrera.io> <54D8B5F3.7060806@digitalbrains.com> <20150209175433.GA27378@athena.barrera.io> <87pp9iubf4.fsf@alice.fifthhorseman.net> <54D9EB56.9090200@digitalbrains.com> <54D9F109.2090101@sumptuouscapital.com> <54D9F89A.8070104@digitalbrains.com> Message-ID: <54D9F9E4.5050803@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 02/10/2015 01:24 PM, Peter Lebbing wrote: > On 10/02/15 12:52, Kristian Fiskerstrand wrote: >> No, the signature is still valid: >> > > Why? The key was revoked because it was superseded or has been > retired, not because it was stolen or compromised. > Unless you rely on a trusted third party to provide signature stamps, signature dates can be forged. A key revocation should result in immediate questioning of all aspects of the key, as it currently does. - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- Dura necessitas Necessity is harsh -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJU2fndAAoJEP7VAChXwav6LSwH/ihbdKxXt7NneEjwvSnu/HtP DJE1ihJB6z+AGe2Z8LR/YkEuvDKcxPbskmjbkVA7+7f4AX+R4pPeZBdgcpt/9SsL 06GzOeHyjkPS3tvKaJ9jHFJWXg3Vkd2++Q8+Awguh0zp+MrN/Np8b/esDsUHOLs7 qPHt0NCc7NveX8HgcS81dZkV1W6Ke1u4HijVw2TkgNuP7qRDlbTMHbrkcp96FxOq bGzVhwjHpQTEuTMnuBq1KL7hl1iATihfeMg/DtLcRXPiMvYGGSomdj9U1RcfbVCL exVNnwBkNzMXy9NGqtTzmZCXuUbtoP65oHmgz0wFzWftA/N8j2/E2yofcMoDJQQ= =F1PH -----END PGP SIGNATURE----- From peter at digitalbrains.com Tue Feb 10 13:51:10 2015 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 10 Feb 2015 13:51:10 +0100 Subject: (bug?) Revoked keys and past signatures In-Reply-To: <54D9F9E4.5050803@sumptuouscapital.com> References: <20150208190652.GA9440@athena.barrera.io> <54D8B5F3.7060806@digitalbrains.com> <20150209175433.GA27378@athena.barrera.io> <87pp9iubf4.fsf@alice.fifthhorseman.net> <54D9EB56.9090200@digitalbrains.com> <54D9F109.2090101@sumptuouscapital.com> <54D9F89A.8070104@digitalbrains.com> <54D9F9E4.5050803@sumptuouscapital.com> Message-ID: <54D9FEBE.30705@digitalbrains.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/02/15 13:30, Kristian Fiskerstrand wrote: > Unless you rely on a trusted third party to provide signature stamps, > signature dates can be forged. A key revocation should result in immediate > questioning of all aspects of the key, as it currently does. Does GnuPG consciously not follow the RFC here then? Otherwise, what does this mean (RFC 4880 section 5.2.23, Reason for Revocation subpacket): > An implementation SHOULD implement this subpacket, include it in all > revocation signatures, and interpret revocations appropriately. There are > important semantic differences between the reasons, and there are thus > important reasons for revoking signatures. > > If a key has been revoked because of a compromise, all signatures created > by that key are suspect. However, if it was merely superseded or retired, > old signatures are still valid. What is the important semantic difference between "Key is superseded" and "Key material has been compromised", if past signatures are immediately questioned? Peter. PS: Odd turn of the sentence, "there are thus important reasons for revoking signatures." I wonder if they intended "there are thus important reasons for handling the cases differently". - -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From hugo at barrera.io Tue Feb 10 14:37:38 2015 From: hugo at barrera.io (Hugo Osvaldo Barrera) Date: Tue, 10 Feb 2015 10:37:38 -0300 Subject: (bug?) Revoked keys and past signatures In-Reply-To: <54D9F9E4.5050803@sumptuouscapital.com> References: <20150208190652.GA9440@athena.barrera.io> <54D8B5F3.7060806@digitalbrains.com> <20150209175433.GA27378@athena.barrera.io> <87pp9iubf4.fsf@alice.fifthhorseman.net> <54D9EB56.9090200@digitalbrains.com> <54D9F109.2090101@sumptuouscapital.com> <54D9F89A.8070104@digitalbrains.com> <54D9F9E4.5050803@sumptuouscapital.com> Message-ID: <20150210133738.GA15389@athena.barrera.io> On 2015-02-10 13:30, Kristian Fiskerstrand wrote: > On 02/10/2015 01:24 PM, Peter Lebbing wrote: > > On 10/02/15 12:52, Kristian Fiskerstrand wrote: > >> No, the signature is still valid: > >> > > > > > Why? The key was revoked because it was superseded or has been > > retired, not because it was stolen or compromised. > > > > Unless you rely on a trusted third party to provide signature stamps, > signature dates can be forged. A key revocation should result in > immediate questioning of all aspects of the key, as it currently does. > There is no reason to assume that the signature has been forged if the key has not been compromised. Also, I see no reason why I should not be able to assign a trust to a revoked key - I might trust it even if the author revoked it as superseded: $ gpg --edit 1BFBED44 [... info on revoked key ...] gpg> lsign Key is revoked. Unable to sign. I believe the reason matters. I can even sit down with the owner of the key and verify his ID and fingerprint and sign it, meaning "this key belongs to this person, but was superseeded a week ago". If actually influences the validity of anything he signed up to a week ago. -- Hugo Osvaldo Barrera A: Because we read from top to bottom, left to right. Q: Why should I start my reply below the quoted text? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From dkg at fifthhorseman.net Tue Feb 10 19:01:17 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 10 Feb 2015 13:01:17 -0500 Subject: (bug?) Revoked keys and past signatures In-Reply-To: <20150210133738.GA15389@athena.barrera.io> References: <20150208190652.GA9440@athena.barrera.io> <54D8B5F3.7060806@digitalbrains.com> <20150209175433.GA27378@athena.barrera.io> <87pp9iubf4.fsf@alice.fifthhorseman.net> <54D9EB56.9090200@digitalbrains.com> <54D9F109.2090101@sumptuouscapital.com> <54D9F89A.8070104@digitalbrains.com> <54D9F9E4.5050803@sumptuouscapital.com> <20150210133738.GA15389@athena.barrera.io> Message-ID: <87pp9hsl1u.fsf@alice.fifthhorseman.net> On Tue 2015-02-10 08:37:38 -0500, Hugo Osvaldo Barrera wrote: > Also, I see no reason why I should not be able to assign a trust to a revoked > key - I might trust it even if the author revoked it as superseded: > > > $ gpg --edit 1BFBED44 > [... info on revoked key ...] > gpg> lsign > Key is revoked. Unable to sign. fwiw, you said "assign trust" above, but then in your example, tried to do "lsign", which is an entirely different operation from assigning trust. > I believe the reason matters. I can even sit down with the owner of the key and > verify his ID and fingerprint and sign it, meaning "this key belongs to this > person, but was superseeded a week ago". If actually influences the validity of > anything he signed up to a week ago. your certifications (whether local or exportable) themselves have a timestamp in them. It would be silly to certify a key and its user ID after it was revoked by the owner; you'd be claiming "i believe that right now this is the correct key", which is not the case. I understand the semantics of what you're trying to do, but i'm not sure that OpenPGP has syntax to represent it. The closest OpenPGP comes would be to forge a certification yourself from *before* the revocation. e.g. gpg --faked-system-time 20100105T153023 --lsign 1BFBED44 This isn't exactly the same semantics (it says "on January 5 2010 i thought that this key was correct") but it's close. --dkg From mailinglisten at hauke-laging.de Tue Feb 10 19:20:03 2015 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Tue, 10 Feb 2015 19:20:03 +0100 Subject: (bug?) Revoked keys and past signatures In-Reply-To: <87pp9hsl1u.fsf@alice.fifthhorseman.net> References: <20150208190652.GA9440@athena.barrera.io> <20150210133738.GA15389@athena.barrera.io> <87pp9hsl1u.fsf@alice.fifthhorseman.net> Message-ID: <8001197.dhmlAKZbt3@inno> Am Di 10.02.2015, 13:01:17 schrieb Daniel Kahn Gillmor: > > I can even sit down with the owner of > > the key and verify his ID and fingerprint and sign it, meaning > > "this key belongs to this person, but was superseeded a week ago". > > If actually influences the validity of anything he signed up to a > > week ago. I support this attitude. > your certifications (whether local or exportable) themselves have a > timestamp in them. It would be silly to certify a key and its user ID > after it was revoked by the owner; you'd be claiming "i believe that > right now this is the correct key", which is not the case. And who says that this is the statement? The RfC? I think that faking cannot be a good idea in a crypto context. What if the signing key was created after the revocation? What would that look like? It must be possible for people who have only newer keys to make a "the owner of this key is X" statement. > I understand the semantics of what you're trying to do, but i'm not > sure that OpenPGP has syntax to represent it. I don't see any problem with the syntax. The problem is the lack of semantic definition. The next OpenPGP version should address that at any rate. Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 603 bytes Desc: This is a digitally signed message part. URL: From philip.jackson at nordnet.fr Tue Feb 10 20:09:59 2015 From: philip.jackson at nordnet.fr (Philip Jackson) Date: Tue, 10 Feb 2015 20:09:59 +0100 Subject: moving up from 2.0.26 to 2.1.1 Message-ID: <54DA5787.3070903@nordnet.fr> I've been a linux user for less than a year and the only configure/make/install I've done is for 2.0.26 and its dependencies (when I couldn't get the distro supplied package 2.0.22 to work). Now when I look at the dependencies for gnupg 2.1.1, I see that I need to upgrade libassuan to 2.2.0, libgpg-error to 1.17 and gpgme to 1.5.3. The first question I have is whether it is necessary to remove the versions I already have prior to installing the later versions ? I suppose simply installing the later version will not automatically replace the previous version ? Up to present, all updates to software have been done by the distro's 'Software updater' and this has not made me any the wiser on the procedure for manual updating. Is there a risk of having a sedimentary layer of unwanted an outdated versions accumulate on disk when updating manually ? Any and all advice will be gratefully accepted, thank you. Philip -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From brian at minton.name Tue Feb 10 21:56:57 2015 From: brian at minton.name (Brian Minton) Date: Tue, 10 Feb 2015 15:56:57 -0500 Subject: status of ed25519 draft Message-ID: <54DA7099.9030909@minton.name> Is there any way to see the progress of the IETF working group on the draft Werner has submitted? I noticed that the draft expires in May. In particular, I would like to know if 22 is going to be the IANA standardized Public-Key Algorithm number. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 213 bytes Desc: OpenPGP digital signature URL: From kloecker at kde.org Tue Feb 10 22:03:56 2015 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Tue, 10 Feb 2015 22:03:56 +0100 Subject: (bug?) Revoked keys and past signatures In-Reply-To: <20150210133738.GA15389@athena.barrera.io> References: <20150208190652.GA9440@athena.barrera.io> <54D9F9E4.5050803@sumptuouscapital.com> <20150210133738.GA15389@athena.barrera.io> Message-ID: <3118075.dMdDMeFj2f@collossus.ingo-kloecker.de> On Tuesday 10 February 2015 10:37:38 Hugo Osvaldo Barrera wrote: > On 2015-02-10 13:30, Kristian Fiskerstrand wrote: > > On 02/10/2015 01:24 PM, Peter Lebbing wrote: > > > On 10/02/15 12:52, Kristian Fiskerstrand wrote: > > >> No, the signature is still valid: > > > Why? The key was revoked because it was superseded or has been > > > retired, not because it was stolen or compromised. > > > > Unless you rely on a trusted third party to provide signature stamps, > > signature dates can be forged. A key revocation should result in > > immediate questioning of all aspects of the key, as it currently does. > > There is no reason to assume that the signature has been forged if the key > has not been compromised. > > Also, I see no reason why I should not be able to assign a trust to a > revoked key - I might trust it even if the author revoked it as superseded: > > > $ gpg --edit 1BFBED44 > [... info on revoked key ...] > gpg> lsign > Key is revoked. Unable to sign. > > I believe the reason matters. I can even sit down with the owner of the key > and verify his ID and fingerprint and sign it, meaning "this key belongs to > this person, but was superseeded a week ago". If actually influences the > validity of anything he signed up to a week ago. Use gpg --lsign --expert 1BFBED44 to sign the key despite the revocation. But this won't change the validity of the key. The validity of a revoked key is (and remains for all times) "revoked" (as far as gpg is concerned). Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From dkg at fifthhorseman.net Tue Feb 10 23:53:05 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 10 Feb 2015 17:53:05 -0500 Subject: moving up from 2.0.26 to 2.1.1 In-Reply-To: <54DA5787.3070903@nordnet.fr> References: <54DA5787.3070903@nordnet.fr> Message-ID: <87iof9qsz2.fsf@alice.fifthhorseman.net> On Tue 2015-02-10 14:09:59 -0500, Philip Jackson wrote: > I've been a linux user for less than a year and the only configure/make/install > I've done is for 2.0.26 and its dependencies (when I couldn't get the distro > supplied package 2.0.22 to work). > > Now when I look at the dependencies for gnupg 2.1.1, I see that I need to > upgrade libassuan to 2.2.0, libgpg-error to 1.17 and gpgme to 1.5.3. > > The first question I have is whether it is necessary to remove the versions I > already have prior to installing the later versions ? I suppose simply > installing the later version will not automatically replace the previous version ? > > Up to present, all updates to software have been done by the distro's 'Software > updater' and this has not made me any the wiser on the procedure for manual > updating. > > Is there a risk of having a sedimentary layer of unwanted an outdated versions > accumulate on disk when updating manually ? The questions you're asking are very much the sort of thing that distributions are designed to address. What distro are you using? what version? 2.1.1 has been packaged for some distros already (as have some of these dependencies), and you might be able to save yourself a lot of pain by choosing a path with a maintainer familiar with your system :) --dkg From dkg at fifthhorseman.net Wed Feb 11 00:24:19 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 10 Feb 2015 18:24:19 -0500 Subject: (bug?) Revoked keys and past signatures In-Reply-To: <8001197.dhmlAKZbt3@inno> References: <20150208190652.GA9440@athena.barrera.io> <20150210133738.GA15389@athena.barrera.io> <87pp9hsl1u.fsf@alice.fifthhorseman.net> <8001197.dhmlAKZbt3@inno> Message-ID: <878ug5qrj0.fsf@alice.fifthhorseman.net> On Tue 2015-02-10 13:20:03 -0500, Hauke Laging wrote: >> your certifications (whether local or exportable) themselves have a >> timestamp in them. It would be silly to certify a key and its user ID >> after it was revoked by the owner; you'd be claiming "i believe that >> right now this is the correct key", which is not the case. > > And who says that this is the statement? The RfC? I think that faking > cannot be a good idea in a crypto context. What if the signing key was > created after the revocation? What would that look like? It must be > possible for people who have only newer keys to make a "the owner of > this key is X" statement. I suspect this is widely held to be the semantics of the "signature created on" timestamp, based on the following two sections of RFC 4880 5.2.3.4. Signature Creation Time (4-octet time field) The time the signature was made. MUST be present in the hashed area. 5.2.3.10. Signature Expiration Time (4-octet time field) The validity period of the signature. This is the number of seconds after the signature creation time that the signature expires. If this is not present or has a value of zero, it never expires. The implication here is that the time of signature creation is the start of the signature validity period. >> I understand the semantics of what you're trying to do, but i'm not >> sure that OpenPGP has syntax to represent it. > > I don't see any problem with the syntax. The problem is the lack of > semantic definition. The next OpenPGP version should address that at any > rate. It sounds to me like you're asking for the standard to separate out "signature creation time" from "signature validity start time". This is an interesting proposal, and i can see why it would make sense for this scenario. I can also see it introducing a lot of subtle bugs in what is already a very nuanced and subtle area (certificate timestamp checking; not just in OpenPGP either -- the ongoing x.509 discussions about overlapping windows of certificate validity). I'm not sure about the tradeoffs here. --dkg From xavier at maillard.im Wed Feb 11 06:41:18 2015 From: xavier at maillard.im (Xavier Maillard) Date: Wed, 11 Feb 2015 06:41:18 +0100 Subject: Sign key with externalized master key Message-ID: Hello, May I ask how one would sign public keys when a "master key" is stored onto an USB stick ? I followed instructions from [1]. Now I am in the process of announcing my key transition to all old signers *but*, as a last test, I just tested public signature with my "master key" and this is where troubles occur: LANG=C gpg --home /Volumes/FSF/.gnupg --recv-keys gpg: WARNING: unsafe permissions on homedir `/Volumes/FSF/.gnupg' gpg: external program calls are disabled due to unsafe options file permissions gpg: keyserver communications error: General error gpg: keyserver receive failed: General error So what ? My USB stick is formated using extFat so permissions are something unknown. Do you have any way to workaround that ? Or better, USB stick storage best practice ? My environment is very hetereogenous but I may only sign from my OS X machine so there can be a better choice than extFat I presume. I did something odd as a very short temporary workaround: umask 077; mkdir /tmp/_gpg-to-sign gpg --home /tmp/_gnupg-to-sign --import /Volumes/FSF/2015-02-09/{public+private}.gpg then did my keysigning. Thank you very much. Footnotes: [1] https://alexcabal.com/creating-the-perfect-gpg-keypair/ -- Sent with my mu4e From wk at gnupg.org Wed Feb 11 11:20:07 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 11 Feb 2015 11:20:07 +0100 Subject: status of ed25519 draft In-Reply-To: <54DA7099.9030909@minton.name> (Brian Minton's message of "Tue, 10 Feb 2015 15:56:57 -0500") References: <54DA7099.9030909@minton.name> Message-ID: <8761b84unc.fsf@vigenere.g10code.de> On Tue, 10 Feb 2015 21:56, brian at minton.name said: > Is there any way to see the progress of the IETF working group on > the draft Werner has submitted? I noticed that the draft expires in The process to get the I-D to an RFC is somewhat work intensive and I would actually prefer to have the OpenPGP WG re-established to make it easier. I will of course update the I-D in time. > May. In particular, I would like to know if 22 is going to be the IANA > standardized Public-Key Algorithm number. We have an informal agreement on the WG list to use that number. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From philip.jackson at nordnet.fr Wed Feb 11 14:44:15 2015 From: philip.jackson at nordnet.fr (Philip Jackson) Date: Wed, 11 Feb 2015 14:44:15 +0100 Subject: moving up from 2.0.26 to 2.1.1 In-Reply-To: <87iof9qsz2.fsf@alice.fifthhorseman.net> References: <54DA5787.3070903@nordnet.fr> <87iof9qsz2.fsf@alice.fifthhorseman.net> Message-ID: <54DB5CAF.1020903@nordnet.fr> On 10/02/15 23:53, Daniel Kahn Gillmor wrote: > The questions you're asking are very much the sort of thing that > distributions are designed to address. > > What distro are you using? what version? 2.1.1 has been packaged for > some distros already (as have some of these dependencies), and you might > be able to save yourself a lot of pain by choosing a path with a > maintainer familiar with your system :) Thank you for your reply, Daniel. I'm using UbuntuStudio 1404 - a flavour of Ubuntu, kept up to date by frequent downloads by their "Software Updater" utility. I originally tried using the gnupg2 2.0.22 available as a package from Ubuntu, but once installed I couldn't make it work (and I do know about enigmail having to locate gpg2). As soon as I removed it, enigmail worked fine with gnupg1.4.16 (the standard with the distro download). I then tried 2.0.26 on my own and this worked a treat. I find that distro packages (for Ubuntu) lag well behind what is available and I do appreciate that there is a trade-off between proven reliability and up-to-dateness and also that distros rely on maintainers who may well be volunteers. So I don't mind trying available releases more up to date than the distro makes available. I'm quite happy using enigmails's nightly builds. Neither "Ubuntu Software Centre" nor "Synaptic Package Manager" indicate availability of anything more modern than 1.4.16 / 2.0.22 - unless you know better ? Philip -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From brian at minton.name Wed Feb 11 14:59:48 2015 From: brian at minton.name (Brian Minton) Date: Wed, 11 Feb 2015 13:59:48 +0000 Subject: moving up from 2.0.26 to 2.1.1 References: <54DA5787.3070903@nordnet.fr> <87iof9qsz2.fsf@alice.fifthhorseman.net> <54DB5CAF.1020903@nordnet.fr> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 In Debian, the experimental repo has gpg 2.1 with all dependencies. Follow the instructions at https://wiki.debian.org/DebianExperimental -----BEGIN PGP SIGNATURE----- Version: OpenKeychain v3.1.2 iIAEAREIACghHEJyaWFuIE1pbnRvbiA8YnJpYW5AbWludG9uLm5hbWU+BQJU22BA AAoJEGuOs6Blz7qpQ2oA/R3WgCWvyL2OTcSeJTkbAKT/mUmq76Zwj+T6x4TTcM53 AP9xUSQFI3RYwiENCrtfpLkQTO1lpdjt6myK+uAQvSY5zQ== =qpQf -----END PGP SIGNATURE----- On Wed, Feb 11, 2015, 8:46 AM Philip Jackson wrote: > On 10/02/15 23:53, Daniel Kahn Gillmor wrote: > > The questions you're asking are very much the sort of thing that > > distributions are designed to address. > > > > What distro are you using? what version? 2.1.1 has been packaged for > > some distros already (as have some of these dependencies), and you might > > be able to save yourself a lot of pain by choosing a path with a > > maintainer familiar with your system :) > > Thank you for your reply, Daniel. > > I'm using UbuntuStudio 1404 - a flavour of Ubuntu, kept up to date by > frequent > downloads by their "Software Updater" utility. > > I originally tried using the gnupg2 2.0.22 available as a package from > Ubuntu, > but once installed I couldn't make it work (and I do know about enigmail > having > to locate gpg2). As soon as I removed it, enigmail worked fine with > gnupg1.4.16 > (the standard with the distro download). > > I then tried 2.0.26 on my own and this worked a treat. > > I find that distro packages (for Ubuntu) lag well behind what is available > and I > do appreciate that there is a trade-off between proven reliability and > up-to-dateness and also that distros rely on maintainers who may well be > volunteers. So I don't mind trying available releases more up to date > than the > distro makes available. I'm quite happy using enigmails's nightly builds. > > Neither "Ubuntu Software Centre" nor "Synaptic Package Manager" indicate > availability of anything more modern than 1.4.16 / 2.0.22 - unless you > know better ? > > Philip > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Wed Feb 11 15:19:11 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 11 Feb 2015 09:19:11 -0500 Subject: Sign key with externalized master key In-Reply-To: References: Message-ID: <87fvacpm3k.fsf@alice.fifthhorseman.net> On Wed 2015-02-11 00:41:18 -0500, Xavier Maillard wrote: > May I ask how one would sign public keys when a "master key" is > stored onto an USB stick ? > > I followed instructions from [1]. Now I am in the process of > announcing my key transition to all old signers *but*, as a last > test, I just tested public signature with my "master key" and this is > where troubles occur: > > LANG=C gpg --home /Volumes/FSF/.gnupg --recv-keys > gpg: WARNING: unsafe permissions on homedir `/Volumes/FSF/.gnupg' > gpg: external program calls are disabled due to unsafe options file permissions > gpg: keyserver communications error: General error > gpg: keyserver receive failed: General error > > So what ? My USB stick is formated using extFat so permissions are > something unknown. The fact that you're using a FAT volume is the root cause here; FAT filesystems do not have ownership or permissions, so when a modern OS mounts them, it has to fake permissions for these files. If you mount the filesystem manually, you can usually specify tighter permissions. I don't know the exact syntax for OS X, but on GNU/Linux systems, that would be: mount -t vfat -ouid=$USERNAME,umask=077 /dev/sdx1 /Volumes/FSF umask is the relevant option here to set the default permissions. Alternately, if your umask is set properly before mounting the filesystem, i think mount(8) will just default to it. hth, --dkg From rjh at sixdemonbag.org Wed Feb 11 16:20:37 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 11 Feb 2015 10:20:37 -0500 Subject: moving up from 2.0.26 to 2.1.1 In-Reply-To: <54DB5CAF.1020903@nordnet.fr> References: <54DA5787.3070903@nordnet.fr> <87iof9qsz2.fsf@alice.fifthhorseman.net> <54DB5CAF.1020903@nordnet.fr> Message-ID: <54DB7345.4080406@sixdemonbag.org> > I find that distro packages (for Ubuntu) lag well behind what is > available and I do appreciate that there is a trade-off between > proven reliability and up-to-dateness and also that distros rely on > maintainers who may well be volunteers... If your goal is to enjoy tinkering with technology, by all means, do what you're doing. Can't fault you for it in the least; I love doing it myself. If your goal is just to make sure you have the latest and greatest security updates, you should probably stick with your distro's packages. The distro package may *say* 2.0.22, but any security fixes released after 2.0.22 will quickly be backported into your distro's 2.0.22 package. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3744 bytes Desc: S/MIME Cryptographic Signature URL: From taltman1 at stanford.edu Wed Feb 11 16:35:08 2015 From: taltman1 at stanford.edu (taltman) Date: Wed, 11 Feb 2015 07:35:08 -0800 Subject: Purchasing OpenPGP cards, card-readers to support GnuPG Message-ID: <54DB76AC.7050802@stanford.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I'd like to both support the GnuPG project, and acquire an OpenPGP card and card reader. Is there any way to purchase these items where a portion of the proceeds goes to supporting GnuPG? Thanks, ~Tomer - -- - ---- - --- Encrypted email preferred. http://taltman.sdf.org/public_key.asc Key fingerprint = DFE8 7D60 D452 9C4F 5D1F 7515 F55F BB30 1719 7991 -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJU23aqAAoJEMAutzpeVLZSxN8P/RZdL4+kzmRtjow5MfshaWfX cmZKxystchC8obkXg1jTxD5TFfQMccgkzC1ans1aRWtUjSJakmcrzsgq4F3ibCHO bRk0G9snXU7gdSMSOHfsJI0IMO29Sile/LmxqTXFRZWayM6m+71J0vsDHFcc65TR GMgvms6/6fL/4XrhL3TXHKdaUcwq1GAhzT3bBd0ERrJjr71q+CeVvsjBAswkqBYO TEo8e87wg/c2wYyE6tFhqinbTzIKukom4WMoRbWWU6LpdoZ1F9wFvDuc446J5R7D aQ+1LhDutYol6g97C1ZXqZYG0zEsrqdjqUGkh3lfpH9DW39GEOFhJCPakoFnrerS UEA4rn+UXyr3G2GXDQpck49Ks4TGSRudyvw8Frnuw8FH+MwU8W8ygdMJ5Pf657tB siYNKD9G/g4d5miH+7DDte+T35I+EQyp86oko97qFYhNUDUKFn6Zm2aSV9G0XuSY fROyFMKBZ3qlOScyG8tbaBEYZziQC8T4KNEomv0R5Tvm2scnfKqKd1bIHhvqe7mn VPfvNuaxidLMVqtITQSshFd2RpruhCHt1Vyd5q/cU1EgiDlxy/SluyqVit05SicX fRCNUE2ZtSvaxPoIwU+LSDWGg0+OPsP2whjjB+Fh3GsArAWfrVPyXCQg9t++f+AA YfchIHRrd4NQJiOLpDtn =zpRT -----END PGP SIGNATURE----- From dave.pawson at gmail.com Wed Feb 11 18:43:05 2015 From: dave.pawson at gmail.com (Dave Pawson) Date: Wed, 11 Feb 2015 17:43:05 +0000 Subject: Purchasing OpenPGP cards, card-readers to support GnuPG In-Reply-To: <54DB76AC.7050802@stanford.edu> References: <54DB76AC.7050802@stanford.edu> Message-ID: I was hoping that long thread might suggest the same. Quite willing to support GPG via a purchase, but so little information is available... regards DaveP On 11 February 2015 at 15:35, taltman wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > I'd like to both support the GnuPG project, and acquire an OpenPGP card > and card reader. > > Is there any way to purchase these items where a portion of the proceeds > goes to supporting GnuPG? > > Thanks, > > ~Tomer > > - -- > - ---- > - --- > > Encrypted email preferred. > http://taltman.sdf.org/public_key.asc > Key fingerprint = DFE8 7D60 D452 9C4F 5D1F 7515 F55F BB30 1719 7991 > -----BEGIN PGP SIGNATURE----- > > iQIcBAEBCgAGBQJU23aqAAoJEMAutzpeVLZSxN8P/RZdL4+kzmRtjow5MfshaWfX > cmZKxystchC8obkXg1jTxD5TFfQMccgkzC1ans1aRWtUjSJakmcrzsgq4F3ibCHO > bRk0G9snXU7gdSMSOHfsJI0IMO29Sile/LmxqTXFRZWayM6m+71J0vsDHFcc65TR > GMgvms6/6fL/4XrhL3TXHKdaUcwq1GAhzT3bBd0ERrJjr71q+CeVvsjBAswkqBYO > TEo8e87wg/c2wYyE6tFhqinbTzIKukom4WMoRbWWU6LpdoZ1F9wFvDuc446J5R7D > aQ+1LhDutYol6g97C1ZXqZYG0zEsrqdjqUGkh3lfpH9DW39GEOFhJCPakoFnrerS > UEA4rn+UXyr3G2GXDQpck49Ks4TGSRudyvw8Frnuw8FH+MwU8W8ygdMJ5Pf657tB > siYNKD9G/g4d5miH+7DDte+T35I+EQyp86oko97qFYhNUDUKFn6Zm2aSV9G0XuSY > fROyFMKBZ3qlOScyG8tbaBEYZziQC8T4KNEomv0R5Tvm2scnfKqKd1bIHhvqe7mn > VPfvNuaxidLMVqtITQSshFd2RpruhCHt1Vyd5q/cU1EgiDlxy/SluyqVit05SicX > fRCNUE2ZtSvaxPoIwU+LSDWGg0+OPsP2whjjB+Fh3GsArAWfrVPyXCQg9t++f+AA > YfchIHRrd4NQJiOLpDtn > =zpRT > -----END PGP SIGNATURE----- > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -- Dave Pawson XSLT XSL-FO FAQ. Docbook FAQ. http://www.dpawson.co.uk From philip.jackson at nordnet.fr Wed Feb 11 20:02:49 2015 From: philip.jackson at nordnet.fr (Philip Jackson) Date: Wed, 11 Feb 2015 20:02:49 +0100 Subject: moving up from 2.0.26 to 2.1.1 In-Reply-To: References: <54DA5787.3070903@nordnet.fr> <87iof9qsz2.fsf@alice.fifthhorseman.net> <54DB5CAF.1020903@nordnet.fr> Message-ID: <54DBA759.5080601@nordnet.fr> On 11/02/15 14:59, Brian Minton wrote: > In Debian, the experimental repo has gpg 2.1 with all dependencies. Follow the > instructions at https://wiki.debian.org/DebianExperimental Thank you for that suggestion, Brian. I looked into the link you provided and decided that to see the precise name of the package, I'd add the repository address into source info in Synaptic Package manager. Which I did, together with Debian's gpg key. After reload, I searched for possible packages available at Debian experimental repo but failed to find any with names like gpg*, gnupg*. So I'm not there yet. No hurry, though - lots to learn. Philip -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From philip.jackson at nordnet.fr Wed Feb 11 20:06:34 2015 From: philip.jackson at nordnet.fr (Philip Jackson) Date: Wed, 11 Feb 2015 20:06:34 +0100 Subject: moving up from 2.0.26 to 2.1.1 In-Reply-To: <54DB7345.4080406@sixdemonbag.org> References: <54DA5787.3070903@nordnet.fr> <87iof9qsz2.fsf@alice.fifthhorseman.net> <54DB5CAF.1020903@nordnet.fr> <54DB7345.4080406@sixdemonbag.org> Message-ID: <54DBA83A.2030104@nordnet.fr> On 11/02/15 16:20, Robert J. Hansen wrote: >> I find that distro packages (for Ubuntu) lag well behind what is >> available and I do appreciate that there is a trade-off between >> proven reliability and up-to-dateness and also that distros rely on >> maintainers who may well be volunteers... > > If your goal is to enjoy tinkering with technology, by all means, do > what you're doing. Can't fault you for it in the least; I love doing it > myself. Yes, I guess that I fall into this type slot. > If your goal is just to make sure you have the latest and greatest > security updates, you should probably stick with your distro's packages. > The distro package may *say* 2.0.22, but any security fixes released > after 2.0.22 will quickly be backported into your distro's 2.0.22 package. A priori, this doesn't seem very transparent but I suppose there must be a way to determine if 2.0.22 is original or augmented ? Philip -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Wed Feb 11 20:40:39 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 11 Feb 2015 20:40:39 +0100 Subject: [Announce] GnuPG 2.1.2 released Message-ID: <874mqs2q4o.fsf@vigenere.g10code.de> Hello! The GnuPG Project is pleased to announce the availability of the third release of GnuPG modern: Version 2.1.2. The GNU Privacy Guard (GnuPG) is a complete and free implementation of the OpenPGP standard as defined by RFC-4880 and better known as PGP. GnuPG, also known as GPG, allows to encrypt and sign data and communication, features a versatile key management system as well as access modules for public key directories. GnuPG itself is a command line tool with features for easy integration with other applications. A wealth of frontend applications and libraries making use of GnuPG are available. Since version 2 GnuPG provides support for S/MIME and Secure Shell in addition to OpenPGP. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License. Three different versions of GnuPG are actively maintained: - GnuPG "modern" (2.1) is the latest development with a lot of new features. This announcement is about the first release of this version. - GnuPG "stable" (2.0) is the current stable version for general use. This is what most users are currently using. - GnuPG "classic" (1.4) is the old standalone version which is most suitable for older or embedded platforms. You may not install "modern" (2.1) and "stable" (2.0) at the same time. However, it is possible to install "classic" (1.4) along with any of the other versions. What's New in GnuPG-2.1 ======================= * gpg: The parameter 'Passphrase' for batch key generation works again. * gpg: Using a passphrase option in batch mode now has the expected effect on --quick-gen-key. * gpg: Improved reporting of unsupported PGP-2 keys. * gpg: Added support for algo names when generating keys using --command-fd. * gpg: Fixed DoS based on bogus and overlong key packets. * agent: When setting --default-cache-ttl the value for --max-cache-ttl is adjusted to be not lower than the former. * agent: Fixed problems with the new --extra-socket. * agent: Made --allow-loopback-pinentry changeable with gpgconf. * agent: Fixed importing of unprotected openpgp keys. * agent: Now tries to use a fallback pinentry if the standard pinentry is not installed. * scd: Added support for ECDH. * Fixed several bugs related to bogus keyrings and improved some other code. A detailed description of the changes found in 2.1 can be found at https://gnupg.org/faq/whats-new-in-2.1.html . Getting the Software ==================== Please follow the instructions found at https://gnupg.org/download/ or read on: GnuPG 2.1.2 may be downloaded from one of the GnuPG mirror sites or direct from its primary FTP server. The list of mirrors can be found at https://gnupg.org/mirrors.html . Note that GnuPG is not available at ftp.gnu.org. On ftp.gnupg.org you find these files: ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.2.tar.bz2 (4720k) ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.2.tar.bz2.sig This is the GnuPG 2.1 source code compressed using BZIP2 and its OpenPGP signature. A Windows installer is not available for this version because we are currently reworking some parts of it. This version fixes a lot of bugs found after the release of 2.1.0 but there are still known bugs which we are working on. Please check the mailing list archives and https://wiki.gnupg.org for known problems and workaround. Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a version of GnuPG installed, you can simply verify the supplied signature. For example to verify the signature of the file gnupg-2.1.2.tar.bz2 you would use this command: gpg --verify gnupg-2.1.2.tar.bz2.sig gnupg-2.1.2.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See below for information on the signing keys. * If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either "sha1sum" or "shasum". Assuming you downloaded the file gnupg-2.1.1.tar.bz2, you would run the command like this: sha1sum gnupg-2.1.2.tar.bz2 and check that the output matches the first line from the following list: 7e972cb9af47d9b8ce164dcf37fc4f32634d6cd6 gnupg-2.1.2.tar.bz2 Release Signing Keys ==================== To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: 2048R/4F25E3B6 2011-01-12 [expires: 2019-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048/E0856959 2014-10-29 [expires: 2019-12-31] Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 David Shaw (GnuPG Release Signing Key) rsa2048/33BD3F06 2014-10-29 [expires: 2016-10-28] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa2048/7EFD60D9 2014-10-19 [expires: 2020-12-31] Key fingerprint = D238 EA65 D64C 67ED 4C30 73F2 8A86 1B1C 7EFD 60D9 Werner Koch (Release Signing Key) You may retrieve these files from the keyservers using this command gpg --recv-keys 249B39D24F25E3B6 04376F3EE0856959 \ 2071B08A33BD3F06 8A861B1C7EFD60D9 The keys are also available at https://gnupg.org/signature_key.html and in the released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed using my standard PGP key. Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese, Czech, French, German, Japanese, Russian, and Ukrainian being almost completely translated (2061 different strings). Documentation ============= If you used GnuPG in the past you should read the description of changes and new features at doc/whats-new-in-2.1.txt or online at https://gnupg.org/faq/whats-new-in-2.1.html The file gnupg.info has the complete user manual of the system. Separate man pages are included as well but they have not all the details available as are the manual. It is also possible to read the complete manual online in HTML format at https://gnupg.org/documentation/manuals/gnupg/ or in Portable Document Format at https://gnupg.org/documentation/manuals/gnupg.pdf . The chapters on gpg-agent, gpg and gpgsm include information on how to set up the whole thing. You may also want search the GnuPG mailing list archives or ask on the gnupg-users mailing lists for advise on how to solve problems. Many of the new features are around for several years and thus enough public knowledge is already available. You may also want to follow postings at https://gnupg.org/blob/. Support ======== Please consult the archive of the gnupg-users mailing list before reporting a bug . We suggest to send bug reports for a new release to this list in favor of filing a bug at . For commercial support requests we keep a list of known service companies at: https://gnupg.org/service.html If you are a developer and you may need a certain feature for your project, please do not hesitate to bring it to the gnupg-devel mailing list for discussion. Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, and answering questions on the mailing lists. Since the start of the funding campaign in December several thousand people have been kind enough to donate a total of 250000 Euro to support this project. In addition the Linux Foundation gave a grant of $ 60000 for 2015, Stripe.com and Facebook.com each pledged $ 50000 per year. I am amazed by this superb and unexpected support for the GnuPG project. This will not only allow us to continue the project and hire at least a second full time developer but gives us also the resources to improve things which have been delayed for too long. *Thank you all !* Salam-Shalom, Werner p.s. This is a announcement only mailing list. Please send replies only to the gnupg-users at gnupg.org mailing lists. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 180 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From rjh at sixdemonbag.org Wed Feb 11 20:58:15 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 11 Feb 2015 14:58:15 -0500 Subject: moving up from 2.0.26 to 2.1.1 In-Reply-To: <54DBA83A.2030104@nordnet.fr> References: <54DA5787.3070903@nordnet.fr> <87iof9qsz2.fsf@alice.fifthhorseman.net> <54DB5CAF.1020903@nordnet.fr> <54DB7345.4080406@sixdemonbag.org> <54DBA83A.2030104@nordnet.fr> Message-ID: <54DBB457.1090001@sixdemonbag.org> > A priori, this doesn't seem very transparent but I suppose there must > be a way to determine if 2.0.22 is original or augmented ? Yep, but as I'm not much of an Ubuntu guy I'll let one of them give you specific instructions -- I just know Ubuntu, like Debian (which it's built on), is very good about making that information available. As a first try I'd suggest looking at: https://launchpad.net/ubuntu/+source/gnupg2/2.0.24-1ubuntu2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3744 bytes Desc: S/MIME Cryptographic Signature URL: From wk at gnupg.org Wed Feb 11 21:11:07 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 11 Feb 2015 21:11:07 +0100 Subject: Purchasing OpenPGP cards, card-readers to support GnuPG In-Reply-To: <54DB76AC.7050802@stanford.edu> (taltman's message of "Wed, 11 Feb 2015 07:35:08 -0800") References: <54DB76AC.7050802@stanford.edu> Message-ID: <87y4o41a5g.fsf@vigenere.g10code.de> On Wed, 11 Feb 2015 16:35, taltman1 at stanford.edu said: > Is there any way to purchase these items where a portion of the proceeds > goes to supporting GnuPG? Not that I know about. I for myself did not wanted to get into the hardware business. But meanwhile I consider to have some merchandise stuff and a card might well fit into that category. Maybe not a card but the fully free gnuk token. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Wed Feb 11 21:16:17 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 11 Feb 2015 15:16:17 -0500 Subject: moving up from 2.0.26 to 2.1.1 In-Reply-To: <54DBA759.5080601@nordnet.fr> References: <54DA5787.3070903@nordnet.fr> <87iof9qsz2.fsf@alice.fifthhorseman.net> <54DB5CAF.1020903@nordnet.fr> <54DBA759.5080601@nordnet.fr> Message-ID: <87pp9gmcfi.fsf@alice.fifthhorseman.net> On Wed 2015-02-11 14:02:49 -0500, Philip Jackson wrote: > On 11/02/15 14:59, Brian Minton wrote: >> In Debian, the experimental repo has gpg 2.1 with all dependencies. Follow the >> instructions at https://wiki.debian.org/DebianExperimental > > Thank you for that suggestion, Brian. I looked into the link you provided and > decided that to see the precise name of the package, I'd add the repository > address into source info in Synaptic Package manager. Which I did, together > with Debian's gpg key. > > After reload, I searched for possible packages available at Debian experimental > repo but failed to find any with names like gpg*, gnupg*. > > So I'm not there yet. No hurry, though - lots to learn. You don't say how you searched specifically, so i can't say what's gone wrong in your case. Here's what i see: 0 dkg at alice:~$ apt-cache policy gnupg2 gnupg2: Installed: 2.1.1-1 Candidate: 2.1.1-1 Version table: *** 2.1.1-1 0 1 http://ftp.us.debian.org/debian/ experimental/main amd64 Packages 100 /var/lib/dpkg/status 2.0.26-4 0 500 http://ftp.us.debian.org/debian/ jessie/main amd64 Packages 200 http://ftp.us.debian.org/debian/ sid/main amd64 Packages 0 dkg at alice:~$ hth, --dkg From laurens.vanhoutven at RACKSPACE.COM Wed Feb 11 19:49:19 2015 From: laurens.vanhoutven at RACKSPACE.COM (Laurens Van Houtven) Date: Wed, 11 Feb 2015 18:49:19 +0000 Subject: Generating Message-ID: Hi, I just acquired an OpenPGP v2.0 SmartCard. Works beautifully, except for one thing: no 4096 bit keys. I thought this would be supported, but when I try to generate a key with gpg ?card-edit, I can only select up to 3072 bits. I thought 4096 was supported on the v2 card, as long as you had GnuPG 2.0.18+, which I do: gpg (GnuPG/MacGPG2) 2.0.26 libgcrypt 1.6.2 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: ~/.gnupg Supported algorithms: Pubkey: RSA, RSA, RSA, ELG, DSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 Any ideas? thanks in advance lvh -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From dkg at fifthhorseman.net Wed Feb 11 21:22:36 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 11 Feb 2015 15:22:36 -0500 Subject: (bug?) Revoked keys and past signatures In-Reply-To: <878ug5qrj0.fsf@alice.fifthhorseman.net> References: <20150208190652.GA9440@athena.barrera.io> <20150210133738.GA15389@athena.barrera.io> <87pp9hsl1u.fsf@alice.fifthhorseman.net> <8001197.dhmlAKZbt3@inno> <878ug5qrj0.fsf@alice.fifthhorseman.net> Message-ID: <87mw4kmc4z.fsf@alice.fifthhorseman.net> On Tue 2015-02-10 18:24:19 -0500, Daniel Kahn Gillmor wrote: > It sounds to me like you're asking for the standard to separate out > "signature creation time" from "signature validity start time". > > This is an interesting proposal, and i can see why it would make sense > for this scenario. > > I can also see it introducing a lot of subtle bugs in what is already a > very nuanced and subtle area (certificate timestamp checking; not just > in OpenPGP either -- the ongoing x.509 discussions about overlapping > windows of certificate validity). For reference, X.509 does not provide the signing time at all, but has notBefore and notAfter fields. Other signed objects that use CMS can potentially have all three, which is potentially confusing: http://csrc.nist.gov/groups/SNS/piv/npivp/SP80078FAQ.htm X.509 public key certificates do not specify the time of signature generation, but do specify a validity period using the notBefore and notAfter fields. For each of the X.509 certificates, the notBefore time in the certificate should be used as the digital signature generation date. The digital signatures on the CHUID, biometric, and security object are all encoded as Cryptographic Message Syntax (CMS) external digital signatures, as defined in RFC 3852. RFC 3852 defines the signingTime attribute, which specifies the time at which the signer (purportedly) performed the signing process. If present in a particular object (i.e., the CHUID, biometric, or security object), the signingTime attribute should be used as the signature generation time. For any object that omits the signingTime attribute, the notBefore time encoded in the corresponding PIV Authentication certificate should be used as the signature generation time. (the above is slightly out of date, and should reference https://tools.ietf.org/html/rfc5652#section-11.3 instead of RFC 3852) --dkg From philip.jackson at nordnet.fr Wed Feb 11 22:35:27 2015 From: philip.jackson at nordnet.fr (Philip Jackson) Date: Wed, 11 Feb 2015 22:35:27 +0100 Subject: moving up from 2.0.26 to 2.1.1 In-Reply-To: <87pp9gmcfi.fsf@alice.fifthhorseman.net> References: <54DA5787.3070903@nordnet.fr> <87iof9qsz2.fsf@alice.fifthhorseman.net> <54DB5CAF.1020903@nordnet.fr> <54DBA759.5080601@nordnet.fr> <87pp9gmcfi.fsf@alice.fifthhorseman.net> Message-ID: <54DBCB1F.80505@nordnet.fr> On 11/02/15 21:16, Daniel Kahn Gillmor wrote: > On Wed 2015-02-11 14:02:49 -0500, Philip Jackson wrote: >> On 11/02/15 14:59, Brian Minton wrote: >>> In Debian, the experimental repo has gpg 2.1 with all dependencies. Follow the >>> instructions at https://wiki.debian.org/DebianExperimental .... snip... > > You don't say how you searched specifically, so i can't say what's gone > wrong in your case. I used the Synaptic Package Manager gui to search for gnupg2 after adding the experimental repository in the Settings/repository using the formula given on the website link provided by Brian Minto (above) : deb http://ftp.debian.org/debian experimental main Amongst all the items listed then as available in experimental (after reload) there was nothing shown in Synaptic Package Manager under gnupg. > Here's what i see: > > 0 dkg at alice:~$ apt-cache policy gnupg2 > gnupg2: > Installed: 2.1.1-1 > Candidate: 2.1.1-1 > Version table: > *** 2.1.1-1 0 > 1 http://ftp.us.debian.org/debian/ experimental/main amd64 Packages > 100 /var/lib/dpkg/status > 2.0.26-4 0 > 500 http://ftp.us.debian.org/debian/ jessie/main amd64 Packages > 200 http://ftp.us.debian.org/debian/ sid/main amd64 Packages > 0 dkg at alice:~$ > When I try your way from the command line, I get : $ apt-cache policy gnupg2 gnupg2: Installed: 2.0.22-3ubuntu1.1 Candidate: 2.0.22-3ubuntu1.1 Version table: 2.1.1-1 0 1 http://ftp.debian.org/debian/ experimental/main amd64 Packages *** 2.0.22-3ubuntu1.1 0 500 http://fr.archive.ubuntu.com/ubuntu/ trusty-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu/ trusty-security/main amd64 Packages 100 /var/lib/dpkg/status 2.0.22-3ubuntu1 0 500 http://fr.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages I'm not sure what this is telling me but I think it is indicating : 1. that 2.1.1 is available in experimental/main Packages. 2. that I have 2.0.22 installed 3. that latest available for my distro (candidate) is 2.0.22 Although I did, last summer, install 2.0.22 using the distro's software centre, I subsequently used the same software centre to remove it before building 2.0.26 on my own. So I don't know why the above indicates that 2.0.22 is installed. If I do gpg2 --version, it comes back clearly with 2.0.26. and enigmail clearly indicates that it has found the gpg2 that I built. So, moving on, if I do : apt-get -t experimental install gnupg2 will I get 2.1.1 installed together with its dependencies ? And returning to my original questions, since it is written that 2.0* and 2.1 cannot co-exist, I suppose that I shall have to remove manually everything connected with my 2.0.26 ? Thanks, Philip -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From xavier at maillard.im Wed Feb 11 23:31:42 2015 From: xavier at maillard.im (Xavier Maillard) Date: Wed, 11 Feb 2015 23:31:42 +0100 Subject: Sign key with externalized master key In-Reply-To: <87fvacpm3k.fsf@alice.fifthhorseman.net> References: <87fvacpm3k.fsf@alice.fifthhorseman.net> Message-ID: Daniel Kahn Gillmor writes: > On Wed 2015-02-11 00:41:18 -0500, Xavier Maillard wrote: >> May I ask how one would sign public keys when a "master key" is >> stored onto an USB stick ? >> >> I followed instructions from [1]. Now I am in the process of >> announcing my key transition to all old signers *but*, as a last >> test, I just tested public signature with my "master key" and this is >> where troubles occur: >> >> LANG=C gpg --home /Volumes/FSF/.gnupg --recv-keys >> gpg: WARNING: unsafe permissions on homedir `/Volumes/FSF/.gnupg' >> gpg: external program calls are disabled due to unsafe options file permissions >> gpg: keyserver communications error: General error >> gpg: keyserver receive failed: General error >> >> So what ? My USB stick is formated using extFat so permissions are >> something unknown. > > The fact that you're using a FAT volume is the root cause here; FAT > filesystems do not have ownership or permissions, so when a modern OS > mounts them, it has to fake permissions for these files. Thank you for this precision. Are you aware of some "portable" and well supported by the 3-major OSes filesystem type ? Regards -- Xavier -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1534 bytes Desc: not available URL: From 2014-667rhzu3dc-lists-groups at riseup.net Thu Feb 12 00:25:22 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Wed, 11 Feb 2015 23:25:22 +0000 Subject: Key keeps showing unknown trust In-Reply-To: <20150209092450.GA12071@athena.barrera.io> References: <20150207194314.GA1381@athena.barrera.io> <54D873C7.50007@mailbox.org> <20150209092450.GA12071@athena.barrera.io> Message-ID: <121598711.20150211232522@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Monday 9 February 2015 at 9:24:50 AM, in , Hugo Osvaldo Barrera wrote: > Only on older versions of gpg, according to the man > pages: > ~/.gnupg/secring.gpg A secret keyring as > used by GnuPG versions before 2.1. It is not > used by GnuPG 2.1 and later. If GnuPG 2.1.x finds an existing secring.gpg, that is used. If not, the new file format secring.kbx is used. - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net Free advice costs nothing until you act upon it -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJU2+WLXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwNk0IAKAeFYJlaM7bxwja5Cd6ufFW NYhTdHwolenLWGyPOyykSDcDShU3utALV/EgosE3IJpZX8VN7LCVQUX3OR7eVoQn PQ3akVhP/ga9rRX0b87/mNxX96U7bHpgzkY4L29s3Zofkk9iOmrL1bGasU/Pkbc/ +RdS4mUGffROslp8+cCIA7BZ78/9NXoOszIgkunjKlWClzsHlsvcbRaHzkwgIN5B guNMLVJqRhKHqfXQ0XFIBlrCRIbaWx1IuMGP+5IuKVF+06qMJoh3/hfWFRrWlYLT ligq17HvIWZtKlHUbAyG8OQEjTP6JbF80C1rMrRfzgwDktuQEi6gwjaHVLa+IkaI vgQBFgoAZgUCVNvloF8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45B08AQCdUFdbokk+fWbHZNCNN+PWD7Td IiHspCCwL+Av2hca5gEAAlVa8hS6sUaOr0Y6XJiMkQGDmfI5iKGysP8hBnVWJAA= =KFAs -----END PGP SIGNATURE----- From flapflap at riseup.net Thu Feb 12 00:08:21 2015 From: flapflap at riseup.net (flapflap) Date: Wed, 11 Feb 2015 23:08:21 +0000 Subject: Sign key with externalized master key In-Reply-To: References: <87fvacpm3k.fsf@alice.fifthhorseman.net> Message-ID: <54DBE0E5.7020500@riseup.net> Xavier Maillard: > > Daniel Kahn Gillmor writes: > >> On Wed 2015-02-11 00:41:18 -0500, Xavier Maillard wrote: >>> May I ask how one would sign public keys when a "master key" is >>> stored onto an USB stick ? >>> >>> I followed instructions from [1]. Now I am in the process of >>> announcing my key transition to all old signers *but*, as a last >>> test, I just tested public signature with my "master key" and this is >>> where troubles occur: >>> >>> LANG=C gpg --home /Volumes/FSF/.gnupg --recv-keys >>> gpg: WARNING: unsafe permissions on homedir `/Volumes/FSF/.gnupg' >>> gpg: external program calls are disabled due to unsafe options file permissions >>> gpg: keyserver communications error: General error >>> gpg: keyserver receive failed: General error >>> >>> So what ? My USB stick is formated using extFat so permissions are >>> something unknown. >> >> The fact that you're using a FAT volume is the root cause here; FAT >> filesystems do not have ownership or permissions, so when a modern OS >> mounts them, it has to fake permissions for these files. > > Thank you for this precision. Are you aware of some "portable" and > well supported by the 3-major OSes filesystem type ? Since your issue only affects signing of other keys - which normally is not a daily scenario - what about using a GNU/Linux live system/CD/USB for that purpose? That way you can use a normal GNU/Linux supported filesystem and don't have to worry whether to trust your normal OS or which filesystem is compatible with all OSses you intend to use. ~flapflap From gniibe at fsij.org Thu Feb 12 02:03:01 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 12 Feb 2015 10:03:01 +0900 Subject: Purchasing OpenPGP cards, card-readers to support GnuPG In-Reply-To: <54DB76AC.7050802@stanford.edu> References: <54DB76AC.7050802@stanford.edu> Message-ID: <54DBFBC5.2070305@fsij.org> On 02/12/2015 12:35 AM, taltman wrote: > Is there any way to purchase these items where a portion of the proceeds > goes to supporting GnuPG? Indirectly, I'd say. I think that if you stay in Europe, being a FSFE member, you'll get its member card with OpenPGPcard feature. I'm sure that it will improve the eco system around GnuPG, although it's not directly supporting GnuPG development. Besides, it gives her good opportunity to consider the importance and difficulty of controling her own computing, by a concrete example of card reader implementation and card implementation. Buying OpenPGPcard implementations (instead of other card implementations of PKCS) also benefits GnuPG development indirectly. Because OpenPGPcard specification is published, and its functionality is clear enough. Well, PKCS is published, YES... but supporting cards other than OpenPGPcard specification is very difficult for free software project, in general, because the standard practice assumes non-free environment and the industry tends to be unfriendly to free software. Buying original OpenPGPcard implementation would be better, so that we can support publishing OpenPGPcard specification as free specification. Perhaps, you'd like more free implementation of OpenPGPcard, but (partially) non-free implementation also works. In the current situation, I never accuse users/developers of non-free OpenPGPcard implementation. It's not ideal, but it would be an important step towards better control of our own computing. Difficulty is... for card readers. I only know one free (as in freedom) implementation which connects physical card, that's CryptoStick (now, new project name, Nitrokey), which combines physical OpenPGPcard into a token. Lastly and unlikely, if you stay in Japan, being a FSIJ member, you'll automatically get the pressure of buying FST-01 as Gnuk Token (or NeuG standalone). :-) I'm selling FST-01 so that I could have more time for GnuPG development, and I'd like to invite more developers into this area, while I'd like to encourage Chinese Industry for free (as in freedom) hardware design. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From brian at minton.name Thu Feb 12 03:43:38 2015 From: brian at minton.name (Brian Minton) Date: Thu, 12 Feb 2015 02:43:38 +0000 Subject: Sign key with externalized master key References: <87fvacpm3k.fsf@alice.fifthhorseman.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Wed, Feb 11, 2015, 5:33 PM Xavier Maillard wrote: Thank you for this precision. Are you aware of some "portable" and well supported by the 3-major OSes filesystem type ? Just UDF -----BEGIN PGP SIGNATURE----- Version: OpenKeychain v3.1.2 iIAEAREIACghHEJyaWFuIE1pbnRvbiA8YnJpYW5AbWludG9uLm5hbWU+BQJU3BNJ AAoJEGuOs6Blz7qpz9MA/0MioB8VjrF/4+6UnN4RP9E+PNWzumMPpYsfkEXej8tW AP95+irR2/yR6Rbv7WXGsV3GSftc/iYaiykwGB1VdIHmMQ== =aHkI -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From xavier at maillard.im Thu Feb 12 06:22:15 2015 From: xavier at maillard.im (Xavier Maillard) Date: Thu, 12 Feb 2015 06:22:15 +0100 Subject: Sign key with externalized master key In-Reply-To: <54DBE0E5.7020500@riseup.net> References: <87fvacpm3k.fsf@alice.fifthhorseman.net> <54DBE0E5.7020500@riseup.net> Message-ID: flapflap writes: > Xavier Maillard: >> >> Daniel Kahn Gillmor writes: >> >>> On Wed 2015-02-11 00:41:18 -0500, Xavier Maillard wrote: >>>> May I ask how one would sign public keys when a "master key" is >>>> stored onto an USB stick ? >>>> >>>> So what ? My USB stick is formated using extFat so permissions are >>>> something unknown. >>> >>> The fact that you're using a FAT volume is the root cause here; FAT >>> filesystems do not have ownership or permissions, so when a modern OS >>> mounts them, it has to fake permissions for these files. >> >> Thank you for this precision. Are you aware of some "portable" and >> well supported by the 3-major OSes filesystem type ? > > Since your issue only affects signing of other keys - which normally is > not a daily scenario - what about using a GNU/Linux live system/CD/USB > for that purpose? > That way you can use a normal GNU/Linux supported filesystem and don't > have to worry whether to trust your normal OS or which filesystem is > compatible with all OSses you intend to use. Good catch. I did something close: refurbished and updated my old slackware GNU/linux system with FUSE exfat support. That does the job ! Thank you for your help. -- Xavier From matt at monaco.cx Thu Feb 12 08:42:06 2015 From: matt at monaco.cx (Matthew Monaco) Date: Thu, 12 Feb 2015 00:42:06 -0700 Subject: SSH generic socket forwarding for gpg-agent In-Reply-To: <87lhmnvn53.fsf@vigenere.g10code.de> References: <546248D5.9050509@monaco.cx> <87lhmnvn53.fsf@vigenere.g10code.de> Message-ID: <54DC594E.6020507@monaco.cx> On 12/04/2014 01:23 AM, Werner Koch wrote: > On Tue, 11 Nov 2014 18:35, matt at monaco.cx said: >> Does anyone have gpg-agent forwarding working with SSH's recent generic socket >> forwarding? Does it still require socat on one end, because I've only been able >> to specify a socket path on the left-hand side of the forwarding >> specification > > Yes, it works for me. However, I tested it with the current development > version of 2.1 which adds an extra features: > > --extra-socket NAME > Also listen on native gpg-agent connections on the given > socket. The intended use for this extra socket is to > setup a Unix domain socket forwarding from a remote > machine to this socket on the local machine. A gpg > running on the remote machine may then connect to the > local gpg-agent and use its private keys. This allows to > decrypt or sign data on a remote machine without exposing > the private keys to the remote machine. > > The documentation on how to use Unix domain sockets with ssh is a bit > sparse. You probably want to use "-o StreamLocalBindUnlink=yes" when > connecting to the remote host and you have to enable the forwarding > features (look for Stream* options). > Hey, thanks for the info! Just to follow up, I was able to get it working with e.g: ssh \ -R /.gnupg/S.gpg-agent:/.gnuppg/S.gpg-agent However, this only works when the private material is in private-keys-v1.d; it doesn't work with a smartcard =/ -oStreamLocalBindUnlick doesn't work either. I need to remove the socket on the remote end manually. And finally, I don't understand where --extra-socket comes into play here. In the 2.1.1 release notes, you say it supports a restricted command set. Is there a security risk, or is it just to prevent mistakes? Also, is the expected use then to forward S.gpg-agent on the remote end to e.g., S.gpg-agent-extra on the local, or should the remote end have a different name as well? -Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Thu Feb 12 13:10:54 2015 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 12 Feb 2015 13:10:54 +0100 Subject: [Announce] GnuPG 2.1.2 released In-Reply-To: <874mqs2q4o.fsf@vigenere.g10code.de> References: <874mqs2q4o.fsf@vigenere.g10code.de> Message-ID: <54DC984E.1070405@digitalbrains.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/02/15 20:40, Werner Koch wrote: > Since the start of the funding campaign in December several thousand people > have been kind enough to donate a total of 250000 Euro to support this > project. In addition the Linux Foundation gave a grant of $ 60000 for > 2015, Stripe.com and Facebook.com each pledged $ 50000 per year. > > I am amazed by this superb and unexpected support for the GnuPG project. > This will not only allow us to continue the project and hire at least a > second full time developer but gives us also the resources to improve > things which have been delayed for too long. I'm so glad to hear that, congratulations! \o/ If there's anybody who deserves it, it's you. I hope this gives you some well-deserved peace of mind regarding financially sustaining yourself and your family while continuing to work on GnuPG. Cheers! Peter. - -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From wk at gnupg.org Thu Feb 12 13:26:57 2015 From: wk at gnupg.org (Werner Koch) Date: Thu, 12 Feb 2015 13:26:57 +0100 Subject: Key keeps showing unknown trust In-Reply-To: <121598711.20150211232522@my_localhost> (MFPA's message of "Wed, 11 Feb 2015 23:25:22 +0000") References: <20150207194314.GA1381@athena.barrera.io> <54D873C7.50007@mailbox.org> <20150209092450.GA12071@athena.barrera.io> <121598711.20150211232522@my_localhost> Message-ID: <87d25fz566.fsf@vigenere.g10code.de> On Thu, 12 Feb 2015 00:25, 2014-667rhzu3dc-lists-groups at riseup.net said: > If GnuPG 2.1.x finds an existing secring.gpg, that is used. If not, > the new file format secring.kbx is used. Nope. You will never find a secring.kbc. 2.1 uses secring.gpg only in this ways: If secring.gpg exists and the file .gpg-v21-migrated does not exist, the secret keys from secring.gpg are imported to private-keys-v1.d/ and .gpg-v21-migrated is created. The migrated keys are stored in a special intermediate format below private-keys-v1.d/ and converted to the final format as soon as you use that key and thus have to enter the passphrase (which is needed for re-encryption). Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From philip.jackson at nordnet.fr Thu Feb 12 14:29:36 2015 From: philip.jackson at nordnet.fr (Philip Jackson) Date: Thu, 12 Feb 2015 14:29:36 +0100 Subject: [Announce] GnuPG 2.1.2 released In-Reply-To: <54DC984E.1070405@digitalbrains.com> References: <874mqs2q4o.fsf@vigenere.g10code.de> <54DC984E.1070405@digitalbrains.com> Message-ID: <54DCAAC0.3030608@nordnet.fr> On 12/02/15 13:10, Peter Lebbing wrote: > On 11/02/15 20:40, Werner Koch wrote: >> > Since the start of the funding campaign in December several thousand people >> > have been kind enough to donate a total of 250000 Euro to support this >> > project. In addition the Linux Foundation gave a grant of $ 60000 for >> > 2015, Stripe.com and Facebook.com each pledged $ 50000 per year. >> > >> > I am amazed by this superb and unexpected support for the GnuPG project. >> > This will not only allow us to continue the project and hire at least a >> > second full time developer but gives us also the resources to improve >> > things which have been delayed for too long. > I'm so glad to hear that, congratulations! \o/ > > If there's anybody who deserves it, it's you. I hope this gives you some > well-deserved peace of mind regarding financially sustaining yourself and your > family while continuing to work on GnuPG. I'll second all that - great news !! Philip -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From brian at minton.name Thu Feb 12 17:19:24 2015 From: brian at minton.name (Brian Minton) Date: Thu, 12 Feb 2015 11:19:24 -0500 Subject: emulating smartcard with Nexus 5 Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I recently got a new Nexus 5, with NFC. Supposedly it supports ISO 7816-4. Is there any possibility of, for instance, porting gnuk to android? I'd love to use my smartphone as a smartcard. Of course, the smartphone wouldn't have as many anti-tampering features as a typical smart card, so this would be mainly for educational purposes rather than true security. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EARYIAAYFAlTc0jMACgkQN7lQes/yAW7/OgEArP9gubqUWEhNV00RJJJreXw1 oe0NgnT8OVjEfCtiouQBAFNFNebTKfEM19bKt2+vVlXOzJRwp9/jqUsNqk29WyME =q0eT -----END PGP SIGNATURE----- From patrick at enigmail.net Thu Feb 12 18:31:12 2015 From: patrick at enigmail.net (Patrick Brunschwig) Date: Thu, 12 Feb 2015 18:31:12 +0100 Subject: [Announce] GnuPG 2.1.2 released In-Reply-To: <874mqs2q4o.fsf__35244.2019539469$1423684508$gmane$org@vigenere.g10code.de> References: <874mqs2q4o.fsf__35244.2019539469$1423684508$gmane$org@vigenere.g10code.de> Message-ID: <54DCE360.8030701@enigmail.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 11.02.15 20:40, Werner Koch wrote: > Hello! > > The GnuPG Project is pleased to announce the availability of the > third release of GnuPG modern: Version 2.1.2. The "usual" installer for Mac OS X is now available from https://sourceforge.net/p/gpgosx/docu/Download/ - -Patrick -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJU3ONdAAoJENsRh7ndX2k7o6EP+weTsb+ziwUfWYa6RCwwchn6 yRaAVGqGtsAOPZFHoodZq0P2ijOtuZn6vgFlWeHUqSV08eg3pIfX/zdm5yEkp/Gu Xe1x8yARXXacLmLaRKmw9+7bBnzFaYOVLjUo92VBH6eLWypuMl1pUY4PwpuWUxoa pX/wnX0mnd3sh9skwpGlMfQCWBjlwe8KIJEtE7odGhTwXHpCW0wGOLxb8eDXB5od kVYakaqscdRwVHnQ0aPeA0cBKN8nqK158L/Wia1S9m+ZhDjskK9lclXLEhnT3TMr 4T2cijlhojAC9IgiplP/pwwcl7grEQvfF4CaEalfUFRZclY9AHI3wtw50MU35RFs a/v4OGlY6edD1wZ8kuSDSPcAoC1B/qFSw5MrSi3aGPzN1ERXNjc6g/liOl5bn/Eh PqEUDox+g3SGGutqmmkp7Du5flwT5Cqxtys5cyOsk7ZYzQg6ApPNS/uFhTauYNw8 8T090SHEgpBqqAxU/kQEIwnh4AfiHfC/9EpmXTv2PpXeYItGlUuDgEQJ3ds2UsIt jLxn1r86kew+W9pI+aBbuQ+Gf0lQCgiXHzWYaVWvixWQe+hzcsAxnjhBLwu7TBmo uWSWeHnd8aqZ+1qqueY5WCIXeihCSjm27RIc549qR/bohN1r0isZv2+MZjMZ0IIg 3Km6HP92CucB2tKhdjL/ =X6xw -----END PGP SIGNATURE----- From wk at gnupg.org Thu Feb 12 20:46:20 2015 From: wk at gnupg.org (Werner Koch) Date: Thu, 12 Feb 2015 20:46:20 +0100 Subject: Pinpad card reader problems in 2.1.2 Message-ID: <87k2zmyktv.fsf@vigenere.g10code.de> Hi! I introduced a regression in 2.1.2 which may lead to a non working pinpad reader. If you experience problems, please try the attached patch. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-scd-Fix-regression-in-2.1.2-due-to-commit-2183683.patch Type: text/x-diff Size: 959 bytes Desc: not available URL: From wk at gnupg.org Thu Feb 12 21:30:11 2015 From: wk at gnupg.org (Werner Koch) Date: Thu, 12 Feb 2015 21:30:11 +0100 Subject: [Announce] GnuPG 2.1.2 released In-Reply-To: <54DCE360.8030701@enigmail.net> (Patrick Brunschwig's message of "Thu, 12 Feb 2015 18:31:12 +0100") References: <874mqs2q4o.fsf__35244.2019539469$1423684508$gmane$org@vigenere.g10code.de> <54DCE360.8030701@enigmail.net> Message-ID: <87egpuyiss.fsf@vigenere.g10code.de> On Thu, 12 Feb 2015 18:31, patrick at enigmail.net said: > The "usual" installer for Mac OS X is now available from > https://sourceforge.net/p/gpgosx/docu/Download/ I just added the URL to the download page. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From xavier at maillard.im Thu Feb 12 23:46:33 2015 From: xavier at maillard.im (Xavier Maillard) Date: Thu, 12 Feb 2015 23:46:33 +0100 Subject: MIME or inline signature ? Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello, in my quest of the perfect setup, I am asking myself what is the prefered way to sign a message: inline (like this one) or using a MIME header ? Is there a big thumb rule to respect ? Regards - -- Sent with my mu4e -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQQcBAEBCgAGBQJU3S03AAoJEN4v/Iaa+lFltkof/j3eXbkVpNETKZi8OXz9K+WX StI2wb3UczzBAJHfeBTPiTLRb+JOG2YvVSkEZ7VQauMK8lAzHzwpixT6eu3cNI6p z4IJXpuJd9Z6f7qOVD8/j3yeENe0929UGqcUyBK1+3Dzj7w+2Pae1R/6dSz8Hrhz 2e6q8J9HTq8O8mH5RdI44xXorMVNP7FEEpwBsqj7qzK/1kYGKnbsL6sI1VYdV/xy mtEoboOAe+Hi1fF8iVTOOIOHgJClInebMgeW6JvZOhPCzZde0OCYyd4elMbt0N0z JHEYutH3rMwMdQ1e+zNnSK9LWmtn4M470YwT9EERkw8x27HYWxRrPId2e2tF2pxp ATYyDZuVjt6Rj7JzW8Z/qOhlUgMbVRHIOPtBgLfcfSLayJXufjlri4C5U+HENbKL 0liAT2GPMTrDe23QuySn+UrFWgeX8gfnEso2eL4IiLjFsmF+CMOL3PIEpRMu1GGN pZ1RQdp9r3/JU4b6zwOEp2PtRglXIVriTtLvolf1MYQnUP7gFrlBzQe+Q8oaIB7y e8M9QbO373dsa2fMZcaAM8nSewA1xD7aUHSvrc+zDDh1Jj0bndbCMcriTX+0BPPI hxlErmONCJ2pfvfZhJInYaz8NO7S5QQM6YVTIrZSIchnuIPZ/KkRdOewcc2/krUi jCOkG5qxd0hg05duHI7R5SKvnLv6OSdU1qSNlyErgtnVGUw7xkRKCVFP0p0xF/Xz lCgztzoDeEaPSv01SavWz07ApEHh8LAS/PR4NZMQpSCACCLTho2IkgVfaQKlRBAJ awKp5hTIoh5mZlV58xF5gO/eHGjule26xBwOuaZhO29CBkeSNUF2LxsHHXduDtV2 llmsntJyPUvMOz4pXW2vyglmumnBK1QY4BlrkfY+VrwymyB67XPlDh0bbDATjKE6 g5WndMV2Bkgo9srpVYTrEcAD8iI/9kkzvMVvKaQYbJfrtvGbAlC+1KwrS1bET1Xu hPa3iJWImky8bY8mlSQP0rZBfQsej/7g5Da+TfvrEkWQ+QKG0XTPnEu7f/wbHjdU LQX8d16Z7dWY2aN0UTHI5zBObnuU/HjAKTGmMq8dhlGGXz5vL8Ru2Ssj1w8m8wv0 dfh+ysYFkkZlGMjeqRm/6S2LKnBrd/TCTHiczuZtZ85DSHHe/VyYKNc+VdwZH1wl dQBEUPG1CC3K6fGqzFP/nwqqN5PuzikP52177ICEx3VxuLwjU1esa+r2KJai7vCJ hvTpoyJhPlf5CTGaGZ8f2wkf5eRsXKVDstXV2FbgO9Jvkze9Uo+10oQ6XNntG/xi TTBnF6pFGsG8yrS1ecK/Oq2dSqif0g8cjjJ1SKUHhZr91pGWdr5X0UkmXjJIvP8= =KuOK -----END PGP SIGNATURE----- From philip.jackson at nordnet.fr Fri Feb 13 00:04:29 2015 From: philip.jackson at nordnet.fr (Philip Jackson) Date: Fri, 13 Feb 2015 00:04:29 +0100 Subject: moving up from 2.0.26 to 2.1.1 In-Reply-To: <54DD1F4D.8060102@mailbox.org> References: <54DA5787.3070903@nordnet.fr> <87iof9qsz2.fsf@alice.fifthhorseman.net> <54DB5CAF.1020903@nordnet.fr> <54DBA759.5080601@nordnet.fr> <87pp9gmcfi.fsf@alice.fifthhorseman.net> <54DBCB1F.80505@nordnet.fr> <54DD1F4D.8060102@mailbox.org> Message-ID: <54DD317D.4010203@nordnet.fr> Hi Stephan, On 12/02/15 22:46, Stephan Beck wrote: > Hi, Philip, > > Am 11.02.2015 um 22:35 schrieb Philip Jackson: >> On 11/02/15 21:16, Daniel Kahn Gillmor wrote: >>> On Wed 2015-02-11 14:02:49 -0500, Philip Jackson wrote: >>>> On 11/02/15 14:59, Brian Minton wrote: > > [snip] > > In synaptic: have you set the "always prefer the latest version" option under > Synaptic > Settings > Preferences > Distribution (tab)? If not, at least in > theory it might explain why your synaptic does not show you the latest version. > > Sorry, if the wording is not 100% correct. I have the German version installed, > and I'm retranslating it into English. Ok - this was already selected by default when I looked (and the English version is : Settings > Preferences > Distribution > "Always prefer the highest version" ) But I just found the latest version of gnupg available in Debian experimental by highlighting the gnupg2 package in Synaptic Manager and then selecting 'properties > Versions tab' It is not shown in the main window but only in the properties dialog box. But that's now clearer to me. >> >> If I do gpg2 --version, it comes back clearly with 2.0.26. and enigmail clearly >> indicates that it has found the gpg2 that I built. >> >> So, moving on, if I do : >> >> apt-get -t experimental install gnupg2 >> >> will I get 2.1.1 installed together with its dependencies ? >> >> And returning to my original questions, since it is written that 2.0* and 2.1 >> cannot co-exist, I suppose that I shall have to remove manually everything >> connected with my 2.0.26 ? > > If you click on "remove completely" in the main window, right-clicking on the > gnupg program list item, all modules should be removed. I think this option is > the equivalent to the --purge command option in apt. > Thanks for that suggestion, Stephan. I hadn't noticed that there were two different removal options in Synaptic Package Manager : removal and complete removal. In fact when I removed 2.0.22, I did so using ubuntu's 'Software Centre' using its removal button. It looks like the Software Centre only does a little bit of removal. How strange, it's like the old story of being only a little bit pregnant. Best, Philip -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From stebe at mailbox.org Thu Feb 12 22:46:53 2015 From: stebe at mailbox.org (Stephan Beck) Date: Thu, 12 Feb 2015 22:46:53 +0100 Subject: moving up from 2.0.26 to 2.1.1 In-Reply-To: <54DBCB1F.80505@nordnet.fr> References: <54DA5787.3070903@nordnet.fr> <87iof9qsz2.fsf@alice.fifthhorseman.net> <54DB5CAF.1020903@nordnet.fr> <54DBA759.5080601@nordnet.fr> <87pp9gmcfi.fsf@alice.fifthhorseman.net> <54DBCB1F.80505@nordnet.fr> Message-ID: <54DD1F4D.8060102@mailbox.org> Hi, Philip, Am 11.02.2015 um 22:35 schrieb Philip Jackson: > On 11/02/15 21:16, Daniel Kahn Gillmor wrote: >> On Wed 2015-02-11 14:02:49 -0500, Philip Jackson wrote: >>> On 11/02/15 14:59, Brian Minton wrote: [snip] > When I try your way from the command line, I get : > > $ apt-cache policy gnupg2 > gnupg2: > Installed: 2.0.22-3ubuntu1.1 > Candidate: 2.0.22-3ubuntu1.1 > Version table: > 2.1.1-1 0 > 1 http://ftp.debian.org/debian/ experimental/main amd64 Packages > *** 2.0.22-3ubuntu1.1 0 > 500 http://fr.archive.ubuntu.com/ubuntu/ trusty-updates/main amd64 Packages > 500 http://security.ubuntu.com/ubuntu/ trusty-security/main amd64 Packages > 100 /var/lib/dpkg/status > 2.0.22-3ubuntu1 0 > 500 http://fr.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages > > I'm not sure what this is telling me but I think it is indicating : > > 1. that 2.1.1 is available in experimental/main Packages. > 2. that I have 2.0.22 installed > 3. that latest available for my distro (candidate) is 2.0.22 > > Although I did, last summer, install 2.0.22 using the distro's software centre, > I subsequently used the same software centre to remove it before building 2.0.26 > on my own. So I don't know why the above indicates that 2.0.22 is installed. In synaptic: have you set the "always prefer the latest version" option under Synaptic > Settings > Preferences > Distribution (tab)? If not, at least in theory it might explain why your synaptic does not show you the latest version. Sorry, if the wording is not 100% correct. I have the German version installed, and I'm retranslating it into English. > > If I do gpg2 --version, it comes back clearly with 2.0.26. and enigmail clearly > indicates that it has found the gpg2 that I built. > > So, moving on, if I do : > > apt-get -t experimental install gnupg2 > > will I get 2.1.1 installed together with its dependencies ? > > And returning to my original questions, since it is written that 2.0* and 2.1 > cannot co-exist, I suppose that I shall have to remove manually everything > connected with my 2.0.26 ? If you click on "remove completely" in the main window, right-clicking on the gnupg program list item, all modules should be removed. I think this option is the equivalent to the --purge command option in apt. Best regards Stephan Beck -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Fri Feb 13 00:14:14 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 12 Feb 2015 18:14:14 -0500 Subject: MIME or inline signature ? In-Reply-To: References: Message-ID: <54DD33C6.1000105@sixdemonbag.org> > in my quest of the perfect setup, I am asking myself what is the > prefered way to sign a message: inline (like this one) or using a > MIME header ? > > Is there a big thumb rule to respect ? https://www.gnupg.org/faq/gnupg-faq.html#use_pgpmime -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3744 bytes Desc: S/MIME Cryptographic Signature URL: From dkg at fifthhorseman.net Fri Feb 13 00:44:03 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 12 Feb 2015 18:44:03 -0500 Subject: MIME or inline signature ? In-Reply-To: <54DD33C6.1000105@sixdemonbag.org> References: <54DD33C6.1000105@sixdemonbag.org> Message-ID: <87k2zmlmpo.fsf@alice.fifthhorseman.net> On Thu 2015-02-12 18:14:14 -0500, Robert J. Hansen wrote: >> in my quest of the perfect setup, I am asking myself what is the >> prefered way to sign a message: inline (like this one) or using a >> MIME header ? >> >> Is there a big thumb rule to respect ? > > https://www.gnupg.org/faq/gnupg-faq.html#use_pgpmime This part appears to be out of date: Since PGP/MIME can't reliably be sent to the three largest GnuPG mailing lists, it?s hard to claim that PGP/MIME is ready for widespread usage. For now, it?s best to use inline traffic unless you can be certain that PGP/MIME messages will not be mangled in transit. I don't know if this is true for PGP-Basics, but it is certainly not true for enigmail or gnupg-users. Please update the FAQ! --dkg, noting the irony of the parent message being sent with S/MIME, an entirely different standard -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From gniibe at fsij.org Fri Feb 13 00:55:50 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 13 Feb 2015 08:55:50 +0900 Subject: emulating smartcard with Nexus 5 In-Reply-To: References: Message-ID: <54DD3D86.3010701@fsij.org> Hello, Let me record a bit of history. On 02/13/2015 01:19 AM, Brian Minton wrote: > I recently got a new Nexus 5, with NFC. Supposedly it supports ISO > 7816-4. Is there any possibility of, for instance, porting gnuk to > android? I'd love to use my smartphone as a smartcard. Of course, the > smartphone wouldn't have as many anti-tampering features as a typical > smart card, so this would be mainly for educational purposes rather > than true security. In fact, Ueno (cc-ed) did something like that around 2007-2008. It was the precursor of Gnuk. IIRC, he wrote a paper describing his work. If he still has the code, it would help you. Since I didn't like smartphone (which is smart enough to cheat its users, by my interpretation), I wrote the code for ATmega 20MHz to implement OpenPGPcard functionality, inspired by his work. It took five second to sign RSA-1024. I demonstraded this work at FSFS 2008 in India, then, I demonstrated "gpg --card-status" worked with ATmega implementation in Japan Linux Symposium 2009, in Akihabara, Tokyo. After that, around 2010, experts claimed that we should not use RSA-1024 any more. So, I gave up my ATmega work, and sought another MCU candidate. That's the start of Gnuk with STM32F103. P.S. The ATmega implementation of RSA was done when I was an employee of National Institute of AIST, Japan, and it was registered as the work under AIST (perhaps, copyrighted by AIST). I left the code there when I left AIST in September, 2010. If interested, please contact AIST (not me). -- From jerry at seibercom.net Fri Feb 13 01:44:46 2015 From: jerry at seibercom.net (Jerry) Date: Thu, 12 Feb 2015 19:44:46 -0500 Subject: MIME or inline signature ? In-Reply-To: References: Message-ID: <20150212194446.18ff07c7@scorpio> On Thu, 12 Feb 2015 23:46:33 +0100, Xavier Maillard stated: > Hello, > > in my quest of the perfect setup, I am asking myself what is the > prefered way to sign a message: inline (like this one) or using a MIME > header ? > > Is there a big thumb rule to respect ? Inline totally destroys a "sig delimiter" and adds a lot of useless garbage to the message body. I never use it. If someone is using an MUA that cannot handle PGP/MIME that is their problem, not mine. -- Jerry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From m.mansfeld at mansfeld-elektronik.de Fri Feb 13 03:23:59 2015 From: m.mansfeld at mansfeld-elektronik.de (Matthias Mansfeld) Date: Fri, 13 Feb 2015 03:23:59 +0100 Subject: MIME or inline signature ? In-Reply-To: References: Message-ID: <20150213032359.Horde.WUmXLZV8S08p43fOMNKBpg1@webmail.df.eu> Zitat von Xavier Maillard : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hello, > > in my quest of the perfect setup, I am asking myself what is the > prefered way to sign a message: inline (like this one) or using a > MIME header ? > > Is there a big thumb rule to respect ? > > Regards > - -- > Sent with my mu4e Maybe I cannot offer a big rule for THE preferred way. Jerry is right, but maybe we HAVE to deal with recipients who have no influence to take a mail client which is capable to handle PGP/MIME sigbatures properly. Then it is also MY problem. If your mail client is able to select the way it signs depending on the recipient's address (for example GPGRelay, in fact a nice local proxy for mail clients which are completetly unable to do anything wich GnuPG) then you can let it sign for all "default" recipients with PGP/MIME and only for these who cannot handle this, with inline signature. Regards Matthias -- Matthias Mansfeld Elektronik * Leiterplattenlayout Neithardtstr. 3, 85540 Haar; Tel.: 089/4620 093-7, Fax: -8 Internet: http://www.mansfeld-elektronik.de GPG http://www.mansfeld-elektronik.de/gnupgkey/mansfeld.asc From rjh at sixdemonbag.org Fri Feb 13 04:18:25 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 12 Feb 2015 22:18:25 -0500 Subject: MIME or inline signature ? In-Reply-To: <87k2zmlmpo.fsf@alice.fifthhorseman.net> References: <54DD33C6.1000105@sixdemonbag.org> <87k2zmlmpo.fsf@alice.fifthhorseman.net> Message-ID: <54DD6D01.9040607@sixdemonbag.org> > I don't know if this is true for PGP-Basics, but it is certainly not > true for enigmail or gnupg-users. Please update the FAQ! It's still true for PGP-Basics; Enigmail's been bit by it within the last year, if memory serves, but it's been generally accepted; GnuPG's been AFAIK stable for it. I've got a few hours free tomorrow; I'll see about fixing this verbiage. I should also add that PGP/MIME *may* give protection to metadata (see Patrick's decision to use the creative header protection scheme you mentioned), with some verbiage about how only Enigmail has promised to implement it. But over the last 18 months or so the metadata issue has become important to a lot of people, so that should also be mentioned. As is my usual, once I draft something I'll post an easily human-readable diff to the mailing list and give people a chance to raise objections and concerns. I'm more the FAQ custodian than the FAQ maintainer -- I want everything in it to reflect community consensus, not just my own opinion. :) > --dkg, noting the irony of the parent message being sent with > S/MIME, an entirely different standard And the MIME attachment being mangled by the mailing list, yes, I agree. It's almost a bizarre endorsement of the attachment fragility idea... -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3744 bytes Desc: S/MIME Cryptographic Signature URL: From xavier at maillard.im Fri Feb 13 06:34:36 2015 From: xavier at maillard.im (Xavier Maillard) Date: Fri, 13 Feb 2015 06:34:36 +0100 Subject: MIME or inline signature ? In-Reply-To: <20150212194446.18ff07c7@scorpio> References: <20150212194446.18ff07c7@scorpio> Message-ID: Jerry writes: > On Thu, 12 Feb 2015 23:46:33 +0100, Xavier Maillard stated: > >> Hello, >> >> in my quest of the perfect setup, I am asking myself what is the >> prefered way to sign a message: inline (like this one) or using a MIME >> header ? >> >> Is there a big thumb rule to respect ? > > Inline totally destroys a "sig delimiter" and adds a lot of useless garbage > to the message body. I never use it. If someone is using an MUA that cannot > handle PGP/MIME that is their problem, not mine. I agree. So I'll go for PGP/mime. -- Sent with my mu4e From xavier at maillard.im Fri Feb 13 06:36:20 2015 From: xavier at maillard.im (Xavier Maillard) Date: Fri, 13 Feb 2015 06:36:20 +0100 Subject: MIME or inline signature ? In-Reply-To: <54DD33C6.1000105@sixdemonbag.org> References: <54DD33C6.1000105@sixdemonbag.org> Message-ID: Robert J. Hansen writes: >> in my quest of the perfect setup, I am asking myself what is the >> prefered way to sign a message: inline (like this one) or using a >> MIME header ? >> >> Is there a big thumb rule to respect ? > > https://www.gnupg.org/faq/gnupg-faq.html#use_pgpmime THank you for this pointer. I effectively remember this point in the old days. I am glad the situation is getting better. Regards -- Sent with my mu4e From des-apare.cido_77 at autistici.org Fri Feb 13 07:04:19 2015 From: des-apare.cido_77 at autistici.org (des-apare.cido_77 at autistici.org) Date: Fri, 13 Feb 2015 07:04:19 +0100 Subject: MIME or inline signature ? In-Reply-To: <20150213032359.Horde.WUmXLZV8S08p43fOMNKBpg1@webmail.df.eu> References: <20150213032359.Horde.WUmXLZV8S08p43fOMNKBpg1@webmail.df.eu> Message-ID: <54DD93E3.2070809@autistici.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > Maybe I cannot offer a big rule for THE preferred way. Jerry is > right, but maybe we HAVE to deal with recipients who have no > influence to take a mail client which is capable to handle PGP/MIME > sigbatures properly. Then it is also MY problem. I agree. With my PGP contacts I learned, that some can't handle PGP/MIME mails. The experience is, that the Addon Mailvelope (Firefox, Chrome) can't handle at all mails with attachment in PGP/MIME format. Also the Client K9 for smartphones. A compromise would be to set up per-recipient-rules in Enigmail to send inline mails to these contacts. Best regards Anton - -- des-apare.cido_77 at autistici dot org 2048R/0x6FE6F0B56FB0CD78, 2014-03-06 PGP: E87B D4A1 45A6 8D97 F672 E50E 6FE6 F0B5 6FB0 CD78 On 13/02/15 03:23, Matthias Mansfeld wrote: > > Zitat von Xavier Maillard : > >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 >> >> Hello, >> >> in my quest of the perfect setup, I am asking myself what is the >> prefered way to sign a message: inline (like this one) or using a >> MIME header ? >> >> Is there a big thumb rule to respect ? >> >> Regards - -- Sent with my mu4e > > Maybe I cannot offer a big rule for THE preferred way. Jerry is > right, but maybe we HAVE to deal with recipients who have no > influence to take a mail client which is capable to handle PGP/MIME > sigbatures properly. Then it is also MY problem. If your mail > client is able to select the way it signs depending on the > recipient's address (for example GPGRelay, in fact a nice local > proxy for mail clients which are completetly unable to do anything > wich GnuPG) then you can let it sign for all "default" recipients > with PGP/MIME and only for these who cannot handle this, with > inline signature. > > Regards Matthias -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQEcBAEBCAAGBQJU3ZPfAAoJEG/m8LVvsM14AM8IAJKwfqMc1k+1Y2YJ0tjbGC6F jrFIuxaqiRkr0Q0rg6Ty1Po8zzfctxuXAMnrRapZAL+ldyvkNrGRW07U0Bkhg83M C5k32cCHuyGjeT1v4Mcx4gExb33zoQBpHLi0EOZcW4VvNQ6RCpK8fBUIGgsi+tJM WBDuuPc70qFWVoA0JJP8vcdGzDg/DXwNtX0aiCBuzXZk8nsZUZKMkWAGDCkzrhpq RF819j1R7L+sUv6NSesoanWuutwDhdunjcEiGbklv0xQ4nlPBgwE6IkN862stuI3 Za8VziG+BdEwvBi0Zi5mlUMkOl1VhQ+x7BPvMTurUm35csoZNngEIMfdwhDQzHU= =EfOk -----END PGP SIGNATURE----- From cwr at cwrichardson.com Fri Feb 13 07:25:35 2015 From: cwr at cwrichardson.com (Christopher W. Richardson) Date: Fri, 13 Feb 2015 07:25:35 +0100 Subject: MIME or inline signature ? In-Reply-To: References: Message-ID: <7E7DD9E3-690C-4ADC-BF42-57622042E8D2@cwrichardson.com> FWIW, Mac Mail marked this message as spam. Not sure if it universally does that for all inline sigs, but ... FYI. Chris > On 12 Feb 2015, at 23:46, Xavier Maillard wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hello, > > in my quest of the perfect setup, I am asking myself what is the > prefered way to sign a message: inline (like this one) or using a MIME header ? > > Is there a big thumb rule to respect ? > > Regards > - -- > Sent with my mu4e > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > > iQQcBAEBCgAGBQJU3S03AAoJEN4v/Iaa+lFltkof/j3eXbkVpNETKZi8OXz9K+WX > StI2wb3UczzBAJHfeBTPiTLRb+JOG2YvVSkEZ7VQauMK8lAzHzwpixT6eu3cNI6p > z4IJXpuJd9Z6f7qOVD8/j3yeENe0929UGqcUyBK1+3Dzj7w+2Pae1R/6dSz8Hrhz > 2e6q8J9HTq8O8mH5RdI44xXorMVNP7FEEpwBsqj7qzK/1kYGKnbsL6sI1VYdV/xy > mtEoboOAe+Hi1fF8iVTOOIOHgJClInebMgeW6JvZOhPCzZde0OCYyd4elMbt0N0z > JHEYutH3rMwMdQ1e+zNnSK9LWmtn4M470YwT9EERkw8x27HYWxRrPId2e2tF2pxp > ATYyDZuVjt6Rj7JzW8Z/qOhlUgMbVRHIOPtBgLfcfSLayJXufjlri4C5U+HENbKL > 0liAT2GPMTrDe23QuySn+UrFWgeX8gfnEso2eL4IiLjFsmF+CMOL3PIEpRMu1GGN > pZ1RQdp9r3/JU4b6zwOEp2PtRglXIVriTtLvolf1MYQnUP7gFrlBzQe+Q8oaIB7y > e8M9QbO373dsa2fMZcaAM8nSewA1xD7aUHSvrc+zDDh1Jj0bndbCMcriTX+0BPPI > hxlErmONCJ2pfvfZhJInYaz8NO7S5QQM6YVTIrZSIchnuIPZ/KkRdOewcc2/krUi > jCOkG5qxd0hg05duHI7R5SKvnLv6OSdU1qSNlyErgtnVGUw7xkRKCVFP0p0xF/Xz > lCgztzoDeEaPSv01SavWz07ApEHh8LAS/PR4NZMQpSCACCLTho2IkgVfaQKlRBAJ > awKp5hTIoh5mZlV58xF5gO/eHGjule26xBwOuaZhO29CBkeSNUF2LxsHHXduDtV2 > llmsntJyPUvMOz4pXW2vyglmumnBK1QY4BlrkfY+VrwymyB67XPlDh0bbDATjKE6 > g5WndMV2Bkgo9srpVYTrEcAD8iI/9kkzvMVvKaQYbJfrtvGbAlC+1KwrS1bET1Xu > hPa3iJWImky8bY8mlSQP0rZBfQsej/7g5Da+TfvrEkWQ+QKG0XTPnEu7f/wbHjdU > LQX8d16Z7dWY2aN0UTHI5zBObnuU/HjAKTGmMq8dhlGGXz5vL8Ru2Ssj1w8m8wv0 > dfh+ysYFkkZlGMjeqRm/6S2LKnBrd/TCTHiczuZtZ85DSHHe/VyYKNc+VdwZH1wl > dQBEUPG1CC3K6fGqzFP/nwqqN5PuzikP52177ICEx3VxuLwjU1esa+r2KJai7vCJ > hvTpoyJhPlf5CTGaGZ8f2wkf5eRsXKVDstXV2FbgO9Jvkze9Uo+10oQ6XNntG/xi > TTBnF6pFGsG8yrS1ecK/Oq2dSqif0g8cjjJ1SKUHhZr91pGWdr5X0UkmXjJIvP8= > =KuOK > -----END PGP SIGNATURE----- > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From wk at gnupg.org Fri Feb 13 10:52:07 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 13 Feb 2015 10:52:07 +0100 Subject: MIME or inline signature ? In-Reply-To: <54DD6D01.9040607@sixdemonbag.org> (Robert J. Hansen's message of "Thu, 12 Feb 2015 22:18:25 -0500") References: <54DD33C6.1000105@sixdemonbag.org> <87k2zmlmpo.fsf@alice.fifthhorseman.net> <54DD6D01.9040607@sixdemonbag.org> Message-ID: <87pp9ew33s.fsf@vigenere.g10code.de> On Fri, 13 Feb 2015 04:18, rjh at sixdemonbag.org said: > And the MIME attachment being mangled by the mailing list, yes, I agree. > It's almost a bizarre endorsement of the attachment fragility idea... Which is a long standing problem of the Python mail library. Mailpile also had its trouble with that standard library. This needs to be fixed and we would get rid of a lot of problems. There are probably other ML managers which get it right. Switching to another ML software is not an option. Mailman simply is the standard for mailing lists and people are used to it. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From johanw at vulcan.xs4all.nl Fri Feb 13 11:19:06 2015 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Fri, 13 Feb 2015 11:19:06 +0100 Subject: MIME or inline signature ? In-Reply-To: <20150212194446.18ff07c7@scorpio> References: <20150212194446.18ff07c7@scorpio> Message-ID: <54DDCF9A.5070104@vulcan.xs4all.nl> On 13-02-2015 1:44, Jerry wrote: > Inline totally destroys a "sig delimiter" It is supposed to sign and/or encrypt the sig too. > and adds a lot of useless garbage to the message body. You need a mailclient to interpret that. Mail clients interprete Mime attachments too (or not). -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From martin at martinpaljak.net Fri Feb 13 10:39:05 2015 From: martin at martinpaljak.net (Martin Paljak) Date: Fri, 13 Feb 2015 11:39:05 +0200 Subject: emulating smartcard with Nexus 5 In-Reply-To: <54DD3D86.3010701@fsij.org> References: <54DD3D86.3010701@fsij.org> Message-ID: Hello, You need to emulate an OpenPGP via Host Card Emulation. You can get necessary parts from here: 1. OpenPGP applet. Try this: https://github.com/Yubico/ykneo-openpgp or This: https://github.com/martinpaljak/AppletPlayground 2. Emulator for running the applet code in Android: https://github.com/martinpaljak/vJCRE I have some code that did exactly that but was not published because of some technical limitation not related to possible software only OpenPGP: https://github.com/martinpaljak/mobiil-idkaart If you are capable of creating Android software with a GUI, I could help with the non-Android-GUI issues. Martin -- Martin +372 515 6495 On Fri, Feb 13, 2015 at 1:55 AM, NIIBE Yutaka wrote: > Hello, > > Let me record a bit of history. > > On 02/13/2015 01:19 AM, Brian Minton wrote: >> I recently got a new Nexus 5, with NFC. Supposedly it supports ISO >> 7816-4. Is there any possibility of, for instance, porting gnuk to >> android? I'd love to use my smartphone as a smartcard. Of course, the >> smartphone wouldn't have as many anti-tampering features as a typical >> smart card, so this would be mainly for educational purposes rather >> than true security. > > In fact, Ueno (cc-ed) did something like that around 2007-2008. It > was the precursor of Gnuk. IIRC, he wrote a paper describing his > work. If he still has the code, it would help you. > > Since I didn't like smartphone (which is smart enough to cheat its > users, by my interpretation), I wrote the code for ATmega 20MHz to > implement OpenPGPcard functionality, inspired by his work. It took > five second to sign RSA-1024. I demonstraded this work at FSFS 2008 > in India, then, I demonstrated "gpg --card-status" worked with ATmega > implementation in Japan Linux Symposium 2009, in Akihabara, Tokyo. > > After that, around 2010, experts claimed that we should not use > RSA-1024 any more. So, I gave up my ATmega work, and sought another > MCU candidate. > > That's the start of Gnuk with STM32F103. > > P.S. > The ATmega implementation of RSA was done when I was an employee of > National Institute of AIST, Japan, and it was registered as the work > under AIST (perhaps, copyrighted by AIST). I left the code there when > I left AIST in September, 2010. If interested, please contact AIST > (not me). > -- > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From stebe at mailbox.org Fri Feb 13 12:28:43 2015 From: stebe at mailbox.org (Stephan Beck) Date: Fri, 13 Feb 2015 12:28:43 +0100 Subject: MIME or inline signature ? In-Reply-To: References: Message-ID: <54DDDFEB.4020906@mailbox.org> Hi Xavier, Am 12.02.2015 um 23:46 schrieb Xavier Maillard: > Hello, sorry, just to inform you that I cannot verify your signature: While trying to verify it, Enigmail (German localization) reports the following: Enigmail-Sicherheitsinfo: Fehler - ?berpr?fung der Unterschrift fehlgeschlagen ?ffentlicher Schl?ssel DE2FFC869AFA5165 zur ?berpr?fung der Unterschrift ben?tigt FALSCHE Unterschrift von Xavier Maillard in English: (translated on-the-fly by myself) Enigmail-security info: Error - Failed to verify signature Public key xx required for signature verification BAD Signature from xx You might have signed your message with a key different from the one I can download from the keyserver. As a security measure I have assigned your key a non-trust attribute. Best regards Stephan Beck -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: OpenPGP digital signature URL: From 2014-667rhzu3dc-lists-groups at riseup.net Fri Feb 13 13:01:21 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Fri, 13 Feb 2015 12:01:21 +0000 Subject: MIME or inline signature ? In-Reply-To: <54DDCF9A.5070104@vulcan.xs4all.nl> References: <20150212194446.18ff07c7@scorpio> <54DDCF9A.5070104@vulcan.xs4all.nl> Message-ID: <1671415529.20150213120121@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Friday 13 February 2015 at 10:19:06 AM, in , Johan Wevers wrote: > On 13-02-2015 1:44, Jerry wrote: >> Inline totally destroys a "sig delimiter" In an OpenPGP-aware mail client, that is the decision of the developer. For example, is there any huge reason why it would be a bad idea to treat the same as they treat ? > It is supposed to sign and/or encrypt the sig too. >> and adds a lot of useless garbage to the message body. > You need a mailclient to interpret that. Mail clients > interprete Mime attachments too (or not). In my opinion, one of the strengths of Inline is that you _don't_ need a mail client to interpret it: the message can be pasted into a text file or a command window. - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net Maybe YOU have nothing to hide; that still leaves plenty you want to hide from! -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJU3eepXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwKDEH/jbh2mG6iKkRiNROUHjnV9a9 g2UosK2Ye9bycNIQrlhR2Jicie0URtzOgeCi889qcXO1z1TxlM+/QPdkGJyuaFbA R1CQouXaM8tXNek3DRc3r6DSU985Q0sQBGm2qsesxzN6cu6CcZcQYY0CmGs6hcY/ nrp3tC9REwTefMj/zBPuCuf6PJfW4ohI6U+VragDJQJi8xCjHpPTbBPItcaNWX2D n9qcJRDGxT/wNYcx77d86blEPKFeU2Ej+WJU9jLu+0js4a5Oi9bQXFBXHs/xwsz5 df9wsxCRxFQ3RstRwzOWzKi90T1k6EqxlmpPM+dT1Oj5v2Ud8ufJCyssHYdFZyaI vgQBFgoAZgUCVN3ntV8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45BFhAQAxrPhfKqDeFUgJ6wR/NMpSFgQX +rDsD6strw3YodyeQAEAdBaB5H3MrrINIydLXqWQ20pFW4Q81YjQ5+g8ZcopmAk= =2SaR -----END PGP SIGNATURE----- From xavier at maillard.im Fri Feb 13 13:21:54 2015 From: xavier at maillard.im (Xavier Maillard) Date: Fri, 13 Feb 2015 13:21:54 +0100 Subject: MIME or inline signature ? In-Reply-To: <54DD93E3.2070809@autistici.org> References: <20150213032359.Horde.WUmXLZV8S08p43fOMNKBpg1@webmail.df.eu> <54DD93E3.2070809@autistici.org> Message-ID: des-apare.cido_77 at autistici.org writes: >> Maybe I cannot offer a big rule for THE preferred way. Jerry is >> right, but maybe we HAVE to deal with recipients who have no >> influence to take a mail client which is capable to handle PGP/MIME >> sigbatures properly. Then it is also MY problem. > > I agree. With my PGP contacts I learned, that some can't handle > PGP/MIME mails. The experience is, that the Addon Mailvelope (Firefox, > Chrome) can't handle at all mails with attachment in PGP/MIME format. > Also the Client K9 for smartphones. > A compromise would be to set up per-recipient-rules in Enigmail to > send inline mails to these contacts. This is getting over complicated just to the purpose it deserves. Sadly. -- Sent with my mu4e From 2014-667rhzu3dc-lists-groups at riseup.net Fri Feb 13 13:22:23 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Fri, 13 Feb 2015 12:22:23 +0000 Subject: MIME or inline signature ? In-Reply-To: References: Message-ID: <377757768.20150213122223@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Thursday 12 February 2015 at 10:46:33 PM, in , Xavier Maillard wrote: > in my quest of the perfect setup, I am asking myself > what is the prefered way to sign a message: inline > (like this one) or using a MIME header ? My preference is Inline: I want everything right there in the message body where I can see it. Some people advocate PGP/MIME, which hides signatures and encrypted messages in attachments. Both standards are valid, neither is deprecated. I have seen it advised to use Inline for initial contact, and switch to MIME only after establishing the recipient can cope with it. But I can't find the reference at the moment, and I think it may be outdated advice. - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net It is not necessary to have enemies if you go out of your way to make friends hate you. -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJU3eyCXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwb2kH/30Y48/dFhbHsjaJriiF1XnF D8DsBr00vfBnkmZE8u0D/OyIeSBHA6BLZEwyrcI7sS4bPEgGsJTZLQ6BV+yJSz0e cLtIUoeS0500Y4EDEEC/lb64Lqk2HFBC3pvWpQyx544TYCm/rEokuoeUAPg64Arc MV7QWaO0opXxWbqqkMJdk+Szsblp23tMjcTaPRobUcfm6qhPLjnGCxRVLtFtzXyY rUAIdb9n/1ttp+7Pby4772uhH88i6L2sANnfGJf5UkD9ub4Fe8tBUeShMQK//nwn rw4jr0WUdcp9dnyWe7/dSNWGwN3NkF8Yby9mGcujc9oMK1OsOioh5eNq9AKV07SI vgQBFgoAZgUCVN3sll8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45P6cAQAQmfXw4RTx+PVLAyMKnc2zQiBr 2kTJ+KYid7vnt+y3XQEAaWa4Z4EWqFyP7fap/WgHCFRM3eAvpFRDLE7RhvBugw8= =lQ3i -----END PGP SIGNATURE----- From 2014-667rhzu3dc-lists-groups at riseup.net Fri Feb 13 13:38:09 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Fri, 13 Feb 2015 12:38:09 +0000 Subject: Key keeps showing unknown trust In-Reply-To: <87d25fz566.fsf@vigenere.g10code.de> References: <20150207194314.GA1381@athena.barrera.io> <54D873C7.50007@mailbox.org> <20150209092450.GA12071@athena.barrera.io> <121598711.20150211232522@my_localhost> <87d25fz566.fsf@vigenere.g10code.de> Message-ID: <1547700689.20150213123809@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Thursday 12 February 2015 at 12:26:57 PM, in , Werner Koch wrote: > Nope. You will never find a secring.kbc. 2.1 uses > secring.gpg only in this ways: > If secring.gpg exists and the file .gpg-v21-migrated > does not exist, the secret keys from secring.gpg are > imported to private-keys-v1.d/ and .gpg-v21-migrated is > created. > The migrated keys are stored in a special intermediate > format below private-keys-v1.d/ and converted to the > final format as soon as you use that key and thus have > to enter the passphrase (which is needed for > re-encryption). Thanks for the correction. I was confusing secret and public keyring files. - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net The problem is not that we're paranoid; it's that we're not paranoid enough. -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJU3fA0XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwYOUIAK72KDYIHggs/XpuncfBA/xd LSX7HcbSXitVVjDX3tkdG8YLxHDZcA/X3cp5rh2idUWVQ/yJv0mFs1Cvoqvrj6ov rhCxMJmPklkXhFDTsTiYI7H2Z3/EVAMoPjU1Bf/RmzmCMla8HOSu9fPughxCEQCL FovqNbKPPCYKzTpf9MFB8kP6R2OfuAsIFydaY7WBEAq3P417B8S8xSPu2jCg6SHC DF/E5y3fDIdFHAogoBZNHRU6ZSbZ2sEdRWrjHfwLv750D6cScYyYAnTUGMYdnTdP FSE5SsBFUQ1KQCP7vBOd4XojmS7HuC/NrTtJj7bqAyR4IIuxDcts0bn1IA7FytqI vgQBFgoAZgUCVN3wO18UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45B4AAQDtocKsGjtX6XxVOCa466S10Bjg LMN7aNZksf/bM8l6zQEAqcGDOJ9x2zLm+oZDIGqv/sGNoRMAnVVQSNLS1imWBAo= =xIda -----END PGP SIGNATURE----- From jerry at seibercom.net Fri Feb 13 14:14:25 2015 From: jerry at seibercom.net (Jerry) Date: Fri, 13 Feb 2015 08:14:25 -0500 Subject: MIME or inline signature ? Message-ID: <20150213081425.7a418830@scorpio> On Fri, 13 Feb 2015 12:22:23 +0000, MFPA stated: > My preference is Inline: I want everything right there in the message > body where I can see it. Exactly what is it you feel the over powering urge to see? -- Jerry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From brian at minton.name Fri Feb 13 15:07:35 2015 From: brian at minton.name (Brian Minton) Date: Fri, 13 Feb 2015 14:07:35 +0000 Subject: MIME or inline signature ? References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 My personal preference is inline, but I do have a request: if you have a 4096 bit RSA key, please don't sign inline. The signature block is ridiculously long. That's why I use DSA and especially ed25519 for signing. My main email access is on my phone, with copy/paste from Open Keychain. I've used K-9 mail, and it is okay but I prefer Google Inbox. I also have used mailvelope, but it didn't work very well IMHO. I do have enigmail available on my desktop, so I have no problem with PGP/MIME (or for that matter S/MIME) messages. -----BEGIN PGP SIGNATURE----- Version: OpenKeychain v3.1.2 iIAEAREIACghHEJyaWFuIE1pbnRvbiA8YnJpYW5AbWludG9uLm5hbWU+BQJU3gTs AAoJEGuOs6Blz7qpBm8A/RPcORSl0WQEs1hNy3Z+bFQ4fr/xqtjDqUO8+l2QHrKN AP9RndrrIDOzsjy9PY2PJMi+3hNcNUDG5AebCwHsSOifyg== =nmOf -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at digitalbrains.com Fri Feb 13 16:17:28 2015 From: peter at digitalbrains.com (Peter Lebbing) Date: Fri, 13 Feb 2015 16:17:28 +0100 Subject: MIME or inline signature =?UTF-8?Q?=3F?= In-Reply-To: References: Message-ID: On 2015-02-13 15:07, Brian Minton wrote: > if you have a 4096 bit RSA key, please dont sign inline. The > signature block is > ridiculously long. You'll find it is actually even an 8192 bit RSA key. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From bernhard at intevation.de Fri Feb 13 16:26:08 2015 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 13 Feb 2015 16:26:08 +0100 Subject: [Announce] GnuPG 2.1.2 released In-Reply-To: <874mqs2q4o.fsf@vigenere.g10code.de> References: <874mqs2q4o.fsf@vigenere.g10code.de> Message-ID: <201502131626.13795.bernhard@intevation.de> Werner, congratulations on getting 2.1.2 released! Also congratulations to all people in the GnuPG-Initiative for the funding success that we all had in the last weeks. Yes, Werner gets the funding, but I consider it a success of all people that actively contribute to GnuPG! On Wednesday 11 February 2015 at 20:40:39, Werner Koch wrote: > What's New in GnuPG-2.1 This was ment to read GnuPG-2.1.2 I guess, because of > A detailed description of the changes found in 2.1 can be found at > https://gnupg.org/faq/whats-new-in-2.1.html . I wasn't sure if this were actually the 2.1.2 diff or something else. A look at http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=NEWS;hb=HEAD clarified it. Again I think you or we as an initiative should write a description that fits the differences for the users. Best, Bernhard -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From mwood at IUPUI.Edu Fri Feb 13 16:44:02 2015 From: mwood at IUPUI.Edu (Mark H. Wood) Date: Fri, 13 Feb 2015 10:44:02 -0500 Subject: MIME or inline signature ? In-Reply-To: References: Message-ID: <20150213154402.GA23632@IUPUI.Edu> On Thu, Feb 12, 2015 at 11:46:33PM +0100, Xavier Maillard wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hello, > > in my quest of the perfect setup, I am asking myself what is the > prefered way to sign a message: inline (like this one) or using a MIME header ? > > Is there a big thumb rule to respect ? There is. In the words of the song: You can't please everyone, so you got to please yourself. -- Rick Nelson, "Garden Party" Some people will complain if you use one format, and others will complain if you use the other, so unless there's someone you especially want to favor (or annoy) you may as well send what you would most like to receive. (Isn't there some sort of Golden Rule about that?) > Regards > - -- > Sent with my mu4e > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > > iQQcBAEBCgAGBQJU3S03AAoJEN4v/Iaa+lFltkof/j3eXbkVpNETKZi8OXz9K+WX > StI2wb3UczzBAJHfeBTPiTLRb+JOG2YvVSkEZ7VQauMK8lAzHzwpixT6eu3cNI6p > z4IJXpuJd9Z6f7qOVD8/j3yeENe0929UGqcUyBK1+3Dzj7w+2Pae1R/6dSz8Hrhz > 2e6q8J9HTq8O8mH5RdI44xXorMVNP7FEEpwBsqj7qzK/1kYGKnbsL6sI1VYdV/xy > mtEoboOAe+Hi1fF8iVTOOIOHgJClInebMgeW6JvZOhPCzZde0OCYyd4elMbt0N0z > JHEYutH3rMwMdQ1e+zNnSK9LWmtn4M470YwT9EERkw8x27HYWxRrPId2e2tF2pxp > ATYyDZuVjt6Rj7JzW8Z/qOhlUgMbVRHIOPtBgLfcfSLayJXufjlri4C5U+HENbKL > 0liAT2GPMTrDe23QuySn+UrFWgeX8gfnEso2eL4IiLjFsmF+CMOL3PIEpRMu1GGN > pZ1RQdp9r3/JU4b6zwOEp2PtRglXIVriTtLvolf1MYQnUP7gFrlBzQe+Q8oaIB7y > e8M9QbO373dsa2fMZcaAM8nSewA1xD7aUHSvrc+zDDh1Jj0bndbCMcriTX+0BPPI > hxlErmONCJ2pfvfZhJInYaz8NO7S5QQM6YVTIrZSIchnuIPZ/KkRdOewcc2/krUi > jCOkG5qxd0hg05duHI7R5SKvnLv6OSdU1qSNlyErgtnVGUw7xkRKCVFP0p0xF/Xz > lCgztzoDeEaPSv01SavWz07ApEHh8LAS/PR4NZMQpSCACCLTho2IkgVfaQKlRBAJ > awKp5hTIoh5mZlV58xF5gO/eHGjule26xBwOuaZhO29CBkeSNUF2LxsHHXduDtV2 > llmsntJyPUvMOz4pXW2vyglmumnBK1QY4BlrkfY+VrwymyB67XPlDh0bbDATjKE6 > g5WndMV2Bkgo9srpVYTrEcAD8iI/9kkzvMVvKaQYbJfrtvGbAlC+1KwrS1bET1Xu > hPa3iJWImky8bY8mlSQP0rZBfQsej/7g5Da+TfvrEkWQ+QKG0XTPnEu7f/wbHjdU > LQX8d16Z7dWY2aN0UTHI5zBObnuU/HjAKTGmMq8dhlGGXz5vL8Ru2Ssj1w8m8wv0 > dfh+ysYFkkZlGMjeqRm/6S2LKnBrd/TCTHiczuZtZ85DSHHe/VyYKNc+VdwZH1wl > dQBEUPG1CC3K6fGqzFP/nwqqN5PuzikP52177ICEx3VxuLwjU1esa+r2KJai7vCJ > hvTpoyJhPlf5CTGaGZ8f2wkf5eRsXKVDstXV2FbgO9Jvkze9Uo+10oQ6XNntG/xi > TTBnF6pFGsG8yrS1ecK/Oq2dSqif0g8cjjJ1SKUHhZr91pGWdr5X0UkmXjJIvP8= > =KuOK > -----END PGP SIGNATURE----- > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: Digital signature URL: From vedaal at nym.hush.com Fri Feb 13 19:09:21 2015 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Fri, 13 Feb 2015 13:09:21 -0500 Subject: MIME or inline signature ? In-Reply-To: Message-ID: <20150213180921.AF7C2400B0@smtp.hushmail.com> On 2/12/2015 at 5:42 PM, "Xavier Maillard" wrote: > >Hello, > >in my quest of the perfect setup, I am asking myself what is the >prefered way to sign a message: inline (like this one) or using a >MIME header ? ===== If, by 'perfect', you mean that it's as close to possible to not be mangled, and/or tampered with, then there is a simple but often overlooked way to do this, while including any meta-data you wish to add: Armor Sign it ;-) Assuming everyone you correspond with, who is interested in your signature, is using GnuPG, then they can easily verify it. Assuming you just want to do this for the mailing list, where most people don't sign their messages anyway, then just send the plaintext without worrying about the signature. vedaal From mailing-lists at asatiifm.net Fri Feb 13 18:12:18 2015 From: mailing-lists at asatiifm.net (=?utf-8?Q?Ville_M=C3=A4=C3=A4tt=C3=A4?=) Date: Fri, 13 Feb 2015 19:12:18 +0200 Subject: MIME or inline signature ? In-Reply-To: <7E7DD9E3-690C-4ADC-BF42-57622042E8D2@cwrichardson.com> References: <7E7DD9E3-690C-4ADC-BF42-57622042E8D2@cwrichardson.com> Message-ID: <8364C525-7042-4575-8D9D-3259A87A8FFF@asatiifm.net> > On 13 Feb 2015, at 08:25, Christopher W. Richardson wrote: > > FWIW, Mac Mail marked this message as spam. Not sure if it universally does that for all inline sigs, but ... FYI. > > Chris Fortunately it certainly does not. -- Ville -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: Message signed with OpenPGP using GPGMail URL: From johanw at vulcan.xs4all.nl Fri Feb 13 19:57:10 2015 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Fri, 13 Feb 2015 19:57:10 +0100 Subject: MIME or inline signature ? In-Reply-To: <20150213154402.GA23632@IUPUI.Edu> References: <20150213154402.GA23632@IUPUI.Edu> Message-ID: <54DE4906.4020109@vulcan.xs4all.nl> On 13-02-2015 16:44, Mark H. Wood wrote: > Some people will complain if you use one format, and others will > complain if you use the other, so unless there's someone you > especially want to favor (or annoy) you may as well send what you > would most like to receive. (Isn't there some sort of Golden Rule > about that?) Be liberal in what you accept, and conservative in what you send: https://en.wikipedia.org/wiki/Robustness_principle -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From dkg at fifthhorseman.net Fri Feb 13 20:03:49 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 13 Feb 2015 14:03:49 -0500 Subject: Key keeps showing unknown trust In-Reply-To: <1547700689.20150213123809@my_localhost> References: <20150207194314.GA1381@athena.barrera.io> <54D873C7.50007@mailbox.org> <20150209092450.GA12071@athena.barrera.io> <121598711.20150211232522@my_localhost> <87d25fz566.fsf@vigenere.g10code.de> <1547700689.20150213123809@my_localhost> Message-ID: <87zj8hiqga.fsf@alice.fifthhorseman.net> On Fri 2015-02-13 07:38:09 -0500, MFPA wrote: > Thanks for the correction. I was confusing secret and public keyring > files. I don't think gpg 2.1 will use any pubring.gpg if pubring.kbx exists, though. gpg2 --list-keys for me looks at /home/dkg/.gnupg/pubring.kbx even though /home/dkg/.gnupg/pubring.gpg exists. --dkg From wk at gnupg.org Fri Feb 13 20:23:26 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 13 Feb 2015 20:23:26 +0100 Subject: [Announce] GnuPG 2.1.2 released In-Reply-To: <201502131626.13795.bernhard@intevation.de> (Bernhard Reiter's message of "Fri, 13 Feb 2015 16:26:08 +0100") References: <874mqs2q4o.fsf@vigenere.g10code.de> <201502131626.13795.bernhard@intevation.de> Message-ID: <8761b5vcnl.fsf@vigenere.g10code.de> On Fri, 13 Feb 2015 16:26, bernhard at intevation.de said: >> What's New in GnuPG-2.1 > > This was ment to read GnuPG-2.1.2 I guess, because of No, this describes what is new in the 2.1 branch. 2.1.2 is basically a bug fix release. > clarified it. Again I think you or we as an initiative should write > a description that fits the differences for the users. It is a bug fix and the NEWS file shows what has been fixes (or added). I may evntually update the whats-new-in-2.1. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From rjh at sixdemonbag.org Fri Feb 13 20:41:14 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 13 Feb 2015 14:41:14 -0500 Subject: MIME or inline signature ? In-Reply-To: <54DE4906.4020109@vulcan.xs4all.nl> References: <20150213154402.GA23632@IUPUI.Edu> <54DE4906.4020109@vulcan.xs4all.nl> Message-ID: <54DE535A.2060205@sixdemonbag.org> > Be liberal in what you accept, and conservative in what you send: > https://en.wikipedia.org/wiki/Robustness_principle It's worth noting that Postel (the guy who first formulated it) was very dissatisfied with how people tended to interpret Postel's Law. Per him, he felt most people who quoted Postel's Law were confused on the difference between 'liberal' and 'foolish', and tried to justify foolish engineering decisions on the basis of a liberal acceptance policy. Postel's sentiments were more, "Reject traffic that does not conform to the spec, even if it's in common use; accept traffic that conforms to the protocol spec, even if it's exotic; and only generate traffic that conforms to both spec and common use." Unfortunately, that loses much of the poetry of the original phrasing. This has long been one of my complaints about the way GnuPG gets used. GnuPG will accept and generate some pretty darn exotic traffic ("let's use SHA-224 with ECDSA and Camellia-256!"), which is good: that's exactly what you want in a toolkit. But just because we can do things like this doesn't mean we actually should... -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3744 bytes Desc: S/MIME Cryptographic Signature URL: From dougb at dougbarton.email Fri Feb 13 21:39:02 2015 From: dougb at dougbarton.email (Doug Barton) Date: Fri, 13 Feb 2015 12:39:02 -0800 Subject: MIME or inline signature ? In-Reply-To: <1671415529.20150213120121@my_localhost> References: <20150212194446.18ff07c7@scorpio> <54DDCF9A.5070104@vulcan.xs4all.nl> <1671415529.20150213120121@my_localhost> Message-ID: <54DE60E6.8090800@dougbarton.email> On 2/13/15 4:01 AM, MFPA wrote: > In an OpenPGP-aware mail client, that is the decision of the > developer. For example, is there any huge reason why it would be a bad > idea to treat the same as they > treat ? And Enigmail, for example, can do exactly that. :) Doug From dkg at fifthhorseman.net Fri Feb 13 22:06:46 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 13 Feb 2015 16:06:46 -0500 Subject: moving up from 2.0.26 to 2.1.1 In-Reply-To: <54DBCB1F.80505@nordnet.fr> References: <54DA5787.3070903@nordnet.fr> <87iof9qsz2.fsf@alice.fifthhorseman.net> <54DB5CAF.1020903@nordnet.fr> <54DBA759.5080601@nordnet.fr> <87pp9gmcfi.fsf@alice.fifthhorseman.net> <54DBCB1F.80505@nordnet.fr> Message-ID: <87h9upikrd.fsf@alice.fifthhorseman.net> On Wed 2015-02-11 16:35:27 -0500, Philip Jackson wrote: > If I do gpg2 --version, it comes back clearly with 2.0.26. and enigmail clearly > indicates that it has found the gpg2 that I built. > > So, moving on, if I do : > > apt-get -t experimental install gnupg2 > > will I get 2.1.1 installed together with its dependencies ? you should, as long as all of those dependencies are satisfiable in either debian experimental or ubuntu trusty. debian experimental is not guaranteed to have dependencies satisfied internally (debian unstable users should be able to install experimental packages without trouble though). apt will refuse to start the install if it can't satisfy the dependencies though, so you can try it out without worrying that it'll leave you in a half-broken state. > And returning to my original questions, since it is written that 2.0* and 2.1 > cannot co-exist, I suppose that I shall have to remove manually everything > connected with my 2.0.26 ? I suppose so, but i don't know how you installed 2.0.26 either, so i don't know how to remove it, sorry! --dkg From xavier at maillard.im Fri Feb 13 22:40:32 2015 From: xavier at maillard.im (Xavier Maillard) Date: Fri, 13 Feb 2015 22:40:32 +0100 Subject: MIME or inline signature ? In-Reply-To: References: Message-ID: Peter Lebbing writes: > On 2015-02-13 15:07, Brian Minton wrote: >> if you have a 4096 bit RSA key, please dont sign inline. The >> signature block is >> ridiculously long. > > You'll find it is actually even an 8192 bit RSA key. Yes sorry. I should add a smaller key for that purpose ... Regards -- Sent with my mu4e From johanw at vulcan.xs4all.nl Fri Feb 13 23:05:26 2015 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Fri, 13 Feb 2015 23:05:26 +0100 Subject: MIME or inline signature ? In-Reply-To: <54DE535A.2060205@sixdemonbag.org> References: <20150213154402.GA23632@IUPUI.Edu> <54DE4906.4020109@vulcan.xs4all.nl> <54DE535A.2060205@sixdemonbag.org> Message-ID: <54DE7526.2050507@vulcan.xs4all.nl> On 13-02-2015 20:41, Robert J. Hansen wrote: > It's worth noting that Postel (the guy who first formulated it) was very > dissatisfied with how people tended to interpret Postel's Law. I think Godwin is even more dissatisfied. :-) > This has long been one of my complaints about the way GnuPG gets used. > GnuPG will accept and generate some pretty darn exotic traffic ("let's > use SHA-224 with ECDSA and Camellia-256!"), which is good: that's > exactly what you want in a toolkit. But just because we can do things > like this doesn't mean we actually should... Hmmm. Some exotic uses with ElGamal keys were removed after a bug was discovered AFAIK. And thinking on some discussions about pgp 2 compatibility I still have some complains about that. But let's not reopen that discussion again. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From BM-2cTjsegDfZQNGQWUQjSwro6jrWLC9B3MN3 at bitmessage.ch Sat Feb 14 01:54:44 2015 From: BM-2cTjsegDfZQNGQWUQjSwro6jrWLC9B3MN3 at bitmessage.ch (BM-2cTjsegDfZQNGQWUQjSwro6jrWLC9B3MN3 at bitmessage.ch) Date: Fri, 13 Feb 2015 19:54:44 -0500 Subject: Tilde (~) in valid email address Message-ID: When generating a uid for a key using gpg2 (2.0.25), and attempting to input an email address containing a tilde (~), I receive an invalid email error. There seems to be no way I can find to bypass this restriction, and use my "invalid" email. Such characters can be used in i2bote addresses, and when managing this i2p-based messaging service through a mail client like Thunderbird or Claws-mail, it would be nice to be able to auto-select recipients and keys via email address, and to be able to distribute my key with an accurate email bound to it. I realize this situation is currently limited to a rather small set of users, though was wondering whether anyone knew how to force the use of such an invalid email, or whether it is worth eliminating this particular constraint on email formatting. Cheers and thanks, From dkg at fifthhorseman.net Fri Feb 13 23:42:34 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 13 Feb 2015 17:42:34 -0500 Subject: Sign key with externalized master key In-Reply-To: References: <87fvacpm3k.fsf@alice.fifthhorseman.net> Message-ID: <87wq3lh1r9.fsf@alice.fifthhorseman.net> On Wed 2015-02-11 17:31:42 -0500, Xavier Maillard wrote: > Daniel Kahn Gillmor writes: > >> The fact that you're using a FAT volume is the root cause here; FAT >> filesystems do not have ownership or permissions, so when a modern OS >> mounts them, it has to fake permissions for these files. > > Thank you for this precision. Are you aware of some "portable" and > well supported by the 3-major OSes filesystem type ? FAT, alas, is the portable filesystem that you're looking for. UDF, mentioned elsewhere in this thread, is a read-only filesystem, and i think it doesn't have ownership or permissions either. I see two approaches: a) figure out how to get each operating system to mount the volume with tighter permissions b) convince gpg that looser permissions on fat32 filesystems are acceptable I think (b) is the wrong way to go -- gpg is pointing out, rightly, that your sensitive data is exposed. So that leaves (a), which probably needs to be fixed anyway. Your operating system is exposing sensitive data from your USB stick (which is supposed to be only yours, since you plugged it in while you were in control of the machine) to any other user account on the computer. Reporting this bug to your OS vendor would be a good thing, because it would help other users of the same OS. --dkg From dkg at fifthhorseman.net Fri Feb 13 23:23:03 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 13 Feb 2015 17:23:03 -0500 Subject: SSH generic socket forwarding for gpg-agent In-Reply-To: <87lhmnvn53.fsf@vigenere.g10code.de> References: <546248D5.9050509@monaco.cx> <87lhmnvn53.fsf@vigenere.g10code.de> Message-ID: <873869ih88.fsf@alice.fifthhorseman.net> On Thu 2014-12-04 03:23:52 -0500, Werner Koch wrote: > On Tue, 11 Nov 2014 18:35, matt at monaco.cx said: >> Does anyone have gpg-agent forwarding working with SSH's recent generic socket >> forwarding? Does it still require socat on one end, because I've only been able >> to specify a socket path on the left-hand side of the forwarding >> specification > > Yes, it works for me. However, I tested it with the current development > version of 2.1 which adds an extra features: > > --extra-socket NAME > Also listen on native gpg-agent connections on the given > socket. The intended use for this extra socket is to > setup a Unix domain socket forwarding from a remote > machine to this socket on the local machine. A gpg > running on the remote machine may then connect to the > local gpg-agent and use its private keys. This allows to > decrypt or sign data on a remote machine without exposing > the private keys to the remote machine. > > The documentation on how to use Unix domain sockets with ssh is a bit > sparse. You probably want to use "-o StreamLocalBindUnlink=yes" when > connecting to the remote host and you have to enable the forwarding > features (look for Stream* options). Encouraging this kind of use seems risky. I certainly wouldn't want to do it without being able to have gpg-agent prompt me on my local machine for each use of the key. Its current silent operation once the passphrase is cached seems ripe for abuse by anyone in control of the remote account. Could gpg-agent have a setting (per-key? per-agent?) that would have it use pinentry for prompting? The traditional argument against this sort of feature is that someone with control over your local socket would most likely have control over your graphical environment, and therefore could dismiss or hide any prompt that comes up (so the prompting is a false sense of security). I'm not sure i buy this argument in general (i see it as defense-in-depth rather than a false sense of security, since it's one more hurdle the attacker needs to clear), but it certainly doesn't hold when there is a clear security boundary like gpg-agent forwarded over a network socket. --dkg From rjh at sixdemonbag.org Sat Feb 14 03:49:24 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 13 Feb 2015 21:49:24 -0500 Subject: Sign key with externalized master key In-Reply-To: <87wq3lh1r9.fsf@alice.fifthhorseman.net> References: <87fvacpm3k.fsf@alice.fifthhorseman.net> <87wq3lh1r9.fsf@alice.fifthhorseman.net> Message-ID: <54DEB7B4.6070301@sixdemonbag.org> > FAT, alas, is the portable filesystem that you're looking for. NTFS also works. Linux can read/write NTFS through NTFS-3G and FUSE, and a port exists for OS X as well. And yes, the stack is 100% libre. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3744 bytes Desc: S/MIME Cryptographic Signature URL: From brian at minton.name Sat Feb 14 04:29:56 2015 From: brian at minton.name (Brian Minton) Date: Fri, 13 Feb 2015 22:29:56 -0500 Subject: Sign key with externalized master key In-Reply-To: <54DEB7B4.6070301@sixdemonbag.org> References: <87fvacpm3k.fsf@alice.fifthhorseman.net> <87wq3lh1r9.fsf@alice.fifthhorseman.net> <54DEB7B4.6070301@sixdemonbag.org> Message-ID: The wikipedia article on UDF mentions write support in all major OSes. It also supports POSIX permissions. On Fri, Feb 13, 2015 at 9:49 PM, Robert J. Hansen wrote: >> FAT, alas, is the portable filesystem that you're looking for. > > NTFS also works. Linux can read/write NTFS through NTFS-3G and FUSE, > and a port exists for OS X as well. And yes, the stack is 100% libre. :) > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > From dkg at fifthhorseman.net Sat Feb 14 05:14:45 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 13 Feb 2015 23:14:45 -0500 Subject: Tilde (~) in valid email address In-Reply-To: References: Message-ID: <87r3ttgmdm.fsf@alice.fifthhorseman.net> On Fri 2015-02-13 19:54:44 -0500, BM-2cTjsegDfZQNGQWUQjSwro6jrWLC9B3MN3 at bitmessage.ch wrote: > When generating a uid for a key using gpg2 (2.0.25), and attempting to > input an email address containing a tilde (~), I receive an invalid > email error. There seems to be no way I can find to bypass this > restriction, and use my "invalid" email. have you tried adding the --expert flag when doing --gen-key? if that doesn't work, have you looked into doing batch key creation? see the "unattended key generation" section of the manual for explanation of how to do that: https://gnupg.org/documentation/manuals/gnupg/Unattended-GPG-key-generation.html hth, --dkg From mk at fsfe.org Sat Feb 14 09:00:22 2015 From: mk at fsfe.org (Matthias Kirschner) Date: Sat, 14 Feb 2015 09:00:22 +0100 Subject: I love Free Software: Thanks to all the GnuPG contributors Message-ID: <20150214080022.GR19689@mbwg.de> Dear GnuPG developers and contributors, today is ?I love Free Software?-Day. A day to thank all the hard working people behind Free Software. So instead a bug report, a feature request, or discussing a problem today I want to thank all the people involved in GnuPG coding and promoting. This is for you: http://blogs.fsfe.org/mk/i-love-free-software-thanks-to-all-the-gnupg-contributors/ Thank you! I love what you are doing! Matthias -- Matthias Kirschner - Vice President FSFE Sch?nhauser Allee 6/7, 10119 Berlin, t +49-30-27595290 Weblog (blogs.fsfe.org/mk) - Contact (fsfe.org/about/kirschner) Receive monthly Free Software news (fsfe.org/news/newsletter.html) Your donation enables our work (fsfe.org/donate) From gniibe at fsij.org Sat Feb 14 10:36:07 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Sat, 14 Feb 2015 18:36:07 +0900 Subject: ilovefs: Thank you, Werner and GnuPG users and developers Message-ID: <54DF1707.4090406@fsij.org> Hello, Werner and GnuPG lovers, I'd like to share Matthias Kirschner's article today. http://blogs.fsfe.org/mk/i-love-free-software-thanks-to-all-the-gnupg-contributors/ And I'd like to say, thank you to all in this opportunity. Well, let me wrote something to celebrate http://ilovefs.org/ In 1999, I met Werner when he visited Japan for FSF seminar in Tokyo. Yes, we exchanged GPG public keys at that time. Then, in 2004, when I visited Germany to join LinuxTag in Karlsruhe, I visited FSFE booth. IIRC, Werner gave me OpenPGPcard version 1.0 (That's _the_ cause which eventually resulted Gnuk). In return, I taught my invention of GDHProtocol: http://www.gniibe.org/pages/gdhp.html Perhaps, some people remembered that we played GDHP in front of the FSFE booth. This time, we exchanged the disks. In the autumn of 2010, I started writing Gnuk, and it caused me to join GnuPG development, so that I could improve scdaemon. In 2011, I signed contracts between FSF to assign copyright. I remember that the counter-part signer of GnuPG was Peter, and the one of Libgcrypt was John, because of personnel changes in FSF. At that time, I didn't expect more involvement than scdaemon, but Werner was right. Gradually, my involvement increased. I happened to review or modify routines in libgcrypt for public key cryptography or lower level functions for that. In 2013, I reviewed ECC code, and then, hacked code for exponentiation to recover performance regression. Now, I'm trying to support Curve25519 in GnuPG. This year, I plan to join Debconf 15 to meet Werner again. If possible, I'd like to play GDHP there. Happy "I love Free Software Day 2015", -- From mailinglisten at hauke-laging.de Sat Feb 14 11:54:47 2015 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Sat, 14 Feb 2015 11:54:47 +0100 Subject: Tilde (~) in valid email address In-Reply-To: References: Message-ID: <2802239.UcSH3iUoTg@inno> Am Fr 13.02.2015, 19:54:44 schrieb @bitmessage.ch: > When generating a uid for a key using gpg2 (2.0.25), and attempting to > input an email address containing a tilde (~), I receive an invalid > email error. There seems to be no way I can find to bypass this > restriction, and use my "invalid" email. You need --allow-freeform-uid to disable this check. Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 603 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Sat Feb 14 14:28:19 2015 From: wk at gnupg.org (Werner Koch) Date: Sat, 14 Feb 2015 14:28:19 +0100 Subject: SSH generic socket forwarding for gpg-agent In-Reply-To: <873869ih88.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 13 Feb 2015 17:23:03 -0500") References: <546248D5.9050509@monaco.cx> <87lhmnvn53.fsf@vigenere.g10code.de> <873869ih88.fsf@alice.fifthhorseman.net> Message-ID: <87d25ctyfg.fsf@vigenere.g10code.de> On Fri, 13 Feb 2015 23:23, dkg at fifthhorseman.net said: > Encouraging this kind of use seems risky. I certainly wouldn't want to > do it without being able to have gpg-agent prompt me on my local machine > for each use of the key. Its current silent operation once the Similar as with smartcards this feature protect against key compromise but not against misuse of the key. > Could gpg-agent have a setting (per-key? per-agent?) that would have it > use pinentry for prompting? Good idea. We can disable the cache in this case by default and allow it only by option - either for all keys or (with a bit more code) for a selected set of keys. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Sat Feb 14 14:39:56 2015 From: wk at gnupg.org (Werner Koch) Date: Sat, 14 Feb 2015 14:39:56 +0100 Subject: Key keeps showing unknown trust In-Reply-To: <87zj8hiqga.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 13 Feb 2015 14:03:49 -0500") References: <20150207194314.GA1381@athena.barrera.io> <54D873C7.50007@mailbox.org> <20150209092450.GA12071@athena.barrera.io> <121598711.20150211232522@my_localhost> <87d25fz566.fsf@vigenere.g10code.de> <1547700689.20150213123809@my_localhost> <87zj8hiqga.fsf@alice.fifthhorseman.net> Message-ID: <878ug0txw3.fsf@vigenere.g10code.de> On Fri, 13 Feb 2015 20:03, dkg at fifthhorseman.net said: > gpg2 --list-keys for me looks at /home/dkg/.gnupg/pubring.kbx even > though /home/dkg/.gnupg/pubring.gpg exists. Right, but only if pubring.kbx has the OpenPGP flag set: $ kbxutil ~/.gnupg/pubring.kbx | head -10 | grep ^Flag Flags: 0002 (openpgp) This flag is set as soon as an OpenPGP key is inserted into pubring.kbx. This is required because pubring.kbx has always been used to store X.509 keys. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Sat Feb 14 14:43:54 2015 From: wk at gnupg.org (Werner Koch) Date: Sat, 14 Feb 2015 14:43:54 +0100 Subject: MIME or inline signature ? In-Reply-To: <54DE7526.2050507@vulcan.xs4all.nl> (Johan Wevers's message of "Fri, 13 Feb 2015 23:05:26 +0100") References: <20150213154402.GA23632@IUPUI.Edu> <54DE4906.4020109@vulcan.xs4all.nl> <54DE535A.2060205@sixdemonbag.org> <54DE7526.2050507@vulcan.xs4all.nl> Message-ID: <874mqotxph.fsf@vigenere.g10code.de> On Fri, 13 Feb 2015 23:05, johanw at vulcan.xs4all.nl said: > Hmmm. Some exotic uses with ElGamal keys were removed after a bug was > discovered AFAIK. And thinking on some discussions about pgp 2 The reason for Elgamal signing keys was that back when I started with GnuPG it was not clear whether DSA was patented. Thus using Elgamal for signing was the only clearly non-patented method. Only in the course of developing OpenPGP in 1998 it got clear that we can use DSA without problems. Gpg than changed to that. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From 2014-667rhzu3dc-lists-groups at riseup.net Sat Feb 14 15:33:00 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Sat, 14 Feb 2015 14:33:00 +0000 Subject: MIME or inline signature ? In-Reply-To: <54DE535A.2060205@sixdemonbag.org> References: <20150213154402.GA23632@IUPUI.Edu> <54DE4906.4020109@vulcan.xs4all.nl> <54DE535A.2060205@sixdemonbag.org> Message-ID: <534769852.20150214143300@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Friday 13 February 2015 at 7:41:14 PM, in , Robert J. Hansen wrote: > Postel's sentiments were more, "Reject traffic that > does not conform to the spec, even if it's in common > use; accept traffic that conforms to the protocol spec, > even if it's exotic; and only generate traffic that > conforms to both spec and common use." Unfortunately, > that loses much of the poetry of the original phrasing. Rejecting traffic that does not conform to the spec, even if it's in common use is counter-intuitive. It seems to be denying yourself access to some of the incoming traffic for the sake of pedantry, which sounds like it would harm interoperability. But, of course, the point of having a spec is interoperability. - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net No man ever listened himself out of a job -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJU31yqXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwanYIAJYsJWmUywdxcm9yRR0KUBmC i+EVmgti1M2wwB/DOgTTw5P1BlTRI4ISuJDF/p1y5AUC5lP25sMpFlWYcXWTT/kD hxeYugs1BaQ9CG1SGk9FuC1xd6fQNAzXtl4gmhNdqyMSXUzVYGJESzxREUrFBpSE C7NZpBBMJ7gDTrzSB13oX0AvaPcxnYz1o3AppA2aRVGkWRy6sOAxag9YIlRLV49F PNBHxRN+XfH2HxA9iPo6fGAMqiQI569QJ/GsvXK4NhfTVSCxRYCRgVib5ryuWc4M xYcTP/nGSBPH+N3Ak8yxHdmEQvUi0/mbOOwJBF8dknayUl+vjChrNtSjiGc5AYGI vgQBFgoAZgUCVN9cu18UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45JThAQDO5+KeIfP6fJDJodyXY/nEV4Xd OVHhqT+p2siO0B8WSwEAYcpk1OIAmfdWXTEjWKqHMmK6UsB+oL3+c2aWd6KbXgw= =MUbx -----END PGP SIGNATURE----- From 2014-667rhzu3dc-lists-groups at riseup.net Sat Feb 14 15:39:35 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Sat, 14 Feb 2015 14:39:35 +0000 Subject: MIME or inline signature ? In-Reply-To: <20150213081425.7a418830@scorpio> References: <20150213081425.7a418830@scorpio> Message-ID: <681480546.20150214143935@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Friday 13 February 2015 at 1:14:25 PM, in , Jerry wrote: > On Fri, 13 Feb 2015 12:22:23 +0000, MFPA stated: >> My preference is Inline: I want everything right there >> in the message body where I can see it. > Exactly what is it you feel the over powering urge to > see? If the message text is covered by a signature, I want to see the signature. I would not accept a cheque where the signature was on an attached document instead of on the cheque. With PGP/MIME, even the message text itself is shifted out of the message body into an attachment. - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net Hard work never killed anyone, but why take a risk? -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJU314nXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwh5oH/1NmieM87eLK35VwTv0g8S0g uSVc9JQNVuY9Q5n2srASTQevlSYOjvXVE9NwHr2yYsmRcSTCoyDDa9mPcN+hPySV 4NK6V5YG8kDTV2zu8PyCbDHtpo67o4Dlxn3bDorm2FcqiH1YPRpeIrqIiJXquFO0 caWDQ/p2KtL8kE7X0YhPoGO5l7wco0Eg6zHkos3CY5EXEuYyo96bgu7MM0/Mep3z BP6AhV8AdsWzTmswYWPlkxR8WTq9evqAFUTYrlIQiFooscQxjo0u/i39WvLppi0D XHnU/rAAfdoE9a4YuZbKcM+rzHEcvLdbeSz52W37rpKAg/E24zA+fPs4yla6BfOI vgQBFgoAZgUCVN9eKF8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45CWeAQCEGMx0i8PTcx/lpqckRlY5fcH7 Akr0W5ztxcBy1A9k9AEA4qdTdFK8RKcUsS0kZvJkQbsFm4kSe+oxu8uz9WsE4AA= =D3XT -----END PGP SIGNATURE----- From 2014-667rhzu3dc-lists-groups at riseup.net Sat Feb 14 15:44:10 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Sat, 14 Feb 2015 14:44:10 +0000 Subject: MIME or inline signature ? In-Reply-To: <54DDDFEB.4020906@mailbox.org> References: <54DDDFEB.4020906@mailbox.org> Message-ID: <1185476069.20150214144410@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Friday 13 February 2015 at 11:28:43 AM, in , Stephan Beck wrote: > BAD Signature from xx I get that as well. > As a > security measure I have assigned your key a non-trust > attribute. Is that something like a local signature? - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net I hit the CTRL key but I'm still not in control! -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJU3187XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwNGYIAL23izS9z+06cSp39o1Q3Asn sht/eKCORWSlbYaj2wLSo8fLErdjPmh/c345zMp853yDAbu1VVrKEGXrf4KtXZUQ utqeaYvg+e61oVtTO5D70rJVoKnpvo/mcOpR+ar6zYHh1D26eRdRDSJgChenGlD2 b9pRxstT1+Hkbp+PzIHpPXqFCJqK1EIiqYAkPRiaNVrsLD6yDS2IGHWm43pfCFM/ +mXLnWXbwjQ/DVka7ghhYIoE2HQXE0FSkP0NK6YXqhynRS5WQvlYsn0Cr/zf3v/c TipFsrRoemmi/7fCQsulsq5ywZtrz/HhVQYeC+FLfcHkHYhT6LZI/gsm6PFqYUmI vgQBFgoAZgUCVN9fO18UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45DFJAQAZxGRRI05hMGUzJEx1XJb6IJRU l+Clqi0JFGvdhoG7tAEAsB81sT0Yuw0LIbnLVO/xjD2QKWu+g+VrlhREpBugIwM= =6L0h -----END PGP SIGNATURE----- From 2014-667rhzu3dc-lists-groups at riseup.net Sat Feb 14 15:45:47 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Sat, 14 Feb 2015 14:45:47 +0000 Subject: MIME or inline signature ? In-Reply-To: <8364C525-7042-4575-8D9D-3259A87A8FFF@asatiifm.net> References: <7E7DD9E3-690C-4ADC-BF42-57622042E8D2@cwrichardson.com> <8364C525-7042-4575-8D9D-3259A87A8FFF@asatiifm.net> Message-ID: <73477477.20150214144547@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Friday 13 February 2015 at 5:12:18 PM, in , Ville M??tt? wrote: > Fortunately it certainly does not. I doubt that many spam emails contain an inline OpenPGP signature, or text that looks like one. - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net Was time invented by an Irishman named O'Clock? -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJU31+bXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXw+YIIAKuGS3U7x+5JO4bTrdYPf8aP RRaqRCtuRvs662sZVNb2RddGZLhHUimTr2hBjoXT5+Knck9GeobRab3bBfi/u5MD GW26ARIFclqK1+UtYSOWMOECpBTSWBmmx4r7lCk6LXSuDegaWgNOCThqVyKgEeg3 CaCMtcY0RLyv5uN52imC9L+qxDMZVHONMMKi4siexqH4rN9T9P0POKhe20vj0TCy yaJEMN8yYtOwiPMI89gFz/70S6efbgOcEnebPoXNKkJoxik+cpwe6viBvVPsfAol OWCzPin1xVMb8bGOyyFiRWm1/Zdp2nN2dYvoX+Tukuuh928IP2lV2uwpDauzxf+I vgQBFgoAZgUCVN9fnF8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45H1rAQA1A8+pQ2kJVFoFhcsV1E2aQZee jPHraDwxwC5ecGLV0gEAVstGlQ0IJp6Zc+mMknXnlXm4h2xe8Zs/cpVhY5dmkgU= =gSUv -----END PGP SIGNATURE----- From hugo at barrera.io Sat Feb 14 16:49:16 2015 From: hugo at barrera.io (Hugo Osvaldo Barrera) Date: Sat, 14 Feb 2015 12:49:16 -0300 Subject: MIME or inline signature ? In-Reply-To: References: Message-ID: <20150214154916.GA11076@athena.barrera.io> On 2015-02-12 23:46, Xavier Maillard wrote: > Hello, > > in my quest of the perfect setup, I am asking myself what is the > prefered way to sign a message: inline (like this one) or using a MIME header ? > > Is there a big thumb rule to respect ? > > Regards > -- > Sent with my mu4e This is a bit of a bikeshed discussion, but I'll still chime in. Pros of GPG/Mime: * It's a lot less ugly for users with no gpg support. The large signature block at the end and the gpg marks are hard to ignore. * AFAIK, inline gpg has issues with non-ascii characters. ? Correct me if I'm wrong. * Inline-gpg includes a signature for each attachment. This allows third parties to count how many files are attached (and their filenames, I believe). gpg/mime include one huge blob, so third parties can't tell this sort of metadata. In the end, I'd suggest you go with what you prefer on a whim, more than techinical reasons. I like gpg/mime because of the above reasons (the first two are pretty important to me). But from a techinical point of view, you'll find plenty clients that don't support one or the other. Some clients support one with relative ease and require tweaking for the other. The truth is, none of the two deprecates the other, so there's no strong convergence, IMHO. -- Hugo Osvaldo Barrera A: Because we read from top to bottom, left to right. Q: Why should I start my reply below the quoted text? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rjh at sixdemonbag.org Sat Feb 14 17:13:29 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 14 Feb 2015 11:13:29 -0500 Subject: MIME or inline signature ? In-Reply-To: <534769852.20150214143300@my_localhost> References: <20150213154402.GA23632@IUPUI.Edu> <54DE4906.4020109@vulcan.xs4all.nl> <54DE535A.2060205@sixdemonbag.org> <534769852.20150214143300@my_localhost> Message-ID: <54DF7429.1010401@sixdemonbag.org> > Rejecting traffic that does not conform to the spec, even if it's in > common use is counter-intuitive. To you, perhaps, sure -- to me, no. Either way it doesn't matter; the guidance is what it is, and many counterintuitive things turn out to be true. > It seems to be denying yourself access to some of the incoming > traffic for the sake of pedantry... Security and reliability. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3744 bytes Desc: S/MIME Cryptographic Signature URL: From dkg at fifthhorseman.net Sat Feb 14 17:26:27 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 14 Feb 2015 11:26:27 -0500 Subject: [Announce] GnuPG 2.1.2 released In-Reply-To: <874mqs2q4o.fsf@vigenere.g10code.de> References: <874mqs2q4o.fsf@vigenere.g10code.de> Message-ID: <87oaowh32k.fsf@alice.fifthhorseman.net> On Wed 2015-02-11 14:40:39 -0500, Werner Koch wrote: > The GnuPG Project is pleased to announce the availability of the > third release of GnuPG modern: Version 2.1.2. Thank you, Werner! 2.1.2 is now in debian experimental, where it builds cleanly on all architectures: https://buildd.debian.org/status/package.php?p=gnupg2&suite=experimental Users of debian sid or jessie should be able to upgrade to it from the experimental archive. For more information, see: https://wiki.debian.org/DebianExperimental The transition to automake 1.14 was painless on the packaging side for me. This modernization is much appreciated. > Since the start of the funding campaign in December several thousand > people have been kind enough to donate a total of 250000 Euro to support > this project. In addition the Linux Foundation gave a grant of $ 60000 > for 2015, Stripe.com and Facebook.com each pledged $ 50000 per year. > > I am amazed by this superb and unexpected support for the GnuPG project. > This will not only allow us to continue the project and hire at least a > second full time developer but gives us also the resources to improve > things which have been delayed for too long. I'm happy to hear this, and glad to see the project getting some of the support it has long deserved. All the best, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From BM-2cTjsegDfZQNGQWUQjSwro6jrWLC9B3MN3 at bitmessage.ch Sat Feb 14 18:32:33 2015 From: BM-2cTjsegDfZQNGQWUQjSwro6jrWLC9B3MN3 at bitmessage.ch (BM-2cTjsegDfZQNGQWUQjSwro6jrWLC9B3MN3 at bitmessage.ch) Date: Sat, 14 Feb 2015 12:32:33 -0500 Subject: Tilde (~) in valid email address In-Reply-To: References: Message-ID: > > When generating a uid for a key using gpg2 (2.0.25), and attempting > > to input an email address containing a tilde (~), I receive an > > invalid email error. There seems to be no way I can find to bypass > > this restriction, and use my "invalid" email. > > You need --allow-freeform-uid to disable this check. > > > Hauke Worked perfectly. Thanks! From hugo at barrera.io Sat Feb 14 21:37:30 2015 From: hugo at barrera.io (Hugo Osvaldo Barrera) Date: Sat, 14 Feb 2015 17:37:30 -0300 Subject: MIME or inline signature ? In-Reply-To: <534769852.20150214143300@my_localhost> References: <20150213154402.GA23632@IUPUI.Edu> <54DE4906.4020109@vulcan.xs4all.nl> <54DE535A.2060205@sixdemonbag.org> <534769852.20150214143300@my_localhost> Message-ID: <20150214203730.GA20721@athena.barrera.io> On 2015-02-14 14:33, MFPA wrote: > Hi > > > On Friday 13 February 2015 at 7:41:14 PM, in > , Robert J. Hansen wrote: > > > > Postel's sentiments were more, "Reject traffic that > > does not conform to the spec, even if it's in common > > use; accept traffic that conforms to the protocol spec, > > even if it's exotic; and only generate traffic that > > conforms to both spec and common use." Unfortunately, > > that loses much of the poetry of the original phrasing. > > > Rejecting traffic that does not conform to the spec, even if it's in > common use is counter-intuitive. It seems to be denying yourself > access to some of the incoming traffic for the sake of pedantry, which > sounds like it would harm interoperability. But, of course, the point > of having a spec is interoperability. > > Not necesarily. Writing and testing the code to support non-standard traffic takes time and effort, and may increase the likelyhood of introducing some bug. In proyects that don't have a lot of manpower, implementing such compatibility may be a dealbreaker. -- Hugo Osvaldo Barrera A: Because we read from top to bottom, left to right. Q: Why should I start my reply below the quoted text? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From dougb at dougbarton.email Sat Feb 14 22:36:08 2015 From: dougb at dougbarton.email (Doug Barton) Date: Sat, 14 Feb 2015 13:36:08 -0800 Subject: MIME or inline signature ? In-Reply-To: <20150214154916.GA11076@athena.barrera.io> References: <20150214154916.GA11076@athena.barrera.io> Message-ID: <54DFBFC8.6030002@dougbarton.email> FWIW, I hate this debate, and try hard to stay out of it. But it really bothers me when people spread factually incorrect information, especially when they try to use that as the basis of their arguments for/against one method or the other. On 2/14/15 7:49 AM, Hugo Osvaldo Barrera wrote: > Pros of GPG/Mime: > * It's a lot less ugly for users with no gpg support. The large signature block > at the end and the gpg marks are hard to ignore. Why are you signing mail that is being sent to people without PGP support in the first place? > * AFAIK, inline gpg has issues with non-ascii characters. ? Correct me if I'm > wrong. This hasn't been true for almost a decade, assuming that the person using the non-ASCII characters has correctly set up their environment. And FWIW, it's also not true that PGP/MIME will be 100% successful when one of the communicants has not correctly set up their environment. > * Inline-gpg includes a signature for each attachment. This allows third > parties to count how many files are attached (and their filenames, I > believe). gpg/mime include one huge blob, so third parties can't tell this > sort of metadata. Nothing you wrote in this section is 100% correct. You *can* send one signature per attachment, but you don't have to. You can also bundle the attachment and signature in an archive, or you can bundle a lot of attachments in the same archive, and sign that, or you can bundle all of the attachments and signatures in one archive .... etc. It's also not true that PGP/MIME protects you from metadata analysis. The messages are not "one big blob," they are actually separated into parts, including the attachments. It's trivial to see how many attachments are in a message just by analyzing the MIME headers, whether the message/attachments are encrypted or not. > In the end, I'd suggest you go with what you prefer on a whim, more than > techinical reasons. ... or, you could use what your correspondents are able to handle, since theoretically that's the point of communication in the first place? :) hope this helps, Doug From hugo at barrera.io Sat Feb 14 22:45:16 2015 From: hugo at barrera.io (Hugo Osvaldo Barrera) Date: Sat, 14 Feb 2015 18:45:16 -0300 Subject: MIME or inline signature ? In-Reply-To: <54DFBFC8.6030002@dougbarton.email> References: <20150214154916.GA11076@athena.barrera.io> <54DFBFC8.6030002@dougbarton.email> Message-ID: <20150214214516.GA23898@athena.barrera.io> On 2015-02-14 13:36, Doug Barton wrote: > FWIW, I hate this debate, and try hard to stay out of it. But it really > bothers me when people spread factually incorrect information, especially > when they try to use that as the basis of their arguments for/against one > method or the other. > > On 2/14/15 7:49 AM, Hugo Osvaldo Barrera wrote: > > >Pros of GPG/Mime: > >* It's a lot less ugly for users with no gpg support. The large signature block > > at the end and the gpg marks are hard to ignore. > > Why are you signing mail that is being sent to people without PGP support in > the first place? > I've no way of determining who has gpg support and who has not really and I prefer to sign by default. Validating (or not) the signature is up to the recipient. They may also gain gpg support in future, and can back-validate previous emails. > >* AFAIK, inline gpg has issues with non-ascii characters. ? Correct me if I'm > > wrong. > > This hasn't been true for almost a decade, assuming that the person using > the non-ASCII characters has correctly set up their environment. And FWIW, > it's also not true that PGP/MIME will be 100% successful when one of the > communicants has not correctly set up their environment. > Ah, I'm sorry for the misinformation in that case. I may never have been updated to the latest on this, and I appreciate the correction - I'll avoid repeating this again. > >* Inline-gpg includes a signature for each attachment. This allows third > > parties to count how many files are attached (and their filenames, I > > believe). gpg/mime include one huge blob, so third parties can't tell this > > sort of metadata. > > Nothing you wrote in this section is 100% correct. You *can* send one > signature per attachment, but you don't have to. You can also bundle the > attachment and signature in an archive, or you can bundle a lot of > attachments in the same archive, and sign that, or you can bundle all of the > attachments and signatures in one archive .... etc. > > It's also not true that PGP/MIME protects you from metadata analysis. The > messages are not "one big blob," they are actually separated into parts, > including the attachments. It's trivial to see how many attachments are in a > message just by analyzing the MIME headers, whether the message/attachments > are encrypted or not. > From my experience, pgp/mime emails with encrypted into a are a single msg.asc, which needs to be decrypted to determine the mime parts inside. Is this inaccurate? The (admitedly few) clients I've tried with gpg-inline attached a single additional mime part per attachment when encrypting, making attachment count and filenames visible. There may be a way to do this differently, but no email client seems to do it, so it's sort of a moot point. Expecting users to do this manually is a bit burdensome, compared to gpg/mime. > >In the end, I'd suggest you go with what you prefer on a whim, more than > >techinical reasons. > > ... or, you could use what your correspondents are able to handle, since > theoretically that's the point of communication in the first place? :) > There will always be people who can handle one and not the other (and let's not forget you'll probably know more people in future). There's no single mechanism that'll work for everyone. > hope this helps, > Yes, thanks for the insight. Especially on the non-ascii related information, for which it seems I was out-of-date. > Doug > -- Hugo Osvaldo Barrera A: Because we read from top to bottom, left to right. Q: Why should I start my reply below the quoted text? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From stebe at mailbox.org Sat Feb 14 23:05:24 2015 From: stebe at mailbox.org (Stephan Beck) Date: Sat, 14 Feb 2015 23:05:24 +0100 Subject: MIME or inline signature ? In-Reply-To: <1185476069.20150214144410@my_localhost> References: <54DDDFEB.4020906@mailbox.org> <1185476069.20150214144410@my_localhost> Message-ID: <54DFC6A4.8070302@mailbox.org> Hi Am 14.02.2015 um 15:44 schrieb MFPA: > Hi > > > On Friday 13 February 2015 at 11:28:43 AM, in > , Stephan Beck wrote: > > > >> BAD Signature from xx > > I get that as well. > > > >> As a >> security measure I have assigned your key a non-trust >> attribute. > > Is that something like a local signature? Well, it's rather a precautionary measure than an actual security measure, , reminding me of not trusting the key owner's ability to handle and verify signatures correctly, if he/she uses a signature no one has the chance to check because the information about the public key's location isn't indicated by its owner in his/her very message. I assigned the "I do not trust him" attribute to the first key he used in a previous message. Or was your comment directed to the owner of the key? Now, I am not quite sure about that... Anyway, nice weekend to all Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: OpenPGP digital signature URL: From greg at turnstep.com Sat Feb 14 22:26:55 2015 From: greg at turnstep.com (Greg Sabino Mullane) Date: Sat, 14 Feb 2015 21:26:55 -0000 Subject: MIME or inline signature ? In-Reply-To: <87k2zmlmpo.fsf@alice.fifthhorseman.net> Message-ID: <9e081e975de0e80f7706dfddc07279af@biglumber.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Daniel Kahn Gillmor wrote: > This part appears to be out of date: > > Since PGP/MIME can't reliably be sent to the three largest GnuPG > mailing lists, it??s hard to claim that PGP/MIME is ready for > widespread usage. For now, it??s best to use inline traffic unless you > can be certain that PGP/MIME messages will not be mangled in transit. > > I don't know if this is true for PGP-Basics, but it is certainly not > true for enigmail or gnupg-users. Please update the FAQ! > --dkg, noting the irony of the parent message being sent with > S/MIME, an entirely different standard Also ironic, and one of the main reasons I prefer inline, is the inability of many archiving systems to preserve attachments - including lists.gnupg.org! For example, when one visits the message I quoted above: http://lists.gnupg.org/pipermail/gnupg-users/2015-February/052456.html This appears at the bottom of the message: A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: (That URL path on lists.gnupg.org is 404, unless I am overlooking some needed munging.) While some sites manage to keep the attachement intact (e.g. gossamer-threads.com), most do not, e.g. http://readlist.com/lists/gnupg.org/gnupg-users/4/24735.html http://markmail.org/message/jajkjbvf7smmjkrr So far all of inline's flaws, it is far better at maintaining message integrity (see also: forwarding and cut-n-paste). - -- Greg Sabino Mullane greg at turnstep.com End Point Corporation http://www.endpoint.com/ PGP Key: 0x14964AC8 201502141623 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAlTfvXcACgkQvJuQZxSWSsiwNQCfRjtx6nOonWn8eQ7ov2w9/ISI tKUAn1+cb8Z0guCXJbjiiuVvSOz2dsD2 =MauL -----END PGP SIGNATURE----- From mlisten at hammernoch.net Sun Feb 15 12:26:16 2015 From: mlisten at hammernoch.net (=?UTF-8?B?THVkd2lnIEjDvGdlbHNjaMOkZmVy?=) Date: Sun, 15 Feb 2015 12:26:16 +0100 Subject: MIME or inline signature ? In-Reply-To: <54DFC6A4.8070302@mailbox.org> References: <54DDDFEB.4020906@mailbox.org> <1185476069.20150214144410@my_localhost> <54DFC6A4.8070302@mailbox.org> Message-ID: <54E08258.2070404@hammernoch.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 14.02.15 23:05, Stephan Beck wrote: > Well, it's rather a precautionary measure than an actual security > measure, , reminding me of not trusting the key owner's ability to > handle and verify signatures correctly, if he/she uses a signature > no one has the chance to check because the information about the > public key's location isn't indicated by its owner in his/her very > message. I assigned the "I do not trust him" attribute to the first > key he used in a previous message. You seem to have misunderstood what ownertrust is good for. Trusting an owner about placing his signatures is not about how she/he signs messages. It is about how carefully she/he checks identity and mail address before signing other keys. You can only judge that if you have seen her/him in real life doing that. Ludwig -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJU4IJXAAoJEDrb+m0Aoeb+e8cP/i+xCIAxQKKl4ON05EARINzV z/PdEZFXMheOXZXVS8icw/hTNlGJkc8wm8RJ3BrkFtMSecrQiA0jrC7SUQ69+wKE xBGc9hAP+IH07bXyThRFp6mujLD/nyyzbF37VzTcced1kgvSDnCn6G5dokvC4kgu QORDnsBf20qettMOjORss6UChxdSgJFfNPbYD0QLOoGjM6MYFOMyG8a1bDV+KUa5 jL4EUTn6Zqvh0pXcDigcXj/UThcozNDzez95ugYue59QGBdKe6LSeMOtmLkss9b9 V1lYxiv6gquHcfd/ygDFO5VNozgOeqI3OAFzIIeL8bYoK60a0guvmaUZjp3QPw6q TYDW27rKCMWigllU1fC8brl5Jl3w/NDvNvWANxCh8EgEHXNCA/mWdrpRhp2/9LFE vQsCdV3CowgZLXOJFXAOT4y05FJFfeAbQmqcoNQJNghhFyggFAjKUBwXKmA6Rzp1 DGoeYD1xe3pWqL+cQpBxOH7ORzAMrhEiqeOueQYGOwZcxnZ7IvydfN/BrYy3Z+tY 3VkFEnO/jU/X0/wmf8Gv+yV8mQLu2wm7ruLLzM9H46SyQBpBRGMQNC48mxLaFybL Rwc30cjnCacfbyIM14byG6a/qSaIOwHw4536K5PdbAHThm1ICatAc1rM2OnFrlSy PgdlXsrt4jpJ4qokILlI =Ryh9 -----END PGP SIGNATURE----- From aixtools at gmail.com Sun Feb 15 12:16:58 2015 From: aixtools at gmail.com (Michael Felt) Date: Sun, 15 Feb 2015 12:16:58 +0100 Subject: GNUPG 2.* and AIX - questions Message-ID: This is not a bug report. Short history - I have tried to package gnupg several times, the gunpg v1.* has never been difficult - and maybe I shall just leave it at that. My key question is about the difference between v1.X and v2.X - are there security elements in v2 that are missing/weaker in v1 - or are the differences mainly that v2 supports/is always GUI while v1 is always CLI. Background info... The first wall I run into with gnupg-2.0.26 is that it wants gnu threads - so, the question is: is there something inherently wrong with POSIX threads, or even specifically with AIX pthreads that configure does not attempt to use them (by default). I took the hint and tried to package gnu/nth but make fails - immediately - with this message. root at x064:[/data/prj/gnu/pth/pth-2.0.7]make ./libtool --mode=compile --quiet cc -c -I. pth_debug.c "pth.h", line 93.2: 1506-205 (S) #error "FD_SETSIZE is larger than what GNU Pth can handle." make: *** [pth_debug.lo] Error 1 root at x064:[/data/prj/gnu/pth/pth-2.0.7] For extra info: root at x064:[/data/prj/gnu/pth/pth-2.0.7]grep FD_SETSIZE *.h pth.h: /* check if the user requests a bigger FD_SETSIZE than we can handle */ pth.h:#if defined(FD_SETSIZE) pth.h:#if FD_SETSIZE > 1024 pth.h:#error "FD_SETSIZE is larger than what GNU Pth can handle." pth_p.h:#if !defined(FD_SETSIZE) pth_p.h:#define FD_SETSIZE 1024 # AIX 5.3 so anno 2009 root at x064:[/data/prj/gnu/pth/pth-2.0.7]grep FD_SETSIZE /usr/include/*.h /usr/include/sys/*.h /usr/include/sys/time.h: * FD_SETSIZE may be defined by the user to the maximum valued file /usr/include/sys/time.h:#ifndef FD_SETSIZE /usr/include/sys/time.h:#define FD_SETSIZE 65534 /usr/include/sys/time.h:/* Number of entries needed for FD_SETSIZE open files */ /usr/include/sys/time.h:#define __NUM_ENTRIES (FD_SETSIZE/__NFDBITS+1) Again, this is NOT a bug-report. I have never seen gnupg 2.0 (so maybe it is all GUI related, when all I am really interested in is security abilities). Thank your for your time. Michael p.s. please forgive the cross post to @devel - not sure which is the best list for this question. -------------- next part -------------- An HTML attachment was scrubbed... URL: From 2014-667rhzu3dc-lists-groups at riseup.net Sun Feb 15 13:14:16 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Sun, 15 Feb 2015 12:14:16 +0000 Subject: MIME or inline signature ? In-Reply-To: <54DFC6A4.8070302@mailbox.org> References: <54DDDFEB.4020906@mailbox.org> <1185476069.20150214144410@my_localhost> <54DFC6A4.8070302@mailbox.org> Message-ID: <1423095397.20150215121416@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Saturday 14 February 2015 at 10:05:24 PM, in , Stephan Beck wrote: > Well, it's rather a precautionary measure than an > actual security measure, , reminding me of not trusting > the key owner's ability to handle and verify signatures > correctly, if he/she uses a signature no one has the > chance to check because the information about the > public key's location isn't indicated by its owner in > his/her very message. When I check the signature of the first message in this thread (Message-ID: ), GnuPG fetches Xavier's key from a keyserver. I don't see why information about a public key's location would need to be indicated for a key that is on the keyservers. That said, Xavier's message kludges contain the key-id and fingerprint, as well as a link to the lookup of that key on a keyserver (wwwkeys.pgp.net, which seems to be down at the moment). > I assigned the "I do not trust > him" attribute to the first key he used in a previous > message. > Or was your comment directed to the owner of the key? > Now, I am not quite sure about that... No, I was asking what you meant by "I have assigned your key a non-trust attribute". From your reply, I see you mean Trust setting number 2 "I do NOT trust". On my keyring, my own keys have a 5 "I trust ultimately" and all other keys have the default. (I presume not setting trust on a key is the same as setting 1 "I don't know or won't say".) - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net Oven mitt: A partially charred grease stain that fits over the hand. -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJU4I2aXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwOZ4H/RqcwizzvB9sVLp0IpfU+Q9C pt6HtthvYU2Zp0bjA2O3ApAkjbp3zaY7hycKce0gUGTuyE/kg9gym6wU9n0qhLy0 x52fGr67zHyit0NnPnWf1Un/gZFQN/AdtjbNANYu7AAY0KlR8nGBJ7q7ljxx7Ecg IS0TzU5Umk89JDW4ch8ZJA240AjpQDHhyiMYrQu9vcKget0giXBKQuxAE9nX22oY 710G4PXSM8KysoyMABGS+zxXw/7lL5D7DSsYE1XuCJk/rXeXuGLJ+GcJimMpZLUk QisvC384Ya4co+YcCrUYIGbDGqfKj59jz63raqcU6uOWDQu/+z6ae3PWraTLdqKI vgQBFgoAZgUCVOCNp18UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45FQrAQC3aO01dRIVTAkh+31Tc1MoN/SU XdoVDu93UaoxN5uWFgEA9EbORCdCTyekswKRSUXbaamDiIO0sNLBAD+1/LEAYQg= =Ybmh -----END PGP SIGNATURE----- From stebe at mailbox.org Sun Feb 15 16:12:01 2015 From: stebe at mailbox.org (Stephan Beck) Date: Sun, 15 Feb 2015 16:12:01 +0100 Subject: MIME or inline signature ? In-Reply-To: <1423095397.20150215121416@my_localhost> References: <54DDDFEB.4020906@mailbox.org> <1185476069.20150214144410@my_localhost> <54DFC6A4.8070302@mailbox.org> <1423095397.20150215121416@my_localhost> Message-ID: <54E0B741.4000909@mailbox.org> Hi MFPA Am 15.02.2015 um 13:14 schrieb MFPA: > > > On Saturday 14 February 2015 at 10:05:24 PM, in > , Stephan Beck wrote: > > >> Well, it's rather a precautionary measure than an >> actual security measure, , reminding me of not trusting >> the key owner's ability to handle and verify signatures >> correctly, if he/she uses a signature no one has the >> chance to check because the information about the >> public key's location isn't indicated by its owner in >> his/her very message. > > When I check the signature of the first message in this thread > (Message-ID: ), GnuPG fetches > Xavier's key from a keyserver. I don't see why information about a > public key's location would need to be indicated for a key that is on > the keyservers. Didn't you say before you got the same error message as I did? No, it does not fetch the correct key, not with that very message. What is is that indicates (you) that the server might be down? Enigmail, which I use in combination with gpg, tries to verify the signature by fetching the key DE2FFC869AFA5165 (the key the message was signed with according to Enigmail) from keyservers, and that action fails resulting in a "bad signature..." output. It most likely seems to fail, because the key the message was signed is not on the keyservers. The header of the message in question is (sorry for having to be that explicit) X-GPG-Key-ID: 0xBA4909B78F04DE1B X-GPG-Key: http://wwwkeys.pgp.net/pks/lookup?search=0xBA4909B78F04DE1B&op=index X-GPG-Fingerprint: 9983 DCA1 1FAC 8DA7 653A F9AA BA49 09B7 8F04 DE1B Obviously, it indicates a key ID 0xBA4909B78F04DE1B and links to a key that is not the key the message was signed with (which is DE2FFC869AFA5165, according to Enigmail/gpg), even if the fingerprint is given as well. A previous message of him was signed with the key ID 0xBA4909B78F04DE1B, hence, Enigmail imported this key correctly. That said, Xavier's message kludges contain the key-id > and fingerprint, as well as a link to the lookup of that key on a > keyserver (wwwkeys.pgp.net, which seems to be down at the moment). On my keyring, my own keys have a 5 "I > trust ultimately" and all other keys have the default. (I presume not > setting trust on a key is the same as setting 1 "I don't know or won't > say".) In fact, it isn't quite the same. The default, before ever having verified the key owner's identity, is "I don't know or won't say". The option 2 "I do not trust" refers to the poor or zero trust you have in the key owner's abilty to sign and verify other signatures correctly, as a result of a behaviour/attitude of the key owner which is contrary to the principles of the Web of Trust, for instance. It is not possible to verify the key DE2FFC869AFA5165 with the information given. Best regards Stephan Beck Below I paste the German output of Enigmail as a proof of what I'm saying. I have already translated it in my previous message. Enigmail-Sicherheitsinfo: Fehler - ?berpr?fung der Unterschrift fehlgeschlagen ?ffentlicher Schl?ssel DE2FFC869AFA5165 zur ?berpr?fung der Unterschrift ben?tigt FALSCHE Unterschrift von Xavier Maillard -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: OpenPGP digital signature URL: From stebe at mailbox.org Sun Feb 15 16:30:33 2015 From: stebe at mailbox.org (Stephan Beck) Date: Sun, 15 Feb 2015 16:30:33 +0100 Subject: MIME or inline signature ? In-Reply-To: <54E08258.2070404@hammernoch.net> References: <54DDDFEB.4020906@mailbox.org> <1185476069.20150214144410@my_localhost> <54DFC6A4.8070302@mailbox.org> <54E08258.2070404@hammernoch.net> Message-ID: <54E0BB99.7050305@mailbox.org> Am 15.02.2015 um 12:26 schrieb Ludwig H?gelsch?fer: > On 14.02.15 23:05, Stephan Beck wrote: > >> Well, it's rather a precautionary measure than an actual security >> measure, , reminding me of not trusting the key owner's ability to >> handle and verify signatures correctly, if he/she uses a signature >> no one has the chance to check because the information about the >> public key's location isn't indicated by its owner in his/her very >> message. I assigned the "I do not trust him" attribute to the first >> key he used in a previous message. > > You seem to have misunderstood what ownertrust is good for. Trusting > an owner about placing his signatures is not about how she/he signs > messages. > > It is about how carefully she/he checks identity and mail address > before signing other keys. You can only judge that if you have seen > her/him in real life doing that. OK, I give you that, strictly speaking, it might not be the same, but at the moment I had no other measure at hand to remind me of being careful with that kind of event. And a bad signature event is not the ideal event for putting trust in a key owner's identity at all. Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: OpenPGP digital signature URL: From mailinglisten at hauke-laging.de Sun Feb 15 17:04:28 2015 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Sun, 15 Feb 2015 17:04:28 +0100 Subject: MIME or inline signature ? In-Reply-To: <54E0B741.4000909@mailbox.org> References: <1423095397.20150215121416@my_localhost> <54E0B741.4000909@mailbox.org> Message-ID: <56965421.MKImfV8cNg@inno> Am So 15.02.2015, 16:12:01 schrieb Stephan Beck: > X-GPG-Key-ID: 0xBA4909B78F04DE1B > X-GPG-Key: > http://wwwkeys.pgp.net/pks/lookup?search=0xBA4909B78F04DE1B&op=index > X-GPG-Fingerprint: 9983 DCA1 1FAC 8DA7 653A F9AA BA49 09B7 8F04 DE1B > > Obviously, it indicates a key ID 0xBA4909B78F04DE1B and links to a key > that is not the key the message was signed with (which is > DE2FFC869AFA5165, according to Enigmail/gpg) 0xDE2FFC869AFA5165 is a subkey of 0xBA4909B78F04DE1B. Of course, when pointing at a certificate you address it by its mainkey. > It is not possible to verify the key DE2FFC869AFA5165 with the > information given. That is wrong. Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 603 bytes Desc: This is a digitally signed message part. URL: From dgouttegattat at incenp.org Sun Feb 15 17:11:36 2015 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Sun, 15 Feb 2015 17:11:36 +0100 Subject: MIME or inline signature ? In-Reply-To: <54E0B741.4000909@mailbox.org> References: <54DDDFEB.4020906@mailbox.org> <1185476069.20150214144410@my_localhost> <54DFC6A4.8070302@mailbox.org> <1423095397.20150215121416@my_localhost> <54E0B741.4000909@mailbox.org> Message-ID: <54E0C538.9060902@incenp.org> On 02/15/2015 04:12 PM, Stephan Beck wrote: > Obviously, it indicates a key ID 0xBA4909B78F04DE1B and links to a key that is > not the key the message was signed with (which is DE2FFC869AFA5165, according to > Enigmail/gpg), even if the fingerprint is given as well. Well, the 0xDE2FFC869AFA5165 key is a signing subkey of Xavier?s master key 0xBA4909B78F04DE1B. Indicating the master key (which is the one everyone needs to know about and sign) instead of the signing subkey is the correct thing to do. By downloading the master key from a keyserver, you will automatically fetch the signing subkey as well. You seem to have misinterpreted Enigmail?s error message. When it says: Error - signature verification failed Public key DE2FFC869AFA5165 needed to verify signature BAD signature from Xavier Maillard the second line does not imply that the indicated key is not available. Enigmail displays such a line everytime a signature verification fails, even when the indicated key *is* present in your keyring (which is somewhat misleading). The important line is the third, which tells that Enigmail was in fact able to perform the verification (meaning it has the right key). Now, I don?t know why the verification failed, but I do note, quite ironically, that this is an inline signature, while a previous message from Xavier, with a PGP/MIME signature from the same key, was verified correctly? Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From mlisten at hammernoch.net Sun Feb 15 17:25:56 2015 From: mlisten at hammernoch.net (=?UTF-8?B?THVkd2lnIEjDvGdlbHNjaMOkZmVy?=) Date: Sun, 15 Feb 2015 17:25:56 +0100 Subject: MIME or inline signature ? In-Reply-To: <54E0BB99.7050305@mailbox.org> References: <54DDDFEB.4020906@mailbox.org> <1185476069.20150214144410@my_localhost> <54DFC6A4.8070302@mailbox.org> <54E08258.2070404@hammernoch.net> <54E0BB99.7050305@mailbox.org> Message-ID: <54E0C894.8080404@hammernoch.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 15.02.15 16:30, Stephan Beck wrote: > OK, I give you that, strictly speaking, it might not be the same, > but at the moment I had no other measure at hand to remind me of > being careful with that kind of event. And a bad signature event is > not the ideal event for putting trust in a key owner's identity at > all. You cannot get trust from good or bad mail signatures. You also cannot get distrust. A "bad signature" _only shows one thing_: The message was modified along the way from the signing process (at the senders computer) to the verification process (at your computer). This can be a tool shortcoming, a mail server mangling the contents or the mailinglist software. You cannot decide where the modification took place. So all evidence is technical. There's absolutely no reson to distrust the mail sender. 1000 good mail signatures from him don't show anything regarding his key. 1000 bad signatures either. The only place to get trust to the senders key (i.e. to make it "valid" for you) is to meet the key owner in real life, verify the identity documents, his fingerprint and mail addresses and sign his key if everything is ok. There's no measure to replace this procedure. Ludwig -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJU4MiTAAoJEDrb+m0Aoeb+lRAP/2MiEq4KQoPRQrBRXQIQ8ayJ tUXFKGVejaTl4KcwUiScqrrBKj2pYMda5kuQagJQThWEGesuzeSPtP7mklVNPCGW htxGNY8SAF6dBCjqLNHTOOeBgLEDKliLv7BLu9Two5/fGsjg6E80ghc/yvnSRzpa Lln6P7W/RhqDhd1ACg4bDeJGf1Sr2kTaMADOTezev4b3bZ6W/OJ+0n10wz/8xR5D 5kTGwVkG0sA4IOUVfFuYz5AM+GfrPHjNUZp5f6IIVbSFLgNbGrxRfN4Xf6ZbHEcH VA/4BDNpD+kN29J+A3cZe+ois3r6BnPXPAwUFgwOD8Mah9bmKgzcBRRj97dnTZC0 6qo6v5XanEljvo7DFjixKxunHQ7pBKXBd3YnbDgDftCvr7QX8KauL88CHirmQh3p gTMupRC9ZZlJ6us7SgCZSRuP1BkuBSnlNhfbpH3Y0moKjbdx8RpTL+fUS1C+o//M RNMg8sKoiUZ33pFkKEAI9Kb1UBHCDD7ye2ZZhsk0tpjNTjQCVxOe7mEhKkz9dila t07u06zlsEEX9hFODHJw4Ph3a7dDiXLg1QHr39G3oSoW7aJ7jnl8gpJLg/J8IWS4 fw8MQvRJKObI2F+a+uSzrDD62U4Utxf/yraX77qIZ2dX94OYWMKoMYwJTQwRnQda sC6bdVe6GB39z87DRsi2 =ZP3O -----END PGP SIGNATURE----- From mlisten at hammernoch.net Sun Feb 15 17:29:06 2015 From: mlisten at hammernoch.net (=?UTF-8?B?THVkd2lnIEjDvGdlbHNjaMOkZmVy?=) Date: Sun, 15 Feb 2015 17:29:06 +0100 Subject: MIME or inline signature ? In-Reply-To: <54E0C538.9060902@incenp.org> References: <54DDDFEB.4020906@mailbox.org> <1185476069.20150214144410@my_localhost> <54DFC6A4.8070302@mailbox.org> <1423095397.20150215121416@my_localhost> <54E0B741.4000909@mailbox.org> <54E0C538.9060902@incenp.org> Message-ID: <54E0C952.1090006@hammernoch.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 15.02.15 17:11, Damien Goutte-Gattat wrote: > Error - signature verification failed Public key DE2FFC869AFA5165 > needed to verify signature ^^^^^^ This is a bug in Enigmail 1.7.2. The sentence should be: "Public key DE2FFC869AFA5165 used to verify signature" and is corrected in Enigmail nightly builds. Ludwig -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJU4MlSAAoJEDrb+m0Aoeb+ijMP/iDRRZynS34WHV0s7604e0XZ fXyYBMB1CBWwraD0D6OoLl3R5DeEk3SHHkjas6Up/wmXKK/izZN54aNMiSBAF+/0 TXI4XvqNShvWHqb7wGmj+qx/2WOfV9c701Egjr0lKCMM7T6bGmO5F0g23ZDLIS0K 8eHlZ0cpyIb2/r7zXPzTbIZ9uB2QxqFxlzP6XWOtp7j/9CbBjU1igeBhQssWuW39 Y8ScCEiFmmhS0tRPHm4YK8BnIVF4PMUNBAxpCFQPPwHrlPyhitBI8wOYGRS01wbK HMsKOrHEym/UAen+WEtOnqEZnuV+JMgHuLFQaaBV3CSdEPw1CDmOQh5Y/k/86c64 vDriB0J7gA9M3QqnKoTVkqH/+l3MrwbnUcRgMCSzftFDTu/yu7J5ExiKAa8dBHij VCx5o2+ighN905hxxB189ZJx3JqbJPHXrXAWNXgHrsmVp2mZ0hUyQCZjV9xfADD4 ACPpQ3KQG10w3rg2ro9kEpHuWizflGst4236/de4TK84ARL3WI0g12LxTai45gvH A4XO07mX7IMPg4la7dlY4VLSWLUMo2NQYqKII84sRXUyF6x5mQFLuFE/2Yitdiwj LqwnMrAOh+s40glG8FhJK/PiY1dp6TaDShRod6z2cQ1PNP+4enUeckT/efI1b1F2 vkMwh+jojV76DYvfM19T =rCW5 -----END PGP SIGNATURE----- From stebe at mailbox.org Sun Feb 15 17:31:46 2015 From: stebe at mailbox.org (Stephan Beck) Date: Sun, 15 Feb 2015 17:31:46 +0100 Subject: MIME or inline signature ? In-Reply-To: <56965421.MKImfV8cNg@inno> References: <1423095397.20150215121416@my_localhost> <54E0B741.4000909@mailbox.org> <56965421.MKImfV8cNg@inno> Message-ID: <54E0C9F2.3060300@mailbox.org> Hi, Hauke, Am 15.02.2015 um 17:04 schrieb Hauke Laging: > Am So 15.02.2015, 16:12:01 schrieb Stephan Beck: > >> X-GPG-Key-ID: 0xBA4909B78F04DE1B >> X-GPG-Key: >> http://wwwkeys.pgp.net/pks/lookup?search=0xBA4909B78F04DE1B&op=index >> X-GPG-Fingerprint: 9983 DCA1 1FAC 8DA7 653A F9AA BA49 09B7 8F04 DE1B >> >> Obviously, it indicates a key ID 0xBA4909B78F04DE1B and links to a key >> that is not the key the message was signed with (which is >> DE2FFC869AFA5165, according to Enigmail/gpg) > > 0xDE2FFC869AFA5165 is a subkey of 0xBA4909B78F04DE1B. Of course, when > pointing at a certificate you address it by its mainkey. OK, I have checked it in the Key Properties window. From within the Inbox window a click on Display Key Properties gave no result. Sorry, Xavier and all list members for much "ado about nothing"! :-( Terribly sorry Stephan I think I got to book that training course of Hauke ;-) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: OpenPGP digital signature URL: From stebe at mailbox.org Sun Feb 15 17:56:33 2015 From: stebe at mailbox.org (Stephan Beck) Date: Sun, 15 Feb 2015 17:56:33 +0100 Subject: MIME or inline signature ? In-Reply-To: <54E0C894.8080404@hammernoch.net> References: <54DDDFEB.4020906@mailbox.org> <1185476069.20150214144410@my_localhost> <54DFC6A4.8070302@mailbox.org> <54E08258.2070404@hammernoch.net> <54E0BB99.7050305@mailbox.org> <54E0C894.8080404@hammernoch.net> Message-ID: <54E0CFC1.90604@mailbox.org> Am 15.02.2015 um 17:25 schrieb Ludwig H?gelsch?fer: > On 15.02.15 16:30, Stephan Beck wrote: > > The only place to get trust to the senders key (i.e. to make it > "valid" for you) is to meet the key owner in real life, verify the > identity documents, his fingerprint and mail addresses and sign his > key if everything is ok. There's no measure to replace this procedure. Thanks, Ludwig, for the explanation. Well, if Xavier will ever be willing to meet me in person, I promise to hand a good cake over to him. Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: OpenPGP digital signature URL: From beckus at beckus.eu Sun Feb 15 20:14:27 2015 From: beckus at beckus.eu (Christopher Beck) Date: Sun, 15 Feb 2015 20:14:27 +0100 Subject: MIME or inline signature ? In-Reply-To: <54E0BB99.7050305@mailbox.org> References: <54E08258.2070404@hammernoch.net> <54E0BB99.7050305@mailbox.org> Message-ID: <1684220.Oq4xnDUWW6@maxwell> On Sunday 15 February 2015 16:30:33 Stephan Beck wrote: > Am 15.02.2015 um 12:26 schrieb Ludwig H?gelsch?fer: > > On 14.02.15 23:05, Stephan Beck wrote: > >> Well, it's rather a precautionary measure than an actual security > >> measure, , reminding me of not trusting the key owner's ability to > >> handle and verify signatures correctly, if he/she uses a signature > >> no one has the chance to check because the information about the > >> public key's location isn't indicated by its owner in his/her very > >> message. I assigned the "I do not trust him" attribute to the first > >> key he used in a previous message. > > > > You seem to have misunderstood what ownertrust is good for. Trusting > > an owner about placing his signatures is not about how she/he signs > > messages. > > > > It is about how carefully she/he checks identity and mail address > > before signing other keys. You can only judge that if you have seen > > her/him in real life doing that. > > OK, I give you that, strictly speaking, it might not be the same, but at the > moment I had no other measure at hand to remind me of being careful with > that kind of event. And a bad signature event is not the ideal event for > putting trust in a key owner's identity at all. > > Stephan Sometimes my signatures are being counted as bad ones. But I figured out it is a bug on kmail or enigmail (there where bug reports on both implementations). Well, I'am just about tu figure it out, so there may be another issue instead of them both. According to the question in the topic: inline signatures always worked, MIME didn't. I still wonder why, and after my next exams I'll investigate on that... Beckus -- I use GnuPG (GPG) for E-Mail encryption and signing. If you want some privacy, my public key ID is 2F9D4F14. The file "singature.asc" this message includes contains a cryptographic signature which enables you to verify this E-Mail really was written by me. Christopher Beck Gerhart-Hauptmann-Str. 1 91058 Erlangen Tel.: 09131 / 9245437 Fax.: 09131 / 8148708 Jabber: beckus at jabber.org EPVPN: (+49 221 59619) - 5232 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From m.mansfeld at mansfeld-elektronik.de Sun Feb 15 20:55:05 2015 From: m.mansfeld at mansfeld-elektronik.de (Matthias Mansfeld) Date: Sun, 15 Feb 2015 20:55:05 +0100 Subject: MIME or inline signature ? In-Reply-To: <1684220.Oq4xnDUWW6@maxwell> References: <54E08258.2070404@hammernoch.net> <54E0BB99.7050305@mailbox.org> <1684220.Oq4xnDUWW6@maxwell> Message-ID: <20150215205505.Horde.1FUPhhFYhIvqSuNkUfiN0w4@webmail.df.eu> Zitat von Christopher Beck : > According to the question in the topic: inline signatures always worked, MIME > didn't. I still wonder why, and after my next exams I'll investigate on > that... One point for inline vs. MIME: You can easily Ctrl-V the complete inline signed or encrypted mail in the clipboard and Ctrl-V it in any GnuPG Interface. Doesn't work with a PGP/MIME mail. Regards Matthias -- Matthias Mansfeld Elektronik * Leiterplattenlayout Neithardtstr. 3, 85540 Haar; Tel.: 089/4620 093-7, Fax: -8 Internet: http://www.mansfeld-elektronik.de GPG http://www.mansfeld-elektronik.de/gnupgkey/mansfeld.asc From dkg at fifthhorseman.net Sun Feb 15 21:26:24 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 15 Feb 2015 15:26:24 -0500 Subject: MIME or inline signature ? In-Reply-To: <54DFBFC8.6030002@dougbarton.email> References: <20150214154916.GA11076@athena.barrera.io> <54DFBFC8.6030002@dougbarton.email> Message-ID: <87fva6hqfj.fsf@alice.fifthhorseman.net> On Sat 2015-02-14 16:36:08 -0500, Doug Barton wrote: > FWIW, I hate this debate, and try hard to stay out of it. But it really > bothers me when people spread factually incorrect information, > especially when they try to use that as the basis of their arguments > for/against one method or the other. I feel the same way. >> * AFAIK, inline gpg has issues with non-ascii characters. ? Correct me if I'm >> wrong. > > This hasn't been true for almost a decade, assuming that the person > using the non-ASCII characters has correctly set up their environment. > And FWIW, it's also not true that PGP/MIME will be 100% successful when > one of the communicants has not correctly set up their environment. if we're talking about signed messages with the possibility of an adversary who can modify the messages, then the the fact is that inline PGP messages have no way of securely indicating the character encoding in use. This means that an attacker can actually modify how the cleartext message is interpreted by fiddling with data *outside* the message body. If we're talking about encrypted messages, the same problem holds. I demonstrate this in the "Message tampering through header substitution" section here: https://dkg.fifthhorseman.net/notes/inline-pgp-harmful/ the lesson here is: if you care about getting the intended textual message through to your peer, you need to embed some information about the formatting *within* the signature. PGP/MIME provides a clear, well-defined way to provide that information. > It's also not true that PGP/MIME protects you from metadata analysis. > The messages are not "one big blob," they are actually separated into > parts, including the attachments. It's trivial to see how many > attachments are in a message just by analyzing the MIME headers, whether > the message/attachments are encrypted or not. If we're talking about PGP/MIME encrypted messages, this is not correct. When having this debate, some people are talking about encrypted messages; others are talking about signed messages. there are lots of ways to talk past one another with this stuff, so please be clear about whether you're talking about encrypted or signed messages. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From jerry at seibercom.net Sun Feb 15 21:20:39 2015 From: jerry at seibercom.net (Jerry) Date: Sun, 15 Feb 2015 15:20:39 -0500 Subject: MIME or inline signature ? In-Reply-To: <20150215205505.Horde.1FUPhhFYhIvqSuNkUfiN0w4@webmail.df.eu> References: <54E08258.2070404@hammernoch.net> <54E0BB99.7050305@mailbox.org> <1684220.Oq4xnDUWW6@maxwell> <20150215205505.Horde.1FUPhhFYhIvqSuNkUfiN0w4@webmail.df.eu> Message-ID: <20150215152039.398ec144@scorpio> On Sun, 15 Feb 2015 20:55:05 +0100, Matthias Mansfeld stated: > One point for inline vs. MIME: You can easily Ctrl-V the complete > inline signed or encrypted mail in the clipboard and Ctrl-V it in any > GnuPG Interface. Doesn't work with a PGP/MIME mail. I have never, ever had a reason to do that, and I cannot think of any reason that I would. I suppose thought that it is possible that it might be of use to someone. -- Jerry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From ndk.clanbo at gmail.com Sun Feb 15 22:06:05 2015 From: ndk.clanbo at gmail.com (NdK) Date: Sun, 15 Feb 2015 22:06:05 +0100 Subject: SSH generic socket forwarding for gpg-agent In-Reply-To: <873869ih88.fsf@alice.fifthhorseman.net> References: <546248D5.9050509@monaco.cx> <87lhmnvn53.fsf@vigenere.g10code.de> <873869ih88.fsf@alice.fifthhorseman.net> Message-ID: <54E10A3D.4040007@gmail.com> Il 13/02/2015 23:23, Daniel Kahn Gillmor ha scritto: > The traditional argument against this sort of feature is that someone > with control over your local socket would most likely have control over > your graphical environment, and therefore could dismiss or hide any > prompt that comes up (so the prompting is a false sense of security). Who told, not so long ago, that if the attacker have control of the machine you're using you've already lost? The machine from where one is originating the ssh connection have to be quite trusted. Else you need a smartcard with out-of-band authorization for every operation. BYtE, Diego From beckus at beckus.eu Sun Feb 15 22:20:33 2015 From: beckus at beckus.eu (Christopher Beck) Date: Sun, 15 Feb 2015 22:20:33 +0100 Subject: MIME or inline signature ? In-Reply-To: <20150215152039.398ec144@scorpio> References: <20150215205505.Horde.1FUPhhFYhIvqSuNkUfiN0w4@webmail.df.eu> <20150215152039.398ec144@scorpio> Message-ID: <3750421.Mf1JsZoiIm@maxwell> On Sunday 15 February 2015 15:20:39 Jerry wrote: > On Sun, 15 Feb 2015 20:55:05 +0100, Matthias Mansfeld stated: > > One point for inline vs. MIME: You can easily Ctrl-V the complete > > inline signed or encrypted mail in the clipboard and Ctrl-V it in any > > GnuPG Interface. Doesn't work with a PGP/MIME mail. > > I have never, ever had a reason to do that, and I cannot think of any reason > that I would. I suppose thought that it is possible that it might be of use > to someone. Forwarding a MIME mail as an attachment also should do the same: The new receiver can see who signed the original mail. And it could be used, but not disused as long as I think... -- I use GnuPG (GPG) for E-Mail encryption and signing. If you want some privacy, my public key ID is 2F9D4F14. The file "singature.asc" this message includes contains a cryptographic signature which enables you to verify this E-Mail really was written by me. Christopher Beck Gerhart-Hauptmann-Str. 1 91058 Erlangen Tel.: 09131 / 9245437 Fax.: 09131 / 8148708 Jabber: beckus at jabber.org EPVPN: (+49 221 59619) - 5232 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From stebe at mailbox.org Sun Feb 15 22:42:09 2015 From: stebe at mailbox.org (Stephan Beck) Date: Sun, 15 Feb 2015 22:42:09 +0100 Subject: MIME or inline signature ? In-Reply-To: <1684220.Oq4xnDUWW6@maxwell> References: <54E08258.2070404@hammernoch.net> <54E0BB99.7050305@mailbox.org> <1684220.Oq4xnDUWW6@maxwell> Message-ID: <54E112B1.4070509@mailbox.org> Hi, Christopher, Am 15.02.2015 um 20:14 schrieb Christopher Beck: > > On Sunday 15 February 2015 16:30:33 Stephan Beck wrote: >> Am 15.02.2015 um 12:26 schrieb Ludwig H?gelsch?fer: >>> On 14.02.15 23:05, Stephan Beck wrote: > > Sometimes my signatures are being counted as bad ones. But I figured out it is > a bug on kmail or enigmail (there where bug reports on both implementations). > Well, I'am just about tu figure it out, so there may be another issue instead > of them both. > > According to the question in the topic: inline signatures always worked, MIME > didn't. I still wonder why, and after my next exams I'll investigate on > that... > > Beckus > I try to be extremely clear. I cannot verify your signature, neither with Enigmail nor using gpg stand-alone. My version is 1.4.12 Steps to reproduce the event: 1) I import your key using your key-ID from within gpg 1.4.12 typing gpg --recv-keys [your key id], result: gpg has imported your key, everything's all right here. 2) I open the header of your message. 3) I copy the signature and save it as a "beckus_sig.asc" file using a simple text editor (or, optionally, as "signature.asc") 4) I type gpg --verify beckus_sig.asc (or signature.asc) 5) gpg outputs: No valid OpenPGP data found. Signature verification failed. (I am retranslating that into English,so please be kind with any imprecision you may find). What's wrong with what I am doing? Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: OpenPGP digital signature URL: From dgouttegattat at incenp.org Sun Feb 15 22:45:38 2015 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Sun, 15 Feb 2015 22:45:38 +0100 Subject: GNUPG 2.* and AIX - questions In-Reply-To: References: Message-ID: <54E11382.9050509@incenp.org> On 02/15/2015 12:16 PM, Michael Felt wrote: > My key question is about the difference between v1.X and v2.X - are there > security elements in v2 that are missing/weaker in v1 - or are the > differences mainly that v2 supports/is always GUI while v1 is always CLI. The gpg program is always CLI-only, both in GnuPG 1.x and GnuPG 2.x. As far as I know, the available GUI frontends can work with all versions (that?s at least the case for GPA and the Enigmail plugin). What?s missing in GnuPG 1.x includes: * elliptic curve-based cryptography, which was introduced in GnuPG 2.1; * all the X.509 and S/MIME stuff?GnuPG 1.x deals with OpenPGP only; * support for SSH authentication; * the GnuPG Agent, only provided with 2.x (although GnuPG 1.x *can* use an Agent if one is available and running); * Maybe some other things, but I guess those are the most important. Overall, and ignoring the above features only present in 2.x, one of the main differences between 1.x and 2.x is that GnuPG 1.x is quite monolithic while GnuPG 2.x is more modular (with many functions delegated to auxiliary programs outside of the gpg binary, such as the GnuPG Agent, the Smartcard Daemon, Dirmngr...) and has more dependencies. As you have experienced yourself, this can make GnuPG 2.x more difficult to compile on some platforms. Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From stebe at mailbox.org Sun Feb 15 22:58:24 2015 From: stebe at mailbox.org (Stephan Beck) Date: Sun, 15 Feb 2015 22:58:24 +0100 Subject: MIME or inline signature ? In-Reply-To: <54E112B1.4070509@mailbox.org> References: <54E08258.2070404@hammernoch.net> <54E0BB99.7050305@mailbox.org> <1684220.Oq4xnDUWW6@maxwell> <54E112B1.4070509@mailbox.org> Message-ID: <54E11680.30207@mailbox.org> A correction: 5) gpg outputs: gpg: no signed data gpg: can't hash datafile: Error opening file Am 15.02.2015 um 22:42 schrieb Stephan Beck: > Hi, Christopher, > > Am 15.02.2015 um 20:14 schrieb Christopher Beck: >> >> On Sunday 15 February 2015 16:30:33 Stephan Beck wrote: >>> Am 15.02.2015 um 12:26 schrieb Ludwig H?gelsch?fer: >>>> On 14.02.15 23:05, Stephan Beck wrote: > I try to be extremely clear. I cannot verify your signature, neither with > Enigmail nor using gpg stand-alone. My version is 1.4.12 > > Steps to reproduce the event: > 1) I import your key using your key-ID from within gpg 1.4.12 typing > gpg --recv-keys [your key id], > result: gpg has imported your key, everything's all right here. > 2) I open the header of your message. > 3) I copy the signature and save it as a "beckus_sig.asc" file using a simple > text editor (or, optionally, as "signature.asc") > 4) I type > gpg --verify beckus_sig.asc (or signature.asc) > 5) gpg outputs: No valid OpenPGP data found. Signature verification failed. > (I am retranslating that into English,so please be kind with any imprecision you > may find). > > What's wrong with what I am doing? > > Stephan > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: OpenPGP digital signature URL: From dgouttegattat at incenp.org Mon Feb 16 00:01:04 2015 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Mon, 16 Feb 2015 00:01:04 +0100 Subject: MIME or inline signature ? In-Reply-To: <54E112B1.4070509@mailbox.org> References: <54E08258.2070404@hammernoch.net> <54E0BB99.7050305@mailbox.org> <1684220.Oq4xnDUWW6@maxwell> <54E112B1.4070509@mailbox.org> Message-ID: <54E12530.7070801@incenp.org> > > What's wrong with what I am doing? You provide GnuPG with only the *signature*. You need to also give it the *signed data* (the message) so that it can perform the verification. If you want to do that manually (something you don?t usually do with PGP/MIME signatures, since it?s quite cumbersome): In addition to what you have already done (saving the signature itself in ?signature.asc?), you must also extract the MIME part that was signed. In the message source, look for a line like the following: Content-Type: multipart/signed; boundary="XXXXXX" and note the ?XXXXXX? boundary string. The signed data will start after the first line starting with ?--XXXXXX? and will end with a blank line followed by another line starting with ?--XXXXXX?. That?s what you need to extract and save to a file (say, ?message.txt?). Do not include the boundary lines themselves, nor the last blank line before the closing boundary line. For example: --XXXXXX Everything from this line ... up to this one is the signed message to verify. --XXXXXX Then you can ask GnuPG to verify the message: gpg --verify signature.asc message.txt (You understand now why nobody does that manually, and leaves that to Enigmail or any other PGP/MIME-enabled mail client.) Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Mon Feb 16 00:07:25 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 15 Feb 2015 18:07:25 -0500 Subject: MIME or inline signature ? In-Reply-To: <54E0C894.8080404@hammernoch.net> References: <54DDDFEB.4020906@mailbox.org> <1185476069.20150214144410@my_localhost> <54DFC6A4.8070302@mailbox.org> <54E08258.2070404@hammernoch.net> <54E0BB99.7050305@mailbox.org> <54E0C894.8080404@hammernoch.net> Message-ID: <54E126AD.2030401@sixdemonbag.org> > A "bad signature" _only shows one thing_: The message was modified > along the way from the signing process (at the senders computer) to > the verification process (at your computer). It doesn't even show that. The modification can be in the signature, not the message -- meaning it's possible to have an entirely unchanged message, but still have a bad signature. A good signature verifies message integrity. A bad signature does not confirm tampering: it only states the integrity is not assured. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3744 bytes Desc: S/MIME Cryptographic Signature URL: From mailinglisten at hauke-laging.de Mon Feb 16 02:01:08 2015 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Mon, 16 Feb 2015 02:01:08 +0100 Subject: MIME or inline signature ? In-Reply-To: <20150215205505.Horde.1FUPhhFYhIvqSuNkUfiN0w4@webmail.df.eu> References: <1684220.Oq4xnDUWW6@maxwell> <20150215205505.Horde.1FUPhhFYhIvqSuNkUfiN0w4@webmail.df.eu> Message-ID: <2579903.TTbjk2cztn@inno> Am So 15.02.2015, 20:55:05 schrieb Matthias Mansfeld: > One point for inline vs. MIME: You can easily Ctrl-V the complete > inline signed or encrypted mail in the clipboard and Ctrl-V it in any > GnuPG Interface. Doesn't work with a PGP/MIME mail. Let's hope that changes soon: https://bugs.kde.org/show_bug.cgi?id=321970 -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 603 bytes Desc: This is a digitally signed message part. URL: From 2014-667rhzu3dc-lists-groups at riseup.net Mon Feb 16 04:00:24 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Mon, 16 Feb 2015 03:00:24 +0000 Subject: MIME or inline signature ? In-Reply-To: <54E0B741.4000909@mailbox.org> References: <54DDDFEB.4020906@mailbox.org> <1185476069.20150214144410@my_localhost> <54DFC6A4.8070302@mailbox.org> <1423095397.20150215121416@my_localhost> <54E0B741.4000909@mailbox.org> Message-ID: <1289600826.20150216030024@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Sunday 15 February 2015 at 3:12:01 PM, in , Stephan Beck wrote: > Didn't you say before you got the same error message as > I did? Yes, I get "gpg: BAD signature from "Xavier Maillard " [unknown]". But that is not an error message, simply a report on how the signature verification went. > No, it does not fetch the correct key, not with > that very message. The preceding lines in the GnuPG output say otherwise:- gpg: Signature made 12/02/2015 22:46:15 GMT Standard Time gpg: using RSA key 0xDE2FFC869AFA5165 gpg: using subkey 0xDE2FFC869AFA5165 instead of primary key 0xBA4909B78F04DE1B which matches with both the key that GnuPG fetches and the key identified in Xavier's message kludges. I do not know what subset of the GnuPG output Enigmail reports. > What is is that indicates (you) that > the server might be down? When I tried to follow the link in Xavier's "X-GPG-Key" header it timed out. And when I put "wwwkeys.pgp.net" into the box on it told me the site was down. The link to that keyserver's web interface still times out for me in two different browsers, but the "downforeveryoneorjustme.com" response now says it is up. Strange. - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net I would like to help you out. Which way did you come in? -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJU4V1KXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwgx8H/0GAd3OKD4KUVGQS2AmTnqJS KjPO+F//q0BvdmqSlZbwxZ1CDNVsxRC9U8yJX2oMJPIvZq/OeIY+1YeZWBHkoMv1 LRsa7zeiZiYF5SGU3Xm6p86O/E13wWo+I2BKkIHLl2h4uzMM4tMnzzHoAguZCHga 4m05dU0XGMl8gGGyxqtFtP5FooWQBnjbn1QseqQEXC7qpROBQqx5usz5b14wVd9c VCG4fYzsf29PtT3DXcig/fd8WYc6+YwHJJwomOMz7iRaEcVdTYabwmqI2Ikgki3b OuiWYBzPpxtOaCyPwUNmZuWXXKQRGt88VJx30qcp+0kY9v1pAOCAWKwQh5O3DwaI vgQBFgoAZgUCVOFdWF8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45LxRAQCrS+uvGTP/Er22f+C13lDk8d+2 xRtCukqjhvzC7niLJgEAbcqFLHDOv5aHuJHq3u4bFPMn5n1pJTcUkwAtk9VsAwc= =i4Wx -----END PGP SIGNATURE----- From 2014-667rhzu3dc-lists-groups at riseup.net Mon Feb 16 04:16:48 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Mon, 16 Feb 2015 03:16:48 +0000 Subject: MIME or inline signature ? In-Reply-To: <20150215205505.Horde.1FUPhhFYhIvqSuNkUfiN0w4@webmail.df.eu> References: <54E08258.2070404@hammernoch.net> <54E0BB99.7050305@mailbox.org> <1684220.Oq4xnDUWW6@maxwell> <20150215205505.Horde.1FUPhhFYhIvqSuNkUfiN0w4@webmail.df.eu> Message-ID: <361265350.20150216031648@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Sunday 15 February 2015 at 7:55:05 PM, in , Matthias Mansfeld wrote: > One point for inline vs. MIME: You can easily Ctrl-V > the complete inline signed or encrypted mail in the > clipboard and Ctrl-V it in any GnuPG Interface. Doesn't > work with a PGP/MIME mail. Copy/pasting the message source instead of the message body works for *some* PGP/MIME messages. - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net Nothing a Pan-Galactic Gargle Blaster won't cure! -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJU4WEhXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXw5TQIAKUEwFP+EaX4MCZKwJXdNY0+ xfuXBtBLu2zk8IM2nk1tTlDjZRLqfmH9kOTNBLGd8KZ3f0U8wO2pvA3fO+5CsaB0 K+8E/krbzWKF/n0sAe01dRX+HuQmqXIxKs4PUGylg8LJ7NlG6E6k1txglAe4mtg7 m2cjs2lIoqMBtuBRcyjHB2S3rtr1iubtJULsCf7U+n56jIW5DHbOoLtlbK7rcE4A ZdJEUjth/qzti3xAKp9qXByJxT7cBdzPemuDtdXtq+SrVavqUUajM/6gn75p5mWD qWOlOF2U0vjeflWlRFnYYc75raW96whB4lb+0ug2sRcHYm6kkpvs7OZdb7RZpAyI vgQBFgoAZgUCVOFhJ18UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45OaNAQB/LZLlQmaB+qEQ69iGwsOBgSjb kD5OTrU37e4cHG9ouwEA8oBrQkn+5r7PD+poZf0y5FwiPBxgbFA0VUa6vzxH7QY= =PRyF -----END PGP SIGNATURE----- From 2014-667rhzu3dc-lists-groups at riseup.net Mon Feb 16 04:25:11 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Mon, 16 Feb 2015 03:25:11 +0000 Subject: MIME or inline signature ? In-Reply-To: <54E0C894.8080404@hammernoch.net> References: <54DDDFEB.4020906@mailbox.org> <1185476069.20150214144410@my_localhost> <54DFC6A4.8070302@mailbox.org> <54E08258.2070404@hammernoch.net> <54E0BB99.7050305@mailbox.org> <54E0C894.8080404@hammernoch.net> Message-ID: <1831259524.20150216032511@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Sunday 15 February 2015 at 4:25:56 PM, in , Ludwig H?gelsch?fer wrote: > The only place to get trust to the senders key (i.e. to > make it "valid" for you) is to meet the key owner in > real life, verify the identity documents, his > fingerprint and mail addresses and sign his key if > everything is ok. There's no measure to replace this > procedure. There is the Web of Trust. Or you used to be able to use a Thawte Notary or similar. Or maybe even a CA. All of which would be overkill for signatures on a mailing list. - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net James, while John had had 'had', had had 'had had'. 'Had had' had had a better effect on the teacher. -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJU4WMYXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwaGcIAK3AVGEjK2MOvP+z0YzCV6Uw oeHTEkimAMOJkOXWqGp5MrgtEDuuti6RmZdoZ8Eao2M1CXFLZvQuMxCD2YLafRMF 8vKDfkgLDzwr55Ze6Hu1pCFpbXnG3sTI1wqVFlgCPejBECSlCpbEFli91mJtMohh fi2ebMhWSvVjCvwBZxrlhfndxbvCH8gb3mP030uu5SFfrPE6OcT9g26RUA9KRt1+ ld2Iadoza3lKTR+epRuKF0VNepHpmjJoHpH+OmT8yQlCSSkrwI7X8UWNicu3sCcC iw3R+aUnM9/En1YzDzXmb+ta1iao+KzjraECk7UnYwEcr/ucnIefBjUC8dmzDgeI vgQBFgoAZgUCVOFjGF8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45DafAQDpBv/QVgD3SpgRrBSUZTkhBzMe TrVlCW3QmMYbBnLnnQEADn1u1KgFe+SACQ7r+p0ZDKoBH96kGKMES9fXempeSw4= =/DFc -----END PGP SIGNATURE----- From dougb at dougbarton.email Mon Feb 16 04:56:21 2015 From: dougb at dougbarton.email (Doug Barton) Date: Sun, 15 Feb 2015 19:56:21 -0800 Subject: MIME or inline signature ? In-Reply-To: <87fva6hqfj.fsf@alice.fifthhorseman.net> References: <20150214154916.GA11076@athena.barrera.io> <54DFBFC8.6030002@dougbarton.email> <87fva6hqfj.fsf@alice.fifthhorseman.net> Message-ID: <54E16A65.5020400@dougbarton.email> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2/15/15 12:26 PM, Daniel Kahn Gillmor wrote: | On Sat 2015-02-14 16:36:08 -0500, Doug Barton wrote: |> FWIW, I hate this debate, and try hard to stay out of it. But it really |> bothers me when people spread factually incorrect information, |> especially when they try to use that as the basis of their arguments |> for/against one method or the other. | | I feel the same way. ... and yet, you not only responded to this thread (fair enough, so did I), but you took the time to write up an entire web page full of FUD on the topic. :) Methinks you do protest too much. |>> * AFAIK, inline gpg has issues with non-ascii characters. ? Correct me if I'm |>> wrong. |> |> This hasn't been true for almost a decade, assuming that the person |> using the non-ASCII characters has correctly set up their environment. |> And FWIW, it's also not true that PGP/MIME will be 100% successful when |> one of the communicants has not correctly set up their environment. | | if we're talking about signed messages with the possibility of an | adversary who can modify the messages, then the the fact is that inline | PGP messages have no way of securely indicating the character encoding | in use. This means that an attacker can actually modify how the | cleartext message is interpreted by fiddling with data *outside* the | message body. | | If we're talking about encrypted messages, the same problem holds. If you are referring to the display of the message after it's decrypted (which is influenced by the content-encoding header) then see below. | I demonstrate this in the "Message tampering through header | substitution" section here: | | https://dkg.fifthhorseman.net/notes/inline-pgp-harmful/ You demonstrate what you claim to be a collision where signatures verify in both cases (I am willing to give you the benefit of the doubt, I haven't tested it). However the collision isn't meaningful. I don't think anyone would receive a message that says, "pay 13" and think that it was what the recipient intended to send. Not to mention, if you were actually sending a message that meant to indicate an amount in monetary units you would spell out the amount in addition to displaying it numerically. Show me a *meaningful* collision that your attack surface is vulnerable to, and I'll pay more attention to it. | the lesson here is: if you care about getting the intended textual | message through to your peer, you need to embed some information about | the formatting *within* the signature. PGP/MIME provides a clear, | well-defined way to provide that information. I don't deny the fact that PGP/MIME encodes the charset info in the body that is signed. I simply deny that this fact is meaningful to the overwhelming majority of users. |> It's also not true that PGP/MIME protects you from metadata analysis. |> The messages are not "one big blob," they are actually separated into |> parts, including the attachments. It's trivial to see how many |> attachments are in a message just by analyzing the MIME headers, whether |> the message/attachments are encrypted or not. | | If we're talking about PGP/MIME encrypted messages, this is not correct. The OP was talking specifically about signed messages with attachments. I made the leap to encrypted, and you're correct, I'm at least partially wrong about that. (I vaguely recall that there is a way to do an encrypted MIME message with attachments that does not end up in one big blob, but I may be mistaken about that. It's been a while since I poked that stuff.) However in the context of signed but not encrypted, my point still stands. Some more errors from your web page: 1. Enigmail is very clear about what parts of the message are signed when decoding an in-line signature. My implementation for Alpine is as well. Do you have any concrete examples of implementations that are not? 2. IME (that is, actually writing code to decrypt and verify e-mail messages of both types) it's actually MIME that is way, way worse to handle when it comes to wrapping, EOL canonicalization, etc. The various implementations play very fast and loose with the "standards" here, Apple being by far the worst culprit. Of course, that means little to nothing to the average users, since their MUA should be able to handle these messages. Just to give you an example, my script to verify in-line signatures is 84 lines, and most of that is the setup (secure temporary directory, error handling, etc.) and the text of the messages that the script prints to indicate to the user what it's doing. The MIME equivalent has basically the same setup cost, but it's 159 lines long. Almost all of the difference is exception handling for MUAs that don't properly follow the standards. 3. Your point that non-MIME messages can't do MIME is accurate, but meaningless. However, you're wrong that you cannot do signatures for attachments, even with multiple attachments, with a message body signed in line. I get that you have a preference, and personally I don't care how you sign your messages. But as I stated before, it really bothers me when the zealots (on either side) misrepresent the facts in order to bolster their case. Doug -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJU4WplAAoJEFzGhvEaGryEmWEIAIWaI2AjQfh/fXR4l7jUSBCn 1kJa7Bjgf27NwE+LHhhCjim72Cvdwf4aNNw52ZsuomOoU0clbe6CmK3sq3pDRvNP RumZ4kaWf3TWkbRFBRhGj88hwx1zu4kE/NxfBnOv3oKrIsG9CpgdCRovjHOF/LMY CxNXDE1mEdY19j8M+4OhXHIkq9F87DMJuz7j/keQu5b0Cn5P8IH8ek0wwx3m7egh BAYq9pcNmlh5gBfT497MXmW3ZlENler8xjSoodcAuCvT4Ut5uLPM65ZLjQ1J69bJ XcAEMCMUyjYwx2J1IIgroMQQdt9A34S/sVMsN9+jy/bx2Mx4CCdcvvOxbd9iMCI= =p8CZ -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: empty-file-one.sig Type: application/octet-stream Size: 287 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: empty-file-two.sig Type: application/octet-stream Size: 287 bytes Desc: not available URL: From dkg at fifthhorseman.net Mon Feb 16 06:08:35 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 16 Feb 2015 00:08:35 -0500 Subject: SSH generic socket forwarding for gpg-agent In-Reply-To: <87d25ctyfg.fsf@vigenere.g10code.de> References: <546248D5.9050509@monaco.cx> <87lhmnvn53.fsf@vigenere.g10code.de> <873869ih88.fsf@alice.fifthhorseman.net> <87d25ctyfg.fsf@vigenere.g10code.de> Message-ID: <874mqmh298.fsf@alice.fifthhorseman.net> On Sat 2015-02-14 08:28:19 -0500, Werner Koch wrote: > On Fri, 13 Feb 2015 23:23, dkg at fifthhorseman.net said: > >> Encouraging this kind of use seems risky. I certainly wouldn't want to >> do it without being able to have gpg-agent prompt me on my local machine >> for each use of the key. Its current silent operation once the > > Similar as with smartcards this feature protect against key > compromise but not against misuse of the key. > >> Could gpg-agent have a setting (per-key? per-agent?) that would have it >> use pinentry for prompting? > > Good idea. We can disable the cache in this case by default and allow > it only by option - either for all keys or (with a bit more code) for a > selected set of keys. To clarify what i meant: My suggestion is to do prompting, but not to require the full passphrase for each use. requiring full passphrase for each use often discourages the use of strong passphrases, esp. if the key is used repeatedly. I've recorded this suggestion here: https://bugs.g10code.com/gnupg/issue1840 Thanks, --dkg From xavier at maillard.im Mon Feb 16 06:38:08 2015 From: xavier at maillard.im (Xavier Maillard) Date: Mon, 16 Feb 2015 06:38:08 +0100 Subject: MIME or inline signature ? In-Reply-To: <681480546.20150214143935@my_localhost> References: <20150213081425.7a418830@scorpio> <681480546.20150214143935@my_localhost> Message-ID: MFPA <2014-667rhzu3dc-lists-groups at riseup.net> writes: >>> My preference is Inline: I want everything right there >>> in the message body where I can see it. > >> Exactly what is it you feel the over powering urge to >> see? > > If the message text is covered by a signature, I want to see the > signature. I would not accept a cheque where the signature was on an > attached document instead of on the cheque. > > With PGP/MIME, even the message text itself is shifted out of the > message body into an attachment. I quite agree with this statement but to do asame here, I should/must use a smaller key than my 8192R. I will probably generate a smaller subkey (2048R ?) and see how it works here. One more argument in favor of the inline: it questions my fellows; what are these cabalistic caracters and then you can what's the purpose of all of this. Regards -- Sent with my mu4e From mlisten at hammernoch.net Mon Feb 16 07:43:52 2015 From: mlisten at hammernoch.net (=?windows-1252?Q?Ludwig_H=FCgelsch=E4fer?=) Date: Mon, 16 Feb 2015 07:43:52 +0100 Subject: MIME or inline signature ? In-Reply-To: <54E126AD.2030401@sixdemonbag.org> References: <54DDDFEB.4020906@mailbox.org> <1185476069.20150214144410@my_localhost> <54DFC6A4.8070302@mailbox.org> <54E08258.2070404@hammernoch.net> <54E0BB99.7050305@mailbox.org> <54E0C894.8080404@hammernoch.net> <54E126AD.2030401@sixdemonbag.org> Message-ID: <54E191A8.2030208@hammernoch.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 16.02.15 00:07, Robert J. Hansen wrote: >> A "bad signature" _only shows one thing_: The message was >> modified along the way from the signing process (at the senders >> computer) to the verification process (at your computer). > > It doesn't even show that. > > The modification can be in the signature, not the message -- > meaning it's possible to have an entirely unchanged message, but > still have a bad signature. > > A good signature verifies message integrity. A bad signature does > not confirm tampering: it only states the integrity is not > assured. You're right. I assumed that modification would be anywhere in message text and signature as a whole, but my wording too tight. Ludwig -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJU4ZGoAAoJEDrb+m0Aoeb+fHAP/RHqt/jo8DTIXvtm+ZaggDGi DRb3KKhnBDhHLsGRSX3xd9om/gmRDLtSSzObp63Gq3LQQg2lfIErfYqsyAChvtzL 0/zjzoRoVBrPjbbiPR5QVX1ge3xWUEeR6X4GLSKtbsPBLizS/bNelYoa4EdfNn3P rY/DXmflm26hZYTGX6GbV321zQtV0MDNop1JFn6jhazwOFNQTssIwVGchKCkwgGz +9aL9coSEFeqnimwS+JURpYZT3nKRa4CmUJOZ0M915DSL3GIBK9qmRoWeEGgvkSr f54r6F2FU/Xqg2eUZI8wXrVE2fk8V38BZSWQfxwtdXzHGLxmD3xgUHjneiJBFU8L d3XrM/iqcQWBFpCwOHizms3QZBHk7RHwcEq3XpOtc9h0hVBp80AdsWGVx2kfG8jD 2e9hyXOxIlDoAM0tdWFa45tTnys/XkGp5HNmkquNdiQtkF7IkNP2Dc85QdAXaPJ9 WLHXfVMlA4AbzZuvhrzfjWaEHDx+6xrq8OiP8xvHQ8AFyMwFmiI8xSxdC5x9hnBa bH8FYVoDVdupTt6n/nm/7pS/Gd6iUy4/2xX8vKuff2kXRS+Duw59jmwqYi72lDwk AA076cJskTXzu0XVG47uc37AnQPv6qB+JwKqmoH0uioft0MKmzPLMAOQmAZultGq txZuf+NZ0KLIRrEf7HAD =+TQu -----END PGP SIGNATURE----- From dkg at fifthhorseman.net Mon Feb 16 08:41:06 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 16 Feb 2015 02:41:06 -0500 Subject: SSH generic socket forwarding for gpg-agent In-Reply-To: <54E10A3D.4040007@gmail.com> References: <546248D5.9050509@monaco.cx> <87lhmnvn53.fsf@vigenere.g10code.de> <873869ih88.fsf@alice.fifthhorseman.net> <54E10A3D.4040007@gmail.com> Message-ID: <871tlqgv71.fsf@alice.fifthhorseman.net> On Sun 2015-02-15 16:06:05 -0500, NdK wrote: > Il 13/02/2015 23:23, Daniel Kahn Gillmor ha scritto: > >> The traditional argument against this sort of feature is that someone >> with control over your local socket would most likely have control over >> your graphical environment, and therefore could dismiss or hide any >> prompt that comes up (so the prompting is a false sense of security). > Who told, not so long ago, that if the attacker have control of the > machine you're using you've already lost? > The machine from where one is originating the ssh connection have to be > quite trusted. Else you need a smartcard with out-of-band authorization > for every operation. Yes, of course. But the remote machine you're connecting *to* (and forwarding your agent to) is outside of that trust boundary. In situations where you want to make sure that you know (and approve of) the use of the agent by the remote machine, you'd like a prompt to appear within your (local, trusted) environment. --dkg From dougb at dougbarton.email Mon Feb 16 08:50:15 2015 From: dougb at dougbarton.email (Doug Barton) Date: Sun, 15 Feb 2015 23:50:15 -0800 Subject: SSH generic socket forwarding for gpg-agent In-Reply-To: <871tlqgv71.fsf@alice.fifthhorseman.net> References: <546248D5.9050509@monaco.cx> <87lhmnvn53.fsf@vigenere.g10code.de> <873869ih88.fsf@alice.fifthhorseman.net> <54E10A3D.4040007@gmail.com> <871tlqgv71.fsf@alice.fifthhorseman.net> Message-ID: <54E1A137.6050308@dougbarton.email> On 2/15/15 11:41 PM, Daniel Kahn Gillmor wrote: > On Sun 2015-02-15 16:06:05 -0500, NdK wrote: >> Il 13/02/2015 23:23, Daniel Kahn Gillmor ha scritto: >> >>> The traditional argument against this sort of feature is that someone >>> with control over your local socket would most likely have control over >>> your graphical environment, and therefore could dismiss or hide any >>> prompt that comes up (so the prompting is a false sense of security). >> Who told, not so long ago, that if the attacker have control of the >> machine you're using you've already lost? >> The machine from where one is originating the ssh connection have to be >> quite trusted. Else you need a smartcard with out-of-band authorization >> for every operation. > > Yes, of course. But the remote machine you're connecting *to* (and > forwarding your agent to) is outside of that trust boundary. > > In situations where you want to make sure that you know (and approve of) > the use of the agent by the remote machine, you'd like a prompt to > appear within your (local, trusted) environment. agent forwarding is off by default, and has to be enabled either on the command line, or in a config file. Why is further user interaction on this point necessary/desirable? Doug From dkg at fifthhorseman.net Mon Feb 16 10:15:10 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 16 Feb 2015 04:15:10 -0500 Subject: SSH generic socket forwarding for gpg-agent In-Reply-To: <54E1A137.6050308@dougbarton.email> References: <546248D5.9050509@monaco.cx> <87lhmnvn53.fsf@vigenere.g10code.de> <873869ih88.fsf@alice.fifthhorseman.net> <54E10A3D.4040007@gmail.com> <871tlqgv71.fsf@alice.fifthhorseman.net> <54E1A137.6050308@dougbarton.email> Message-ID: <87vbj2fc9t.fsf@alice.fifthhorseman.net> On Mon 2015-02-16 02:50:15 -0500, Doug Barton wrote: > On 2/15/15 11:41 PM, Daniel Kahn Gillmor wrote: >> In situations where you want to make sure that you know (and approve of) >> the use of the agent by the remote machine, you'd like a prompt to >> appear within your (local, trusted) environment. > > agent forwarding is off by default, and has to be enabled either on the > command line, or in a config file. Why is further user interaction on > this point necessary/desirable? Because saying "i want to forward my agent to remote system X so that i can sign a couple of specific messages on that host" is different than saying "i want to forward my agent to remote system X so that X can make as many uses of my agent's secret key material as can be pushed down the network pipe". We're now explicitly enabling people to forward the agent (e.g. --extra-socket in gpg-agent(1)); we should be providing appropriate usage controls to accompany that functionality. --dkg From bernhard at intevation.de Mon Feb 16 11:03:51 2015 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 16 Feb 2015 11:03:51 +0100 Subject: [Announce] GnuPG 2.1.2 released In-Reply-To: <8761b5vcnl.fsf@vigenere.g10code.de> References: <874mqs2q4o.fsf@vigenere.g10code.de> <201502131626.13795.bernhard@intevation.de> <8761b5vcnl.fsf@vigenere.g10code.de> Message-ID: <201502161103.58043.bernhard@intevation.de> On Friday 13 February 2015 at 20:23:26, Werner Koch wrote: > > This was ment to read GnuPG-2.1.2 I guess, because of > > No, this describes what is new in the 2.1 branch. ?2.1.2 is basically a > bug fix release. Just wanted to point out that the release announcement left me confused at a few points. If it confused me (as a long time GnuPG User/Contributor) I assume it will confuse many others as well. To restate, I was confused about * What the items in section "What's New in GnuPG-2.1" actually meant, it were the differencen 2.1.1 to 2.1.2 as I could figure out, but this wasn't clear from the text. * "This version fixes a lot of bugs found after the release of 2.1.0" which probably should have been "2.1.1". Overall I believe the announcement as too much text that stays the same for each release. It would benefit from being focussed on the key differences and let the rest be a standard "doc" part. Best, Bernhard ps.: Congrats on the taz article (in German) I've added the link to the wiki. -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Mon Feb 16 11:12:08 2015 From: wk at gnupg.org (Werner Koch) Date: Mon, 16 Feb 2015 11:12:08 +0100 Subject: SSH generic socket forwarding for gpg-agent In-Reply-To: <874mqmh298.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Mon, 16 Feb 2015 00:08:35 -0500") References: <546248D5.9050509@monaco.cx> <87lhmnvn53.fsf@vigenere.g10code.de> <873869ih88.fsf@alice.fifthhorseman.net> <87d25ctyfg.fsf@vigenere.g10code.de> <874mqmh298.fsf@alice.fifthhorseman.net> Message-ID: <87sie6rwqv.fsf@vigenere.g10code.de> On Mon, 16 Feb 2015 06:08, dkg at fifthhorseman.net said: > My suggestion is to do prompting, but not to require the full passphrase > for each use. Okay, that is then similar to the "confirm" flag for the sshcontrol. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From beckus at beckus.eu Mon Feb 16 12:32:49 2015 From: beckus at beckus.eu (Christopher Beck) Date: Mon, 16 Feb 2015 12:32:49 +0100 Subject: MIME or inline signature ? In-Reply-To: <54E112B1.4070509@mailbox.org> References: <1684220.Oq4xnDUWW6@maxwell> <54E112B1.4070509@mailbox.org> Message-ID: <7700724.ItMC3PXH9N@maxwell> On Sunday 15 February 2015 22:42:09 Stephan Beck wrote: > Hi, Christopher, > > Am 15.02.2015 um 20:14 schrieb Christopher Beck: > > On Sunday 15 February 2015 16:30:33 Stephan Beck wrote: > >> Am 15.02.2015 um 12:26 schrieb Ludwig H?gelsch?fer: > >>> On 14.02.15 23:05, Stephan Beck wrote: > > Sometimes my signatures are being counted as bad ones. But I figured out > > it is a bug on kmail or enigmail (there where bug reports on both > > implementations). Well, I'am just about tu figure it out, so there may be > > another issue instead of them both. > > > > > > According to the question in the topic: inline signatures always worked, > > MIME didn't. I still wonder why, and after my next exams I'll investigate > > on that... > > > > Beckus > > I try to be extremely clear. I cannot verify your signature, neither with > Enigmail nor using gpg stand-alone. My version is 1.4.12 > > Steps to reproduce the event: > 1) I import your key using your key-ID from within gpg 1.4.12 typing > gpg --recv-keys [your key id], > result: gpg has imported your key, everything's all right here. > 2) I open the header of your message. > 3) I copy the signature and save it as a "beckus_sig.asc" file using a > simple text editor (or, optionally, as "signature.asc") > 4) I type > gpg --verify beckus_sig.asc (or signature.asc) > 5) gpg outputs: No valid OpenPGP data found. Signature verification failed. > (I am retranslating that into English,so please be kind with any imprecision > you may find). > > What's wrong with what I am doing? > > Stephan Hi, now I'll use the inline format. If you can now verify my signature, this still could be the same bug (or whatever it is...). -- I use GnuPG (GPG) for E-Mail encryption and signing. If you want some privacy, my public key ID is 2F9D4F14. The file "singature.asc" this message includes contains a cryptographic signature which enables you to verify this E-Mail really was written by me. Christopher Beck Gerhart-Hauptmann-Str. 1 91058 Erlangen Tel.: 09131 / 9245437 Fax.: 09131 / 8148708 Jabber: beckus at jabber.org EPVPN: (+49 221 59619) - 5232 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From jerry at seibercom.net Mon Feb 16 12:51:51 2015 From: jerry at seibercom.net (Jerry) Date: Mon, 16 Feb 2015 06:51:51 -0500 Subject: MIME or inline signature ? In-Reply-To: <54E16A65.5020400@dougbarton.email> References: <20150214154916.GA11076@athena.barrera.io> <54DFBFC8.6030002@dougbarton.email> <87fva6hqfj.fsf@alice.fifthhorseman.net> <54E16A65.5020400@dougbarton.email> Message-ID: <20150216065151.6d800a96@scorpio> On Sun, 15 Feb 2015 19:56:21 -0800, Doug Barton stated: > I get that you have a preference, and personally I don't care how you > sign your messages. But as I stated before, it really bothers me when > the zealots (on either side) misrepresent the facts in order to bolster > their case. I agree Doug, and I think this debate has gone on long enough. We are each free to use what ever method we feel most at ease with. Until an RFC is released definitively declaring one type obsolete, who really cares. -- Jerry "That guy's gotta stop... He'll see us." Said to friend Rolf W?therich in 1955 after being advised to slow his driving speed, moments before a head-on collision took his life. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From beckus at beckus.eu Mon Feb 16 13:01:24 2015 From: beckus at beckus.eu (Christopher Beck) Date: Mon, 16 Feb 2015 13:01:24 +0100 Subject: MIME or inline signature ? In-Reply-To: <7700724.ItMC3PXH9N@maxwell> References: <54E112B1.4070509@mailbox.org> <7700724.ItMC3PXH9N@maxwell> Message-ID: <4048664.Goon6ssHQ2@maxwell> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 16 February 2015 12:32:49 Christopher Beck wrote: > On Sunday 15 February 2015 22:42:09 Stephan Beck wrote: > > Hi, Christopher, > > > > Am 15.02.2015 um 20:14 schrieb Christopher Beck: > > > On Sunday 15 February 2015 16:30:33 Stephan Beck wrote: > > >> Am 15.02.2015 um 12:26 schrieb Ludwig H?gelsch?fer: > > >>> On 14.02.15 23:05, Stephan Beck wrote: > > > Sometimes my signatures are being counted as bad ones. But I figured out > > > it is a bug on kmail or enigmail (there where bug reports on both > > > implementations). Well, I'am just about tu figure it out, so there may > > > be > > > another issue instead of them both. > > > > > > > > > According to the question in the topic: inline signatures always worked, > > > MIME didn't. I still wonder why, and after my next exams I'll > > > investigate > > > on that... > > > > > > Beckus > > > > I try to be extremely clear. I cannot verify your signature, neither with > > Enigmail nor using gpg stand-alone. My version is 1.4.12 > > > > Steps to reproduce the event: > > 1) I import your key using your key-ID from within gpg 1.4.12 typing > > gpg --recv-keys [your key id], > > result: gpg has imported your key, everything's all right here. > > 2) I open the header of your message. > > 3) I copy the signature and save it as a "beckus_sig.asc" file using a > > simple text editor (or, optionally, as "signature.asc") > > 4) I type > > gpg --verify beckus_sig.asc (or signature.asc) > > 5) gpg outputs: No valid OpenPGP data found. Signature verification > > failed. > > (I am retranslating that into English,so please be kind with any > > imprecision you may find). > > > > What's wrong with what I am doing? > > > > Stephan > > Hi, > > now I'll use the inline format. If you can now verify my signature, this > still could be the same bug (or whatever it is...). Ah sorry, the previous mail still was MIME. Now it's inline. - -- I use GnuPG (GPG) for E-Mail encryption and signing. If you want some privacy, my public key ID is 2F9D4F14. The file "singature.asc" this message includes contains a cryptographic signature which enables you to verify this E-Mail really was written by me. Christopher Beck Gerhart-Hauptmann-Str. 1 91058 Erlangen Tel.: 09131 / 9245437 Fax.: 09131 / 8148708 Jabber: beckus at jabber.org EPVPN: (+49 221 59619) - 5232 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJU4dwUAAoJEC5gOMAWHIcpIPIH/ilt/1RgO8mbSNinLXogUhvg QEIIjCmG9GzyiO3F3qy+Ni0rW1drMhQAjITzfqwM+oz1q7IC8KSIAS7FhbGNVL7N sVB/qBp+TVCldIl9QeCLtHcd73+hx024OqhHeFwl/R8fLw6vmfz7FOgTbooX226J MmG7XdnBuuv+01ApvYRn0eOuKwM0nZZj/7qjORql2BtOa1+QxRX8D0vDIpF98JS5 xk3R+Mc9Zxb1xFDDjLVQMf7mgbjNdyodNYe3CMpRWZRID5us46MKGmMK2lg4c0LX eMDZWhFQz9fzYoyGT0uwvMh0YFUJFQeuaXRInWhIJVcFLbXFAntUGYOKDawIEN4= =Ht2o -----END PGP SIGNATURE----- From philip.jackson at nordnet.fr Mon Feb 16 13:53:41 2015 From: philip.jackson at nordnet.fr (Philip Jackson) Date: Mon, 16 Feb 2015 13:53:41 +0100 Subject: MIME or inline signature ? In-Reply-To: <54E112B1.4070509@mailbox.org> References: <54E08258.2070404@hammernoch.net> <54E0BB99.7050305@mailbox.org> <1684220.Oq4xnDUWW6@maxwell> <54E112B1.4070509@mailbox.org> Message-ID: <54E1E855.7060601@nordnet.fr> On 15/02/15 22:42, Stephan Beck wrote: > Hi, Christopher, > > Am 15.02.2015 um 20:14 schrieb Christopher Beck: >> >> On Sunday 15 February 2015 16:30:33 Stephan Beck wrote: >>> Am 15.02.2015 um 12:26 schrieb Ludwig H?gelsch?fer: >>>> On 14.02.15 23:05, Stephan Beck wrote: > >> >> Sometimes my signatures are being counted as bad ones. But I figured out it is >> a bug on kmail or enigmail (there where bug reports on both implementations). >> Well, I'am just about tu figure it out, so there may be another issue instead >> of them both. > >> >> According to the question in the topic: inline signatures always worked, MIME >> didn't. I still wonder why, and after my next exams I'll investigate on >> that... >> >> Beckus >> > > I try to be extremely clear. I cannot verify your signature, neither with > Enigmail nor using gpg stand-alone. My version is 1.4.12 > > Steps to reproduce the event: > 1) I import your key using your key-ID from within gpg 1.4.12 typing > gpg --recv-keys [your key id], > result: gpg has imported your key, everything's all right here. > 2) I open the header of your message. > 3) I copy the signature and save it as a "beckus_sig.asc" file using a simple > text editor (or, optionally, as "signature.asc") > 4) I type > gpg --verify beckus_sig.asc (or signature.asc) > 5) gpg outputs: No valid OpenPGP data found. Signature verification failed. > (I am retranslating that into English,so please be kind with any imprecision you > may find). > > What's wrong with what I am doing? > With the expression you used, (gpg --verify signature.asc), gpg will look for a similarly named data file in the same directory where you saved signature.asc. Is that data file (the signed email) present there or is it still in your email client ? Since gpg replies that 'no valid opengpg data found' it would seem that you saved the signature.asc file in some convenient place completely removed from the email concerned and gpg couldn't make the connection. In any case, the Beckus signed emails do check fine with good signature in my thunderbird/enigmail client. Philip -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Mon Feb 16 17:24:52 2015 From: wk at gnupg.org (Werner Koch) Date: Mon, 16 Feb 2015 17:24:52 +0100 Subject: GnuPG News for January 2015 Message-ID: <87d259su23.fsf@vigenere.g10code.de> Hi! Find below the plain text version of https://gnupg.org/blog/20150216-gnupg-in-january.html Shalom-Salam, Werner 1 GnuPG News for January 2015 ????????????????????????????? This is the first issue of a series of status reports for the GnuPG project. It is quite late for a review of things which happened January but unexpected (but meanwhile widely known) events prohibited me from writing this earlies. More on this in another article. First the good news: In January I was contacted by the [Core Infrastructure Initiative] with an offer to help funding the GnuPG development. I gladly accepted that that offer for 60,000 USD for this year. After short and exceptionally non-bureaucratic negotiations we agreed on a contract which pays [g10^code] 5,000 USD each month in 2015 for work on GnuPG. That money will be used to pay my, now increased, salary. Thanks guys. After the release of GnuPG 2.1.1 in late December quite some bugs were reported for this new branch. Thus most of my work was related to fixing these bugs and prepare a bug fix release. As usual Niibe Yutaka helped a lot by taking care of the smartcard part and reviewing other patches and bugs. Some minor bugs and memory leaks were fixed in that time as well as some code cleanup. The move to automake 1.14 and gcc 4.9 required a bit of work. The update to the latest automake version was originally planned after the release of Debian Jessie but for other reasons I had to update my development box to to-be-Jessie already now and thus switching automake was done right away. This required only minor changes but with all those libraries required by GnuPG 2.x, it nevertheless took some days. At that opportunity all the build-aux files (config.guess et al.) were also updated to the latest version. The code base is now quite up to the latest development tools (at least in the repo). gcc 4.9 prints a couple of new warnings and thus a few other code changes were required as well. I also took some days to play with the Windows port but finally decided that there won't be a Windows installer for the forthcoming 2.1.2 versions. We need to investigate on how to best package the Windows binary version without having too much dependencies to external libraries. In particular GPGME with its dependencies on Glib is still troublesome and this might need some re-packaging of GPGME. The general idea for the 2.1 installer will be to package only the GnuPG core without any GUI stuff and do that in a way which helps other packages to use that one GnuPG version on Windows. This has the huge advantage that we can release updates to GnuPG without having also to update all the other software which uses GnuPG under the hood. After having fixed a couple of build problems of OS X, Patrick Brunswick of Enigmail is meanwhile able to build an OS X installer soon after a new GnuPG release and thus a link to this installer has been added to the download page. To allow for a one-stop key generation we also came up with an easy way to generate a key without having to resort to Pinentry. Even after 15 or so years of the `--command-fd' based API to gpg, the first request was filed to provide a stable interface to select the algorithm: gpg has always printed a list of algorithm sets and asked the user to enter the order number to select the algorithms. However, there was no way for a script to map algorithm names to these order numbers. It is surprising that it took so long until someone requested a solid way of entering that. It has been solved by assigning fixed strings (see doc/DETAILS) to each algorithm and allowing this string as an alternative to the order number. Please do not hesitate to ask on gnupg-devel@ for advise or ask for a new feature. If a new feature makes sense and fits into the overall architecture then there is quite some chance that it will be added. But we need to know about it. Like in many years, January closed at that great hackers meeting in Brussels. Maybe next year there will be enough interest for a GnuPG session and a booth as [FOSDEM]. [Core Infrastructure Initiative] http://www.linuxfoundation.org/programs/core-infrastructure-initiative [g10^code] https://g10code.com [FOSDEM] https://fosdem.org -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From stebe at mailbox.org Mon Feb 16 18:19:25 2015 From: stebe at mailbox.org (Stephan Beck) Date: Mon, 16 Feb 2015 18:19:25 +0100 Subject: MIME or inline signature ? In-Reply-To: <54E12530.7070801@incenp.org> References: <54E08258.2070404@hammernoch.net> <54E0BB99.7050305@mailbox.org> <1684220.Oq4xnDUWW6@maxwell> <54E112B1.4070509@mailbox.org> <54E12530.7070801@incenp.org> Message-ID: <54E2269D.1000003@mailbox.org> Am 16.02.2015 um 00:01 schrieb Damien Goutte-Gattat: >> > What's wrong with what I am doing? > > You provide GnuPG with only the *signature*. You need to also give it the > *signed data* (the message) so that it can perform the verification. > > If you want to do that manually (something you don?t usually do with PGP/MIME > signatures, since it?s quite cumbersome): In addition to what you have already > done (saving the signature itself in ?signature.asc?), you must also extract the > MIME part that was signed. Thanks, Damien, now my GPG (stand-alone) has verified the signature, telling me BAD signature. I don't know why, but I do not worry (too much). Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: OpenPGP digital signature URL: From stebe at mailbox.org Mon Feb 16 18:39:00 2015 From: stebe at mailbox.org (Stephan Beck) Date: Mon, 16 Feb 2015 18:39:00 +0100 Subject: MIME or inline signature ? In-Reply-To: <4048664.Goon6ssHQ2@maxwell> References: <54E112B1.4070509@mailbox.org> <7700724.ItMC3PXH9N@maxwell> <4048664.Goon6ssHQ2@maxwell> Message-ID: <54E22B34.2070305@mailbox.org> Hi, Christopher, Am 16.02.2015 um 13:01 schrieb Christopher Beck: > > >> Hi, > >> now I'll use the inline format. If you can now verify my signature, this >> still could be the same bug (or whatever it is...). > > Ah sorry, the previous mail still was MIME. Now it's inline. The signature of this (inline) message was automatically marked as correct by Enigmail, whereas the PGP/MIME tend to give a failure, at least, that's what it looks like at first glance. I will check my Enigmail settings, maybe there's something wrong with them. Thanks Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Mon Feb 16 18:58:38 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 16 Feb 2015 12:58:38 -0500 Subject: SSH generic socket forwarding for gpg-agent In-Reply-To: <87sie6rwqv.fsf@vigenere.g10code.de> References: <546248D5.9050509@monaco.cx> <87lhmnvn53.fsf@vigenere.g10code.de> <873869ih88.fsf@alice.fifthhorseman.net> <87d25ctyfg.fsf@vigenere.g10code.de> <874mqmh298.fsf@alice.fifthhorseman.net> <87sie6rwqv.fsf@vigenere.g10code.de> Message-ID: <87fva5g2lt.fsf@alice.fifthhorseman.net> On Mon 2015-02-16 05:12:08 -0500, Werner Koch wrote: > On Mon, 16 Feb 2015 06:08, dkg at fifthhorseman.net said: > >> My suggestion is to do prompting, but not to require the full passphrase >> for each use. > > Okay, that is then similar to the "confirm" flag for the sshcontrol. yes, exactly. --dkg From stebe at mailbox.org Mon Feb 16 19:01:07 2015 From: stebe at mailbox.org (Stephan Beck) Date: Mon, 16 Feb 2015 19:01:07 +0100 Subject: MIME or inline signature ? In-Reply-To: <54E1E855.7060601@nordnet.fr> References: <54E08258.2070404@hammernoch.net> <54E0BB99.7050305@mailbox.org> <1684220.Oq4xnDUWW6@maxwell> <54E112B1.4070509@mailbox.org> <54E1E855.7060601@nordnet.fr> Message-ID: <54E23063.50707@mailbox.org> Am 16.02.2015 um 13:53 schrieb Philip Jackson: [...] >> >> What's wrong with what I am doing? >> > With the expression you used, (gpg --verify signature.asc), gpg will look for a > similarly named data file in the same directory where you saved signature.asc. > > Is that data file (the signed email) present there or is it still in your email > client ? Since gpg replies that 'no valid opengpg data found' it would seem > that you saved the signature.asc file in some convenient place completely > removed from the email concerned and gpg couldn't make the connection. > > In any case, the Beckus signed emails do check fine with good signature in my > thunderbird/enigmail client. > Thanks, Philip, I already replied to Damien's message, but, indeed, I forgot to copy the text into the same directory. Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: OpenPGP digital signature URL: From mail at rainerkeller.de Mon Feb 16 20:40:18 2015 From: mail at rainerkeller.de (Rainer Keller) Date: Mon, 16 Feb 2015 20:40:18 +0100 Subject: gpg-agent does not authenticate ssh connections In-Reply-To: <2120060.4oWDU2pi9h@green.grummel.netz> References: <2120060.4oWDU2pi9h@green.grummel.netz> Message-ID: <22607479.XnJ47iP72A@green.grummel.netz> > According to the error message gpg-agent is unable to sign using the card: > > ssh user at server > > Agent admitted failure to sign using the key. > > Permission denied (publickey,keyboard-interactive). I had a look on the card with pksc15-tool (removed irrelevant parts): PKCS#15 Card [OpenPGP Card]: Version : 0 Serial number : XXX Manufacturer ID: OpenPGP project Language : de Flags : PRN generation, EID compliant PIN [Signature PIN] Object Flags : [0x3], private, modifiable ID : 01 Flags : [0x13], case-sensitive, local, initialized Length : min_len:0, max_len:32, stored_len:32 Pad char : 0x00 Reference : 1 Type : ascii-numeric Path : 3f00 Tries left : 3 PIN [Encryption PIN] Object Flags : [0x3], private, modifiable ID : 02 Flags : [0x13], case-sensitive, local, initialized Length : min_len:0, max_len:32, stored_len:32 Pad char : 0x00 Reference : 2 Type : ascii-numeric Path : 3f00 Tries left : 0 Private RSA Key [Authentication key] Object Flags : [0x3], private, modifiable Usage : [0x200], nonRepudiation Access Flags : [0x1D], sensitive, alwaysSensitive, neverExtract, local ModLength : 1024 Key ref : 2 (0x2) Native : yes Auth ID : 02 ID : 03 For me it looks like the authentication private key uses the encryption pin (Auth ID 0x02) while it should use the signature pin. It tried to set the encryption pin via "pkcs15-tool --auth-id 02 --change-pin" but this did not work: "PIN code change failed: Data object not found". It seems the encryption pin is not supported by gnupg. Is there any way to change the authentication key to use the signature pin? On mu Gnupg card is only the autentication key present, all other keys are currently empty. May this happen due to the empty slots and may be fixed when I add an encryption key to the card? From antony at blazrsoft.com Mon Feb 16 20:32:57 2015 From: antony at blazrsoft.com (Antony Prince) Date: Mon, 16 Feb 2015 14:32:57 -0500 Subject: MIME or inline signature ? In-Reply-To: <54E22B34.2070305@mailbox.org> References: <54E112B1.4070509@mailbox.org> <7700724.ItMC3PXH9N@maxwell> <4048664.Goon6ssHQ2@maxwell> <54E22B34.2070305@mailbox.org> Message-ID: <54E245E9.7080803@blazrsoft.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/16/2015 12:39 PM, Stephan Beck wrote: > Hi, Christopher, > > Am 16.02.2015 um 13:01 schrieb Christopher Beck: >> > >> >>> Hi, >> >>> now I'll use the inline format. If you can now verify my >>> signature, this still could be the same bug (or whatever it >>> is...). >> >> Ah sorry, the previous mail still was MIME. Now it's inline. > > > > The signature of this (inline) message was automatically marked as > correct by Enigmail, whereas the PGP/MIME tend to give a failure, > at least, that's what it looks like at first glance. I will check > my Enigmail settings, maybe there's something wrong with them. > > Thanks > > Stephan > > > > _______________________________________________ Gnupg-users mailing > list Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > I'm getting the same results with Thunderbird/Enigmail. Christopher's MIME signature fails to verify("BAD signature"), but the inline signature verifies just fine "UNTRUSTED Good signature from Christopher Beck". Just wanted to confirm that I was getting the same results. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJU4kXlAAoJEKbhYkJPBAdEVlgIAL0dXKBFPxiQy+75mrezC/Rb YWTKh83Qopj5YebHBVsOtKhs3N++gHgc36lcAHxC9o5pU3WnpWqoZFHj367ACabu sRU3ilCnvQYXGKTHWeNzezDckGYe5orYAggyg2iLA7GK8Bh2t2o+G7OK3kCbDe0U H6zU1nsP2iUNUuyVnThftoUsmAcurSr72SWzT4DqX4Uoak3bg2ArUzwqBNeEruD+ 6MvZWLrYcl8UMcAbAENGC05kJdKKrPK+bLQmq8KmxbzUj5Brzdz9b959HjFCBXxi P/wU58jUIIQAhLhRyEErJvgQ8bN66OhF7TKHdM7WacZOGJ9AYaSrw4Ua0roDxeE= =2zWd -----END PGP SIGNATURE----- From philip.jackson at nordnet.fr Mon Feb 16 22:14:07 2015 From: philip.jackson at nordnet.fr (Philip Jackson) Date: Mon, 16 Feb 2015 22:14:07 +0100 Subject: moving up from 2.0.26 to 2.1.1 In-Reply-To: <54DA5787.3070903@nordnet.fr> References: <54DA5787.3070903@nordnet.fr> Message-ID: <54E25D9F.2010208@nordnet.fr> I passed an interesting Sunday afternoon : removed gnupg2.0.26 and attempted to replace it with gnupg-2.1.2. The experience was not entirely successful. I got the updated libraries installed using configure/make/checkinstall. I used checkinstall because various howto articles on ubuntu's wiki recommend it and deprecate the older 'make install'. Checkinstall offered the advantage (or so it seemed to me) of producing a deb package which when installed could be easily identified by the package management system - all the easier to remove it later if needed. Sure enough, for the libraries involved, Synaptic Package Manager recognizes these packages installed in the /usr/local/... region of the file system. However, when it came to using checkinstall on the gnupg-2.1.2 build, the deb package installed itself OVER the distro's gnupg-1.4.16. So the end result was a gain of 2.1.2 together with a loss of 1.4.16. Eventually, after re-installing 1.4.16 for a third time, and going back to 'make install', I got 2.1.2 installed without losing 1.4.16. 2.1.2 started up and looked good until I tried to do something with it and then it could not get gpg-agent running : gpg-agent: "error while loading shared libraries: libnpth.so.0: cannot open shared object file: No such file or directory" libnpth.so.0 is certainly present in /usr/local/lib/. Then I ran out of time - put the distro standard version back into service and went back to life (until next time). Philip -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From js-gnupg-users at webkeks.org Mon Feb 16 22:48:17 2015 From: js-gnupg-users at webkeks.org (Jonathan Schleifer) Date: Mon, 16 Feb 2015 22:48:17 +0100 Subject: Please remove MacGPG from gnupg.org due to serious security concerns Message-ID: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> Hi! I hereby request that MacGPG gets removed from gnupg.org due to serious security concerns. Basically, the first thing the Makefile in all their repos / tarballs does is this: @bash -c "$$(curl -fsSL https://raw.github.com/GPGTools/GPGTools_Core/master/newBuildSystem/prepare-core.sh)" So you type make not expecting anything bad (you verified the checksum and everything), but you just executed remote code. Great. And they even hide it from you by prefixing it with @, which is downright evil. So you never notice unless you look at the Makefile. Currently, that script clones another common repo using the unverified git:// protocol (because, why use submodules if you can do it in an insecure way?), but obviously, that can change any minute and could change just for certain IPs etc. The developer(s) don't allow any issues on GitHub, so I tried contacting them by other means (e.g. Twitter), only to get ignored. They clearly don't care about security. In any case, somebody who does something like this clearly doesn't care about security the least. The potential for backdoors is extremely high and I think nobody should be using any software written by this developer / these developer(s), as they clearly demonstrated that they couldn't care less about your security. I don't feel comfortable that the majority of Mac users are using this software which doesn't care for security at all, but is used for extremely security sensitive tasks. I guess this is because gnupg.org recommends it and therefore people think it's safe. I think gnupg.org should do the contrary instead and strongly discourage using it. -- Jonathan From s.murthy at mykolab.com Tue Feb 17 00:16:06 2015 From: s.murthy at mykolab.com (Sandeep Murthy) Date: Mon, 16 Feb 2015 23:16:06 +0000 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> References: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> Message-ID: Hi I think this is an exaggeration. I have been using MacGPG and the GPG Tools support forum for quite some time, and have brought a number of issues to their attention, including a couple of security related ones, like making their key fingerprints more visible. They do care about security and are very responsive to posts on the GPG Tools support forum http://support.gpgtools.org/ The GitHub issues page for MacGPG is not the main places where issues are raised, it?s actually the support forum, where there are lots of other resources as well. Sandeep Murthy s.murthy at mykolab.com > On 16 Feb 2015, at 21:48, Jonathan Schleifer wrote: > > Hi! > > I hereby request that MacGPG gets removed from gnupg.org due to serious security concerns. Basically, the first thing the Makefile in all their repos / tarballs does is this: > > @bash -c "$$(curl -fsSL https://raw.github.com/GPGTools/GPGTools_Core/master/newBuildSystem/prepare-core.sh)" > > So you type make not expecting anything bad (you verified the checksum and everything), but you just executed remote code. Great. And they even hide it from you by prefixing it with @, which is downright evil. So you never notice unless you look at the Makefile. Currently, that script clones another common repo using the unverified git:// protocol (because, why use submodules if you can do it in an insecure way?), but obviously, that can change any minute and could change just for certain IPs etc. > > The developer(s) don't allow any issues on GitHub, so I tried contacting them by other means (e.g. Twitter), only to get ignored. They clearly don't care about security. > > In any case, somebody who does something like this clearly doesn't care about security the least. The potential for backdoors is extremely high and I think nobody should be using any software written by this developer / these developer(s), as they clearly demonstrated that they couldn't care less about your security. > > I don't feel comfortable that the majority of Mac users are using this software which doesn't care for security at all, but is used for extremely security sensitive tasks. I guess this is because gnupg.org recommends it and therefore people think it's safe. I think gnupg.org should do the contrary instead and strongly discourage using it. > > -- > Jonathan > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 873 bytes Desc: Message signed with OpenPGP using GPGMail URL: From s.murthy at mykolab.com Tue Feb 17 00:31:18 2015 From: s.murthy at mykolab.com (Sandeep Murthy) Date: Mon, 16 Feb 2015 23:31:18 +0000 Subject: Fwd: Please remove MacGPG from gnupg.org due to serious security concerns References: Message-ID: <6EA773FA-1564-42DB-8208-20CD3DEFE206@mykolab.com> If you have concerns or suggestions then the best thing would be to contact Luke Le, Steve or the other support staff on http://support.gpgtools.org/ Sandeep Murthy s.murthy at mykolab.com > Begin forwarded message: > > Subject: Re: Please remove MacGPG from gnupg.org due to serious security concerns > From: Sandeep Murthy > Date: 16 February 2015 23:16:06 GMT > Cc: js-gnupg-users at webkeks.org > To: gnupg-users at gnupg.org > > Hi > > I think this is an exaggeration. I have been using MacGPG and the > GPG Tools support forum for quite some time, and have brought a > number of issues to their attention, including a couple of security > related ones, like making their key fingerprints more visible. > > They do care about security and are very responsive to posts on the > GPG Tools support forum > > http://support.gpgtools.org/ > > The GitHub issues page for MacGPG is not the main places where > issues are raised, it?s actually the support forum, where there are > lots of other resources as well. > > Sandeep Murthy > s.murthy at mykolab.com > >> On 16 Feb 2015, at 21:48, Jonathan Schleifer wrote: >> >> Hi! >> >> I hereby request that MacGPG gets removed from gnupg.org due to serious security concerns. Basically, the first thing the Makefile in all their repos / tarballs does is this: >> >> @bash -c "$$(curl -fsSL https://raw.github.com/GPGTools/GPGTools_Core/master/newBuildSystem/prepare-core.sh)" >> >> So you type make not expecting anything bad (you verified the checksum and everything), but you just executed remote code. Great. And they even hide it from you by prefixing it with @, which is downright evil. So you never notice unless you look at the Makefile. Currently, that script clones another common repo using the unverified git:// protocol (because, why use submodules if you can do it in an insecure way?), but obviously, that can change any minute and could change just for certain IPs etc. >> >> The developer(s) don't allow any issues on GitHub, so I tried contacting them by other means (e.g. Twitter), only to get ignored. They clearly don't care about security. >> >> In any case, somebody who does something like this clearly doesn't care about security the least. The potential for backdoors is extremely high and I think nobody should be using any software written by this developer / these developer(s), as they clearly demonstrated that they couldn't care less about your security. >> >> I don't feel comfortable that the majority of Mac users are using this software which doesn't care for security at all, but is used for extremely security sensitive tasks. I guess this is because gnupg.org recommends it and therefore people think it's safe. I think gnupg.org should do the contrary instead and strongly discourage using it. >> >> -- >> Jonathan >> >> >> _______________________________________________ >> Gnupg-users mailing list >> Gnupg-users at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 873 bytes Desc: Message signed with OpenPGP using GPGMail URL: From js-gnupg-users at webkeks.org Tue Feb 17 00:41:51 2015 From: js-gnupg-users at webkeks.org (Jonathan Schleifer) Date: Tue, 17 Feb 2015 00:41:51 +0100 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: References: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> Message-ID: <3501398A-6622-4065-AEE3-E7F8EBAACCFE@webkeks.org> Am 17.02.2015 um 00:16 schrieb Sandeep Murthy : > I think this is an exaggeration. I have been using MacGPG and the > GPG Tools support forum for quite some time, and have brought a > number of issues to their attention, including a couple of security > related ones, like making their key fingerprints more visible. On the one hand, you think it's an exaggeration, on the other, you can list even more examples. I mean, they don't even do the most basic security practices which are common in basically all projects these days, even non-security related projects. And we're talking about a security related project here! If someone clearly demonstrates even lack of the most basic security measures, why should that someone be trusted with way more complex stuff? You listing they had problems in the past basically only strengthens the argument that they are not to be trusted and should not be endorsed. > They do care about security and are very responsive to posts on the > GPG Tools support forum Really? Somebody caring about security executing remote code? Rather than using git submodules (which exist for how many years?), they prefer executing remote code that then downloads more code using an unverified channel. This can't be just laziness (using git submodules is less work), but looks like somebody even put a lot of effort into failing at security. How can you call that "caring about security"? If you'd argue they care a lot about being insecure, I'd agree though, because they actually seem to put a lot of effort into that? > http://support.gpgtools.org/ If you are a security project, you should be thankful for people reporting bugs, not trying to make it as hard as possible to report a serious bug. This looks like more of a "users help users" forum kind of thing, nothing where you would want to report a bug. -- Jonathan From hugo at barrera.io Tue Feb 17 00:53:11 2015 From: hugo at barrera.io (Hugo Osvaldo Barrera) Date: Mon, 16 Feb 2015 20:53:11 -0300 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> References: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> Message-ID: <20150216235311.GA10680@athena.barrera.io> On 2015-02-16 22:48, Jonathan Schleifer wrote: > Hi! > > I hereby request that MacGPG gets removed from gnupg.org due to serious security concerns. Basically, the first thing the Makefile in all their repos / tarballs does is this: > > @bash -c "$$(curl -fsSL https://raw.github.com/GPGTools/GPGTools_Core/master/newBuildSystem/prepare-core.sh)" > > So you type make not expecting anything bad (you verified the checksum and everything), but you just executed remote code. Great. And they even hide it from you by prefixing it with @, which is downright evil. So you never notice unless you look at the Makefile. Currently, that script clones another common repo using the unverified git:// protocol (because, why use submodules if you can do it in an insecure way?), but obviously, that can change any minute and could change just for certain IPs etc. > > The developer(s) don't allow any issues on GitHub, so I tried contacting them by other means (e.g. Twitter), only to get ignored. They clearly don't care about security. > > In any case, somebody who does something like this clearly doesn't care about security the least. The potential for backdoors is extremely high and I think nobody should be using any software written by this developer / these developer(s), as they clearly demonstrated that they couldn't care less about your security. > > I don't feel comfortable that the majority of Mac users are using this software which doesn't care for security at all, but is used for extremely security sensitive tasks. I guess this is because gnupg.org recommends it and therefore people think it's safe. I think gnupg.org should do the contrary instead and strongly discourage using it. > > -- > Jonathan > It is true that there's a pretty big security hole there with "git clone git://github.com...", since any malicious attacker can intercept that communication. There's no checksuming or anything to make this difficult *at all*. What *does* suprise me is that there's a commit to specifically remove git+ssh in favour of insecure ssh. There's no comment on why that was done either: https://github.com/GPGTools/GPGTools_Core/commit/5186bade36acedfdc0b76f9f5ddfcfc004ec698b However, I'd recomend that you go over the proper support channels first (rather than merely twitter) before asking that references to the proyect are deleted. As stated on https://gpgtools.org/: Please report any issues you find on our support platform. Which points to http://support.gpgtools.org/. Cheers, -- Hugo Osvaldo Barrera A: Because we read from top to bottom, left to right. Q: Why should I start my reply below the quoted text? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From js-gnupg-users at webkeks.org Tue Feb 17 01:03:38 2015 From: js-gnupg-users at webkeks.org (Jonathan Schleifer) Date: Tue, 17 Feb 2015 01:03:38 +0100 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: <20150216235311.GA10680@athena.barrera.io> References: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> <20150216235311.GA10680@athena.barrera.io> Message-ID: Am 17.02.2015 um 00:53 schrieb Hugo Osvaldo Barrera : > It is true that there's a pretty big security hole there with "git clone > git://github.com...", since any malicious attacker can intercept that > communication. There's no checksuming or anything to make this difficult *at > all*. Well, this is only checking out the code. While I agree that this is dangerous, the curl | sh paradigm is even more dangerous. > What *does* suprise me is that there's a commit to specifically remove git+ssh > in favour of insecure ssh. There's no comment on why that was done either: > > https://github.com/GPGTools/GPGTools_Core/commit/5186bade36acedfdc0b76f9f5ddfcfc004ec698b I'm guessing because you need an SSH key at GitHub in order to pull via SSH. Yet another problem solved by git modules. Still, they could have at least changed it to https. > However, I'd recomend that you go over the proper support channels first > (rather than merely twitter) before asking that references to the proyect are > deleted. > > As stated on https://gpgtools.org/: > > Please report any issues you find on our support platform. > > Which points to http://support.gpgtools.org/. Well, I think there's enough evidence that they do not know how to do things securely. It has even been pointed out in this thread that this is not the first time there are serious security problems. It feels like they are actively trying to make it insecure, because they do things that normally nobody working on a security product would even consider. Please consider this: GnuPG is a security product. People's lives might depend on it. They might have heard that GnuPG is secure and think they are safe since even Snowden uses it. They go to gnupg.org and then download MacGPG. That's dangerous and there's no way for them to know unless they go check the source. As a matter of fact, I compromised one of my machines by checking out one of the MacGPG tools, checking the checksum of the downloaded tarball and then typing make. I did not realize it executed remote code (twice even, the curl and the git checkout, on which make is also run later on). They even actively hide the fact, which makes it even worse. Should gnupg.org really endorse that? -- Jonathan From 2014-667rhzu3dc-lists-groups at riseup.net Tue Feb 17 01:16:26 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Tue, 17 Feb 2015 00:16:26 +0000 Subject: MIME or inline signature ? In-Reply-To: References: <20150213081425.7a418830@scorpio> <681480546.20150214143935@my_localhost> Message-ID: <1736159995.20150217001626@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Monday 16 February 2015 at 5:38:08 AM, in , Xavier Maillard wrote: > One more argument in favor of the inline: it questions > my fellows; what are these cabalistic caracters and > then you can what's the purpose of all of this. I like that advantage of keeping it all visible in the message body. But don't recall ever having been asked the question. - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net Man is not a rational animal, he is a rationalising animal. -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJU4oiQXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXw3/QH+wWOd7nCCLPCs5Ae2pj+W5kZ b/j02U9oQmunl2COpKsF+/Apy1pcZ9Zi6YKFH9nAzeyV7QuZJJdtg52m5r9/5ZFv BiYntEDJBeQtGB/uJ00OhtI09NU1oGwILv4UmXubScrxF3GFY2Ib62GB6Nl7JTEC Zd+L72hF7Qf4hZhjMMRJKAD/9XnkTZ5KNulHcCAPUberzoheIT8BzeuCYobJR+OH 8wMH62MqBnSERR4ppknlEOu1+95zjYMyOgn6zXR4xpPnNzfK+80/UmVYloHYxhbU 5xL85SX6abCC3mx9tcpqCn35t1afcyc3fhAT7GjnH6vNLG7zTxdlx/gY4fODabuI vgQBFgoAZgUCVOKIn18UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45KtZAQCh3eIW7ts4093r4hI3EAVFG2bS 8++QE9IohrSvhPVPoQEAdDQxj8hclIhZbXNImWMJ4PN0UZ4yvOaThLLZ0yBvOQI= =z/ea -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Tue Feb 17 02:21:00 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 16 Feb 2015 20:21:00 -0500 Subject: 2.1.2: keyserver route failure Message-ID: <54E2977C.106@sixdemonbag.org> Is there any explanation for this behavior, or is this a 2.1.2 bug? (This is using Patrick's OS X package, if that matters. It also affects all keyservers I tested, not just the round-robin front-end.) quorra:~ rjh$ gpg -vvvv --keyserver x-hkp://pool.sks-keyservers.net --recv-key 0xD6B98E10 gpg: using character set 'utf-8' gpg: keyserver receive failed: No route to host quorra:~ rjh$ ping pool.sks-keyservers.net PING pool.sks-keyservers.net (140.211.169.202): 56 data bytes 64 bytes from 140.211.169.202: icmp_seq=0 ttl=55 time=102.879 ms From s.murthy at mykolab.com Tue Feb 17 07:53:18 2015 From: s.murthy at mykolab.com (Sandeep Murthy) Date: Tue, 17 Feb 2015 06:53:18 +0000 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: References: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> <20150216235311.GA10680@athena.barrera.io> Message-ID: <68A83FF0-7527-4300-9A47-79562DACAFA1@mykolab.com> > I'm guessing because you need an SSH key at GitHub in order to pull via SSH. Yet another problem solved by git modules. > > Still, they could have at least changed it to https. GitHub supports pull/push via SSH or HTTPS therefore you can do this to with MacGPG (2) or any GitHub repo. > >> However, I'd recomend that you go over the proper support channels first >> (rather than merely twitter) before asking that references to the proyect are >> deleted. There must be lots of MacGPG users and most of them probably use the GPG suite, because it is GUI based (also more user friendly, unlike GnuPG) and it would not be fair on them to unilaterally remove the link to GnuPG or to receive some kind of security warning without raising the issues you mention with the people who are actively developing and maintaining the source. Sandeep -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 873 bytes Desc: Message signed with OpenPGP using GPGMail URL: From js-gnupg-users at webkeks.org Tue Feb 17 11:01:52 2015 From: js-gnupg-users at webkeks.org (Jonathan Schleifer) Date: Tue, 17 Feb 2015 11:01:52 +0100 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: <68A83FF0-7527-4300-9A47-79562DACAFA1@mykolab.com> References: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> <20150216235311.GA10680@athena.barrera.io> <68A83FF0-7527-4300-9A47-79562DACAFA1@mykolab.com> Message-ID: <078EC143-B618-41DD-B2B3-3A46FF83184A@webkeks.org> Am 17.02.2015 um 07:53 schrieb Sandeep Murthy : >> I'm guessing because you need an SSH key at GitHub in order to pull via SSH. Yet another problem solved by git modules. >> >> Still, they could have at least changed it to https. > > GitHub supports pull/push via SSH or HTTPS therefore you can do this to with MacGPG (2) > or any GitHub repo. Well, for SSH, you need a key, but for HTTPS, you don't, so they could have used that. However, git submodules solve the problem completely, as you can use relative paths. So it uses whatever you used to check out the initial repo. > There must be lots of MacGPG users and most of them probably use the GPG > suite, because it is GUI based (also more user friendly, unlike GnuPG) and it > would not be fair on them to unilaterally remove the link to GnuPG or to receive > some kind of security warning without raising the issues you mention with > the people who are actively developing and maintaining the source. I disagree. The developers are not capable of writing secure software, as demonstrated (several times even, it seems). It would be best to advise to never use that at all and then write new software, if there's demand for it. It's sometimes better to not use something than to use something untrustworthy. For security products, this is especially true. -- Jonathan From jerry at seibercom.net Tue Feb 17 12:13:18 2015 From: jerry at seibercom.net (Jerry) Date: Tue, 17 Feb 2015 06:13:18 -0500 Subject: MIME or inline signature ? In-Reply-To: <1736159995.20150217001626@my_localhost> References: <20150213081425.7a418830@scorpio> <681480546.20150214143935@my_localhost> <1736159995.20150217001626@my_localhost> Message-ID: <20150217061318.3cd64936@scorpio> On Tue, 17 Feb 2015 00:16:26 +0000, MFPA stated: > I like that advantage of keeping it all visible in the message body. That is the reason I detest INLINE as opposed to PGP/MIME. The insertion of superfluous garbage in the message body is annoying to say the least. Worse, since most users have no concept of "trimming" a message before replying to it, even more useless garbage is transmitted when replied to, thus killing more innocent electrons and wasting bandwidth not to mention the consumption of screen territory. -- Jerry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From kristian.fiskerstrand at sumptuouscapital.com Tue Feb 17 12:21:42 2015 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Tue, 17 Feb 2015 12:21:42 +0100 Subject: 2.1.2: keyserver route failure In-Reply-To: <54E2977C.106@sixdemonbag.org> References: <54E2977C.106@sixdemonbag.org> Message-ID: <54E32446.9040402@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 02/17/2015 02:21 AM, Robert J. Hansen wrote: > Is there any explanation for this behavior, or is this a 2.1.2 > bug? (This is using Patrick's OS X package, if that matters. It > also affects all keyservers I tested, not just the round-robin > front-end.) > > > > quorra:~ rjh$ gpg -vvvv --keyserver > x-hkp://pool.sks-keyservers.net --recv-key 0xD6B98E10 gpg: using > character set 'utf-8' gpg: keyserver receive failed: No route to > host > > quorra:~ rjh$ ping pool.sks-keyservers.net PING > pool.sks-keyservers.net (140.211.169.202): 56 data bytes 64 bytes > from 140.211.169.202: icmp_seq=0 ttl=55 time=102.879 ms > You don't know that the hosts in those two situations are the same, since it is a DNS round-robin behind the pool address. You can get more info by increase dirmngr verbosity and looking at its logs. - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- Varitatio delectat Change pleases -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJU4yQRAAoJEP7VAChXwav6EFkH/3e/4Qfx/0b6t5QlECHwE2Fj KulGxX8y7eKFYMZkq/7p3GkVmAJPNzX8N8pHHtOhRAHNDXucb7qib4nGVcKGYLff FWQhH3VFArnMUoVbplKYfl5UWrQfYulJhmI5SNFlQX7a29/7JIPOtfi/qXZmJfTm +MHbad6DWAlIZQbQ5Eluo4KHm5RSpD337vgCfcTO4r1ZSFh81U9TRGoUxdrfQdls hbegOyPLJU/SszvX40I8HGVd9o0OsLJ9lmqKZf+fW0so6LBh1R+m8lqU6MSgwXZ0 dzqBET2NNw2+M0jB8PL7t+bxJ6C+op+iro3PaTtH+HEssZLqVDA2lB3t2a1pVuA= =gqgY -----END PGP SIGNATURE----- From wk at gnupg.org Tue Feb 17 13:54:52 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 17 Feb 2015 13:54:52 +0100 Subject: 2.1.2: keyserver route failure In-Reply-To: <54E2977C.106@sixdemonbag.org> (Robert J. Hansen's message of "Mon, 16 Feb 2015 20:21:00 -0500") References: <54E2977C.106@sixdemonbag.org> Message-ID: <87wq3gpujn.fsf@vigenere.g10code.de> On Tue, 17 Feb 2015 02:21, rjh at sixdemonbag.org said: > quorra:~ rjh$ gpg -vvvv --keyserver x-hkp://pool.sks-keyservers.net > --recv-key 0xD6B98E10 > gpg: using character set 'utf-8' > gpg: keyserver receive failed: No route to host It should have swithed to the next host of the pool. Please run gpg-connect-agent --dirmngr 'keyserver --hosttable' /bye which shows what dirmngr knows about the pool. Here is an example: $ gpg-connect-agent --dirmngr 'keyserver --hosttable' /bye S # hosttable (idx, ipv6, ipv4, dead, name, time): S # 0 6 4 zimmermann.mayfirst.org v6=[2001:470:1:116::6] v4=216.66.15.2 S # 1 4 pgpkeys.mit.edu v4=18.9.60.141 S # 2 pgpkeyss.mit.edu S # 3 pool.sks-keyservers.net S # . pool.sks-keyservers.net S # . --> 21 15 9 14 6 7 8 12 17 5 16 19 20 18 10 4* 11 13 S # 4 6 [2001:67c:2050:1000::3:4] S # 5 6 keyserver.cns.ipv6.vt.edu v6=[2001:468:c80:210f:0:162:701c:c917] S # 6 6 4 gpg.spline.inf.fu-berlin.de v6=[2001:6f8:1c3c:babe::62:1] v4=130.133.110.62 S # 7 6 hufu.ki.iif.hu v6=[2001:738:0:600:216:3eff:fe02:42] S # 8 6 key.bbs4.us v6=[2001:19f0:ac00:42::dead:beef] S # 9 6 bluemlisalp.durcheinandertal.ch v6=[2a03:580:f001:103::2] S # 10 6 s3.pkern.at v6=[2a03:4000:5:b3::1] S # 11 6 [2a00:b9c0:e::4] S # 12 6 4 key.ip6.li v6=[2a01:7a0:1::6] v4=193.17.17.6 S # 13 6 [2a01:a500:385:1::9:1] S # 14 4 cryptonomicon.mit.edu v4=18.9.60.141 S # 15 4 79.143.214.216 S # 16 4 kronecker.scientia.net v4=85.10.205.199 S # 17 4 keys02.fedoraproject.org v4=140.211.169.202 S # 18 4 RESISP-209-135-211-141.smf.ragingwire.net v4=209.135.211.141 S # 19 4 mira.cbaines.net v4=212.71.252.8 S # 20 4 openpgp.andrew.kvalhe.im v4=107.170.242.217 S # 21 4 176.31.199.172 S # 22 6 4 keys.mayfirst.org v6=[2001:470:1:116::6] v4=216.66.15.2 OK Here host [2001:67c:2050:1000::3:4] (index 4) is used. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Feb 17 14:22:32 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 17 Feb 2015 14:22:32 +0100 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: <20150216235311.GA10680@athena.barrera.io> (Hugo Osvaldo Barrera's message of "Mon, 16 Feb 2015 20:53:11 -0300") References: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> <20150216235311.GA10680@athena.barrera.io> Message-ID: <87sie4pt9j.fsf@vigenere.g10code.de> On Tue, 17 Feb 2015 00:53, hugo at barrera.io said: > git://github.com...", since any malicious attacker can intercept that > communication. There's no checksuming or anything to make this difficult *at > all*. > > What *does* suprise me is that there's a commit to specifically remove git+ssh > in favour of insecure ssh. There's no comment on why that was done either: [I assume you meant "insecure git"] I do not think that it matters whether you pull using the git or the ssh protocol. In both cases an active attacker can intercept the traffic easily. Virtually nobody checks ssh host keys and how should they do it given that I can't find its fingerprint easily on github. Thus you would only see the "host key changed" warning in case this is not the first time you connected to this github project (I assume they use different host keys per project). After all it is not different from downloading tarballs - only 10 to 20% of all downloads also download the signature file and for most projects there is no signature file. For gnupg.org we assume that users of the repos closely watch out for conflicts and verify the latest release tag. If there is a problem that should be reported to a mailing-list (after verification that it is really a conflict). git meanwhile allows to sign commits. If anyone knows a method to set a different key for tagging and commits, I would soon start to sign each commit. I use a smartcard based key for tagging but won't use that for regular commits. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Feb 17 14:31:29 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 17 Feb 2015 14:31:29 +0100 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> (Jonathan Schleifer's message of "Mon, 16 Feb 2015 22:48:17 +0100") References: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> Message-ID: <87oaospsum.fsf@vigenere.g10code.de> On Mon, 16 Feb 2015 22:48, js-gnupg-users at webkeks.org said: > @bash -c "$$(curl -fsSL https://raw.github.com/GPGTools/GPGTools_Core/master/newBuildSystem/prepare-core.sh)" Bad idea to directly run code from a foreign remote site. I'd appreciate if someone from gpgtools.org can comment on this. GnuPG's speedo build system also downloads stuff via the Makefile but it verifies the checksums before proceeding. The checksums are taken from a public file which has a detached signature and the public key for that is one of the GnuPG release signing keys. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From rjh at sixdemonbag.org Tue Feb 17 14:39:18 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 17 Feb 2015 08:39:18 -0500 Subject: 2.1.2: keyserver route failure In-Reply-To: <54E32446.9040402@sumptuouscapital.com> References: <54E2977C.106@sixdemonbag.org> <54E32446.9040402@sumptuouscapital.com> Message-ID: <54E34486.7060208@sixdemonbag.org> > You don't know that the hosts in those two situations are the > same... I know, which is why I said: > It also affects all keyservers I tested, not just the round-robin > front-end. I tried several different non-round-robin servers. Same thing. From s.murthy at mykolab.com Tue Feb 17 14:42:41 2015 From: s.murthy at mykolab.com (Sandeep Murthy) Date: Tue, 17 Feb 2015 13:42:41 +0000 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: <87oaospsum.fsf@vigenere.g10code.de> References: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> <87oaospsum.fsf@vigenere.g10code.de> Message-ID: I have posted a message in the GPG Tools support forum copying the original post in this thread, letting the developers know of the concerns raised here. Perhaps you will see some comments in the near future. Sandeep Murthy s.murthy at mykolab.com > On 17 Feb 2015, at 13:31, Werner Koch wrote: > > On Mon, 16 Feb 2015 22:48, js-gnupg-users at webkeks.org said: > >> @bash -c "$$(curl -fsSL https://raw.github.com/GPGTools/GPGTools_Core/master/newBuildSystem/prepare-core.sh)" > > Bad idea to directly run code from a foreign remote site. I'd > appreciate if someone from gpgtools.org can comment on this. > > GnuPG's speedo build system also downloads stuff via the Makefile but it > verifies the checksums before proceeding. The checksums are taken from a > public file which has a detached signature and the public key for that > is one of the GnuPG release signing keys. > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 873 bytes Desc: Message signed with OpenPGP using GPGMail URL: From s.murthy at mykolab.com Tue Feb 17 14:58:47 2015 From: s.murthy at mykolab.com (Sandeep Murthy) Date: Tue, 17 Feb 2015 13:58:47 +0000 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: <3501398A-6622-4065-AEE3-E7F8EBAACCFE@webkeks.org> References: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> <3501398A-6622-4065-AEE3-E7F8EBAACCFE@webkeks.org> Message-ID: <06ACA41C-7BCE-4509-905C-97DC21AAD15D@mykolab.com> > >> http://support.gpgtools.org/ > > If you are a security project, you should be thankful for people reporting bugs, not trying to make it as hard as possible to report a serious bug. This looks like more of a "users help users" forum kind of thing, nothing where you would want to report a bug. FYI I think you haven?t really looked at the support forum. This page http://support.gpgtools.org/kb/faq/found-an-issue clearly lists instructions for submitting a bug. They are always interested in reproducible issues, and every week in the discussions such issues are reported. Therefore it is not true that this support forum does not allow people to report bugs. Sandeep -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 873 bytes Desc: Message signed with OpenPGP using GPGMail URL: From wk at gnupg.org Tue Feb 17 14:58:24 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 17 Feb 2015 14:58:24 +0100 Subject: gpg-agent does not authenticate ssh connections In-Reply-To: <22607479.XnJ47iP72A@green.grummel.netz> (Rainer Keller's message of "Mon, 16 Feb 2015 20:40:18 +0100") References: <2120060.4oWDU2pi9h@green.grummel.netz> <22607479.XnJ47iP72A@green.grummel.netz> Message-ID: <87k2zgprlr.fsf@vigenere.g10code.de> On Mon, 16 Feb 2015 20:40, mail at rainerkeller.de said: > For me it looks like the authentication private key uses the encryption pin > (Auth ID 0x02) while it should use the signature pin. > It tried to set the encryption pin via "pkcs15-tool --auth-id 02 [ You should not use this tool for the OpenPGP card. That card is not pkcs#15 and Olaf's implementaion for the OpenPGP card is thus quite limited. Use "gpg --card-status" or watch the scdameon log. ] > Is there any way to change the authentication key to use the signature pin? > On mu Gnupg card is only the autentication key present, all other keys are > currently empty. May this happen due to the empty slots and may be Gpg-agent uses the smartcard key which is identified by the $AUTHKEYID attribute: $ gpg-connect-agent 'scd getattr $AUTHKEYID' /bye S $AUTHKEYID OPENPGP.3 OK Thus for this card the key with the id OPENPGP.3 is to be used for ssh access. This is the standard for OpenPGP cards. Another example $ gpg-connect-agent 'scd getattr $AUTHKEYID' /bye S $AUTHKEYID NKS-NKS3.4531 OK This is an old Telesec card and it shows the keyid to be used with this card. Now, how is this attribute assigned? It is simply a matter of the driver. For app-openpgp.c it is hardwired to "OPENPGP.3", the app-nks.c driver hardwires to "NKS-NKS3.4531", and the generic app-p15.c driver uses the first listed key capabable of signing. If there is no current card with an $AUTHKEYID attribute, gpg-agent won't add the currently inserted card to the list of supported keys. Thus only the keys listed in ~/.gnupg/sshcontrol will be used. After gpg-agent has seen the card the first time it creates a stub key in its keystore to record the serial number. You would simply put the keygrip (which is also the basename of the stub key file) into sshcontrol and things should work as expected - of course you need to make sure that the key is capable of signing. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From hugo at barrera.io Tue Feb 17 15:14:24 2015 From: hugo at barrera.io (Hugo Osvaldo Barrera) Date: Tue, 17 Feb 2015 11:14:24 -0300 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: <078EC143-B618-41DD-B2B3-3A46FF83184A@webkeks.org> References: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> <20150216235311.GA10680@athena.barrera.io> <68A83FF0-7527-4300-9A47-79562DACAFA1@mykolab.com> <078EC143-B618-41DD-B2B3-3A46FF83184A@webkeks.org> Message-ID: <20150217141424.GA24511@athena.barrera.io> On 2015-02-17 11:01, Jonathan Schleifer wrote: > > I disagree. The developers are not capable of writing secure software, as demonstrated (several times even, it seems). It would be best to advise to never use that at all and then write new software, if there's demand for it. It's sometimes better to not use something than to use something untrustworthy. For security products, this is especially true. > Actually, I've noticed that there was a very quick reply to this when it was brought to the dev's attention. I'll leave this here for anyone else interested in following-up: https://github.com/GPGTools/GPGTools_Core/commit/5186bade36acedfdc0b76f9f5ddfcfc004ec698b I'm not aware of any track record of writing bad software in the past either - I believe they're just human. Cheers, -- Hugo Osvaldo Barrera A: Because we read from top to bottom, left to right. Q: Why should I start my reply below the quoted text? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From s.murthy at mykolab.com Tue Feb 17 15:54:12 2015 From: s.murthy at mykolab.com (Sandeep Murthy) Date: Tue, 17 Feb 2015 14:54:12 +0000 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: <20150217141424.GA24511@athena.barrera.io> References: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> <20150216235311.GA10680@athena.barrera.io> <68A83FF0-7527-4300-9A47-79562DACAFA1@mykolab.com> <078EC143-B618-41DD-B2B3-3A46FF83184A@webkeks.org> <20150217141424.GA24511@athena.barrera.io> Message-ID: > > Actually, I've noticed that there was a very quick reply to this when it was > brought to the dev's attention. I'll leave this here for anyone else interested > in following-up: > > https://github.com/GPGTools/GPGTools_Core/commit/5186bade36acedfdc0b76f9f5ddfcfc004ec698b > > I'm not aware of any track record of writing bad software in the past either - > I believe they're just human. Yes and I think the developers? commitment to GPG is also evident in the user support forum http://support.gpgtools.org/. And it is nonsense to suggest that there is some attempt at weakening security. Sandeep -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 873 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mailing-lists at asatiifm.net Tue Feb 17 17:00:50 2015 From: mailing-lists at asatiifm.net (=?utf-8?Q?Ville_M=C3=A4=C3=A4tt=C3=A4?=) Date: Tue, 17 Feb 2015 18:00:50 +0200 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: <87oaospsum.fsf@vigenere.g10code.de> References: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> <87oaospsum.fsf@vigenere.g10code.de> Message-ID: <8CBC97E5-C896-4989-814D-45E67C9014CF@asatiifm.net> I?ve had some concerns about GPGTools for months now. For some time I've disliked the way the project is being run, the communication of what they are planning and the way they have been doing their development for example. Months went by when their Yosemite betas were not available in source at all and development was happening in a separate repository closed from the public [1]. GPGTools makes an installer, GPG Suite, which provides the following: - GPGMail (plugin for Apple Mail) - GPG Keychain (GUI tool for generating and managing keys) - GPGServices (OS X Services menu tools for OpenPGP actions) - GPGPreferences (OS X preferences GUI for some options (gpg.conf) - MacGPG2 (Fork of GnuPG 2.0.26) I happen to use Mail so for a long time I?ve been using the GPGMail plugin with a brewed[2] upstream GnuPG. I.e. *just one of the things in the GPG Suite*. I?ve talked about this setup before in the thread [3]. If one doesn?t use Apple Mail there is no reason to use GPGTools at all. I?ve been planning on writing a request to http://support.gpgtools.org for downsizing / pivoting the project. I just haven?t gotten around to it yet. MacGPG: Years back there was no easy way of getting upstream GnuPG working on a Mac. As I recall there were a couple of ports making a working Mac version and MacGPG was / evolved from one of them. Today the situation is very much different. Anyone can easily install either 1.x or 2.0.x via brew or another preferred method of installing their command line tools. *I think there is no more reason to develop MacGPG*, i.e. a port, anymore. Let the port die. Instead they should use upstream and contribute the minimal amount of wrappers or fixes upstream. Case in point: Has the fix for gpg-agent / scdaemon hang been discussed upstream at all [4], [5]? In MacGPG there is still ../libexec/gnupg-pcsc-wrapper which has been modified in commit f4c3e1bb to fix the issues of scdaemon hanging in Yosemite [6]. GnuPG proper has removed it in bc6b45 [7]. How would one go about fixing this issue for upstream? Has GPGTools contributed anything regarding this other than the initial discussion[8] about the issue? Upstream still does have the issue which now seems to have been fixed in the fork but in a binary removed from upstream? Many times when a new version of OS X comes out GPGTools has been a little late in getting a compatible version out. GPGTools are planning to move to a paid release of GPG Suite [9]. Whether it?s paid or not, my suggestion for GPGTools is to drop MacGPG and start using an upstream version in the Suite. There are a lot of users out there that will not fiddle with command lines, brew or otherwise. And for them there needs to be a GUI package. Quoting from GPGTools support regarding paid support [10], "non-power-users that were partially even surprised, that email does not imply webmail?. "I hope you are aware of the social responsibility that comes with running the official website for gpg on OS X.?. So, *"official website for gpg on OS X"* according to this user critical of making discontinuation of a free version. There is a real problem here in that whatever GPGTools does, affects a large population of Mac users as the "official GPG on Mac?. There is a history of problems regarding GPGTools and MacGPG. This is not the first time that project or decisions of its developers has been questioned [11]. Here?s one: 1. Modify source code to allow non-sensical 8192 bit keys [12]. 2. Have users wonder, at gnupg-users, years later why things don?t quite seem right [13]. Another: GPGTools support site has a certificate mismatch [14]. WTF is a *.tenderapp.com cert doing here? GnuPG provides a GUI for Windows in addition to the set of command line tools. On *NIX official builds are command line only. I think the GUI tooling of not only Mac but other *NIX systems to be quite an important factor in getting wider use for encryption. Such tools must be from a respectable source and properly implemented just as much as the underlying engine. I would argue GnuPG should take the responsibility of such tooling where there isn?t a good option. Other *NIX systems are doing fairly well already so I suppose a Mac GUI would really be the urgent one. And I?m willing to put my time and effort where my mouth is. I would be happy to participate such a project. Links: [1]: http://support.gpgtools.org/discussions/problems/24976-how-to-build-yosemite-branch [2]: http://brew.sh [3]: http://lists.gnupg.org/pipermail/gnupg-users/2014-August/050677.html [4]: http://support.gpgtools.org/discussions/problems/28634-gpg-agent-stops-working-after-osx-upgrade-to-yosemite [5]: https://gpgtools.lighthouseapp.com/projects/66001/tickets/140-gpg-agent-stops-working-after-osx-upgrade-to-yosemite [6]: https://github.com/GPGTools/MacGPG2/commit/f4c3e1bbf1c96cf03ad33a364ec10365f68bf63f [7]: http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=bc6b452129178658da7241903ca2174c79281752 [8]: http://lists.gnupg.org/pipermail/gnupg-devel/2015-January/029345.html [9]: http://web.archive.org/web/20150206164802/https://gpgtools.org/news [10]: http://support.gpgtools.org/discussions/beta-feedback/640-discontinuation-of-free-version-for-yosemite [11]: https://lists.gnupg.org/pipermail/gnupg-users/2014-July/050321.html [12]: http://lists.gnupg.org/pipermail/gnupg-users/2011-February/040655.html [13]: http://lists.gnupg.org/pipermail/gnupg-users/2015-January/052141.html [14]: https://www.dropbox.com/s/crsg7ofrqb0l7ri/Screen%20Shot%202015-02-17%20at%2014.39.10.png?dl=0 -- Ville -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: Message signed with OpenPGP using GPGMail URL: From htd+ml at fritha.org Tue Feb 17 16:36:16 2015 From: htd+ml at fritha.org (Heinz Diehl) Date: Tue, 17 Feb 2015 16:36:16 +0100 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: <87sie4pt9j.fsf@vigenere.g10code.de> References: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> <20150216235311.GA10680@athena.barrera.io> <87sie4pt9j.fsf@vigenere.g10code.de> Message-ID: <20150217153616.GA1728@fritha.org> On 17.02.2015, Werner Koch wrote: > git meanwhile allows to sign commits. If anyone knows a method to set a > different key for tagging and commits, I would soon start to sign each > commit. I can be seriously wrong, but is that not something the LKML people do? From martin at martinpaljak.net Tue Feb 17 17:31:18 2015 From: martin at martinpaljak.net (Martin Paljak) Date: Tue, 17 Feb 2015 18:31:18 +0200 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: <8CBC97E5-C896-4989-814D-45E67C9014CF@asatiifm.net> References: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> <87oaospsum.fsf@vigenere.g10code.de> <8CBC97E5-C896-4989-814D-45E67C9014CF@asatiifm.net> Message-ID: On Tue, Feb 17, 2015 at 6:00 PM, Ville M??tt? wrote: > Instead they should use upstream and contribute the minimal amount of wrappers or fixes upstream. Case in point: Has the fix for gpg-agent / scdaemon hang been discussed upstream at all [4], [5]? In MacGPG there is still ../libexec/gnupg-pcsc-wrapper which has been modified in commit f4c3e1bb to fix the issues of scdaemon hanging in Yosemite [6]. GnuPG proper has removed it in bc6b45 [7]. How would one go about fixing this issue for upstream? Has GPGTools contributed anything regarding this other than the initial discussion[8] about the issue? Upstream still does have the issue which now seems to have been fixed in the fork but in a binary removed from upstream? Not sure about overall GnuPG affection with Apple or other closed source software, but the PC/SC layer in Yosemite is broken (again): http://ludovicrousseau.blogspot.fr/2014/12/os-x-yosemite-and-smart-cards-known-bugs.html Generally speaking, I think the GPGTools folks care about "usage for dumbusers" which means making stuff Work(tm) for the not-so-powerusers on a not-so-great platform. It is the users's choice to use OSX (not Linux), the same way it is their choice to use Mail.app (not Enigmail) the same way it is their choice to use a simple to use binary installer with crappy build machinery instead of verifying the checksums of every download. > So, *"official website for gpg on OS X"* according to this user critical of making discontinuation of a free version. GnuPG just got a huge sum of money, I'm sure arrangements can be made to allocate some of that for a easy to use and *free* OSX version with an integrated GUI ? > Another: GPGTools support site has a certificate mismatch [14]. WTF is a *.tenderapp.com cert doing here? Because that site is run by Tender and if you connect to the https version, you get their site? Probably makes sense to bug Tender with this. So, generally speaking: if the upstream has not catered to the OSX folks and somebody on the internet has, I would not blame GPGTools guys for doing it. Yes, it would be nice if one at least tried to contribute back to upstream and to work in an open manner, but at least they DO something, for what there is apparent need. Martin From s.murthy at mykolab.com Tue Feb 17 20:03:30 2015 From: s.murthy at mykolab.com (Sandeep Murthy) Date: Tue, 17 Feb 2015 19:03:30 +0000 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: References: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> <87oaospsum.fsf@vigenere.g10code.de> <8CBC97E5-C896-4989-814D-45E67C9014CF@asatiifm.net> Message-ID: I suppose if you were conceited enough to describe yourself as a ?power user? then you might be dumb enough to think that people who use GPG Suite are ?dumb users?. Platform fanatics and those make an easy job of caricaturing themselves in their fanaticism for a ?pure setup?, which is an illusion. In the real world every system can be compromised and no can have such a setup, no matter how hard you try. You don?t have to choose between OS X and Linux, there are lots of people who use both. I have both GnuPG and GPG Suite, and I use both when I have to. As a user, not a developer on MacGPG, the issues previously raised here about the remote execution of scripts etc. may be questionable, but they do not directly affect my use of the software, which is nothing but a front end for GnuPG. The GPG plug-in for Apple Mail is not without its shortcomings but it is incredibly easy to use and works well the other components of the GPG suite. I have not used Enigmail, but it?s simply a question of choice. Sandeep Murthy s.murthy at mykolab.com > On 17 Feb 2015, at 16:31, Martin Paljak wrote: > > On Tue, Feb 17, 2015 at 6:00 PM, Ville M??tt? > wrote: >> Instead they should use upstream and contribute the minimal amount of wrappers or fixes upstream. Case in point: Has the fix for gpg-agent / scdaemon hang been discussed upstream at all [4], [5]? In MacGPG there is still ../libexec/gnupg-pcsc-wrapper which has been modified in commit f4c3e1bb to fix the issues of scdaemon hanging in Yosemite [6]. GnuPG proper has removed it in bc6b45 [7]. How would one go about fixing this issue for upstream? Has GPGTools contributed anything regarding this other than the initial discussion[8] about the issue? Upstream still does have the issue which now seems to have been fixed in the fork but in a binary removed from upstream? > > > Not sure about overall GnuPG affection with Apple or other closed > source software, but the PC/SC layer in Yosemite is broken (again): > > http://ludovicrousseau.blogspot.fr/2014/12/os-x-yosemite-and-smart-cards-known-bugs.html > > Generally speaking, I think the GPGTools folks care about "usage for > dumbusers" which means making stuff Work(tm) for the not-so-powerusers > on a not-so-great platform. It is the users's choice to use OSX (not > Linux), the same way it is their choice to use Mail.app (not Enigmail) > the same way it is their choice to use a simple to use binary > installer with crappy build machinery instead of verifying the > checksums of every download. > >> So, *"official website for gpg on OS X"* according to this user critical of making discontinuation of a free version. > > GnuPG just got a huge sum of money, I'm sure arrangements can be made > to allocate some of that for a easy to use and *free* OSX version with > an integrated GUI ? > >> Another: GPGTools support site has a certificate mismatch [14]. WTF is a *.tenderapp.com cert doing here? > > Because that site is run by Tender and if you connect to the https > version, you get their site? Probably makes sense to bug Tender with > this. > > > So, generally speaking: if the upstream has not catered to the OSX > folks and somebody on the internet has, I would not blame GPGTools > guys for doing it. Yes, it would be nice if one at least tried to > contribute back to upstream and to work in an open manner, but at > least they DO something, for what there is apparent need. > > Martin > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 873 bytes Desc: Message signed with OpenPGP using GPGMail URL: From rjh at sixdemonbag.org Tue Feb 17 20:23:43 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 17 Feb 2015 14:23:43 -0500 Subject: 2.1.2: keyserver route failure In-Reply-To: <87wq3gpujn.fsf@vigenere.g10code.de> References: <54E2977C.106@sixdemonbag.org> <87wq3gpujn.fsf@vigenere.g10code.de> Message-ID: <54E3953F.2000909@sixdemonbag.org> > gpg-connect-agent --dirmngr 'keyserver --hosttable' /bye Okay. I have no idea what I'm looking for, but here goes. quorra:~ rjh$ gpg-connect-agent --dirmngr 'keyserver --hosttable' /bye S # hosttable (idx, ipv6, ipv4, dead, name, time): S # 0 pool.sks-keyservers.net S # . pool.sks-keyservers.net S # . --> 6 8 1 13 20 4 10 11 7 2 15 5 12 17 9 19* 14 3 16 18 S # 1 4 c-75-75-183-132.hsd1.pa.comcast.net v4=75.75.183.132 S # 2 4 keys.exosphere.de v4=81.7.19.101 S # 3 4 tarquin.bootc.eu v4=81.187.55.68 S # 4 4 gozer.rediris.es v4=130.206.1.8 S # 5 4 keys02.fedoraproject.org v4=140.211.169.202 S # 6 4 176.31.199.172 S # 7 4 key.ip6.li v4=193.17.17.6 S # 8 4 198.128.3.63 S # 9 4 pgpkeys.eu v4=37.59.144.15 S # 10 4 host-37-191-220-247.lynet.no v4=37.191.220.247 S # 11 6 hufu.ki.iif.hu v6=[2001:738::600:216:3eff:fe02:42] S # 12 6 keyserver.mattrude.com v6=[2001:4801:7827:101:be76:4eff:fe10:2c22] S # 13 6 cl-1291.qas-01.us.sixxs.net v6=[2001:4830:1600:50a::2] S # 14 6 svcs4.riverwillow.net.au v6=[2405:1000:10:309::5004] S # 15 6 keys.jhcloos.com v6=[2602:ffea:1:ea::1] S # 16 6 [2610:81:3001:53::231] S # 17 6 keyserver.synack.com v6=[2a00:d880:3:2::4f76:8c5c] S # 18 6 [2a02:180:a:65:2456:6542:1101:1010] S # 19 6 sks.spodhuis.org v6=[2a02:898:31::48:4558:73:6b73] S # 20 6 francis.connectical.com v6=[2001:41d0:1:bc3e::1] OK From mailing-lists at asatiifm.net Tue Feb 17 20:30:21 2015 From: mailing-lists at asatiifm.net (=?utf-8?Q?Ville_M=C3=A4=C3=A4tt=C3=A4?=) Date: Tue, 17 Feb 2015 21:30:21 +0200 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: References: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> <87oaospsum.fsf@vigenere.g10code.de> <8CBC97E5-C896-4989-814D-45E67C9014CF@asatiifm.net> Message-ID: > On 17 Feb 2015, at 18:31, Martin Paljak wrote: > > Not sure about overall GnuPG affection with Apple or other closed > source software, but the PC/SC layer in Yosemite is broken (again): > > http://ludovicrousseau.blogspot.fr/2014/12/os-x-yosemite-and-smart-cards-known-bugs.html Yeah, Apple has once again moved things around and even seemingly reimplemented some things for no apparent reason. Hard to know why because Apple doesn?t talk much about their plans with the outside world. Ludovic has been doing a great job of finding and reporting issues to Apple. > ?for the not-so-powerusers > on a not-so-great platform. It is the users's choice to use OSX (not > Linux), the same way it is their choice to use Mail.app (not Enigmail) > the same way it is their choice to use a simple to use binary > installer with crappy build machinery instead of verifying the > checksums of every download. You?re letting your hate shine bright. Haters gonna hate. >> Another: GPGTools support site has a certificate mismatch [14]. WTF is a *.tenderapp.com cert doing here? > > Because that site is run by Tender and if you connect to the https > version, you get their site? Probably makes sense to bug Tender with > this. GPGTools is very much responsible for where their site is hosted and the proper use of such things as certificates. In the scheme of things the actual hosting issue is probably quite small but one could say that *GPGTools has not planned for the use of HTTPS on their support site at all*. > So, generally speaking: if the upstream has not catered to the OSX > folks and somebody on the internet has, I would not blame GPGTools > guys for doing it. That makes no sense. > Yes, it would be nice if one at least tried to > contribute back to upstream and to work in an open manner, but at > least they DO something, for what there is apparent need. Nothing requires GPGTools to contribute their code changes back upstream but licensing does require the source to be available. There was a period when this licence requirement was not adhered to. Fortunately, as I said, it was momentary and at the moment as far as I know they have merged back to the public repository. -- Ville From mailing-lists at asatiifm.net Tue Feb 17 20:42:48 2015 From: mailing-lists at asatiifm.net (=?utf-8?Q?Ville_M=C3=A4=C3=A4tt=C3=A4?=) Date: Tue, 17 Feb 2015 21:42:48 +0200 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: References: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> <87oaospsum.fsf@vigenere.g10code.de> <8CBC97E5-C896-4989-814D-45E67C9014CF@asatiifm.net> Message-ID: <90E49EAE-A491-459A-8BD7-D4841629B5FE@asatiifm.net> > On 17 Feb 2015, at 21:03, Sandeep Murthy wrote: > > As a user, not a developer on MacGPG, the issues previously > raised here about the remote execution of scripts etc. may be > questionable, but they do not directly affect my use of the software, > which is nothing but a front end for GnuPG. If MacGPG were not a fork that would be the situation. Alas, it *is a fork and not just a front-end* for GPG. There are binary level differences from upstream which the average user does not know, nor should they need to. > The GPG plug-in for Apple Mail is not without its shortcomings but > it is incredibly easy to use and works well the other components > of the GPG suite. I have not used Enigmail, but it?s simply a > question of choice. I agree. I wouldn?t like anything better than to have all users using an open source client but I don?t have any illusions of getting there any time soon. Thus, plugins for the system default are necessary. -- Ville From mailing-lists at asatiifm.net Tue Feb 17 20:48:05 2015 From: mailing-lists at asatiifm.net (=?utf-8?Q?Ville_M=C3=A4=C3=A4tt=C3=A4?=) Date: Tue, 17 Feb 2015 21:48:05 +0200 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: References: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> <87oaospsum.fsf@vigenere.g10code.de> <8CBC97E5-C896-4989-814D-45E67C9014CF@asatiifm.net> Message-ID: <63246A59-2A46-4E54-A3DA-DC6A93E79E67@asatiifm.net> > On 17 Feb 2015, at 21:16, Juergen Fenn wrote: > > as you've pointed > out, the GPGTools have decided to go all commercial including, I > didn't realise this before, a closed code repository so that no one > can study the code? Is this true? I can't believe it. That?s not quite true. They must release the changes they make. The private repository issue has been corrected and at this time one should be able to build the whole suite on their own. -- Ville From robertc at broadcom.com Tue Feb 17 20:51:22 2015 From: robertc at broadcom.com (Bob (Robert) Cavanaugh) Date: Tue, 17 Feb 2015 19:51:22 +0000 Subject: MIME or inline signature ? In-Reply-To: <20150217061318.3cd64936@scorpio> References: <20150213081425.7a418830@scorpio> <681480546.20150214143935@my_localhost> <1736159995.20150217001626@my_localhost> <20150217061318.3cd64936@scorpio> Message-ID: <8F0B09FC6339FA439524099BFCABC11F2D3B91C4@IRVEXCHMB11.corp.ad.broadcom.com> Jerry writes: >> ...Worse, >> since most users have no concept of "trimming" a message before replying to >> it, even more useless garbage is transmitted when replied to, thus killing >> more innocent electrons and wasting bandwidth not to mention the consumption >> of screen territory. Does that make you an elecologist? From s.murthy at mykolab.com Tue Feb 17 20:58:10 2015 From: s.murthy at mykolab.com (Sandeep Murthy) Date: Tue, 17 Feb 2015 19:58:10 +0000 Subject: Fwd: Please remove MacGPG from gnupg.org due to serious security concerns References: Message-ID: <68F2AA9B-B192-4727-9AA3-2BC33CBE5434@mykolab.com> I would also add that if you agree that more people should be using encryption in more forms then the way to go is to make it more more usable and user friendly (and at the moment the standard GnuPG version can?t exactly be described as that) then this is not an aspiration that should be described as dumb. What is probably dumb is the kind of purist attitude about the perfect Linux platform and how great it is to have the perfect GnuPG set up. I would bet that more people who?ve used tools like GPG Suite have taken up encryption than those exposed to the command line subtleties of GnuPG. Both can be used at the same time, as I do, you don?t have to choose between them. Sandeep Murthy s.murthy at mykolab.com > Begin forwarded message: > > Subject: Re: Please remove MacGPG from gnupg.org due to serious security concerns > From: Sandeep Murthy > Date: 17 February 2015 19:03:30 GMT > Cc: Martin Paljak > To: gnupg-users at gnupg.org > > I suppose if you were conceited enough to describe yourself > as a ?power user? then you might be dumb enough to think > that people who use GPG Suite are ?dumb users?. > > Platform fanatics and those make an easy job of caricaturing > themselves in their fanaticism for a ?pure setup?, which is an > illusion. In the real world every system can be compromised > and no can have such a setup, no matter how hard you try. > > You don?t have to choose between OS X and Linux, there are > lots of people who use both. > > I have both GnuPG and GPG Suite, and I use both when I have > to. As a user, not a developer on MacGPG, the issues previously > raised here about the remote execution of scripts etc. may be > questionable, but they do not directly affect my use of the software, > which is nothing but a front end for GnuPG. > > The GPG plug-in for Apple Mail is not without its shortcomings but > it is incredibly easy to use and works well the other components > of the GPG suite. I have not used Enigmail, but it?s simply a > question of choice. > > Sandeep Murthy > s.murthy at mykolab.com > >> On 17 Feb 2015, at 16:31, Martin Paljak wrote: >> >> On Tue, Feb 17, 2015 at 6:00 PM, Ville M??tt? >> wrote: >>> Instead they should use upstream and contribute the minimal amount of wrappers or fixes upstream. Case in point: Has the fix for gpg-agent / scdaemon hang been discussed upstream at all [4], [5]? In MacGPG there is still ../libexec/gnupg-pcsc-wrapper which has been modified in commit f4c3e1bb to fix the issues of scdaemon hanging in Yosemite [6]. GnuPG proper has removed it in bc6b45 [7]. How would one go about fixing this issue for upstream? Has GPGTools contributed anything regarding this other than the initial discussion[8] about the issue? Upstream still does have the issue which now seems to have been fixed in the fork but in a binary removed from upstream? >> >> >> Not sure about overall GnuPG affection with Apple or other closed >> source software, but the PC/SC layer in Yosemite is broken (again): >> >> http://ludovicrousseau.blogspot.fr/2014/12/os-x-yosemite-and-smart-cards-known-bugs.html >> >> Generally speaking, I think the GPGTools folks care about "usage for >> dumbusers" which means making stuff Work(tm) for the not-so-powerusers >> on a not-so-great platform. It is the users's choice to use OSX (not >> Linux), the same way it is their choice to use Mail.app (not Enigmail) >> the same way it is their choice to use a simple to use binary >> installer with crappy build machinery instead of verifying the >> checksums of every download. >> >>> So, *"official website for gpg on OS X"* according to this user critical of making discontinuation of a free version. >> >> GnuPG just got a huge sum of money, I'm sure arrangements can be made >> to allocate some of that for a easy to use and *free* OSX version with >> an integrated GUI ? >> >>> Another: GPGTools support site has a certificate mismatch [14]. WTF is a *.tenderapp.com cert doing here? >> >> Because that site is run by Tender and if you connect to the https >> version, you get their site? Probably makes sense to bug Tender with >> this. >> >> >> So, generally speaking: if the upstream has not catered to the OSX >> folks and somebody on the internet has, I would not blame GPGTools >> guys for doing it. Yes, it would be nice if one at least tried to >> contribute back to upstream and to work in an open manner, but at >> least they DO something, for what there is apparent need. >> >> Martin >> >> _______________________________________________ >> Gnupg-users mailing list >> Gnupg-users at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 873 bytes Desc: Message signed with OpenPGP using GPGMail URL: From thomaswhite at riseup.net Tue Feb 17 19:48:26 2015 From: thomaswhite at riseup.net (Thomas White) Date: Tue, 17 Feb 2015 18:48:26 +0000 Subject: Extract passphrase hash Message-ID: <54E38CFA.20209@riseup.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I have a private key I am trying to recover the passphrase hash from to try and then use in conjunction with another tool (hashcat?) to recover the passphrase on a GPU cluster I have. How would one go about extracting the passphrase hash from the private key? Regards, T - -- Activist, anarchist and a bit of a dreamer. Keybase: https://keybase.io/thomaswhite PGP Keys: https://www.thecthulhu.com/pgp-keys/ Current Fingerprint: E771 BE69 4696 F742 DB94 AA8C 5C2A 8C5A 0CCA 4983 Key-ID: 0CCA4983 Master Fingerprint: DDEF AB9B 1962 5D09 4264 2558 1F23 39B7 EF10 09F0 Key-ID: EF1009F0 Twitter: @CthulhuSec XMPP: thecthulhu at jabber.ccc.de XMPP-OTR: 4321B19F A9A3462C FE64BAC7 294C8A7E A53CC966 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJU44z3AAoJEFwqjFoMykmDrMMQAKVZqrmonIQtJhOlwvvd5ksR bp2MWlA1+QUA7NWhjex7esH64dlef+9zuqTPwPBrbLffLwABvfelDCzQAUlinoNC 6zxWKGnQJgImZnOykaDVYnUQ9D9JhhehYsddETyTOH7dW38SMrMVA5BcfkYcD4Mr hsvOLH/n1RDGkzofKd05Pdtb/Luv4KZ7wAz0mzgiDEs0U8BO2RFMpWRR7tiEoAxv gB99FSyBGRg3lo10h18rhSdWwrYmkISh2+dHGC5mUPV4wb1QugX/XC0yi71QBDNq t+UVHuz+PdlzNboMEwWKfuQg+F6Z45PuwIrHLwA923JC38Mf3DszHDXZ2KGep7wP 3jB6LtY2fZlJkhORkB3y7l+PrC+uKBrfVIbqFLxtvrtImUgBwAn5ubUgSNQ/fBI/ Aq1sEiQOIuUnFXJ2izg6UgsNg0ys55Kl+RXDPEWfGltSGul07KONQYGAjivA2f/i Ml6TUSNg/w9/w/eIJ7Wy9pO+vya1EFBuddF8gQEcflkPJVvqU0UQFpvtUtbPNQvh th17kIpkoZo/fEIdvq3O/ec2eZrrTvNrrueWQBFQuPXLOS+7u2XiPiwl6cc1R6PA B8lDQ4ee3X5jy8S9IPXfOHiGRNoPCuBHnoTgz1rDcQBiyILd4NIXz2l1B8qbSGge 3ZK4t1CeoIcSRmis80+l =gK0A -----END PGP SIGNATURE----- From schneeschmelze at googlemail.com Tue Feb 17 20:16:27 2015 From: schneeschmelze at googlemail.com (Juergen Fenn) Date: Tue, 17 Feb 2015 20:16:27 +0100 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: References: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> <87oaospsum.fsf@vigenere.g10code.de> <8CBC97E5-C896-4989-814D-45E67C9014CF@asatiifm.net> Message-ID: 2015-02-17 17:31 GMT+01:00 Martin Paljak : > So, generally speaking: if the upstream has not catered to the OSX > folks and somebody on the internet has, I would not blame GPGTools > guys for doing it. Yes, it would be nice if one at least tried to > contribute back to upstream and to work in an open manner, but at > least they DO something, for what there is apparent need. Well, there are by now three ways get GPG running on a Mac, we have had this summary on the Enigmail list just this weekend: https://lists.enigmail.net/pipermail/enigmail-users_enigmail.net/2015-February/002505.html I tried to get GnuPG working under Mavericks via MacPorts, to no avail, because there was no pinentry for the Mac. There are only two ones, viz. from GPGTools and the one from Patrick Brunschwig's project. The third option Ludwig mentions in his post is not a current version. I have not had the time to test Patrick's distro so far, but if it works it looks more interesting to me because, as you've pointed out, the GPGTools have decided to go all commercial including, I didn't realise this before, a closed code repository so that no one can study the code? Is this true? I can't believe it. Enigmail has discussed recently to drop support for GnuPG1, making gpg-agent/pinentry a crucial issue on the Mac. The standard version of pinentry from MacPorts does not work properly out of the box. Anyway, alternatives should be mentioned on the GnuPG pages because?I agree to the OP?this is too important an issue, GnuPG also being used by many people who seriously depend on its security. The question is, can we use GnuPG on the Mac and rely on it? Regards, J?rgen. From errol at askerrol.org Tue Feb 17 21:12:22 2015 From: errol at askerrol.org (Errol Casey) Date: Tue, 17 Feb 2015 15:12:22 -0500 Subject: Compiled binaries execute but exit with "Abort" Message-ID: I have successfully compile gnupg 2.0.26 on Solaris 10 using gcc (GCC) 3.4.3 (csl-sol210-3_4-branch+sol_rpath) But it fails openpgp tests, and all executable exit with an "Abort" message. I cannot determine what is causing this abort, but it I can successfullyexecute programs to generate keys. Decrypt and encrypt. Making all in po Making all in doc make all-am Making all in tests Making all in openpgp ./gpg_dearmor > ./plain-1 < ./plain-1o.asc gpg: WARNING: unsafe ownership on homedir `.' Abort *** Error code 134 make: Fatal error: Command failed for target `plain-1' Current working directory /syshome/gecasey/gpg/gnupg-2.0.26/tests/openpgp ./gpg2 --version gpg (GnuPG) 2.0.26 libgcrypt 1.6.2 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: ~/.gnupg Supported algorithms: Pubkey: RSA, RSA, RSA, ELG, DSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 Abort -- Errol Casey errol at askerrol.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From dougb at dougbarton.email Tue Feb 17 23:08:29 2015 From: dougb at dougbarton.email (Doug Barton) Date: Tue, 17 Feb 2015 14:08:29 -0800 Subject: Compiled binaries execute but exit with "Abort" In-Reply-To: References: Message-ID: <54E3BBDD.90407@dougbarton.email> On 2/17/15 12:12 PM, Errol Casey wrote: > gpg: WARNING: unsafe ownership on homedir `.' What are the permissions on your home directory, and your ~/.gnupg directory? From lukele at gpgtools.org Tue Feb 17 22:32:57 2015 From: lukele at gpgtools.org (Lukas Pitschl) Date: Tue, 17 Feb 2015 22:32:57 +0100 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: <68F2AA9B-B192-4727-9AA3-2BC33CBE5434@mykolab.com> References: <68F2AA9B-B192-4727-9AA3-2BC33CBE5434@mykolab.com> Message-ID: Hi all, since we?ve only now subscribed to the gnupg-users list, unfortunately we can?t reply to the correct message in the thread. First off we?d like to apologize for not reacting sooner to this issue. We only today became aware of it, when we received a message on our support platform (thanks Sandeep), and later a comment on Github (thanks Hugo) regarding the affected line of code. While we?re responding to all mail and discussions opened on our support platform, we don?t keep track of Twitter regularly. Some days we see everything going on there and respond immediately and other days we don't check Twitter at all, so unfortunately it's possible that important messages remain unseen. The best way to reach us is either our support platform at https://gpgtools.tenderapp.com or team at gpgtools.org. The code that checks out our GPGTools_Core repository is pretty old already and it?s certainly a stupid way to do it. At the time we assumed that it was safe to check it out via ssl from github, since curl would refuse to do so if there was a certificate error. Passing it directly to bash is definitely a bad idea. We?ve discussed this internally and decided on removing the automated checkout completely. By making it a manual task, everyone can checkout the code and verify that it?s in fact the code they wanted to checkout. We will also look through our build system and check for similar code if there is. To address the "Modify source code to allow non-sensical 8192 bit keys" mentioned by Villa: in the past we were too quick to give in to user requests without first researching the side-effects that could be caused by this. The ?non-sensical 8192 bit keys? is one instance. It was requested by a few users and a quick ?fix?. We?ve seen that homebrew did the same and decided to add this option. We believed if some users wanted this option, we should not hinder them. Unfortunately to this day, there still seems to be a lot of disagreement (not on the gnupg list, but other blogs / places on the internet) on whether such a key size makes sense or not. We?ve recently been accused again of "knowlingly lowering the overall security? [1] by not allowing such a key size. We?re still not sure what to do about it exactly. In regards to the fix of PCSC on Yosemite, this is a quick workaround which currently works ?well enough?, but we?re still waiting to hear from more users if it?s really fixed. Once it is, we?ll be certain to discuss it on gnupg-devel. We?ve been wanting for a while now to discuss our few patches with the gnupg-devel list in order to push them upstream or find a different solution, but unfortunately have been struggling to find time to do that. We also believe that providing gnupg as is on OS X would be the way to go. To clarify some info posted on this thread about "GPGTools going commercial?: we will only charge a fee for GPGMail, the rest of GPG Suite will remain free. The source code will also remain open and on Github. It's true we sometimes failed to keep it up to date in the past, but we're committed to make sure that it stays current with new releases. We really appreciate any feedback and try to address any concerns as quickly as possible. As already mentioned above, it's not always possible for us to keep track of Twitter, so the best way to reach us is via email or our support platform. Best, Lukas, Steve, Mento GPGTools [1] http://support.gpgtools.org/discussions/feedback/1132-8k-key-generation-via-keychain-access#comment_35220287 Am 17.02.2015 um 20:58 schrieb Sandeep Murthy : > I would also add that if you agree that more people should > be using encryption in more forms then the way to go is > to make it more more usable and user friendly (and at the > moment the standard GnuPG version can?t exactly be described as > that) then this is not an aspiration that should be described > as dumb. What is probably dumb is the kind of purist attitude > about the perfect Linux platform and how great it is to have > the perfect GnuPG set up. > > I would bet that more people who?ve used tools like GPG Suite > have taken up encryption than those exposed to the command > line subtleties of GnuPG. Both can be used at the same time, > as I do, you don?t have to choose between them. > > Sandeep Murthy > s.murthy at mykolab.com > >> Begin forwarded message: >> >> Subject: Re: Please remove MacGPG from gnupg.org due to serious security concerns >> From: Sandeep Murthy >> Date: 17 February 2015 19:03:30 GMT >> Cc: Martin Paljak >> To: gnupg-users at gnupg.org >> >> I suppose if you were conceited enough to describe yourself >> as a ?power user? then you might be dumb enough to think >> that people who use GPG Suite are ?dumb users?. >> >> Platform fanatics and those make an easy job of caricaturing >> themselves in their fanaticism for a ?pure setup?, which is an >> illusion. In the real world every system can be compromised >> and no can have such a setup, no matter how hard you try. >> >> You don?t have to choose between OS X and Linux, there are >> lots of people who use both. >> >> I have both GnuPG and GPG Suite, and I use both when I have >> to. As a user, not a developer on MacGPG, the issues previously >> raised here about the remote execution of scripts etc. may be >> questionable, but they do not directly affect my use of the software, >> which is nothing but a front end for GnuPG. >> >> The GPG plug-in for Apple Mail is not without its shortcomings but >> it is incredibly easy to use and works well the other components >> of the GPG suite. I have not used Enigmail, but it?s simply a >> question of choice. >> >> Sandeep Murthy >> s.murthy at mykolab.com >> >>> On 17 Feb 2015, at 16:31, Martin Paljak wrote: >>> >>> On Tue, Feb 17, 2015 at 6:00 PM, Ville M??tt? >>> wrote: >>>> Instead they should use upstream and contribute the minimal amount of wrappers or fixes upstream. Case in point: Has the fix for gpg-agent / scdaemon hang been discussed upstream at all [4], [5]? In MacGPG there is still ../libexec/gnupg-pcsc-wrapper which has been modified in commit f4c3e1bb to fix the issues of scdaemon hanging in Yosemite [6]. GnuPG proper has removed it in bc6b45 [7]. How would one go about fixing this issue for upstream? Has GPGTools contributed anything regarding this other than the initial discussion[8] about the issue? Upstream still does have the issue which now seems to have been fixed in the fork but in a binary removed from upstream? >>> >>> >>> Not sure about overall GnuPG affection with Apple or other closed >>> source software, but the PC/SC layer in Yosemite is broken (again): >>> >>> http://ludovicrousseau.blogspot.fr/2014/12/os-x-yosemite-and-smart-cards-known-bugs.html >>> >>> Generally speaking, I think the GPGTools folks care about "usage for >>> dumbusers" which means making stuff Work(tm) for the not-so-powerusers >>> on a not-so-great platform. It is the users's choice to use OSX (not >>> Linux), the same way it is their choice to use Mail.app (not Enigmail) >>> the same way it is their choice to use a simple to use binary >>> installer with crappy build machinery instead of verifying the >>> checksums of every download. >>> >>>> So, *"official website for gpg on OS X"* according to this user critical of making discontinuation of a free version. >>> >>> GnuPG just got a huge sum of money, I'm sure arrangements can be made >>> to allocate some of that for a easy to use and *free* OSX version with >>> an integrated GUI ? >>> >>>> Another: GPGTools support site has a certificate mismatch [14]. WTF is a *.tenderapp.com cert doing here? >>> >>> Because that site is run by Tender and if you connect to the https >>> version, you get their site? Probably makes sense to bug Tender with >>> this. >>> >>> >>> So, generally speaking: if the upstream has not catered to the OSX >>> folks and somebody on the internet has, I would not blame GPGTools >>> guys for doing it. Yes, it would be nice if one at least tried to >>> contribute back to upstream and to work in an open manner, but at >>> least they DO something, for what there is apparent need. >>> >>> Martin >>> >>> _______________________________________________ >>> Gnupg-users mailing list >>> Gnupg-users at gnupg.org >>> http://lists.gnupg.org/mailman/listinfo/gnupg-users >> > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 236 bytes Desc: Message signed with OpenPGP using GPGMail URL: From maxp at trystero.is Wed Feb 18 00:53:23 2015 From: maxp at trystero.is (Max R.D. Parmer) Date: Tue, 17 Feb 2015 15:53:23 -0800 Subject: Extract passphrase hash In-Reply-To: <54E38CFA.20209@riseup.net> References: <54E38CFA.20209@riseup.net> Message-ID: <1424217203.3824933.228984357.6B454E72@webmail.messagingengine.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Tue, Feb 17, 2015, at 10:48, Thomas White wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > I have a private key I am trying to recover the passphrase hash from > to try and then use in conjunction with another tool (hashcat?) to > recover the passphrase on a GPU cluster I have. > > How would one go about extracting the passphrase hash from the private > key? If I understand correctly, I think you want `gpg --list-packets --debug 2 secring.gpg` > Regards, > T > - -- > Activist, anarchist and a bit of a dreamer. > Keybase: https://keybase.io/thomaswhite > > PGP Keys: https://www.thecthulhu.com/pgp-keys/ > Current Fingerprint: E771 BE69 4696 F742 DB94 AA8C 5C2A 8C5A 0CCA 4983 > Key-ID: 0CCA4983 > Master Fingerprint: DDEF AB9B 1962 5D09 4264 2558 1F23 39B7 EF10 09F0 > Key-ID: EF1009F0 > > Twitter: @CthulhuSec > XMPP: thecthulhu at jabber.ccc.de > XMPP-OTR: 4321B19F A9A3462C FE64BAC7 294C8A7E A53CC966 - -- 0x7D964D3361142ACF -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJU49QrXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ1REI3REQxQUQ3Nzg5NUNDQTFBMEZEQ0NE ODdFM0VENjdERDRERTlEAAoJENh+PtZ91N6digMP/ioy+q30sA3Y8zDVpiiUXHRc j9QeLeIZULtJ/ni0ltdIqXm5pzrmg4r+NenUnk/dMOSMUjMYW9lZTndr8Y27kBX8 YTBfdVfuKYgYzAI6W5vab9DUt3yeCel7P/NO7kVXlEKObGOmOkeB4AqH7v7ep1q0 f/LaW/X/5icWV0W5g3JbFlUiPOQbGSk0DrXwgTUlm4v5dNtSQwUP72fN8eJQ9ydr qjVQmN7SV7QUlKYGVUp1l+iNq6P+RQrQS/R6wU16s+dNpi11FCFDBVq59dKe0TA0 S+o1tfFlZF7+aambJJcpatsWGHlWeMfY1Sd6RpY44ux65OWjlN/jAoa47sTxs0cI MgJzt1xWa/O2vkm8hGdUDrknUM/VxppwIO4JJ/8sikKjk1pXSxYzTEL0J82lM0Vo Zie/MVYL+Wsw7gGwo+2MF79zPfPujIiuxvDNuE+NQZWSOWg4/AryLdyjUihtgCOJ 6Mgzwc/9tRXqED2EM3GAPeDBjuPRd07lE7hC2UyTxr5Kaj+Gt90ebqlYkAhRsL7s G9LeNiprYuRD07hIHWG+17mo+4rPv6eJA55Iv0wDMZSgnYbC/MMIiwlWUv6CeRow QHnoWd6U+4dryrc3EaN/IXvWRFKwCYdclDggI7aLlS6LFt4kYbi2yyH4+jZY9kwM eCOCn/AAaMjUbhSEiWiO =srpa -----END PGP SIGNATURE----- From dkg at fifthhorseman.net Wed Feb 18 01:14:51 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 17 Feb 2015 19:14:51 -0500 Subject: Extract passphrase hash In-Reply-To: <54E38CFA.20209@riseup.net> References: <54E38CFA.20209@riseup.net> Message-ID: <87k2zgcbyc.fsf@alice.fifthhorseman.net> On Tue 2015-02-17 13:48:26 -0500, Thomas White wrote: > I have a private key I am trying to recover the passphrase hash from > to try and then use in conjunction with another tool (hashcat?) to > recover the passphrase on a GPU cluster I have. > > How would one go about extracting the passphrase hash from the private > key? This is not how OpenPGP passphrases work. there is no embedded hash of the password. For details about how the password is used to unlock the secret key material, please see: Secret-Key Packet Formats https://tools.ietf.org/html/rfc4880#section-5.5.3 and: Secret-Key Encryption https://tools.ietf.org/html/rfc4880#section-3.7.2.1 and: String-to-key (S2K) specifier types: https://tools.ietf.org/html/rfc4880#section-3.7 In particular: Encryption/decryption of the secret data is done in CFB mode using the key created from the passphrase and the Initial Vector from the packet. You can use pgpdump or gpg --list-packets on your secret key to see what the S2K parameters and IV are, and then test passphrases by generating keys and testing them against encrypted MPI and trailing checksum. This is unlikely to work on your GPU cluster without custom coding. --dkg From wk at gnupg.org Wed Feb 18 04:47:12 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 18 Feb 2015 04:47:12 +0100 Subject: 2.1.2: keyserver route failure In-Reply-To: <54E3953F.2000909@sixdemonbag.org> (Robert J. Hansen's message of "Tue, 17 Feb 2015 14:23:43 -0500") References: <54E2977C.106@sixdemonbag.org> <87wq3gpujn.fsf@vigenere.g10code.de> <54E3953F.2000909@sixdemonbag.org> Message-ID: <878ufvop8f.fsf@vigenere.g10code.de> On Tue, 17 Feb 2015 20:23, rjh at sixdemonbag.org said: > S # . pool.sks-keyservers.net > S # . --> 6 8 1 13 20 4 10 11 7 2 15 5 12 17 9 19* 14 3 16 18 > S # 19 6 sks.spodhuis.org v6=[2a02:898:31::48:4558:73:6b73] You are using this keyserver. ping6 shows that this server is currently up. May it be that your v6 routing is not working correct? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Feb 18 04:53:06 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 18 Feb 2015 04:53:06 +0100 Subject: Compiled binaries execute but exit with "Abort" In-Reply-To: (Errol Casey's message of "Tue, 17 Feb 2015 15:12:22 -0500") References: Message-ID: <874mqjooyl.fsf@vigenere.g10code.de> On Tue, 17 Feb 2015 21:12, errol at askerrol.org said: > But it fails openpgp tests, and all executable exit with an "Abort" message. Please run such an executable under a debugger and privide a stack backtrace. Using gdb you would use: gdb g10/gpg then enter "break abort", "run", and after it stops "bt". Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Feb 18 05:57:39 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 18 Feb 2015 05:57:39 +0100 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: (Martin Paljak's message of "Tue, 17 Feb 2015 18:31:18 +0200") References: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> <87oaospsum.fsf@vigenere.g10code.de> <8CBC97E5-C896-4989-814D-45E67C9014CF@asatiifm.net> Message-ID: <87zj8bn7ek.fsf@vigenere.g10code.de> On Tue, 17 Feb 2015 17:31, martin at martinpaljak.net said: > GnuPG just got a huge sum of money, I'm sure arrangements can be made > to allocate some of that for a easy to use and *free* OSX version with > an integrated GUI ? I would consider it unfair to all true free software developers to take the donated money and buy up a non-free application just to make it free software (again). However, that does not mean that we won't support the gpgtools developers to drop their need for a license fee (or whatever this is) and help them to keep on developing gpgtools. There is one prerequisite for any such action: They need to communicate with the non-Mac developers which means to discuss things at gnupg-devel and use bugs.gnupg.org for GnuPG related problems on OS X. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From rjh at sixdemonbag.org Wed Feb 18 06:24:51 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 18 Feb 2015 00:24:51 -0500 Subject: 2.1.2: keyserver route failure In-Reply-To: <878ufvop8f.fsf@vigenere.g10code.de> References: <54E2977C.106@sixdemonbag.org> <87wq3gpujn.fsf@vigenere.g10code.de> <54E3953F.2000909@sixdemonbag.org> <878ufvop8f.fsf@vigenere.g10code.de> Message-ID: <54E42223.9070307@sixdemonbag.org> > You are using this keyserver. ping6 shows that this server is > currently up. May it be that your v6 routing is not working > correct? I don't have IPv6 routing, period. This raises the question of why GnuPG is trying to reach an IPv6 address at all. Worked fine under 2.0.x; under 2.1, this behavior manifested. From wk at gnupg.org Wed Feb 18 06:21:46 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 18 Feb 2015 06:21:46 +0100 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: <8CBC97E5-C896-4989-814D-45E67C9014CF@asatiifm.net> ("Ville =?utf-8?B?TcOkw6R0dMOkIidz?= message of "Tue, 17 Feb 2015 18:00:50 +0200") References: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> <87oaospsum.fsf@vigenere.g10code.de> <8CBC97E5-C896-4989-814D-45E67C9014CF@asatiifm.net> Message-ID: <87vbizn6ad.fsf@vigenere.g10code.de> On Tue, 17 Feb 2015 17:00, mailing-lists at asatiifm.net said: > command line tools. *I think there is no more reason to develop > MacGPG*, i.e. a port, anymore. Let the port die. Can you briefly explain how Patrick's new installer [1] is related to that? Would it be an option to use that as the core for gpgtools? [1] https://sourceforge.net/p/gpgosx/docu/Download/ > wrappers or fixes upstream. Case in point: Has the fix for gpg-agent / > scdaemon hang been discussed upstream at all [4], [5]? In MacGPG there > is still ../libexec/gnupg-pcsc-wrapper which has been modified in > commit f4c3e1bb to fix the issues of scdaemon hanging in Yosemite > [6]. GnuPG proper has removed it in bc6b45 [7]. How would one go about I just tried to figure out what this is about. The problem description is pretty clear but I can't easliy find a description of the solution. I don't think this has been discussed upstream. Right, in 2.1 there is no more need for the pcsc-wrapper because we switched from Pth to native threads (wrapped by the ntph library). > fixing this issue for upstream? Has GPGTools contributed anything > regarding this other than the initial discussion[8] about the issue? There was no followup on my answer. As we all now mailing lists are a primary source to evaluate problems and thus it is usually a good idea to post the found or not-found solution. Moving the discussion to some forum is not helpful. > the underlying engine. I would argue GnuPG should take the > responsibility of such tooling where there isn?t a good option. Other > *NIX systems are doing fairly well already so I suppose a Mac GUI > would really be the urgent one. Unfortunately I have no experience with OS X and I doubt it makes sense for me to jump into this too. We will have a GnuPG summit in April and I hope that the gpgtools folks will attend it so that the problems with that important platform can be discussed. Please contact me off-list if you have any questions. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From xavier at maillard.im Wed Feb 18 07:31:43 2015 From: xavier at maillard.im (Xavier Maillard) Date: Wed, 18 Feb 2015 07:31:43 +0100 Subject: Double sign a document Message-ID: Hi, in order to announce my new GPG key< I have written a key transition document. I am at the step where I should/must sign it with both keys (old and new one). I can sign (inline) my document using this: gpg --output keytransition.signed --clearsign keytransition.txt This works for one GPG key but how can I make it work twice ? If I do the same command but using my old key: gpg --default-key 0xold-key --output keytransition.signed2 --clearsign keytransition.txt then I should "merge" the signed files but when verifying, it just complains: gpg: Attention?: conflit de hachage de signature dans le message gpg: Impossible de v?rifier la signature?: General error How am I supposed to achieve this ? How do you double (triple or even more) gpg-sign a file ? Regards -- Sent with my mu4e -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1534 bytes Desc: not available URL: From jesper at graffen.dk Wed Feb 18 07:51:46 2015 From: jesper at graffen.dk (Jesper Hess Nielsen) Date: Wed, 18 Feb 2015 07:51:46 +0100 Subject: Double sign a document In-Reply-To: References: Message-ID: <54E43682.3040107@graffen.dk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 02/18/2015 07:31 AM, Xavier Maillard wrote: > Hi, > > in order to announce my new GPG key< I have written a key > transition document. > > > gpg --output keytransition.signed --clearsign keytransition.txt > > This works for one GPG key but how can I make it work twice ? > gpg -u -u --clearsign keytransition.txt > keytransition.signed2 Should do the trick. - -- Jesper Hess Nielsen Web: http://graffen.dk Twitter: @graffen - ---------------------------------- For increased privacy feel free to send me OpenPGP-encrypted email. NB! I have recently transitioned to a new key NB! http://graffen.dk/transition-notice.html Public GPG key 0xCAEBD4B2 at hkps://pool.sks-keyservers.net Fingerprint: 03CD 582F 13C0 682C 8F52 9C05 8417 0D85 CAEB D4B2 - ---------------------------------- -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJU5DZ5AAoJEDUaieQNdj8PstAP/RkJF396fXgjyIruTLwZo/Df 8tpGaMix7PdCVQE76hmuHM0j0W/otMWS2jOk7IOxv/vcYaYyOkdpnMf+4wxTyHsq afWd5BebdcSiMSI/wn0FhmOwkFE44Vx75OIsEawy1YyS+Ru5TkRNczowGf76i8vo ebpnq+UFcgharyeUN8CSF/6Eq1ZY1DF8qizG5F2hcqxMR+ba/xer1q6SvgyQmODH 9xuXLUOGxcX940KKflRqmpep9WJdn1JBqYNmvbB04U+lBd0gzQOiwJCQOiXrukq3 746sj3ULLnRqirNVlntyewBUUUpZ/oe3GyIgFcoKvi5pWqzoU73oY+Awjyc3hFpt zUDk/Ov3/4l1spVNuizNLzw0ksNa8QQJv1r9q8Ies+RvJwTpwSpCbIv+6n2lfAK+ tJL67QJyf3tnKj6AYodjdqsmQkWevx438FwdLH1uBzNAeEUWlDavOIfG+XsGdKaU SO19cFzqM05u+O3jXSviXqjB0EBqLzZSacgHxh+070AsogXfF7d6CX4MJZ0286YU dJxNqStcC7E/AXwiTX25lIyF/69XKWZMzsoyn9Hp1ZbdAtQ8T82V04NPEYPVqEAf vlxsivmJ+2jHkM9YL8tJa6x5vTZzZYXfO3bUpCXnwvmmZOI9tOgiagq9WxvurhC/ fxNjZfLHXhEetC/YP4Oe =1dCd -----END PGP SIGNATURE----- From jesper at graffen.dk Wed Feb 18 07:59:58 2015 From: jesper at graffen.dk (Jesper Hess Nielsen) Date: Wed, 18 Feb 2015 07:59:58 +0100 Subject: Double sign a document In-Reply-To: <54E43682.3040107@graffen.dk> References: <54E43682.3040107@graffen.dk> Message-ID: <54E4386E.3020506@graffen.dk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 > > gpg -u -u --clearsign keytransition.txt > > keytransition.signed2 > woops, forget about the '> keytransition.signed2' part. Just running with --clearsign will give you a keytransition.txt.asc file automatically. - -- Jesper Hess Nielsen Web: http://graffen.dk Twitter: @graffen - ---------------------------------- For increased privacy feel free to send me OpenPGP-encrypted email. NB! I have recently transitioned to a new key NB! http://graffen.dk/transition-notice.html Public GPG key 0xCAEBD4B2 at hkps://pool.sks-keyservers.net Fingerprint: 03CD 582F 13C0 682C 8F52 9C05 8417 0D85 CAEB D4B2 - ---------------------------------- -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJU5DhuAAoJEDUaieQNdj8PL4sP/Rvg5myj49B4dVMp62KmbGgp w0V6Evv7hpqJch7/hfhWQdT//Cp1S2TkVZIQK/fQFEnFozqO0agPQ6BZ8+diTD9z jAoxFd+HxQrrVbwYq7i9i2rF5hZe9O2qzHa+8ah9qpBFjIKuqj8pm4xTNugraFpP +UQt4KGHbmymuUN950EaZ251sRe7nx7+HOdPAd4EUNs3jgdASeif7EzPuR/jsns3 ZmxmEvhawQ8Pl/k0uZVO/IHoSbzYqHYMickCguB1CBr/u/VJ+UEPLwm3azoiFhCG 7YB3LFAzWGT5SX/8vmIE76VAoQuuYi5asm69RAy2o4NpBlLWojfclo+gpTW5J6or pksBmgBx1iSL2nC/7r6rtxHIXxSguWdk6+9jJ5Kl5GpbKp9MtAGI5xsnr+Wq1b0B CEkPj2Ei2BNwMKzPKqVqlrH8Pnto7DD+54W9JwZUAOvblp1Ej99zzd1T1hQe9pup TjwWwBhl7msQvKo7KAvPu9Hdmw9E+D+3DQbpY5Dv5XiTcWvV0F19SfkDntPfqqot +FY4h0I9rS9p4G1V4lx+es7TCtPenOAz772rJw8aCUn54LuNPT0AkWtV5It8Vfe5 YkvMl7OxnbClvUIa+lts4KTGW3w8Ik4w6h8IcWx6uBpRQBwm2rF8WhpZO4+mTC4F bUu/V0bslmN1QJZ92o+I =eTrd -----END PGP SIGNATURE----- From peter at digitalbrains.com Wed Feb 18 10:40:37 2015 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 18 Feb 2015 10:40:37 +0100 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: References: <68F2AA9B-B192-4727-9AA3-2BC33CBE5434@mykolab.com> Message-ID: <54E45E15.5020206@digitalbrains.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 17/02/15 22:32, Lukas Pitschl wrote: > We?ve recently been accused again of "knowlingly lowering the overall > security? [1] by not allowing such a key size. We?re still not sure what > to do about it exactly. There will always be people who think they know better and be very... vocal about it on the internet. I'm sure it has been mentioned how they'll switch to another program if you don't comply with their demands instantly... :( I think you should just ignore them and not second-guess the security related decisions taken by your upstream, the GnuPG project. I don't see any reason why a version for Mac would need different RSA key size limits than a version for Linux or Windows.[1] In fact, the second-guessing might actually unintentionally lower the overall security... My 2 cents, Peter. [1] Unless of course all Macs are much more powerful and Mac users only communicate with Mac users... just kidding :P - -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From js-gnupg-users at webkeks.org Wed Feb 18 11:52:52 2015 From: js-gnupg-users at webkeks.org (Jonathan Schleifer) Date: Wed, 18 Feb 2015 11:52:52 +0100 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: <87sie4pt9j.fsf@vigenere.g10code.de> References: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> <20150216235311.GA10680@athena.barrera.io> <87sie4pt9j.fsf@vigenere.g10code.de> Message-ID: Am 17.02.2015 um 14:22 schrieb Werner Koch : > I do not think that it matters whether you pull using the git or the ssh > protocol. In both cases an active attacker can intercept the traffic > easily. Virtually nobody checks ssh host keys and how should they do it > given that I can't find its fingerprint easily on github. Thus you would only > see the "host key changed" warning in case this is not the first time > you connected to this github project (I assume they use different host > keys per project). I do verify the fingerprint, and they are quite easy to find actually: https://help.github.com/articles/what-are-github-s-ssh-key-fingerprints/ First Google match for "GitHub SSH fingerprint". > After all it is not different from downloading tarballs - only 10 to 20% > of all downloads also download the signature file and for most projects > there is no signature file. Well, I guess you have to take into account that a lot of downloads are from packaging software like pkgsrc, FreeBSD ports, Gentoo portage, ArchLinux's makepkg, etc. Usually, these do download the signature and tarball once, verify it and then write a checksum to the Makefile / PKGBUILD / however it is called that is then verified. So I guess you can't easily map that to "Only x% of users check the downloaded tarball". I guess it's a lot more, it's just not all check it using the .sig. > For gnupg.org we assume that users of the repos closely watch out for > conflicts and verify the latest release tag. If there is a problem that > should be reported to a mailing-list (after verification that it is > really a conflict). > > git meanwhile allows to sign commits. If anyone knows a method to set a > different key for tagging and commits, I would soon start to sign each > commit. I use a smartcard based key for tagging but won't use that for > regular commits. git commit -S You can just create an alias for that, I for example use git ci. -- Jonathan From js-gnupg-users at webkeks.org Wed Feb 18 11:54:28 2015 From: js-gnupg-users at webkeks.org (Jonathan Schleifer) Date: Wed, 18 Feb 2015 11:54:28 +0100 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: <87oaospsum.fsf@vigenere.g10code.de> References: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> <87oaospsum.fsf@vigenere.g10code.de> Message-ID: Am 17.02.2015 um 14:31 schrieb Werner Koch : > GnuPG's speedo build system also downloads stuff via the Makefile but it > verifies the checksums before proceeding. The checksums are taken from a > public file which has a detached signature and the public key for that > is one of the GnuPG release signing keys. While this is much better from a security point of view, it still means that building needs an internet connection. It would be nice to be able to build it on an air-gapped machine, which I guess is quite a common use case for GnuPG. To be fair, though, I never noticed that until you mentioned it :). -- Jonathan From js-gnupg-users at webkeks.org Wed Feb 18 11:55:48 2015 From: js-gnupg-users at webkeks.org (Jonathan Schleifer) Date: Wed, 18 Feb 2015 11:55:48 +0100 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: <06ACA41C-7BCE-4509-905C-97DC21AAD15D@mykolab.com> References: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> <3501398A-6622-4065-AEE3-E7F8EBAACCFE@webkeks.org> <06ACA41C-7BCE-4509-905C-97DC21AAD15D@mykolab.com> Message-ID: <389B9F4D-549B-4152-B7F8-99B7E5391509@webkeks.org> Am 17.02.2015 um 14:58 schrieb Sandeep Murthy : > FYI I think you haven?t really looked at the support forum. This page > > http://support.gpgtools.org/kb/faq/found-an-issue > > clearly lists instructions for submitting a bug. They are always interested > in reproducible issues, and every week in the discussions such issues > are reported. > > Therefore it is not true that this support forum does not allow people to > report bugs. I looked for this a month ago and couldn't find anything besides a support forum (didn't sound right to me) and a Twitter handle, thus I decided to try Twitter. -- Jonathan From js-gnupg-users at webkeks.org Wed Feb 18 11:58:29 2015 From: js-gnupg-users at webkeks.org (Jonathan Schleifer) Date: Wed, 18 Feb 2015 11:58:29 +0100 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: <20150217141424.GA24511@athena.barrera.io> References: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> <20150216235311.GA10680@athena.barrera.io> <68A83FF0-7527-4300-9A47-79562DACAFA1@mykolab.com> <078EC143-B618-41DD-B2B3-3A46FF83184A@webkeks.org> <20150217141424.GA24511@athena.barrera.io> Message-ID: Am 17.02.2015 um 15:14 schrieb Hugo Osvaldo Barrera : > Actually, I've noticed that there was a very quick reply to this when it was > brought to the dev's attention. I'll leave this here for anyone else interested > in following-up: > > https://github.com/GPGTools/GPGTools_Core/commit/5186bade36acedfdc0b76f9f5ddfcfc004ec698b > > I'm not aware of any track record of writing bad software in the past either - > I believe they're just human. "A user complained, so we'd rather use something insecure." This is not the correct mindset to develop security software! Also, the new way they solve it ignores the proposal to use git submodules entirely, not even stating why they don't want to use git submodules. But that at least is not a security problem, so I don't have strong feeling about this :). -- Jonathan From js-gnupg-users at webkeks.org Wed Feb 18 12:05:18 2015 From: js-gnupg-users at webkeks.org (Jonathan Schleifer) Date: Wed, 18 Feb 2015 12:05:18 +0100 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: <8CBC97E5-C896-4989-814D-45E67C9014CF@asatiifm.net> References: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> <87oaospsum.fsf@vigenere.g10code.de> <8CBC97E5-C896-4989-814D-45E67C9014CF@asatiifm.net> Message-ID: <8F2638C2-DBB8-4079-A1FA-A8720887B687@webkeks.org> Am 17.02.2015 um 17:00 schrieb Ville M??tt? : > Upstream still does have the issue which now seems to have been fixed in the fork but in a binary removed from upstream? I really can not confirm this. I am running vanilla GnuPG 2.1.2 (built from source) on Yosemite (10.10.2 to be exact) with a Gnuk without any problems. In any case, I agree about the part that such fixes should be developed in the GnuPG repo and not in basically a fork that receives less reviewing. > I think the GUI tooling of not only Mac but other *NIX systems to be quite an important factor in getting wider use for encryption. Such tools must be from a respectable source and properly implemented just as much as the underlying engine. I would argue GnuPG should take the responsibility of such tooling where there isn?t a good option. Other *NIX systems are doing fairly well already so I suppose a Mac GUI would really be the urgent one. I suppose it might be a good idea to have a Qt GUI. That looks native enough on Mac so that most users won't complain, works good on X11 or Wayland based systems and also works well on Windows. Ideally, this would be a project under the GnuPG umbrella, but ideally not taking away time from core developers and thus be done by others. It also is not that security critical if it's just a GUI using the command line tool. -- Jonathan From js-gnupg-users at webkeks.org Wed Feb 18 12:12:04 2015 From: js-gnupg-users at webkeks.org (Jonathan Schleifer) Date: Wed, 18 Feb 2015 12:12:04 +0100 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: References: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> <87oaospsum.fsf@vigenere.g10code.de> <8CBC97E5-C896-4989-814D-45E67C9014CF@asatiifm.net> Message-ID: <3F1E4544-4E04-4472-82F4-A9DAF578627B@webkeks.org> Am 17.02.2015 um 20:16 schrieb Juergen Fenn : > Enigmail has discussed recently to drop support for GnuPG1, making > gpg-agent/pinentry a crucial issue on the Mac. The standard version of > pinentry from MacPorts does not work properly out of the box. For homebrew, there's a pinentry-mac formula, which unfortunately also does the remote code execution. I raised the issue with homebrew, however, most posts in that ticket were deleted because some people started questioning the review process of new formula and asked how this could even have gotten into homebrew. The solution I chose is an ugly, but more secure one: I use pinentry-gtk with XDarwin. Sure it's ugly, even more so since it is upscaled on a retina display. But it's only for entering the PIN / passphrase, so I'd rather use that then pinentry-mac. I did not choose pinentry-curses because that didn't work well with signing Git commits. > Anyway, alternatives should be mentioned on the GnuPG pages because?I > agree to the OP?this is too important an issue, GnuPG also being used > by many people who seriously depend on its security. I totally agree. There should at least be a big fat warning, saying to not use if it you really depend on security. > The question is, can we use GnuPG on the Mac and rely on it? I'd say yes. I'm using GnuPG 2.1.2 vanilla with a Gnuk token and don't see why it should be any less reliable than on Linux. -- Jonathan From samir at samirnassar.com Wed Feb 18 12:19:33 2015 From: samir at samirnassar.com (Samir Nassar) Date: Wed, 18 Feb 2015 12:19:33 +0100 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: <8F2638C2-DBB8-4079-A1FA-A8720887B687@webkeks.org> References: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> <8CBC97E5-C896-4989-814D-45E67C9014CF@asatiifm.net> <8F2638C2-DBB8-4079-A1FA-A8720887B687@webkeks.org> Message-ID: <4686916.cH5caygS4z@lathe> On Wednesday, February 18, 2015 12:05:18 PM Jonathan Schleifer wrote: > I suppose it might be a good idea to have a Qt GUI. That looks native enough > on Mac so that most users won't complain, works good on X11 or Wayland > based systems and also works well on Windows. Ideally, this would be a > project under the GnuPG umbrella, but ideally not taking away time from > core developers and thus be done by others. It also is not that security > critical if it's just a GUI using the command line tool. Hello, If you are using MacPorts you could try KGPG. Rolf Eike Beer is the maintainer and is very active and responsive. I don't know if all the features will work on OS X, but I really like KGPG's ability to take text and encrypt and sign plain text from an interface as well as decrypt and verify ASCII-armored text. Samir -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From js-gnupg-users at webkeks.org Wed Feb 18 12:21:43 2015 From: js-gnupg-users at webkeks.org (Jonathan Schleifer) Date: Wed, 18 Feb 2015 12:21:43 +0100 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: References: <68F2AA9B-B192-4727-9AA3-2BC33CBE5434@mykolab.com> Message-ID: Am 17.02.2015 um 22:32 schrieb Lukas Pitschl : > The best way to reach us is either our support platform at https://gpgtools.tenderapp.com or team at gpgtools.org. When I tried contacting you guys a little more than a month ago, there was no e-mail to be found on the website. Only a support forum that sounded like "Users helping users" (so I didn't want to report the bug there) and a Twitter, which I then used. Can you please make sure it's easy to find that mail address? > The code that checks out our GPGTools_Core repository is pretty old already and it?s certainly a stupid way to do it. It's not so much about age, but about what thought process came to the conclusion that this might be a good idea. This is a security project, so every change done should be done with thoroughly thinking about the security implications that change might have. This was clearly not done here, and IMHO downloading and executing remote code without any verification is unforgivable for a security project. > At the time we assumed that it was safe to check it out via ssl from github, since curl would refuse to do so if there was a certificate error. This entirely depends on the certification store curl has and the configuration. Granted, the defaults on OS X are sane. But still, this relies completely on GitHub not being compromised. And it was only quite recently that someone managed to get write access to repos due to a bug in GitHub. How can someone blindly trust and rely on a service they can neither control nor audit for the security of their users in a security project? This is just extremely irresponsible. And even worse: Why did you decide to hide what is going on by prefixing it with a @? This really feels like you are trying to deceit users, hiding from them that they execute remote code that you could change at any moment. Worse yet, you could later on switch it back and nobody would notice. This feels a lot like a hidden backdoor to me. > we will only charge a fee for GPGMail, the rest of GPG Suite will remain free. Actually, I'm all for you charging a fee. That will create enough pressure for a fork that will then hopefully have better security practices. -- Jonathan From wk at gnupg.org Wed Feb 18 12:40:12 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 18 Feb 2015 12:40:12 +0100 Subject: 2.1.2: keyserver route failure In-Reply-To: <54E42223.9070307@sixdemonbag.org> (Robert J. Hansen's message of "Wed, 18 Feb 2015 00:24:51 -0500") References: <54E2977C.106@sixdemonbag.org> <87wq3gpujn.fsf@vigenere.g10code.de> <54E3953F.2000909@sixdemonbag.org> <878ufvop8f.fsf@vigenere.g10code.de> <54E42223.9070307@sixdemonbag.org> Message-ID: <87bnkrla77.fsf@vigenere.g10code.de> On Wed, 18 Feb 2015 06:24, rjh at sixdemonbag.org said: > I don't have IPv6 routing, period. This raises the question of why > GnuPG is trying to reach an IPv6 address at all. Because the resolver tells that there is an AAAA record. It seems that we need to figure out at runtime whether v6 is actually working. Any hints on how to do that? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From johanw at vulcan.xs4all.nl Wed Feb 18 12:59:34 2015 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Wed, 18 Feb 2015 12:59:34 +0100 Subject: 2.1.2: keyserver route failure In-Reply-To: <87bnkrla77.fsf@vigenere.g10code.de> References: <54E2977C.106@sixdemonbag.org> <87wq3gpujn.fsf@vigenere.g10code.de> <54E3953F.2000909@sixdemonbag.org> <878ufvop8f.fsf@vigenere.g10code.de> <54E42223.9070307@sixdemonbag.org> <87bnkrla77.fsf@vigenere.g10code.de> Message-ID: <54E47EA6.4090208@vulcan.xs4all.nl> On 18-02-2015 12:40, Werner Koch wrote: > Because the resolver tells that there is an AAAA record. It seems that > we need to figure out at runtime whether v6 is actually working. Any > hints on how to do that? The most easy solution in such cases is to try IPv4 first, if that doesn't work or is unavailable, try IPv6 if available. Non-working or misconfigured IPv6 setups are rather common, probably done by default setups where the builder prefers IPv6 and a server owner who isn't even aware the server supports IPv6. Combined with a "IPv6 first" approach of some software a recipe for problems. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From errol at askerrol.org Wed Feb 18 14:18:11 2015 From: errol at askerrol.org (Errol Casey) Date: Wed, 18 Feb 2015 08:18:11 -0500 Subject: Compiled binaries execute but exit with "Abort" In-Reply-To: <874mqjooyl.fsf@vigenere.g10code.de> References: <874mqjooyl.fsf@vigenere.g10code.de> Message-ID: gdb gpg2 GNU gdb 6.6 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc-sun-solaris2.10"... (gdb) break abort Breakpoint 1 at 0x1278fc (gdb) run Starting program: /syshome/gecasey/gpg/gnupg-2.0.26/g10/gpg2 warning: Temporarily disabling breakpoints for unloaded shared library "/usr/lib/ld.so.1" Breakpoint 1 at 0xfedc28a4 gpg: Go ahead and type your message ... this is a test . gpg: no valid OpenPGP data found. gpg: processing message failed: Unknown system error Breakpoint 1, 0xfedc28a4 in abort () from /lib/libc.so.1 (gdb) bt #0 0xfedc28a4 in abort () from /lib/libc.so.1 #1 0xff15367c in get_lock_object (lockhd=0xff16e3b0) at posix-lock.c:111 #2 0xff1536f8 in _gpgrt_lock_lock (lockhd=0xff16e3b0) at posix-lock.c:155 #3 0xff156a74 in _gpgrt_fflush (stream=0x0) at estream.c:3590 #4 0xff156b0c in do_deinit () at estream.c:490 #5 0xfedc3180 in _exithandle () from /lib/libc.so.1 #6 0xfedb1140 in exit () from /lib/libc.so.1 #7 0x0002717c in g10_exit () #8 0x00025de0 in main () (gdb) On Tue, Feb 17, 2015 at 10:53 PM, Werner Koch wrote: > On Tue, 17 Feb 2015 21:12, errol at askerrol.org said: > > > But it fails openpgp tests, and all executable exit with an "Abort" > message. > > Please run such an executable under a debugger and privide a stack > backtrace. Using gdb you would use: > > gdb g10/gpg > > then enter "break abort", "run", and after it stops "bt". > > > Shalom-Salam, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > -- Errol Casey errol at askerrol.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Wed Feb 18 15:46:54 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 18 Feb 2015 15:46:54 +0100 Subject: Compiled binaries execute but exit with "Abort" In-Reply-To: (Errol Casey's message of "Wed, 18 Feb 2015 08:18:11 -0500") References: <874mqjooyl.fsf@vigenere.g10code.de> Message-ID: <87a90bjmzl.fsf@vigenere.g10code.de> On Wed, 18 Feb 2015 14:18, errol at askerrol.org said: > #0 0xfedc28a4 in abort () from /lib/libc.so.1 > #1 0xff15367c in get_lock_object (lockhd=0xff16e3b0) at posix-lock.c:111 That is an assert() checking that the used library matches the one used for building. This is all in libgpg-error - please build libgpg-error and check that "make check" works. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Feb 18 15:59:14 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 18 Feb 2015 15:59:14 +0100 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: (Jonathan Schleifer's message of "Wed, 18 Feb 2015 11:54:28 +0100") References: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> <87oaospsum.fsf@vigenere.g10code.de> Message-ID: <871tlnjmf1.fsf@vigenere.g10code.de> On Wed, 18 Feb 2015 11:54, js-gnupg-users at webkeks.org said: > While this is much better from a security point of view, it still means that building needs an internet connection. It would be nice to be able to build it on an air-gapped machine, which I guess is quite a common use case for GnuPG. > > To be fair, though, I never noticed that until you mentioned it :). The speedo.mk Makefile is optional. And of course it is possible to run that offline (make -f speedo.mk native CUSTOM_SWDB=1) - I like to work while on a train. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Feb 18 15:57:12 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 18 Feb 2015 15:57:12 +0100 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: (Jonathan Schleifer's message of "Wed, 18 Feb 2015 11:52:52 +0100") References: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> <20150216235311.GA10680@athena.barrera.io> <87sie4pt9j.fsf@vigenere.g10code.de> Message-ID: <8761azjmif.fsf@vigenere.g10code.de> On Wed, 18 Feb 2015 11:52, js-gnupg-users at webkeks.org said: > I do verify the fingerprint, and they are quite easy to find actually: > > https://help.github.com/articles/what-are-github-s-ssh-key-fingerprints/ > > First Google match for "GitHub SSH fingerprint". Using a search engine to find important information is not very user friendly. The host keys should be linked from the root page. But in this regard this is not different than any root CA - most make it really hard to find the fingerprint and the support lines sometimes don't even known why one what to check this. > Makefile / PKGBUILD / however it is called that is then verified. So I > guess you can't easily map that to "Only x% of users check the > downloaded tarball". I guess it's a lot more, it's just not all check > it using the .sig. Sure I can. If there are 1000 downloads of the tarball and only 100 of the corresponding sig it should be pretty clear that 90% of those who download not even pretend to check the signature. > git commit -S > > You can just create an alias for that, I for example use git ci. I know that but I would like to have a different key for tag and commit. Requiring an option is just too cumbersome. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Feb 18 16:01:57 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 18 Feb 2015 16:01:57 +0100 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: <8F2638C2-DBB8-4079-A1FA-A8720887B687@webkeks.org> (Jonathan Schleifer's message of "Wed, 18 Feb 2015 12:05:18 +0100") References: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> <87oaospsum.fsf@vigenere.g10code.de> <8CBC97E5-C896-4989-814D-45E67C9014CF@asatiifm.net> <8F2638C2-DBB8-4079-A1FA-A8720887B687@webkeks.org> Message-ID: <87wq3fi7q2.fsf@vigenere.g10code.de> On Wed, 18 Feb 2015 12:05, js-gnupg-users at webkeks.org said: > I suppose it might be a good idea to have a Qt GUI. That looks native Although Kleopatra is a KDE application there is not much of KDE in it and, iirc, Andre once suggested to turn it into a plain Qt application. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Feb 18 16:05:24 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 18 Feb 2015 16:05:24 +0100 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: (Jonathan Schleifer's message of "Wed, 18 Feb 2015 12:21:43 +0100") References: <68F2AA9B-B192-4727-9AA3-2BC33CBE5434@mykolab.com> Message-ID: <87sie3i7kb.fsf@vigenere.g10code.de> On Wed, 18 Feb 2015 12:21, js-gnupg-users at webkeks.org said: > And even worse: Why did you decide to hide what is going on by > prefixing it with a @? This really feels like you are trying to deceit I also do this often to avoid cluttering the screen. No need to assume a backdoor. It is for a Mac and Mac users want a clean tty ;-) Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Feb 18 16:29:12 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 18 Feb 2015 16:29:12 +0100 Subject: [Announce] GnuPG 2.0.27 "stable" released Message-ID: <87ioezi6gn.fsf@vigenere.g10code.de> Hello! We are pleased to announce the availability of a new stable GnuPG-2 release: Version 2.0.27. This is a maintenance release which fixes a couple of bugs. Update to this version is suggested. The GNU Privacy Guard (GnuPG) is a complete and free implementation of the OpenPGP standard as defined by RFC-4880 and better known as PGP. GnuPG, also known as GPG, allows to encrypt and sign data and communication, features a versatile key management system as well as access modules for public key directories. GnuPG itself is a command line tool with features for easy integration with other applications. A wealth of frontend applications and libraries making use of GnuPG are available. Since version 2 GnuPG provides support for S/MIME and Secure Shell in addition to OpenPGP. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License. Three different versions of GnuPG are actively maintained: - GnuPG "modern" (2.1) is the latest development with a lot of new features. - GnuPG "stable" (2.0) - which this is about - is the current stable version for general use. This is what most users are currently using. - GnuPG "classic" (1.4) is the old standalone version which is most suitable for older or embedded platforms. You may not install "modern" (2.1) and "stable" (2.0) at the same time. However, it is possible to install "classic" (1.4) along with any of the other versions. What's New in 2.0.27 ==================== * gpg: Detect faulty use of --verify on detached signatures. * gpg: New import option "keep-ownertrust". * gpg: Uses SHA-256 for all signature types also on RSA keys. * gpg: Added support for algo names when generating keys using the --command-fd method. * gpg: Unless --allow-weak-digest-algos is used the insecure MD5 based fingerprints are shown as all zeroe * gpg: Fixed DoS based on bogus and overlong key packets. * gpg: Better error reporting for keyserver problems. * Fixed several bugs related to bogus keyrings and improved some other code. Getting the Software ==================== Please follow the instructions found at https://gnupg.org/download/ or read on: GnuPG 2.0.27 may be downloaded from one of the GnuPG mirror sites or direct from ftp://ftp.gnupg.org/gcrypt/gnupg/ . The list of mirrors can be found at https://gnupg.org/mirrors.html . Note that GnuPG is not available at ftp.gnu.org. On ftp.gnupg.org and on its mirrors you should find the following new files in the gnupg/ directory: - The GnuPG source code compressed using BZIP2 and its OpenPGP signature: gnupg-2.0.27.tar.bz2 (4321k) gnupg-2.0.27.tar.bz2.sig Note, that we don't distribute gzip compressed tarballs for GnuPG-2. A Windows version will eventually be released at https://gpg4win.org . If you are new to GnuPG please consider to use the "modern" version 2.1.2. Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a version of GnuPG installed, you can simply verify the supplied signature. For example to verify the signature of the file gnupg-2.0.27.tar.bz2 you would use this command: gpg --verify gnupg-2.0.27.tar.bz2.sig gnupg-2.0.27.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See below for information on the signing keys. * If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either "sha1sum" or "shasum". Assuming you downloaded the file gnupg-2.1.1.tar.bz2, you would run the command like this: sha1sum gnupg-2.0.27.tar.bz2 and check that the output matches the next line: d065be185f5bac8ea07b210ab7756e79b83b63d4 gnupg-2.0.27.tar.bz2 Release Signing Keys ==================== To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: 2048R/4F25E3B6 2011-01-12 [expires: 2019-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048/E0856959 2014-10-29 [expires: 2019-12-31] Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 David Shaw (GnuPG Release Signing Key) rsa2048/33BD3F06 2014-10-29 [expires: 2016-10-28] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa2048/7EFD60D9 2014-10-19 [expires: 2020-12-31] Key fingerprint = D238 EA65 D64C 67ED 4C30 73F2 8A86 1B1C 7EFD 60D9 Werner Koch (Release Signing Key) You may retrieve these files from the keyservers using this command gpg --recv-keys 249B39D24F25E3B6 04376F3EE0856959 \ 2071B08A33BD3F06 8A861B1C7EFD60D9 using an already installed version of gpg. Remeber to check the fingerprints against the above list (which you also find on the flip side of our printed visit cards). The keys are also available at https://gnupg.org/signature_key.html and in the released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed using my standard PGP key. Documentation ============= The file gnupg.info has the complete user manual of the system. Separate man pages are included as well; however they have not all the details available in the manual. It is also possible to read the complete manual online in HTML format at https://www.gnupg.org/documentation/manuals/gnupg/ or in Portable Document Format at https://www.gnupg.org/documentation/manuals/gnupg.pdf . The chapters on gpg-agent, gpg and gpgsm include information on how to set up the whole thing. You may also want search the GnuPG mailing list archives or ask on the gnupg-users mailing lists for advise on how to solve problems. Many of the new features are around for several years and thus enough public knowledge is already available. Support ======= Please consult the archive of the gnupg-users mailing list before reporting a bug . We suggest to send bug reports for a new release to this list in favor of filing a bug at . We also have a dedicated service directory at: https://www.gnupg.org/service.html The driving force behind the development of GnuPG is the company of its principal author, Werner Koch. Maintenance and improvement of GnuPG and related software takes up most of their resources. To allow him to continue this work he kindly asks to either purchase a support contract, engage g10 Code for custom enhancements, or to donate money: https://gnupg.org/donate/ Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, and answering questions on the mailing lists. Since the start of the funding campaign in December several thousand people have been kind enough to donate a total of 250000 Euro to support this project. In addition the Linux Foundation gave a grant of $ 60000 for 2015, Stripe.com and Facebook.com each pledged $ 50000 per year. I am amazed by this superb and unexpected support for the GnuPG project. This will not only allow us to continue the project and hire at least a second full time developer but gives us also the resources to improve things which have been delayed for too long. *Thank you all !* Shalom-Salam, Werner p.s. This is a announcement only mailing list. Please send replies only to the gnupg-users 'at' gnupg.org mailing list. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 180 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From wk at gnupg.org Wed Feb 18 16:37:29 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 18 Feb 2015 16:37:29 +0100 Subject: [Announce] GnuPG 2.1.2 released In-Reply-To: <201502161103.58043.bernhard@intevation.de> (Bernhard Reiter's message of "Mon, 16 Feb 2015 11:03:51 +0100") References: <874mqs2q4o.fsf@vigenere.g10code.de> <201502131626.13795.bernhard@intevation.de> <8761b5vcnl.fsf@vigenere.g10code.de> <201502161103.58043.bernhard@intevation.de> Message-ID: <87egpni62u.fsf@vigenere.g10code.de> On Mon, 16 Feb 2015 11:03, bernhard at intevation.de said: > * What the items in section "What's New in GnuPG-2.1" actually meant, I should have read "What's New in GnuPG 2.1.2", sorry. > * "This version fixes a lot of bugs found after the release of 2.1.0" > which probably should have been "2.1.1". Actually I meant 2.1.0 as the first release of the 2.1 branch. Might be a bit unclear, indeed. > Overall I believe the announcement as too much text that stays the same > for each release. It would benefit from being focussed on the key differences That is how I expect an announcement. > ps.: Congrats on the taz article (in German) I've added the link to the wiki. [I don't understand why the all pretend that I am working in a cellar. I even have to walk another 12 steps down to the garden.] Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dougb at dougbarton.email Wed Feb 18 17:31:48 2015 From: dougb at dougbarton.email (Doug Barton) Date: Wed, 18 Feb 2015 08:31:48 -0800 Subject: 2.1.2: keyserver route failure In-Reply-To: <54E47EA6.4090208@vulcan.xs4all.nl> References: <54E2977C.106@sixdemonbag.org> <87wq3gpujn.fsf@vigenere.g10code.de> <54E3953F.2000909@sixdemonbag.org> <878ufvop8f.fsf@vigenere.g10code.de> <54E42223.9070307@sixdemonbag.org> <87bnkrla77.fsf@vigenere.g10code.de> <54E47EA6.4090208@vulcan.xs4all.nl> Message-ID: <54E4BE74.5050602@dougbarton.email> On 2/18/15 3:59 AM, Johan Wevers wrote: > On 18-02-2015 12:40, Werner Koch wrote: > >> Because the resolver tells that there is an AAAA record. It seems that >> we need to figure out at runtime whether v6 is actually working. Any >> hints on how to do that? > > The most easy solution in such cases is to try IPv4 first, if that > doesn't work or is unavailable, try IPv6 if available. Yeah, please DO NOT do that. The more traffic we can push to IPv6 the better for everyone, both now and in the future. I'll get some refs on testing IPv6 capability, give me a couple hours. Doug From dougb at dougbarton.email Wed Feb 18 17:46:23 2015 From: dougb at dougbarton.email (Doug Barton) Date: Wed, 18 Feb 2015 08:46:23 -0800 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: References: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> <20150216235311.GA10680@athena.barrera.io> <87sie4pt9j.fsf@vigenere.g10code.de> Message-ID: <54E4C1DF.3080601@dougbarton.email> On 2/18/15 2:52 AM, Jonathan Schleifer wrote: > Well, I guess you have to take into account that a lot of downloads are from packaging software like pkgsrc, FreeBSD ports, Gentoo portage, ArchLinux's makepkg, etc. Usually, these do download the signature and tarball once, verify it and then write a checksum to the Makefile / PKGBUILD / however it is called that is then verified. So I guess you can't easily map that to "Only x% of users check the downloaded tarball". I guess it's a lot more, it's just not all check it using the .sig. Back when I was involved with the FreeBSD project I included code in the Makefile to verify the PGP signature for all of my ports that had one, as did a few other maintainers. However there was not only not a consensus to do this more generally, there was active opposition to doing it at all. If you are a FreeBSD user and believe that this would be something beneficial to the ports system, please send them e-mail at freebsd-ports at freebsd.org and let them know. :) Doug From rjh at sixdemonbag.org Wed Feb 18 17:56:43 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 18 Feb 2015 11:56:43 -0500 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: References: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> <20150216235311.GA10680@athena.barrera.io> <68A83FF0-7527-4300-9A47-79562DACAFA1@mykolab.com> <078EC143-B618-41DD-B2B3-3A46FF83184A@webkeks.org> <20150217141424.GA24511@athena.barrera.io> Message-ID: <54E4C44B.2000604@sixdemonbag.org> > "A user complained, so we'd rather use something insecure." That's not what the GPGTools folks did. Your caricature of their response is unfair and ungentlemanly. From johanw at vulcan.xs4all.nl Wed Feb 18 18:07:02 2015 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Wed, 18 Feb 2015 18:07:02 +0100 Subject: 2.1.2: keyserver route failure In-Reply-To: <54E4BE74.5050602@dougbarton.email> References: <54E2977C.106@sixdemonbag.org> <87wq3gpujn.fsf@vigenere.g10code.de> <54E3953F.2000909@sixdemonbag.org> <878ufvop8f.fsf@vigenere.g10code.de> <54E42223.9070307@sixdemonbag.org> <87bnkrla77.fsf@vigenere.g10code.de> <54E47EA6.4090208@vulcan.xs4all.nl> <54E4BE74.5050602@dougbarton.email> Message-ID: <54E4C6B6.5060306@vulcan.xs4all.nl> On 18-02-2015 17:31, Doug Barton wrote: >> The most easy solution in such cases is to try IPv4 first, if that >> doesn't work or is unavailable, try IPv6 if available. > Yeah, please DO NOT do that. The more traffic we can push to IPv6 the > better for everyone, both now and in the future. I've seen that before: proponents of IPv6 try to fore an "IPv6 first" doctrine to get at least _some_ traffic over IPv6 because IPv4 first would mean that IPv6 would nearly nover been used. Admit it, IPv6 has failed. It may get some uses, but the widespread adaptation of carrier NAT has made it largely obsolete. Removing the AAAA record would be the quickest solution I guess. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From wk at gnupg.org Wed Feb 18 19:36:32 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 18 Feb 2015 19:36:32 +0100 Subject: 2.1.2: keyserver route failure In-Reply-To: <54E47EA6.4090208@vulcan.xs4all.nl> (Johan Wevers's message of "Wed, 18 Feb 2015 12:59:34 +0100") References: <54E2977C.106@sixdemonbag.org> <87wq3gpujn.fsf@vigenere.g10code.de> <54E3953F.2000909@sixdemonbag.org> <878ufvop8f.fsf@vigenere.g10code.de> <54E42223.9070307@sixdemonbag.org> <87bnkrla77.fsf@vigenere.g10code.de> <54E47EA6.4090208@vulcan.xs4all.nl> Message-ID: <87vbizgj7z.fsf@vigenere.g10code.de> On Wed, 18 Feb 2015 12:59, johanw at vulcan.xs4all.nl said: > The most easy solution in such cases is to try IPv4 first, if that > doesn't work or is unavailable, try IPv6 if available. That server has no v4 address. For obvious reasons we use the standard version first and only then fallback to a legacy IP version .-). > Non-working or misconfigured IPv6 setups are rather common, probably The problem is more that the all machines now have v6 enabled but no address configured. It is a bug in GnuPG's server selection code not to check whether a real v6 interface is up. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From daniele at grinta.net Wed Feb 18 19:46:19 2015 From: daniele at grinta.net (Daniele Nicolodi) Date: Wed, 18 Feb 2015 19:46:19 +0100 Subject: Unattended signing Message-ID: <54E4DDFB.1010405@grinta.net> Hello, I have a quite simple question on best practice for the use of GPG. I haven't found an answer searching online. I hope this mailing list is the right place for asking. I have an automated process that collects some data and unattended sends it via email. I want that data to be encrypted and signed. The encryption part is easy as it requires only public keys of the recipients. Signing, however, requires to make the private key used available to the process. I have a sufficient trust in the security of the server where the automated process runs, but I would like to reduce to a minimum the risks. What is the best practices in such cases? I can imagine several possible options: using a subkey of my key (is it possible to remove passphrase protection from a subkey?), using a dedicated key, using a subkey of a dedicated key and periodically rotate such subkey. Ideas? Comments? Thanks. Cheers, Daniele From wk at gnupg.org Wed Feb 18 19:51:46 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 18 Feb 2015 19:51:46 +0100 Subject: Talking about Cryptodevices... which one? In-Reply-To: <54C31A18.4040100@fsij.org> (NIIBE Yutaka's message of "Sat, 24 Jan 2015 13:05:44 +0900") References: <54C1BF3A.2040903@gmail.com> <87lhktldwz.fsf@alice.fifthhorseman.net> <54C31A18.4040100@fsij.org> Message-ID: <87r3tngiil.fsf@vigenere.g10code.de> On Sat, 24 Jan 2015 05:05, gniibe at fsij.org said: > DINSIG (DIN V 66291-1) card > German Geldkarte > Telesec NKS card > pkcs#15 card > SmartCard-HSM card > > ... but I think that most are outdated, except the last one. DINSIG is still German standard (actually a pre-standard) but I doubt that you can find any card. Vendors have all moved to their own standard. The Geldkarte ("Money-card") is a gadget which only allows you to check the amount of money left on the card. The telesec card still works, although I don't known about the availability. p15 cards also work as long as they fully comply to the pkcs#15 standard (only few do). > And when you use those devices, you should know that each application > has tendency to grab smartcard/token access exclusively. At least, Which makes the use of the card much faster. The PC/SC system is broken so that even Microsoft replaced it by a system similar to scdaemon (minidrivers). But don't let me start to rant about it again. > I don't use X.509 much. I think that it's easily possible for us to Neither me. That has all been done as part of a contract; now with the secured funding it would be possible to revive the X.509 support - iff there is a need for it. > OpenPGPcard (and its compatible) usually doesn't have any public keys > of higher layer, because of its limited storage. ... and because of the I/O speed - it would take long to read out keys with many key signatures. Those who need to use the German eHealth card know what I mean by slow. > purpose MCU. In my theory, using general purpose small MCU would be > superior to avoid malicious/fake hardware features by semiconductor > vendor. If it's very expensive hardware, specific for "crypto", there I agree. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From peter at digitalbrains.com Wed Feb 18 19:56:35 2015 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 18 Feb 2015 19:56:35 +0100 Subject: 2.1.2: keyserver route failure In-Reply-To: <54E4C6B6.5060306@vulcan.xs4all.nl> References: <54E2977C.106@sixdemonbag.org> <87wq3gpujn.fsf@vigenere.g10code.de> <54E3953F.2000909@sixdemonbag.org> <878ufvop8f.fsf@vigenere.g10code.de> <54E42223.9070307@sixdemonbag.org> <87bnkrla77.fsf@vigenere.g10code.de> <54E47EA6.4090208@vulcan.xs4all.nl> <54E4BE74.5050602@dougbarton.email> <54E4C6B6.5060306@vulcan.xs4all.nl> Message-ID: <54E4E063.5030100@digitalbrains.com> On 18/02/15 18:07, Johan Wevers wrote: > Admit it, IPv6 has failed. It may get some uses, but the widespread > adaptation of carrier NAT has made it largely obsolete. Tired as I may be of this discussion (what's your next argument, NAT provides beneficial firewalling behaviour?), I still wish to say that I will not "admit" IPv6 has failed or that IPv4 advancements[1] made it obsolete. Get off your soapbox. Peter. [1] I shudder to call NAT an advancement, but that's apparently how you present it. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From dkg at fifthhorseman.net Wed Feb 18 20:13:31 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 18 Feb 2015 14:13:31 -0500 Subject: 2.1.2: keyserver route failure In-Reply-To: <87bnkrla77.fsf@vigenere.g10code.de> References: <54E2977C.106@sixdemonbag.org> <87wq3gpujn.fsf@vigenere.g10code.de> <54E3953F.2000909@sixdemonbag.org> <878ufvop8f.fsf@vigenere.g10code.de> <54E42223.9070307@sixdemonbag.org> <87bnkrla77.fsf@vigenere.g10code.de> Message-ID: <87mw4bav8k.fsf@alice.fifthhorseman.net> On Wed 2015-02-18 06:40:12 -0500, Werner Koch wrote: > On Wed, 18 Feb 2015 06:24, rjh at sixdemonbag.org said: > >> I don't have IPv6 routing, period. This raises the question of why >> GnuPG is trying to reach an IPv6 address at all. > > Because the resolver tells that there is an AAAA record. It seems that > we need to figure out at runtime whether v6 is actually working. Any > hints on how to do that? Reasonable IPv6 stacks should return an ENETUNREACH (Network is unreachable) error message when trying to connect() to an address for which there is no route, which should already cause dirmngr to failover immediately. I'm not convinced that it's gnupg's job to compensate for unreasonably-configured IPv6 stacks that think they have a route but actually don't. Should gnupg also try to detect whether the IPv4 networking configuration is actually correct? That seems like an operating system level task. I certainly don't want all of my client software to always try to second-guess my netwoking stack, that sounds like a recipe for trouble. --dkg From dkg at fifthhorseman.net Wed Feb 18 20:24:52 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 18 Feb 2015 14:24:52 -0500 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: <54E4C1DF.3080601@dougbarton.email> References: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> <20150216235311.GA10680@athena.barrera.io> <87sie4pt9j.fsf@vigenere.g10code.de> <54E4C1DF.3080601@dougbarton.email> Message-ID: <87h9ujaupn.fsf@alice.fifthhorseman.net> On Wed 2015-02-18 11:46:23 -0500, Doug Barton wrote: > On 2/18/15 2:52 AM, Jonathan Schleifer wrote: >> Well, I guess you have to take into account that a lot of downloads >> are from packaging software like pkgsrc, FreeBSD ports, Gentoo >> portage, ArchLinux's makepkg, etc. Usually, these do download the >> signature and tarball once, verify it and then write a checksum to >> the Makefile / PKGBUILD / however it is called that is then >> verified. So I guess you can't easily map that to "Only x% of users >> check the downloaded tarball". I guess it's a lot more, it's just not >> all check it using the .sig. > > Back when I was involved with the FreeBSD project I included code in the > Makefile to verify the PGP signature for all of my ports that had one, > as did a few other maintainers. However there was not only not a > consensus to do this more generally, there was active opposition to > doing it at all. that's a bummer :( > If you are a FreeBSD user and believe that this would be something > beneficial to the ports system, please send them e-mail at > freebsd-ports at freebsd.org and let them know. :) In the Debian Project, we now have a simple framework for including upstream signing keys and automatically checking them when fetching new downloads: https://wiki.debian.org/debian/watch#Cryptographic_signature_verification If you see a debian package that could make use of this but isn't currently configured to do so, please file a bug report in the debian BTS (or drop me an e-mail). If it would help with arguing the case within FreeBSD to see how debian does it, i'm happy to talk with any FreeBSDers about it too. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From xavier at maillard.im Wed Feb 18 21:29:40 2015 From: xavier at maillard.im (Xavier Maillard) Date: Wed, 18 Feb 2015 21:29:40 +0100 Subject: Double sign a document In-Reply-To: <54E4386E.3020506@graffen.dk> References: <54E43682.3040107@graffen.dk> <54E4386E.3020506@graffen.dk> Message-ID: Hi Jesper, Jesper Hess Nielsen writes: >> gpg -u -u --clearsign keytransition.txt > >> keytransition.signed2 >> > > woops, forget about the '> keytransition.signed2' part. Just running > with --clearsign will give you a keytransition.txt.asc file > automatically. Thnaks for that Jesper. Just a quick question: do I need to have both keypairs in my keyring ? I mean both my old secret key and my new secret key. Regards -- Sent with my mu4e -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1534 bytes Desc: not available URL: From s.murthy at mykolab.com Wed Feb 18 21:48:46 2015 From: s.murthy at mykolab.com (Sandeep Murthy) Date: Wed, 18 Feb 2015 20:48:46 +0000 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: References: <68F2AA9B-B192-4727-9AA3-2BC33CBE5434@mykolab.com> Message-ID: <4B2A99DD-4D03-48D2-9163-E65D00DD905D@mykolab.com> Hi I do think your key fingerprint should be made more visible on gpgtools.org and it would be a good idea to have instructions for users to do the checksum and verify the signature of the dmg (there are probably lots of people who don?t even know how to do checksums). Sandeep Murthy s.murthy at mykolab.com > On 17 Feb 2015, at 21:32, Lukas Pitschl wrote: > > Hi all, > > since we?ve only now subscribed to the gnupg-users list, unfortunately we can?t reply to the correct message in the thread. > > First off we?d like to apologize for not reacting sooner to this issue. We only today became aware of it, when we received a message on our support platform (thanks Sandeep), and later a comment on Github (thanks Hugo) regarding the affected line of code. > > While we?re responding to all mail and discussions opened on our support platform, we don?t keep track of Twitter regularly. Some days we see everything going on there and respond immediately and other days we don't check Twitter at all, so unfortunately it's possible that important messages remain unseen. > > The best way to reach us is either our support platform at https://gpgtools.tenderapp.com or team at gpgtools.org. > > The code that checks out our GPGTools_Core repository is pretty old already and it?s certainly a stupid way to do it. > At the time we assumed that it was safe to check it out via ssl from github, since curl would refuse to do so if there was a certificate error. Passing it directly to bash is definitely a bad idea. > We?ve discussed this internally and decided on removing the automated checkout completely. > By making it a manual task, everyone can checkout the code and verify that it?s in fact the code they wanted to checkout. > We will also look through our build system and check for similar code if there is. > > To address the "Modify source code to allow non-sensical 8192 bit keys" mentioned by Villa: in the past we were too quick to give in to user requests without first researching the side-effects that could be caused by this. > The ?non-sensical 8192 bit keys? is one instance. It was requested by a few users and a quick ?fix?. We?ve seen that homebrew did the same and decided to add this option. We believed if some users wanted this option, we should not hinder them. > Unfortunately to this day, there still seems to be a lot of disagreement (not on the gnupg list, but other blogs / places on the internet) on whether such a key size makes sense or not. We?ve recently been accused again of "knowlingly lowering the overall security? [1] by not allowing such a key size. > We?re still not sure what to do about it exactly. > > In regards to the fix of PCSC on Yosemite, this is a quick workaround which currently works ?well enough?, but we?re still waiting to hear from more users if it?s really fixed. Once it is, we?ll be certain to discuss it on gnupg-devel. > > We?ve been wanting for a while now to discuss our few patches with the gnupg-devel list in order to push them upstream or find a different solution, but unfortunately have been struggling to find time to do that. We also believe that providing gnupg as is on OS X would be the way to go. > > To clarify some info posted on this thread about "GPGTools going commercial?: we will only charge a fee for GPGMail, the rest of GPG Suite will remain free. The source code will also remain open and on Github. > It's true we sometimes failed to keep it up to date in the past, but we're committed to make sure that it stays current with new releases. > > We really appreciate any feedback and try to address any concerns as quickly as possible. As already mentioned above, it's not always possible for us to keep track of Twitter, so the best way to reach us is via email or our support platform. > > Best, > > Lukas, Steve, Mento > GPGTools > > [1] http://support.gpgtools.org/discussions/feedback/1132-8k-key-generation-via-keychain-access#comment_35220287 > > Am 17.02.2015 um 20:58 schrieb Sandeep Murthy : > >> I would also add that if you agree that more people should >> be using encryption in more forms then the way to go is >> to make it more more usable and user friendly (and at the >> moment the standard GnuPG version can?t exactly be described as >> that) then this is not an aspiration that should be described >> as dumb. What is probably dumb is the kind of purist attitude >> about the perfect Linux platform and how great it is to have >> the perfect GnuPG set up. >> >> I would bet that more people who?ve used tools like GPG Suite >> have taken up encryption than those exposed to the command >> line subtleties of GnuPG. Both can be used at the same time, >> as I do, you don?t have to choose between them. >> >> Sandeep Murthy >> s.murthy at mykolab.com >> >>> Begin forwarded message: >>> >>> Subject: Re: Please remove MacGPG from gnupg.org due to serious security concerns >>> From: Sandeep Murthy >>> Date: 17 February 2015 19:03:30 GMT >>> Cc: Martin Paljak >>> To: gnupg-users at gnupg.org >>> >>> I suppose if you were conceited enough to describe yourself >>> as a ?power user? then you might be dumb enough to think >>> that people who use GPG Suite are ?dumb users?. >>> >>> Platform fanatics and those make an easy job of caricaturing >>> themselves in their fanaticism for a ?pure setup?, which is an >>> illusion. In the real world every system can be compromised >>> and no can have such a setup, no matter how hard you try. >>> >>> You don?t have to choose between OS X and Linux, there are >>> lots of people who use both. >>> >>> I have both GnuPG and GPG Suite, and I use both when I have >>> to. As a user, not a developer on MacGPG, the issues previously >>> raised here about the remote execution of scripts etc. may be >>> questionable, but they do not directly affect my use of the software, >>> which is nothing but a front end for GnuPG. >>> >>> The GPG plug-in for Apple Mail is not without its shortcomings but >>> it is incredibly easy to use and works well the other components >>> of the GPG suite. I have not used Enigmail, but it?s simply a >>> question of choice. >>> >>> Sandeep Murthy >>> s.murthy at mykolab.com >>> >>>> On 17 Feb 2015, at 16:31, Martin Paljak wrote: >>>> >>>> On Tue, Feb 17, 2015 at 6:00 PM, Ville M??tt? >>>> wrote: >>>>> Instead they should use upstream and contribute the minimal amount of wrappers or fixes upstream. Case in point: Has the fix for gpg-agent / scdaemon hang been discussed upstream at all [4], [5]? In MacGPG there is still ../libexec/gnupg-pcsc-wrapper which has been modified in commit f4c3e1bb to fix the issues of scdaemon hanging in Yosemite [6]. GnuPG proper has removed it in bc6b45 [7]. How would one go about fixing this issue for upstream? Has GPGTools contributed anything regarding this other than the initial discussion[8] about the issue? Upstream still does have the issue which now seems to have been fixed in the fork but in a binary removed from upstream? >>>> >>>> >>>> Not sure about overall GnuPG affection with Apple or other closed >>>> source software, but the PC/SC layer in Yosemite is broken (again): >>>> >>>> http://ludovicrousseau.blogspot.fr/2014/12/os-x-yosemite-and-smart-cards-known-bugs.html >>>> >>>> Generally speaking, I think the GPGTools folks care about "usage for >>>> dumbusers" which means making stuff Work(tm) for the not-so-powerusers >>>> on a not-so-great platform. It is the users's choice to use OSX (not >>>> Linux), the same way it is their choice to use Mail.app (not Enigmail) >>>> the same way it is their choice to use a simple to use binary >>>> installer with crappy build machinery instead of verifying the >>>> checksums of every download. >>>> >>>>> So, *"official website for gpg on OS X"* according to this user critical of making discontinuation of a free version. >>>> >>>> GnuPG just got a huge sum of money, I'm sure arrangements can be made >>>> to allocate some of that for a easy to use and *free* OSX version with >>>> an integrated GUI ? >>>> >>>>> Another: GPGTools support site has a certificate mismatch [14]. WTF is a *.tenderapp.com cert doing here? >>>> >>>> Because that site is run by Tender and if you connect to the https >>>> version, you get their site? Probably makes sense to bug Tender with >>>> this. >>>> >>>> >>>> So, generally speaking: if the upstream has not catered to the OSX >>>> folks and somebody on the internet has, I would not blame GPGTools >>>> guys for doing it. Yes, it would be nice if one at least tried to >>>> contribute back to upstream and to work in an open manner, but at >>>> least they DO something, for what there is apparent need. >>>> >>>> Martin >>>> >>>> _______________________________________________ >>>> Gnupg-users mailing list >>>> Gnupg-users at gnupg.org >>>> http://lists.gnupg.org/mailman/listinfo/gnupg-users >>> >> >> _______________________________________________ >> Gnupg-users mailing list >> Gnupg-users at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-users > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 873 bytes Desc: Message signed with OpenPGP using GPGMail URL: From neal at walfield.org Wed Feb 18 21:36:24 2015 From: neal at walfield.org (Neal H. Walfield) Date: Wed, 18 Feb 2015 21:36:24 +0100 Subject: GNUPG 2.* and AIX - questions In-Reply-To: References: Message-ID: <87k2zfaref.wl%neal@walfield.org> At Sun, 15 Feb 2015 12:16:58 +0100, Michael Felt wrote: > My key question is about the difference between v1.X and v2.X - are there > security elements in v2 that are missing/weaker in v1 - or are the > differences mainly that v2 supports/is always GUI while v1 is always CLI. gpg2 is a more extensible rewrite of gpg classic. gpg2 supports some crypto algorithms that gpg does not support (e.g., ECC starting with version 2.1). gpg2 is still for the CLI and makes some CLI operations easier than gpg. > The first wall I run into with gnupg-2.0.26 is that it wants gnu threads - > so, the question is: is there something inherently wrong with POSIX > threads, or even specifically with AIX pthreads that configure does not > attempt to use them (by default). npth uses cooperative threading rather than preemptive threading. This has the advantage of simplifying code: if you don't explicitly yield (or use a function that yields), then you can't be preempted. This can significantly reduce synchronization bugs. Neal From mailinglisten at hauke-laging.de Wed Feb 18 22:49:54 2015 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Wed, 18 Feb 2015 22:49:54 +0100 Subject: Double sign a document In-Reply-To: References: <54E4386E.3020506@graffen.dk> Message-ID: <6143978.jS9ZTdej7d@inno> Am Mi 18.02.2015, 21:29:40 schrieb Xavier Maillard: > Jesper Hess Nielsen writes: > >> gpg -u -u --clearsign keytransition.txt > > >> keytransition.signed2 > > > > woops, forget about the '> keytransition.signed2' part. Just running > > with --clearsign will give you a keytransition.txt.asc file > > automatically. > > Thnaks for that Jesper. > > Just a quick question: do I need to have both keypairs in my keyring > ? I mean both my old secret key and my new secret key. Of course. Would be strange if you could make a signature without the respective secret key. Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 603 bytes Desc: This is a digitally signed message part. URL: From mailing-lists at asatiifm.net Wed Feb 18 23:00:29 2015 From: mailing-lists at asatiifm.net (=?utf-8?Q?Ville_M=C3=A4=C3=A4tt=C3=A4?=) Date: Thu, 19 Feb 2015 00:00:29 +0200 Subject: 2.1.2: keyserver route failure In-Reply-To: <87mw4bav8k.fsf@alice.fifthhorseman.net> References: <54E2977C.106@sixdemonbag.org> <87wq3gpujn.fsf@vigenere.g10code.de> <54E3953F.2000909@sixdemonbag.org> <878ufvop8f.fsf@vigenere.g10code.de> <54E42223.9070307@sixdemonbag.org> <87bnkrla77.fsf@vigenere.g10code.de> <87mw4bav8k.fsf@alice.fifthhorseman.net> Message-ID: <1C67B82D-5C50-46D6-8EE3-94BD8AA12BD9@asatiifm.net> > On 18 Feb 2015, at 21:13, Daniel Kahn Gillmor wrote: > > I'm not convinced that it's gnupg's job to compensate for > unreasonably-configured IPv6 stacks that think they have a route but > actually don?t. I agree. I think the actual problem should be addressed at the networking level instead of adding logic to GnuPG. -- Ville From johanw at xs4all.nl Wed Feb 18 20:31:36 2015 From: johanw at xs4all.nl (Johan Wevers) Date: Wed, 18 Feb 2015 20:31:36 +0100 Subject: 2.1.2: keyserver route failure In-Reply-To: <54E4E063.5030100@digitalbrains.com> References: <54E2977C.106@sixdemonbag.org> <87wq3gpujn.fsf@vigenere.g10code.de> <54E3953F.2000909@sixdemonbag.org> <878ufvop8f.fsf@vigenere.g10code.de> <54E42223.9070307@sixdemonbag.org> <87bnkrla77.fsf@vigenere.g10code.de> <54E47EA6.4090208@vulcan.xs4all.nl> <54E4BE74.5050602@dougbarton.email> <54E4C6B6.5060306@vulcan.xs4all.nl> <54E4E063.5030100@digitalbrains.com> Message-ID: <54E4E898.1070905@xs4all.nl> On 18-02-2015 19:56, Peter Lebbing wrote: >> Admit it, IPv6 has failed. It may get some uses, but the widespread >> adaptation of carrier NAT has made it largely obsolete. > Tired as I may be of this discussion (what's your next argument, NAT provides > beneficial firewalling behaviour?), I still wish to say that I will not "admit" > IPv6 has failed or that IPv4 advancements[1] made it obsolete. Get off your soapbox. I didn't claim that one version was better than another version, I said it will probably never become widespread. Just like Linux on the desktop is only a small niche player, and windows phone on the smartphone market. Wether I like that or not and which system is best doesn't change anything. -- Met vriendelijke groet, Johan Wevers From mailing-lists at asatiifm.net Wed Feb 18 22:56:45 2015 From: mailing-lists at asatiifm.net (=?utf-8?Q?Ville_M=C3=A4=C3=A4tt=C3=A4?=) Date: Wed, 18 Feb 2015 23:56:45 +0200 Subject: 2.1.2: keyserver route failure In-Reply-To: <54E4C6B6.5060306@vulcan.xs4all.nl> References: <54E2977C.106@sixdemonbag.org> <87wq3gpujn.fsf@vigenere.g10code.de> <54E3953F.2000909@sixdemonbag.org> <878ufvop8f.fsf@vigenere.g10code.de> <54E42223.9070307@sixdemonbag.org> <87bnkrla77.fsf@vigenere.g10code.de> <54E47EA6.4090208@vulcan.xs4all.nl> <54E4BE74.5050602@dougbarton.email> <54E4C6B6.5060306@vulcan.xs4all.nl> Message-ID: > On 18 Feb 2015, at 19:07, Johan Wevers wrote: > > Admit it, IPv6 has > failed. It may get some uses, but the widespread adaptation of carrier > NAT has made it largely obsolete. Utter, complete, nonsense. -- Ville From 2014-667rhzu3dc-lists-groups at riseup.net Thu Feb 19 02:15:59 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Thu, 19 Feb 2015 01:15:59 +0000 Subject: MIME or inline signature ? [OT] In-Reply-To: <20150217061318.3cd64936@scorpio> References: <20150213081425.7a418830@scorpio> <681480546.20150214143935@my_localhost> <1736159995.20150217001626@my_localhost> <20150217061318.3cd64936@scorpio> Message-ID: <17210692876.20150219011559@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Tuesday 17 February 2015 at 11:13:18 AM, in , Jerry wrote: > That is the reason I detest INLINE as opposed to > PGP/MIME. You detest pgp-inline for the main reason I prefer it. Wouldn't life be boring if we all liked the same things? > The insertion of superfluous garbage in the > message body is annoying to say the least. Given all the corporate non-sense footers "requiring" us to telepathically know whether or not the sender meant to include us in the circulation list and to delete it without reading if the answer is "No", most email users are well-practised at ignoring anything that seems irrelevant. > Worse, since > most users have no concept of "trimming" a message > before replying to it, I tend to find those poor unfortunates usually top-post, so all the extraneous content is off-screen below their message. But so is anything that could give context to their pearls of wisdom. > even more useless garbage is > transmitted when replied to, thus killing more innocent > electrons Presumably this virtual massacre adds to the virtual problem of global warming. > and wasting bandwidth Those of us on a metered connection would be with you all the way. Except that HTML emails are a far bigger bandwidth-hog. > not to mention the > consumption of screen territory. I find that my screen territory all comes back when I delete the email. - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net Free advice costs nothing until you act upon it -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJU5TlQXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwnLoH/3CJk6q9XrgNeam+izDL0tvH ZdOvUuNjj9qsu1qP5BDTYBWiKE9mMxN4b5RwRFKvPJYrwwd+Q4Bp8zLbskZzUJi6 bsP/XC2loU/7cpFUdMECRglxbKZtC0vYD2L0pabolBehkHXFKiK5ppHN3TOo0RKI x6fd3d9T8iFhtkWY1cs6vva/AGZIBuwyovQYwdjBuNoaxMTiz/c2Wc11wMjnmhQQ 6I4/Pt+wgl2e6VUphm/6fVgbFmV6OxJb1hIsBHpPdW74MiK2IY42MlsHdURjGrsk a8Q12DYE2IVO4Nad4S7l2lHDi1S8sikp0OXu5ApFzKAtMtGPFSWV3DYCBKq1zBaI vgQBFgoAZgUCVOU5Xl8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45A0mAQAarb8UhID55PQN+Xa9t1aA+q5o Cd8mL9gQmt7A3hDEDQEAsqfT2P7Qe5XnOifp+PS8k4LnOpbn1Z1iJWNmXgabzgg= =xgmS -----END PGP SIGNATURE----- From 2014-667rhzu3dc-lists-groups at riseup.net Thu Feb 19 02:31:30 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Thu, 19 Feb 2015 01:31:30 +0000 Subject: Double sign a document In-Reply-To: References: <54E43682.3040107@graffen.dk> <54E4386E.3020506@graffen.dk> Message-ID: <1024252665.20150219013130@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Wednesday 18 February 2015 at 8:29:40 PM, in , Xavier Maillard wrote: > Just a quick question: do I need to have both keypairs > in my keyring ? I mean both my old secret key and my > new secret key. To sign, yes. To check the signatures you would just need both public keys. - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net During an eruption - move away from the volcano - not towards it -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJU5TzyXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwhMoIAL3XmuF4NiiDC3Cpt9AwZOy1 NSl/Hblwq0Syv36jZkiqxvFK8etQPm/v2oKjdvQ7pqlBccxmtl15pYWBQgJ/KmK6 K9ALUyPqEyuxeW+b6vl1/6ZoSV+XJJZl3alg4FFI1RN0ZkixXaPL0dnZgX2j40Q0 pce4ss/ZlBxQOL7qzAkoobPr2OfZo72l0cuJdltwTbKAQnUMyFBedRX2aqIiDXHV E33Ip7BixMKNMrL3QGPiWRqCM4AJX4/GUxD3RS+wnNWVVmhT2QfA0HLZayTUjt1N tisL1F54C6TDlIjTfjPUSx1EOUGZIA0InxEZZN546G/IIj2PLr53q3/Vc6inDNuI vgQBFgoAZgUCVOU8+F8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45FuoAQBAizU7Cwj8FN94YWowNY5a1TIZ ox/OWzaq35fGigWwTwEADCz3Nj4XopZeNYF26E+qh0xJOmUpeMgFLQI+4YNmqgE= =24p4 -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Thu Feb 19 03:30:31 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 18 Feb 2015 21:30:31 -0500 Subject: 2.1.2: keyserver route failure In-Reply-To: <54E4E898.1070905@xs4all.nl> References: <54E2977C.106@sixdemonbag.org> <87wq3gpujn.fsf@vigenere.g10code.de> <54E3953F.2000909@sixdemonbag.org> <878ufvop8f.fsf@vigenere.g10code.de> <54E42223.9070307@sixdemonbag.org> <87bnkrla77.fsf@vigenere.g10code.de> <54E47EA6.4090208@vulcan.xs4all.nl> <54E4BE74.5050602@dougbarton.email> <54E4C6B6.5060306@vulcan.xs4all.nl> <54E4E063.5030100@digitalbrains.com> <54E4E898.1070905@xs4all.nl> Message-ID: <54E54AC7.8050305@sixdemonbag.org> > I didn't claim that one version was better than another version, I > said it will probably never become widespread. It already *is* widespread. China and Japan have signed onto it in a big way. In the US, the largest wireless carrier -- Verizon -- has migrated over a third of its smartphones to IPv6, and plans to migrate the rest in the next few years. The largest Aussie telecom firm, Telstra, is 100% dual-stacked. 22% of Deutsche Telekom DSL customers are on IPv6 and they're migrating mobile devices to IPv6 this summer. IPv6 adoption is largely invisible, but it's picking up worldwide. From rjh at sixdemonbag.org Thu Feb 19 06:07:55 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 19 Feb 2015 00:07:55 -0500 Subject: 2.1.2: keyserver route failure In-Reply-To: <87mw4bav8k.fsf@alice.fifthhorseman.net> References: <54E2977C.106@sixdemonbag.org> <87wq3gpujn.fsf@vigenere.g10code.de> <54E3953F.2000909@sixdemonbag.org> <878ufvop8f.fsf@vigenere.g10code.de> <54E42223.9070307@sixdemonbag.org> <87bnkrla77.fsf@vigenere.g10code.de> <87mw4bav8k.fsf@alice.fifthhorseman.net> Message-ID: <54E56FAB.3050701@sixdemonbag.org> > I'm not convinced that it's gnupg's job to compensate for > unreasonably-configured IPv6 stacks that think they have a route but > actually don't. Nor am I, but the world has never much cared whether something was my job: it concerns itself more with ensuring there are consequences for the job going undone. At the very least, if we're not going to address the problem we should (a) reach out to Apple about the problem and (b) document for OS X users that GnuPG's keyserver functionality may be broken on that platform. From dougb at dougbarton.email Thu Feb 19 07:23:07 2015 From: dougb at dougbarton.email (Doug Barton) Date: Wed, 18 Feb 2015 22:23:07 -0800 Subject: 2.1.2: keyserver route failure In-Reply-To: <54E56FAB.3050701@sixdemonbag.org> References: <54E2977C.106@sixdemonbag.org> <87wq3gpujn.fsf@vigenere.g10code.de> <54E3953F.2000909@sixdemonbag.org> <878ufvop8f.fsf@vigenere.g10code.de> <54E42223.9070307@sixdemonbag.org> <87bnkrla77.fsf@vigenere.g10code.de> <87mw4bav8k.fsf@alice.fifthhorseman.net> <54E56FAB.3050701@sixdemonbag.org> Message-ID: <54E5814B.6030403@dougbarton.email> It was not my intention to start an IPv6 advocacy thread, but in case anyone is interested in facts about the current state of things, this is a good summary: http://www.slideshare.net/AkamaiTechnologies/edge-2014-ipv6-is-here-what-you-need-to-know From ranjinihk at tyfone.com Thu Feb 19 05:53:52 2015 From: ranjinihk at tyfone.com (Ranjini H.K) Date: Thu, 19 Feb 2015 10:23:52 +0530 Subject: Help need to use truecryt + openpgp applet. Message-ID: Hi all, Am trying to implement disk encryption/decryption using truecrypt with security token support. I have a java card with openPGP applet loaded on to it. Inspite of configuring truecrypt to use the security token, its not finding it and notififng me with an error saying : security token error "FUNCTION NOT SUPPORTED ". Please help me with this. Regards, Ranjini HK Software Engineer - Tyfone, Inc. Bangalore www.tyfone.com Mobile: +91-9886262192 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Thu Feb 19 08:28:14 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 19 Feb 2015 02:28:14 -0500 Subject: Help need to use truecryt + openpgp applet. In-Reply-To: References: Message-ID: <54E5908E.5070804@sixdemonbag.org> > Please help me with this. Unfortunately, we really can't. GnuPG is written in C, not Java, so it's unlikely your OpenPGP applet uses GnuPG. You might have better luck on a mailing list for the applet you're using. From wk at gnupg.org Thu Feb 19 09:10:57 2015 From: wk at gnupg.org (Werner Koch) Date: Thu, 19 Feb 2015 09:10:57 +0100 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: <87h9ujaupn.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 18 Feb 2015 14:24:52 -0500") References: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> <20150216235311.GA10680@athena.barrera.io> <87sie4pt9j.fsf@vigenere.g10code.de> <54E4C1DF.3080601@dougbarton.email> <87h9ujaupn.fsf@alice.fifthhorseman.net> Message-ID: <87d256gw32.fsf@vigenere.g10code.de> On Wed, 18 Feb 2015 20:24, dkg at fifthhorseman.net said: >> as did a few other maintainers. However there was not only not a >> consensus to do this more generally, there was active opposition to >> doing it at all. > > that's a bummer :( I guess that is a GPL issue. They don't want any GPLed stuff for the core. However, there are other implementations and in particular a signature verification tool is pretty simple. It might even make sense to write one stripped down for the Ed25519 signature verification. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ranjinihk at tyfone.com Thu Feb 19 09:23:03 2015 From: ranjinihk at tyfone.com (Ranjini H.K) Date: Thu, 19 Feb 2015 13:53:03 +0530 Subject: Help need to use truecryt + openpgp applet. In-Reply-To: References: Message-ID: Thanks Pete Stephenson. Yes my java card supports PKCS#11. Am not so sure about OpenPGP applet. What should i do othercase To make my OpenPGP applet support PKCS#11. Ranjini HK Software Engineer - Tyfone, Inc. Bangalore www.tyfone.com Mobile: +91-9886262192 On Thu, Feb 19, 2015 at 1:46 PM, Pete Stephenson wrote: > On Thu, Feb 19, 2015 at 5:53 AM, Ranjini H.K wrote: > > Hi all, > > > > Am trying to implement disk encryption/decryption using truecrypt with > > security token support. I have a java card with openPGP applet loaded on > to > > it. Inspite of configuring truecrypt to use the security token, its not > > finding it and notififng me with an error saying : security token error > > "FUNCTION NOT SUPPORTED ". > > Considering the way it was abandoned by its developers, TrueCrypt is > probably not the best choice going forward. > > That said, TrueCrypt only supports smartcards that use PKCS #11 > libraries. Does the JavaCard you're using support PKCS #11? Does the > OpenPGP applet? > > -- > Pete Stephenson > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pete at heypete.com Thu Feb 19 09:16:29 2015 From: pete at heypete.com (Pete Stephenson) Date: Thu, 19 Feb 2015 09:16:29 +0100 Subject: Help need to use truecryt + openpgp applet. In-Reply-To: References: Message-ID: On Thu, Feb 19, 2015 at 5:53 AM, Ranjini H.K wrote: > Hi all, > > Am trying to implement disk encryption/decryption using truecrypt with > security token support. I have a java card with openPGP applet loaded on to > it. Inspite of configuring truecrypt to use the security token, its not > finding it and notififng me with an error saying : security token error > "FUNCTION NOT SUPPORTED ". Considering the way it was abandoned by its developers, TrueCrypt is probably not the best choice going forward. That said, TrueCrypt only supports smartcards that use PKCS #11 libraries. Does the JavaCard you're using support PKCS #11? Does the OpenPGP applet? -- Pete Stephenson From wk at gnupg.org Thu Feb 19 11:03:01 2015 From: wk at gnupg.org (Werner Koch) Date: Thu, 19 Feb 2015 11:03:01 +0100 Subject: 2.1.2: keyserver route failure In-Reply-To: <87mw4bav8k.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 18 Feb 2015 14:13:31 -0500") References: <54E2977C.106@sixdemonbag.org> <87wq3gpujn.fsf@vigenere.g10code.de> <54E3953F.2000909@sixdemonbag.org> <878ufvop8f.fsf@vigenere.g10code.de> <54E42223.9070307@sixdemonbag.org> <87bnkrla77.fsf@vigenere.g10code.de> <87mw4bav8k.fsf@alice.fifthhorseman.net> Message-ID: <87y4nufcbu.fsf@vigenere.g10code.de> On Wed, 18 Feb 2015 20:13, dkg at fifthhorseman.net said: > Reasonable IPv6 stacks should return an ENETUNREACH (Network is > unreachable) error message when trying to connect() to an address for > which there is no route, which should already cause dirmngr to failover The error handler after a connect does this: switch (gpg_err_code (err)) { case GPG_ERR_ECONNREFUSED: case GPG_ERR_ENETUNREACH: case GPG_ERR_UNKNOWN_HOST: case GPG_ERR_NETWORK: if (mark_host_dead (request) && *tries_left) retry = 1; break; By setting RETRY the connect will be retried after selecting another random host. However tehre is a retry limit of 3. Thus if we happen to select 3 v6 hosts the keyserver action will fail but the next time it should work. Need to replicate the problem and check that we really receive the right error code. > Should gnupg also try to detect whether the IPv4 networking > configuration is actually correct? That seems like an operating system Better error reporting would be useful, though. > level task. I certainly don't want all of my client software to always > try to second-guess my netwoking stack, that sounds like a recipe for dirmngr is a bit special in that it does its own host selection from the DNS pool instead of leaving it to the usual round-robin scheme. We want that to recover from host failures without waiting for the resolver cache to expire. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Feb 19 11:41:28 2015 From: wk at gnupg.org (Werner Koch) Date: Thu, 19 Feb 2015 11:41:28 +0100 Subject: GNUPG 2.* and AIX - questions In-Reply-To: (Michael Felt's message of "Sun, 15 Feb 2015 12:16:58 +0100") References: Message-ID: <87k2zefajr.fsf@vigenere.g10code.de> On Sun, 15 Feb 2015 12:16, aixtools at gmail.com said: > I took the hint and tried to package gnu/nth but make fails - immediately - > with this message. You might find something about this in bugs.gnupg.org. I have not tried gnupg 2.0.x on AIX for many years thus it is quite possible that you run into problems, possible due to newer AIX versions. However, GnuPG 2.1 builds and works fine on AIX. I even test it from time to time. Thus instead of settling on 2.0 you may want to jump directly jump from 1.4 to 2.1. 2.0 will be maintained for some times but probably not more than two years from now. > p.s. please forgive the cross post to @devel - not sure which is the best > list for this question. Both make sense ;-) Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From errol at askerrol.org Thu Feb 19 12:01:14 2015 From: errol at askerrol.org (Errol Casey) Date: Thu, 19 Feb 2015 06:01:14 -0500 Subject: Compiled binaries execute but exit with "Abort" In-Reply-To: <87a90bjmzl.fsf@vigenere.g10code.de> References: <874mqjooyl.fsf@vigenere.g10code.de> <87a90bjmzl.fsf@vigenere.g10code.de> Message-ID: Thanks. Now to figure out why make check fails but make works without error. Are there dependencies besides pth for libgpg-error? make check-TESTS bash: line 5: 11699 Abort (core dumped) ${dir}$tst FAIL: t-version Unspecified source: Success gcrypt: Invalid length specifier in S-expression GnuPG: Unknown packet GpgSM: Certificate too young GPG Agent: Bad CA certificate Pinentry: Operation cancelled SCD: Card removed GPGME: Bad secret key Keybox: Unknown error code bash: line 5: 11708 Abort (core dumped) ${dir}$tst FAIL: t-strerror bash: line 5: 11714 Abort (core dumped) ${dir}$tst FAIL: t-syserror bash: line 5: 11719 Abort (core dumped) ${dir}$tst FAIL: t-lock bash: line 5: 11724 Abort (core dumped) ${dir}$tst FAIL: t-printf ====================================== 5 of 5 tests failed Please report to http://bugs.gnupg.org ====================================== *** Error code 1 On Wed, Feb 18, 2015 at 9:46 AM, Werner Koch wrote: > On Wed, 18 Feb 2015 14:18, errol at askerrol.org said: > > > #0 0xfedc28a4 in abort () from /lib/libc.so.1 > > #1 0xff15367c in get_lock_object (lockhd=0xff16e3b0) at posix-lock.c:111 > > That is an assert() checking that the used library matches the one used > for building. This is all in libgpg-error - please build libgpg-error > and check that "make check" works. > > > Shalom-Salam, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > -- Errol Casey errol at askerrol.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From ricul77 at gmail.com Thu Feb 19 13:33:06 2015 From: ricul77 at gmail.com (Richard Ulrich) Date: Thu, 19 Feb 2015 13:33:06 +0100 Subject: Help need to use truecryt + openpgp applet. In-Reply-To: References: Message-ID: <1424349186.8443.20.camel@gmail.com> Hi Ranjini, Does it have to be truecrypt? LUKS works very well with OpenPGP SmartCards or JavaApplets implementing it (e.g. YubiKey NEO). Just follow the steps in this blog post: https://blog.kumina.nl/2010/07/two-factor-luks-using-ubuntu Rgds Richard Am Donnerstag, den 19.02.2015, 13:53 +0530 schrieb Ranjini H.K: > Thanks Pete Stephenson. > Yes my java card supports PKCS#11. Am not so sure about OpenPGP applet. > What should i do othercase To make my OpenPGP applet support PKCS#11. > > Ranjini HK > > Software Engineer - Tyfone, Inc. > > Bangalore > www.tyfone.com > > Mobile: +91-9886262192 > > On Thu, Feb 19, 2015 at 1:46 PM, Pete Stephenson wrote: > > > On Thu, Feb 19, 2015 at 5:53 AM, Ranjini H.K wrote: > > > Hi all, > > > > > > Am trying to implement disk encryption/decryption using truecrypt with > > > security token support. I have a java card with openPGP applet loaded on > > to > > > it. Inspite of configuring truecrypt to use the security token, its not > > > finding it and notififng me with an error saying : security token error > > > "FUNCTION NOT SUPPORTED ". > > > > Considering the way it was abandoned by its developers, TrueCrypt is > > probably not the best choice going forward. > > > > That said, TrueCrypt only supports smartcards that use PKCS #11 > > libraries. Does the JavaCard you're using support PKCS #11? Does the > > OpenPGP applet? > > > > -- > > Pete Stephenson > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part URL: From js-gnupg-users at webkeks.org Thu Feb 19 18:15:32 2015 From: js-gnupg-users at webkeks.org (Jonathan Schleifer) Date: Thu, 19 Feb 2015 18:15:32 +0100 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: <8761azjmif.fsf@vigenere.g10code.de> References: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> <20150216235311.GA10680@athena.barrera.io> <87sie4pt9j.fsf@vigenere.g10code.de> <8761azjmif.fsf@vigenere.g10code.de> Message-ID: <1FDC39EC-8080-46D7-99E0-E78F9785269D@webkeks.org> Am 18.02.2015 um 15:57 schrieb Werner Koch : >> git commit -S >> >> You can just create an alias for that, I for example use git ci. > > I know that but I would like to have a different key for tag and commit. > Requiring an option is just too cumbersome. I don't really see how that is cumbersome if you have an alias for tag and for commit that each specify the key you want? As an aside, what's the reason for not signing the commits with the key on the card? I sign all my commits with the key stored on my Gnuk. What is kinda annoying though is if you set commit.gpgsign = true, as it will then even sign git stash etc. and ask you to enter the PIN all the time. Which is why I have an alias git ci for git commit -S, as I only want to sign commits, not temporary state. -- Jonathan From js-gnupg-users at webkeks.org Thu Feb 19 18:16:45 2015 From: js-gnupg-users at webkeks.org (Jonathan Schleifer) Date: Thu, 19 Feb 2015 18:16:45 +0100 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: <87sie3i7kb.fsf@vigenere.g10code.de> References: <68F2AA9B-B192-4727-9AA3-2BC33CBE5434@mykolab.com> <87sie3i7kb.fsf@vigenere.g10code.de> Message-ID: Am 18.02.2015 um 16:05 schrieb Werner Koch : > I also do this often to avoid cluttering the screen. No need to assume > a backdoor. It is for a Mac and Mac users want a clean tty ;-) I also like @ to hide useless output, but is downloading *and executing* from a remote location really something you should hide? Especially if everything else isn't hidden? -- Jonathan From ott at mirix.org Thu Feb 19 18:22:42 2015 From: ott at mirix.org (Matthias-Christian Ott) Date: Thu, 19 Feb 2015 18:22:42 +0100 Subject: Help need to use truecryt + openpgp applet. In-Reply-To: References: Message-ID: <54E61BE2.30305@mirix.org> On 2015-02-19 09:23, Ranjini H.K wrote: > Yes my java card supports PKCS#11. Am not so sure about OpenPGP applet. > What should i do othercase To make my OpenPGP applet support PKCS#11. Your Java Card does probably not support PKCS #11. An applet on the card might implement it. To make it work, you need a PKCS #11 middleware and tell TrueCrypt about it (Settings > Security Tokens... > PKCS #11 Library Path). If you are using an applet that is supported by OpenSC, you can use OpenSC. Otherwise you have to resort to the proprietary middleware supplied by the vendor. OpenPGP cards should be supported by OpenSC and should be usable with TrueCrypt [1]. There is also a proprietary PKCS #11 library that should provide a PKCS #11 interface for OpenPGP cards [2]. Otherwise you can try Scute [3]. That said, it is probably better to ask on the OpenSC mailing list [4] about PKCS #11. The Java Card OpenPGP applet seems to be maintained by Yubico at the moment [5]. Regards, Matthias-Christian [1] https://github.com/OpenSC/OpenSC/issues/125 [2] http://smartcard-auth.de/download-de.html [3] http://www.scute.org/ [4] http://sourceforge.net/p/opensc/mailman/ [5] https://github.com/Yubico/ykneo-openpgp From peter at digitalbrains.com Thu Feb 19 18:31:14 2015 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 19 Feb 2015 18:31:14 +0100 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: References: <68F2AA9B-B192-4727-9AA3-2BC33CBE5434@mykolab.com> <87sie3i7kb.fsf@vigenere.g10code.de> Message-ID: <48c92342ece9a4e2f30b3f382523ed72@butters.digitalbrains.com> On 2015-02-19 18:16, Jonathan Schleifer wrote: > I also like @ to hide useless output, but is downloading *and > executing* from a remote location really something you should hide? > Especially if everything else isn't hidden? I can understand you're pretty darn pissed off that they executed untrusted remote code on your computer, which, I think, explains why you're "lashing out" so strongly. And I also think that it was truly poorly designed. But I find your quest for bad faith on their part a bit far fetched... Never attribute to malice that which is adequately explained by stupidity.[1][2] By now, you should probably cool down a bit. I'd say you've made your point. Peter. [1] https://en.wikipedia.org/wiki/Hanlon%27s_razor ; apparently after Robert J. Hanlon, not Hansen ;P [2] Although with security software, a bit of healthy paranoia can be warranted, IMHO. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From mailing-lists at asatiifm.net Thu Feb 19 19:11:52 2015 From: mailing-lists at asatiifm.net (=?windows-1252?Q?Ville_M=E4=E4tt=E4?=) Date: Thu, 19 Feb 2015 20:11:52 +0200 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: References: <68F2AA9B-B192-4727-9AA3-2BC33CBE5434@mykolab.com> Message-ID: <54E62768.8070903@asatiifm.net> On 17.02.15 23:32, Lukas Pitschl wrote: > The best way to reach us is either our support platform at https://gpgtools.tenderapp.com or team at gpgtools.org. Ok, that link explains the certificate and it makes more sense. I can see you've already changed at least the first link to the support site on the front page. Great. -- Ville -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 648 bytes Desc: OpenPGP digital signature URL: From mailing-lists at asatiifm.net Thu Feb 19 19:41:23 2015 From: mailing-lists at asatiifm.net (=?UTF-8?B?VmlsbGUgTcOkw6R0dMOk?=) Date: Thu, 19 Feb 2015 20:41:23 +0200 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: <87vbizn6ad.fsf@vigenere.g10code.de> References: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> <87oaospsum.fsf@vigenere.g10code.de> <8CBC97E5-C896-4989-814D-45E67C9014CF@asatiifm.net> <87vbizn6ad.fsf@vigenere.g10code.de> Message-ID: <54E62E53.7030608@asatiifm.net> On 18.02.15 07:21, Werner Koch wrote: >> > command line tools. *I think there is no more reason to develop >> > MacGPG*, i.e. a port, anymore. Let the port die. > Can you briefly explain how Patrick's new installer [1] is related to that? > Would it be an option to use that as the core for gpgtools? > > [1] https://sourceforge.net/p/gpgosx/docu/Download/ > I haven't tried Patrick's installer but it should be a fine option as the core. The Mail plug-in should work just fine with 2.1 like it works with upstream 2.0.* builds. I'm not aware of any specific need for MacGPG in that regard. Same goes for the other little helpers. The things that would require a little changing are the launchd templates that are used to start gpg-agent et al. I've been using my own templates already before and with 2.1 it's even simpler as per the changes to related gpg-agent. This sort of a script is not even necessary unless one needs SSH support which I do. I've attached my new template here. I know, that's a lot of /shoulds/ :). There is an existing ticket [1] for MacGPG upgrade to 2.1 and it links to a couple of their support request [2] [3], one of them mentions the need to /"first have to adapt our library which is responsible for communicating with the gnupg binary"/. Lukas, maybe you could comment on the other tools' dependencies with MacGPG, if any. [1]: https://gpgtools.lighthouseapp.com/projects/66001/tickets/142-update-to-gnupg-21 [2]: https://gpgtools.tenderapp.com/discussions/problems/29108-gnupg-21-ecc-is-now-in-stable [3]: https://gpgtools.tenderapp.com/discussions/suggestions/150-gnupg-21-modern-for-mac -- Ville -------------- next part -------------- A non-text attachment was scrubbed... Name: com.ruriat.gpgagent.plist Type: text/xml Size: 659 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 648 bytes Desc: OpenPGP digital signature URL: From mailing-lists at asatiifm.net Thu Feb 19 19:53:30 2015 From: mailing-lists at asatiifm.net (=?UTF-8?B?VmlsbGUgTcOkw6R0dMOk?=) Date: Thu, 19 Feb 2015 20:53:30 +0200 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: <87vbizn6ad.fsf@vigenere.g10code.de> References: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> <87oaospsum.fsf@vigenere.g10code.de> <8CBC97E5-C896-4989-814D-45E67C9014CF@asatiifm.net> <87vbizn6ad.fsf@vigenere.g10code.de> Message-ID: <54E6312A.5030408@asatiifm.net> On 18.02.15 07:21, Werner Koch wrote: >> wrappers or fixes upstream. Case in point: Has the fix for gpg-agent / >> > scdaemon hang been discussed upstream at all [4], [5]? In MacGPG there >> > is still ../libexec/gnupg-pcsc-wrapper which has been modified in >> > commit f4c3e1bb to fix the issues of scdaemon hanging in Yosemite >> > [6]. GnuPG proper has removed it in bc6b45 [7]. How would one go about > I just tried to figure out what this is about. The problem description > is pretty clear but I can't easliy find a description of the solution. > I don't think this has been discussed upstream. > > Right, in 2.1 there is no more need for the pcsc-wrapper because we > switched from Pth to native threads (wrapped by the ntph library). > Yep, unfortunately it would appear the same or identical issue does occur with a speedo build of 2.1.2. The issue is essentially that smartcard works for the first time but once some-indeterminate-time has passed, gpg just hangs. No pinentry, nothing just happens. /Will need to troubleshoot this further on 2.1.2 to try to find out more./ >> fixing this issue for upstream? Has GPGTools contributed anything >> regarding this other than the initial discussion[8] about the issue? > > There was no followup on my answer. As we all now mailing lists are a > primary source to evaluate problems and thus it is usually a good idea > to post the found or not-found solution. I think we might want to move some of this discussion to gnupg-devel side at some point. -- Ville -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 648 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Thu Feb 19 20:00:24 2015 From: wk at gnupg.org (Werner Koch) Date: Thu, 19 Feb 2015 20:00:24 +0100 Subject: Help need to use truecryt + openpgp applet. In-Reply-To: <54E61BE2.30305@mirix.org> (Matthias-Christian Ott's message of "Thu, 19 Feb 2015 18:22:42 +0100") References: <54E61BE2.30305@mirix.org> Message-ID: <87bnkpd8vr.fsf@vigenere.g10code.de> On Thu, 19 Feb 2015 18:22, ott at mirix.org said: > Your Java Card does probably not support PKCS #11. An applet on the card > might implement it. To make it work, you need a PKCS #11 middleware and PKCS#11 is an API between two applications. It is not directly related to smartcards. However, it is very common that the smart card driver software (on the host) provides an PKCS#11 interface towards applications. (Scute can be considered a smartcard card driver software.) PKCS#15 is a standard which some cards implement and what OpenPSC is mostly about. PKCS#15 is for cards what FHS (Filesystem Hierarchy Standard) is for Linux. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Feb 19 20:08:17 2015 From: wk at gnupg.org (Werner Koch) Date: Thu, 19 Feb 2015 20:08:17 +0100 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: <1FDC39EC-8080-46D7-99E0-E78F9785269D@webkeks.org> (Jonathan Schleifer's message of "Thu, 19 Feb 2015 18:15:32 +0100") References: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> <20150216235311.GA10680@athena.barrera.io> <87sie4pt9j.fsf@vigenere.g10code.de> <8761azjmif.fsf@vigenere.g10code.de> <1FDC39EC-8080-46D7-99E0-E78F9785269D@webkeks.org> Message-ID: <877fvdd8im.fsf@vigenere.g10code.de> On Thu, 19 Feb 2015 18:15, js-gnupg-users at webkeks.org said: > I don't really see how that is cumbersome if you have an alias for tag > and for commit that each specify the key you want? Because it is too easy to forget about it. And I would need to teag Magit. I started to use a new key for commits. Let's hope that I don't forget to tag the releases with the other key. > As an aside, what's the reason for not signing the commits with the > key on the card? I sign all my commits with the key stored on my Because I have to enter the PIN everytime (right, I do this on purpose), the RSA signatures a long, and I do not keep my signing key card inserted all the time. In fact I have to walk out of the office to pick it up. Using a on-disk for commits is okay because it only serves the purpose to assert that the commit was done on one of my machines. If that machine has been compromised all kind of things can be manipulated and thus it does the extra protection a smartcard gives is not useful. Shalom-Salam, Werner ps. Here is the key I started to use for commits. pub ed25519/E3FDFF218E45B72B 2015-02-18 [expires: 2025-02-15] Key fingerprint = C1D3 4B69 219E 4AEE C0BA 1C21 E3FD FF21 8E45 B72B uid [ unknown] Werner Koch (wheatstone commit signing) -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 180 bytes Desc: not available URL: From wk at gnupg.org Thu Feb 19 20:10:37 2015 From: wk at gnupg.org (Werner Koch) Date: Thu, 19 Feb 2015 20:10:37 +0100 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: (Jonathan Schleifer's message of "Thu, 19 Feb 2015 18:16:45 +0100") References: <68F2AA9B-B192-4727-9AA3-2BC33CBE5434@mykolab.com> <87sie3i7kb.fsf@vigenere.g10code.de> Message-ID: <873861d8eq.fsf@vigenere.g10code.de> On Thu, 19 Feb 2015 18:16, js-gnupg-users at webkeks.org said: > I also like @ to hide useless output, but is downloading *and > executing* from a remote location really something you should hide? > Especially if everything else isn't hidden? Okay, someone please write a noscript extension for the loader ;-) Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From mailing-lists at asatiifm.net Thu Feb 19 20:18:04 2015 From: mailing-lists at asatiifm.net (=?UTF-8?B?VmlsbGUgTcOkw6R0dMOk?=) Date: Thu, 19 Feb 2015 21:18:04 +0200 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: <8F2638C2-DBB8-4079-A1FA-A8720887B687@webkeks.org> References: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> <87oaospsum.fsf@vigenere.g10code.de> <8CBC97E5-C896-4989-814D-45E67C9014CF@asatiifm.net> <8F2638C2-DBB8-4079-A1FA-A8720887B687@webkeks.org> Message-ID: <54E636EC.7060500@asatiifm.net> On 18.02.15 13:05, Jonathan Schleifer wrote: >> > Upstream still does have the issue which now seems to have been fixed in the fork but in a binary removed from upstream? > I really can not confirm this. I am running vanilla GnuPG 2.1.2 (built from source) on Yosemite (10.10.2 to be exact) with a Gnuk without any problems. Previously I was running brewed 2.0.26. And now I've experienced the similar issue with a speedo build of 2.1.2. There's still definately something going awry but I'll need to do some more testing to find out more. I'm using the FSFE card and the issue is a hang when it should be asking for PIN. > I suppose it might be a good idea to have a Qt GUI. I kinda had that in mind :). QT 4 is going out of support very soon, i.e. sometime this year. Surely someone from the KDE / larger community using pinentry-qt4 has been working on a QT 5 version of pinentry? -- Ville -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 648 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Thu Feb 19 20:31:03 2015 From: wk at gnupg.org (Werner Koch) Date: Thu, 19 Feb 2015 20:31:03 +0100 Subject: Compiled binaries execute but exit with "Abort" In-Reply-To: (Errol Casey's message of "Thu, 19 Feb 2015 06:01:14 -0500") References: <874mqjooyl.fsf@vigenere.g10code.de> <87a90bjmzl.fsf@vigenere.g10code.de> Message-ID: <8761axbsw8.fsf@vigenere.g10code.de> On Thu, 19 Feb 2015 12:01, errol at askerrol.org said: > Thanks. Now to figure out why make check fails but make works without > error. Are there dependencies besides pth for libgpg-error? Are you using a recent Pth version? I recall that older Pth versions had problems when used by programs which also make use of pthreads. That was actually the reasons for the pcsc-wrapper used by scdaemon. My tests indicated that there was no more problem - on Linux. However, this might be because glibc implements mutex directly and not in libpthread. Thus we may have the same conflict as we had with older glibc versions. A solution for you might be to go back to libgpg-error 1.12 which has no mutexes and thus no need for pthreads. I doubt that we can do a real fix for that. I dropped Pth support for a reason ;-). The only thing I can image is an environment variable forcing libgpg-error to entire disable the mutex support. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From js-gnupg-users at webkeks.org Thu Feb 19 20:29:43 2015 From: js-gnupg-users at webkeks.org (Jonathan Schleifer) Date: Thu, 19 Feb 2015 20:29:43 +0100 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: <877fvdd8im.fsf@vigenere.g10code.de> References: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> <20150216235311.GA10680@athena.barrera.io> <87sie4pt9j.fsf@vigenere.g10code.de> <8761azjmif.fsf@vigenere.g10code.de> <1FDC39EC-8080-46D7-99E0-E78F9785269D@webkeks.org> <877fvdd8im.fsf@vigenere.g10code.de> Message-ID: Am 19.02.2015 um 20:08 schrieb Werner Koch : > Because I have to enter the PIN everytime (right, I do this on purpose), > the RSA signatures a long, and I do not keep my signing key card > inserted all the time. In fact I have to walk out of the office to pick > it up. Another approach is to not sign them when working on it and only signing them before pushing using git rebase. I do agree that it's sometimes annoying to always plug it in and out again. > ps. Here is the key I started to use for commits. > > pub ed25519/E3FDFF218E45B72B 2015-02-18 [expires: 2025-02-15] > Key fingerprint = C1D3 4B69 219E 4AEE C0BA 1C21 E3FD FF21 8E45 B72B > uid [ unknown] Werner Koch (wheatstone commit signing) +1 for choosing Ed25519! (I did the same because I didn't want commits to be huge). As most keyservers still don't support Ed25519 keys, I guess it's worth pointing out that you can get the key with --keyserver keyserver.mattrude.com. Btw, does this mean that basically Ed25519 keys are stable enough now and won't change anymore? -- Jonathan From harningt at gmail.com Thu Feb 19 19:50:45 2015 From: harningt at gmail.com (Thomas Harning Jr.) Date: Thu, 19 Feb 2015 18:50:45 +0000 Subject: Help need to use truecryt + openpgp applet. References: <54E61BE2.30305@mirix.org> Message-ID: On Thu Feb 19 2015 at 12:23:34 PM Matthias-Christian Ott wrote: > On 2015-02-19 09:23, Ranjini H.K wrote: > > Yes my java card supports PKCS#11. Am not so sure about OpenPGP applet. > > What should i do othercase To make my OpenPGP applet support PKCS#11. > > Your Java Card does probably not support PKCS #11. An applet on the card > might implement it. To make it work, you need a PKCS #11 middleware and > tell TrueCrypt about it (Settings > Security Tokens... > PKCS #11 > Library Path). If you are using an applet that is supported by OpenSC, > you can use OpenSC. Otherwise you have to resort to the proprietary > middleware supplied by the vendor. OpenPGP cards should be supported by > OpenSC and should be usable with TrueCrypt [1]. There is also a > proprietary PKCS #11 library that should provide a PKCS #11 interface > for OpenPGP cards [2]. Otherwise you can try Scute [3]. > > That said, it is probably better to ask on the OpenSC mailing list [4] > about PKCS #11. > > The Java Card OpenPGP applet seems to be maintained by Yubico at the > moment [5]. > > Regards, > Matthias-Christian > > [1] https://github.com/OpenSC/OpenSC/issues/125 > [2] http://smartcard-auth.de/download-de.html > [3] http://www.scute.org/ > [4] http://sourceforge.net/p/opensc/mailman/ > [5] https://github.com/Yubico/ykneo-openpgp > The main issue is that TrueCrypt does not generate a key on-card, but instead it stores pin-protected data which it reads out when it needs to unlock the disk. OpenPGP cards, if I recall right, have no capability to store arbitrary data. Perhaps you can file a feature-request against VeraCrypt (the "current" TrueCrypt project) to implement a mechanism where the master key (or subkey of sorts) is encrypted with a key stored on-card. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rms at gnu.org Thu Feb 19 14:02:54 2015 From: rms at gnu.org (Richard Stallman) Date: Thu, 19 Feb 2015 08:02:54 -0500 Subject: GnuPG 2.0.27 "stable" released In-Reply-To: <87ioezi6gn.fsf@vigenere.g10code.de> (message from Werner Koch on Wed, 18 Feb 2015 16:29:12 +0100) References: <87ioezi6gn.fsf@vigenere.g10code.de> Message-ID: [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] Congratulations on the new release. -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! See stallman.org/skype.html. From ott at mirix.org Thu Feb 19 21:16:43 2015 From: ott at mirix.org (Matthias-Christian Ott) Date: Thu, 19 Feb 2015 21:16:43 +0100 Subject: Help need to use truecryt + openpgp applet. In-Reply-To: References: <54E61BE2.30305@mirix.org> Message-ID: <54E644AB.9020402@mirix.org> On 2015-02-19 19:50, Thomas Harning Jr. wrote: > On Thu Feb 19 2015 at 12:23:34 PM Matthias-Christian Ott > wrote: > >> On 2015-02-19 09:23, Ranjini H.K wrote: >>> Yes my java card supports PKCS#11. Am not so sure about OpenPGP applet. >>> What should i do othercase To make my OpenPGP applet support PKCS#11. >> >> Your Java Card does probably not support PKCS #11. An applet on the card >> might implement it. To make it work, you need a PKCS #11 middleware and >> tell TrueCrypt about it (Settings > Security Tokens... > PKCS #11 >> Library Path). If you are using an applet that is supported by OpenSC, >> you can use OpenSC. Otherwise you have to resort to the proprietary >> middleware supplied by the vendor. OpenPGP cards should be supported by >> OpenSC and should be usable with TrueCrypt [1]. There is also a >> proprietary PKCS #11 library that should provide a PKCS #11 interface >> for OpenPGP cards [2]. Otherwise you can try Scute [3]. >> >> That said, it is probably better to ask on the OpenSC mailing list [4] >> about PKCS #11. >> >> The Java Card OpenPGP applet seems to be maintained by Yubico at the >> moment [5]. >> >> Regards, >> Matthias-Christian >> >> [1] https://github.com/OpenSC/OpenSC/issues/125 >> [2] http://smartcard-auth.de/download-de.html >> [3] http://www.scute.org/ >> [4] http://sourceforge.net/p/opensc/mailman/ >> [5] https://github.com/Yubico/ykneo-openpgp >> > The main issue is that TrueCrypt does not generate a key on-card, but > instead it stores pin-protected data which it reads out when it needs to > unlock the disk. > > OpenPGP cards, if I recall right, have no capability to store arbitrary > data. You could store it in the private use data objects (0103, 0104). I look at both TrueCrypt's and OpenSC's source code. TrueCrypt uses PKCS #11 to find all private object with a matching label. OpenSC's PKCS #11 implementation in turn uses its PKCS #15 implementation to store objects. OpenSC's PKCS #15 driver for OpenPGP cards in turn does not handle data objects even if the card could store them. It doesn't look too difficult to implement this feature. Perhaps somebody will do it for you if ask on the OpenSC mailing list. Scute supports certificates only as well. > Perhaps you can file a feature-request against VeraCrypt (the "current" > TrueCrypt project) to implement a mechanism where the master key (or subkey > of sorts) is encrypted with a key stored on-card. I think this is impossible TrueCrypt derives keys from the password and then decrypts the header of the volume. There is no space to store encrypted key material. Regards, Matthias-Christian From ott at mirix.org Thu Feb 19 21:20:05 2015 From: ott at mirix.org (Matthias-Christian Ott) Date: Thu, 19 Feb 2015 21:20:05 +0100 Subject: Help need to use truecryt + openpgp applet. In-Reply-To: <87bnkpd8vr.fsf@vigenere.g10code.de> References: <54E61BE2.30305@mirix.org> <87bnkpd8vr.fsf@vigenere.g10code.de> Message-ID: <54E64575.8020505@mirix.org> On 2015-02-19 20:00, Werner Koch wrote: > On Thu, 19 Feb 2015 18:22, ott at mirix.org said: > >> Your Java Card does probably not support PKCS #11. An applet on the card >> might implement it. To make it work, you need a PKCS #11 middleware and > > PKCS#11 is an API between two applications. It is not directly related > to smartcards. However, it is very common that the smart card driver > software (on the host) provides an PKCS#11 interface towards > applications. (Scute can be considered a smartcard card driver > software.) > > PKCS#15 is a standard which some cards implement and what OpenPSC is > mostly about. PKCS#15 is for cards what FHS (Filesystem Hierarchy > Standard) is for Linux. I'm well aware of this. That why I wrote "middlware" instead of "driver". SoftHSM is a good example of a PKCS #11 middleware that is not a smartcard. Regards, Matthias-Christian From mail at rainerkeller.de Thu Feb 19 21:40:09 2015 From: mail at rainerkeller.de (Rainer Keller) Date: Thu, 19 Feb 2015 21:40:09 +0100 Subject: gpg-agent does not authenticate ssh connections In-Reply-To: <87k2zgprlr.fsf@vigenere.g10code.de> References: <2120060.4oWDU2pi9h@green.grummel.netz> <22607479.XnJ47iP72A@green.grummel.netz> <87k2zgprlr.fsf@vigenere.g10code.de> Message-ID: <1509529.HkZX2mFM6z@green.grummel.netz> > Gpg-agent uses the smartcard key which is identified by the $AUTHKEYID > attribute: > > $ gpg-connect-agent 'scd getattr $AUTHKEYID' /bye > S $AUTHKEYID OPENPGP.3 > OK I get the same output for my card. > Thus only the keys listed in ~/.gnupg/sshcontrol will be used. The keygrip from the card is listed in sshcontrol. > of course you need to make sure that the key is capable of signing. I created the key with authentication flag set. It has no other flags set. Just a general note, I did not do anything special. I just used "keytocard" to move the key over. But unfortunately it does not work out ouf the box afterwards. gpg --card-status Application ID ...: Version ..........: 2.0 Manufacturer .....: ZeitControl Serial number ....: Name of cardholder: Rainer Keller Language prefs ...: de Sex ..............: male URL of public key : [not set] Login data .......: [not set] Signature PIN ....: forced Key attributes ...: 2048R 2048R 4096R Max. PIN lengths .: 32 32 32 PIN retry counter : 3 0 3 Signature counter : 0 Signature key ....: [none] Encryption key....: [none] Authentication key: XXX created ....: XXX General key info..: pub 4096R/A7 2014 Rainer Keller sec# 4096R/D8 created: 2005 expires: never ssb 2048R/4C created: 2008 expires: 2010 ssb 2048R/CC created: 2008 expires: 2010 ssb 2048R/26 created: 2010 expires: 2012 ssb 2048R/B0 created: 2010 expires: 2012 ssb 2048R/A5 created: 2012 expires: 2014 ssb 2048R/09 created: 2012 expires: 2014 ssb 4096R/A9 created: 2014 expires: 2016 usage: S ssb 4096R/6F created: 2014 expires: 2016 usage: E ssb> 4096R/A7 created: 2014 expires: 2016 usage: A card-no: XXX Regards Rainer From mailing-lists at asatiifm.net Thu Feb 19 22:04:57 2015 From: mailing-lists at asatiifm.net (=?UTF-8?B?VmlsbGUgTcOkw6R0dMOk?=) Date: Thu, 19 Feb 2015 23:04:57 +0200 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: <54E636EC.7060500@asatiifm.net> References: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> <87oaospsum.fsf@vigenere.g10code.de> <8CBC97E5-C896-4989-814D-45E67C9014CF@asatiifm.net> <8F2638C2-DBB8-4079-A1FA-A8720887B687@webkeks.org> <54E636EC.7060500@asatiifm.net> Message-ID: <54E64FF9.2060508@asatiifm.net> On 19.02.15 21:18, Ville M??tt? wrote: > Surely someone from the KDE / larger community > using pinentry-qt4 has been working on a QT 5 version of pinentry? Ok, found it :). Issue #1806 [1]. [1]: https://bugs.g10code.com/gnupg/issue1806 -- Ville -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 648 bytes Desc: OpenPGP digital signature URL: From gniibe at fsij.org Fri Feb 20 02:30:31 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 20 Feb 2015 10:30:31 +0900 Subject: gpg-agent does not authenticate ssh connections In-Reply-To: <2120060.4oWDU2pi9h@green.grummel.netz> References: <2120060.4oWDU2pi9h@green.grummel.netz> Message-ID: <54E68E37.1030501@fsij.org> On 02/09/2015 02:41 AM, Rainer Keller wrote: > In .gnupg/sshcontrol I have added the correct keygrip and "ssh-add -l" shows > the right key: > >> 4096 XX:XX:XX cardno:XXXX (RSA) Well, you don't need to add this manually, for your smartcard. >> gpg-agent smartcard signing failed: Bad PIN > > It sounds like the PIN entered was wrong, but I am sure it is correct. > The PIN retry counters are still at 3. One possibility is that it's gpg-agent which says "Bad PIN". The gpg-agent does its own check for pin length. OpenPGPcard specification requires minimum length of user's PIN to be 6. gpg-agent checks if it's at least 6. If not, it returns "Bad PIN" error. It is not possible for OpenPGP card to have user's PIN with length of less than 6. Your user's PIN would be the factory default still. -- From rjh at sixdemonbag.org Fri Feb 20 03:41:58 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 19 Feb 2015 21:41:58 -0500 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: <48c92342ece9a4e2f30b3f382523ed72@butters.digitalbrains.com> References: <68F2AA9B-B192-4727-9AA3-2BC33CBE5434@mykolab.com> <87sie3i7kb.fsf@vigenere.g10code.de> <48c92342ece9a4e2f30b3f382523ed72@butters.digitalbrains.com> Message-ID: <54E69EF6.7000006@sixdemonbag.org> > [1] https://en.wikipedia.org/wiki/Hanlon%27s_razor ; apparently > after Robert J. Hanlon, not Hansen ;P There are at least four guys in the security world named Robert Hansen; to make matters worse, some of us have spoken at the same conferences. My middle initial is only to distinguish me from the others; my friends just call me Rob. :) From ranjinihk at tyfone.com Fri Feb 20 06:32:13 2015 From: ranjinihk at tyfone.com (Ranjini H.K) Date: Fri, 20 Feb 2015 11:02:13 +0530 Subject: Help need to use truecryt + openpgp applet. In-Reply-To: <54E64575.8020505@mirix.org> References: <54E61BE2.30305@mirix.org> <87bnkpd8vr.fsf@vigenere.g10code.de> <54E64575.8020505@mirix.org> Message-ID: Yes i used Scute. No success with it. I better ask OpenSC mailing list with the help asking for the support for handle data objects even if the card could store them.. Ranjini HK Software Engineer - Tyfone, Inc. Bangalore www.tyfone.com Mobile: +91-9886262192 On Fri, Feb 20, 2015 at 1:50 AM, Matthias-Christian Ott wrote: > On 2015-02-19 20:00, Werner Koch wrote: > > On Thu, 19 Feb 2015 18:22, ott at mirix.org said: > > > >> Your Java Card does probably not support PKCS #11. An applet on the card > >> might implement it. To make it work, you need a PKCS #11 middleware and > > > > PKCS#11 is an API between two applications. It is not directly related > > to smartcards. However, it is very common that the smart card driver > > software (on the host) provides an PKCS#11 interface towards > > applications. (Scute can be considered a smartcard card driver > > software.) > > > > PKCS#15 is a standard which some cards implement and what OpenPSC is > > mostly about. PKCS#15 is for cards what FHS (Filesystem Hierarchy > > Standard) is for Linux. > > I'm well aware of this. That why I wrote "middlware" instead of > "driver". SoftHSM is a good example of a PKCS #11 middleware that is not > a smartcard. > > Regards, > Matthias-Christian > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dougb at dougbarton.email Fri Feb 20 07:00:52 2015 From: dougb at dougbarton.email (Doug Barton) Date: Thu, 19 Feb 2015 22:00:52 -0800 Subject: Help need to use truecryt + openpgp applet. In-Reply-To: References: Message-ID: <54E6CD94.4050106@dougbarton.email> On 2/19/15 12:16 AM, Pete Stephenson wrote: > Considering the way it was abandoned by its developers, TrueCrypt is > probably not the best choice going forward. We don't know the whole story about what happened there, so I would be hesitant to attribute malice. For some of us who need to have the same data accessible on multiple platforms there is not a better option. Doug From antony at blazrsoft.com Fri Feb 20 07:52:51 2015 From: antony at blazrsoft.com (Antony Prince) Date: Fri, 20 Feb 2015 06:52:51 +0000 Subject: Help need to use truecryt + openpgp applet. In-Reply-To: <54E6CD94.4050106@dougbarton.email> References: <54E6CD94.4050106@dougbarton.email> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On February 20, 2015 1:00:52 AM EST, Doug Barton wrote: >On 2/19/15 12:16 AM, Pete Stephenson wrote: > >> Considering the way it was abandoned by its developers, TrueCrypt is >> probably not the best choice going forward. > >We don't know the whole story about what happened there, so I would be >hesitant to attribute malice. For some of us who need to have the same >data accessible on multiple platforms there is not a better option. > >Doug > > >_______________________________________________ >Gnupg-users mailing list >Gnupg-users at gnupg.org >http://lists.gnupg.org/mailman/listinfo/gnupg-users I wasn't aware TrueCrypt had been abandoned. I also haven't visited their site for some time. That's a shame though. Its a useful piece of software. I hope someone continues in their footsteps. - -- Antony Prince Key ID: 0x4F040744 Fingerprint: FE96 5B7F A708 18D3 B74B 959F A6E1 6242 4F04 0744 URL: https://hkps.pool.sks-keyservers.net/pks/lookup?op=get&search=0xA6E162424F040744 -----BEGIN PGP SIGNATURE----- Version: APG v1.1.1 iQFCBAEBCAAsBQJU5tnDJRxBbnRvbnkgUHJpbmNlIDxhbnRvbnlAYmxhenJzb2Z0 LmNvbT4ACgkQpuFiQk8EB0RrjQgArr080em0l2sznMPMpmDGkB8PZs+v8eiPaJAj F8Qbgg2h04H1bpUGvOv6Mk5fJeqffBXs/3o6yr8MEqiVLGxXNGxLIuS2r0mEgT7Z 3RkR10R6hixPyEQZw6ysl9Mk1aVM8TZDPUHvdCtqUzOIWHIlWNUtmnW2GqurRS+B UhkqxV+4VAmriYx3GgZMbCAcokjIY++xTFYkLnVuRRpZWhWXo/OqhFRLQ+R7rDcH kODlTmjdCjlpqCq5GSyxWrhoXxY//+k6r4LT7Qw6Wq2mPjImyJNVvBGhtrj9u0He 8OVveL9LF1TxR4kOZBhDTPvLYmoOiM53ukLHAGA5wvwMixWfvA== =tySd -----END PGP SIGNATURE----- From wk at gnupg.org Fri Feb 20 09:03:50 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 20 Feb 2015 09:03:50 +0100 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: (Jonathan Schleifer's message of "Thu, 19 Feb 2015 20:29:43 +0100") References: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> <20150216235311.GA10680@athena.barrera.io> <87sie4pt9j.fsf@vigenere.g10code.de> <8761azjmif.fsf@vigenere.g10code.de> <1FDC39EC-8080-46D7-99E0-E78F9785269D@webkeks.org> <877fvdd8im.fsf@vigenere.g10code.de> Message-ID: <87d2559fh5.fsf@vigenere.g10code.de> On Thu, 19 Feb 2015 20:29, js-gnupg-users at webkeks.org said: > Btw, does this mean that basically Ed25519 keys are stable enough now and won't change anymore? I everything goes wrong, gpg will continue to support them if they don't make it into an RFC. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Feb 20 09:08:42 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 20 Feb 2015 09:08:42 +0100 Subject: Help need to use truecryt + openpgp applet. In-Reply-To: (Ranjini H. K.'s message of "Fri, 20 Feb 2015 11:02:13 +0530") References: <54E61BE2.30305@mirix.org> <87bnkpd8vr.fsf@vigenere.g10code.de> <54E64575.8020505@mirix.org> Message-ID: <878uft9f91.fsf@vigenere.g10code.de> On Fri, 20 Feb 2015 06:32, ranjinihk at tyfone.com said: > Yes i used Scute. No success with it. I better ask OpenSC mailing list with > the help asking for the support for handle data objects even if the card > could store them.. You may want to checkout https://gnupg.org/service.html to find help for fixing/adjusting Scute. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From mail at rainerkeller.de Fri Feb 20 09:31:39 2015 From: mail at rainerkeller.de (Rainer Keller) Date: Fri, 20 Feb 2015 09:31:39 +0100 Subject: gpg-agent does not authenticate ssh connections In-Reply-To: <54E68E37.1030501@fsij.org> References: <2120060.4oWDU2pi9h@green.grummel.netz> <54E68E37.1030501@fsij.org> Message-ID: <4240146.uWi14KpJk8@green.grummel.netz> Hi, thanks very much for your help, it works now. > It is not possible for OpenPGP card to have user's PIN with length of > less than 6. Your user's PIN would be the factory default still. You were right, my PIN had a length of 5 and was still set to factory default. After changing it all problems are gone. Maybe the error message should be improved a bit to tell the user what is really wrong. I don't remember completely but I don't think gnupg showed an error when setting the short PIN. From ndk.clanbo at gmail.com Fri Feb 20 09:32:45 2015 From: ndk.clanbo at gmail.com (NdK) Date: Fri, 20 Feb 2015 09:32:45 +0100 Subject: Whishlist for next-gen card Message-ID: <54E6F12D.40504@gmail.com> Hello all. What I'd like to see addressed in future card specifications: 1 - support for more keys (expired ENC keys, multiple signature keys) 2 - different PINs for different keys 3 - separate key for NFC auth (with its own optional PIN) 4 - HOTP PINs for signature/certification keys 5 - possibility to export private keys to user-certified devices 6 - support for out-of-band authorization (HW) 7 - support for more informative signing (requires a small display: HW) 3 to 6 should be under a "policy" object connected to the main key to make it public and let relying parties evaluate how much trust to give. Since smartcards have evolved (slowly...) and nowadays we have other much-less-constrained alternatives (GnuK), I feel that many limitations are just an heavy heritage that's becoming nonsensical. The reasons behind my list, point by point: 1 - I'd like to roll the key used for reading mail every year, but currently that would mean I'd have to use a new card every year or have old keys on-disk, defeating the purpose of using a smartcard/token (from my tests on actual smartcards, it's not hard to have room for 14 to 20 keys on an 80k smartcard, more than 30 on a 144k one, WAY more are possible on GnuK) 2 - If I have to use my card to login on a possibly untrusted computer, I don't want it to steal my PIN and sign/certify without me knowing it 3 - Since NFC readers often have no pinpad (or could have easily been tampered with) I don't want to expose my main PIN nor the same key I use for "wired" auth 4 - since HOTP changes at every use, it makes keyloggers nearly useless and gives a third factor to the auth process (might be combined by simple means -like digit-by-digit addition modulo 10- to the PIN) 5 - I know, it's debatable and many see it as dangerous... but is it more dangerous than keeping an on-disk (or on-paper) copy of the key? Key export should be protected by a "certificate" (policy object defines an "allowed KeyID for export" and the private key is exported only encrypted to that KeyID); might even set a "fuse" to mark the fact that the key have been exported 6 - like in Yubikey NEO, a physical button to authorize some operations can be useful (certification, signature, NFC PIN-less auth) 7 - malaware currently can replace the hash of the object being signed and the user can't know it till it's late... a small display could be used to report some metadata (file name type and size for signature, keyID and owner data for certification, peer ID for auth...) to give the user more feedback What do you think? Complete BS or could something be considered for inclusion? PS: 1 is the main reason I'm not yet using GPG much, even if I started using it since DOS & FIDO-BBSs era... BYtE, Diego. From pete at heypete.com Fri Feb 20 09:32:43 2015 From: pete at heypete.com (Pete Stephenson) Date: Fri, 20 Feb 2015 09:32:43 +0100 Subject: Help need to use truecryt + openpgp applet. In-Reply-To: <54E6CD94.4050106@dougbarton.email> References: <54E6CD94.4050106@dougbarton.email> Message-ID: On Fri, Feb 20, 2015 at 7:00 AM, Doug Barton wrote: > On 2/19/15 12:16 AM, Pete Stephenson wrote: > >> Considering the way it was abandoned by its developers, TrueCrypt is >> probably not the best choice going forward. > > We don't know the whole story about what happened there, so I would be > hesitant to attribute malice. For some of us who need to have the same data > accessible on multiple platforms there is not a better option. No malice implied. My apologies if I was unclear. I just feel that using publicly-abandoned security software, particularly when it hadn't been updated in the two years leading up to its abandonment and used old, crufty build dependencies[1] that hadn't been updated in decades, is probably unwise if one desires a high degree of security. Don't get me wrong: I really like TrueCrypt and think it was a great cross-platform disk encryption program that was remarkably easy to use, but using it as a part of new projects probably isn't a good idea. Cheers! -Pete [1] https://madiba.encs.concordia.ca/~x_decarn/truecrypt-binaries-analysis/ -- Pete Stephenson From lukele at gpgtools.org Fri Feb 20 10:29:33 2015 From: lukele at gpgtools.org (Lukas Pitschl) Date: Fri, 20 Feb 2015 10:29:33 +0100 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: <54E62E53.7030608@asatiifm.net> References: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> <87oaospsum.fsf@vigenere.g10code.de> <8CBC97E5-C896-4989-814D-45E67C9014CF@asatiifm.net> <87vbizn6ad.fsf@vigenere.g10code.de> <54E62E53.7030608@asatiifm.net> Message-ID: <3A25D3B5-4614-4353-80F4-EF5768C8DD55@gpgtools.org> > I haven't tried Patrick's installer but it should be a fine option as > the core. The Mail plug-in should work just fine with 2.1 like it works > with upstream 2.0.* builds. I'm not aware of any specific need for > MacGPG in that regard. Same goes for the other little helpers. > We also believe that gnupg 2.1 should work as is with our Mail plugin and our other applications, it also has some improvements we?ve currently added patches to, so we should be able to get rid of a lot of them. Unfortunately until now we?ve not had the time to look more closely into the changes of gnupg 2.1. It would be great if there?s an outline of the changes which might break backwards compatibility (if any). Following gnupg-devel I?ve read about --allow-loopback-pinentry, which sounded like our tools might need some adjustments in that area. > The things that would require a little changing are the launchd > templates that are used to start gpg-agent et al. I've been using my own > templates already before and with 2.1 it's even simpler as per the > changes to related gpg-agent. This sort of a script is not even > necessary unless one needs SSH support which I do. I've attached my new > template here. > Since gpg-agent was changed to be started on demand we?ve not been using any launchd scripts, as there no longer seems to be a need for them. > I know, that's a lot of /shoulds/ :). There is an existing ticket [1] > for MacGPG upgrade to 2.1 and it links to a couple of their support > request [2] [3], one of them mentions the need to /"first have to adapt > our library which is responsible for communicating with the gnupg > binary"/. Lukas, maybe you could comment on the other tools' > dependencies with MacGPG, if any. > There?s no direct dependency on MacGPG from the tools, since all the communication goes through our Libmacgpg framework. We have some users who are using homebrew?s gnupg or their own compiled version of gnupg and they?ve not run into major issues. One that was recently mentioned on our support platform is that pinentry doesn?t store pass phrases if used with homebrew?s gnupg, it does however if they?re using MacGPG2, so there still seem to be minor differences, but some that should be fixed rather easily. We?d be more than happy to work with gnupg-devel to get rid of our patches and build and distribute ?vanilla" gnupg. > [1]: > https://gpgtools.lighthouseapp.com/projects/66001/tickets/142-update-to-gnupg-21 > [2]: > https://gpgtools.tenderapp.com/discussions/problems/29108-gnupg-21-ecc-is-now-in-stable > [3]: > https://gpgtools.tenderapp.com/discussions/suggestions/150-gnupg-21-modern-for-mac > > -- > Ville > Best, Lukas GPGTools -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 236 bytes Desc: Message signed with OpenPGP using GPGMail URL: From lukele at gpgtools.org Fri Feb 20 10:38:43 2015 From: lukele at gpgtools.org (Lukas Pitschl) Date: Fri, 20 Feb 2015 10:38:43 +0100 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: <873861d8eq.fsf@vigenere.g10code.de> References: <68F2AA9B-B192-4727-9AA3-2BC33CBE5434@mykolab.com> <87sie3i7kb.fsf@vigenere.g10code.de> <873861d8eq.fsf@vigenere.g10code.de> Message-ID: <483FE4A0-C58E-44AB-AD78-EA5E1A80C8D1@gpgtools.org> We?ve started to rework our build system in a different branch on github. It no longer fetches any remote code and removes the dependency from GPGTools_Core, which was previously fetched. It?s not complete yet, but we?re actively working on it and updating one ?application? at a time. Am 19.02.2015 um 20:10 schrieb Werner Koch : > On Thu, 19 Feb 2015 18:16, js-gnupg-users at webkeks.org said: > >> I also like @ to hide useless output, but is downloading *and >> executing* from a remote location really something you should hide? >> Especially if everything else isn't hidden? > > Okay, someone please write a noscript extension for the loader ;-) > > > Salam-Shalom, > > Werner > > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users Best, Lukas GPGTools -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 236 bytes Desc: Message signed with OpenPGP using GPGMail URL: From lukele at gpgtools.org Fri Feb 20 10:59:25 2015 From: lukele at gpgtools.org (Lukas Pitschl) Date: Fri, 20 Feb 2015 10:59:25 +0100 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: <54E62768.8070903@asatiifm.net> References: <68F2AA9B-B192-4727-9AA3-2BC33CBE5434@mykolab.com> <54E62768.8070903@asatiifm.net> Message-ID: > Ok, that link explains the certificate and it makes more sense. I can > see you've already changed at least the first link to the support site > on the front page. Great. > Yes, we started on the website and changing it everywhere the old link is referenced. > -- > Ville > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 236 bytes Desc: Message signed with OpenPGP using GPGMail URL: From js-gnupg-users at webkeks.org Fri Feb 20 11:36:32 2015 From: js-gnupg-users at webkeks.org (Jonathan Schleifer) Date: Fri, 20 Feb 2015 11:36:32 +0100 Subject: Whishlist for next-gen card In-Reply-To: <54E6F12D.40504@gmail.com> References: <54E6F12D.40504@gmail.com> Message-ID: Am 20.02.2015 um 09:32 schrieb NdK : > 1 - support for more keys (expired ENC keys, multiple signature keys) And maybe for storing a certification key with a different PIN. > 5 - possibility to export private keys to user-certified devices That pretty much defeats the point of using a smart card in the first place. > 6 - like in Yubikey NEO, a physical button to authorize some operations > can be useful (certification, signature, NFC PIN-less auth) That would be a pretty useful thing, but require you to trust the card reader. This, however, would really make sense on the Gnuk and I guess you could even do that without changing the spec. -- Jonathan From js-gnupg-users at webkeks.org Fri Feb 20 11:42:04 2015 From: js-gnupg-users at webkeks.org (Jonathan Schleifer) Date: Fri, 20 Feb 2015 11:42:04 +0100 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: <483FE4A0-C58E-44AB-AD78-EA5E1A80C8D1@gpgtools.org> References: <68F2AA9B-B192-4727-9AA3-2BC33CBE5434@mykolab.com> <87sie3i7kb.fsf@vigenere.g10code.de> <873861d8eq.fsf@vigenere.g10code.de> <483FE4A0-C58E-44AB-AD78-EA5E1A80C8D1@gpgtools.org> Message-ID: <2786DC31-AEAC-4406-9143-94F32C74A644@webkeks.org> Great to see that you are planning on trying to bring things into shape so they can get upstreamed. Might I suggest that you start with pinentry? Currently, you import an old pinentry release and then build a lot of things around it. It would be really helpful if you could instead create a new subdirectory cocoa and do it like the other pinentries. That would allow to review it more easily (only the new directory needs to be reviewed) and would allow upstreaming it. I think that would be a lot more helpful than having a pinentry-mac fork. -- Jonathan From ndk.clanbo at gmail.com Fri Feb 20 14:27:33 2015 From: ndk.clanbo at gmail.com (NdK) Date: Fri, 20 Feb 2015 14:27:33 +0100 Subject: Whishlist for next-gen card In-Reply-To: References: <54E6F12D.40504@gmail.com> Message-ID: <54E73645.7020609@gmail.com> Il 20/02/2015 11:36, Jonathan Schleifer ha scritto: >> 1 - support for more keys (expired ENC keys, multiple signature keys) > And maybe for storing a certification key with a different PIN. Wasn't it covered by 2 - different PINs for different keys ? :) >> 5 - possibility to export private keys to user-certified devices > That pretty much defeats the point of using a smart card in the first place. That's not "uncontrolled export", and in fact such a feature is implemented in HSMs to avoid unsafe key generation (outside the HSM itself) *and* the risk of key loss. The idea is that *before* creating/importing the master key, you set the policy, including the key ID (or IDs) that can ask for key export. Once the master key gets created, you no longer can alter the policy. The policy should be exported together with the key and override the existing one while importing a key (so that you "can't" alter -actually it's just "really hard", but doing that should invalidate signatures on your master key!- the policy by exporting from a device and importing on another). >> 6 - like in Yubikey NEO, a physical button to authorize some operations >> can be useful (certification, signature, NFC PIN-less auth) > That would be a pretty useful thing, but require you to trust the card > reader. This, however, would really make sense on the Gnuk and I guess > you could even do that without changing the spec. Nope. it's possible to have (at least I've seen one: my father does have it!) smartcards with small displays, keyboards (1-2 keys could be enough, but a full 4x3 keypad would be awesome!) and even batteries/solar panels! The form factor is not the real problem. The problem is that it's quite a close and secretive market, heavily relying on security by obscurity (when I asked Yubikey how to access the "user presence" key from a Java appled, they answered I'd have had to contact NXP and sign an NDA! So no need to trust the card reader :) BYtE, Diego. From mailing-lists at asatiifm.net Fri Feb 20 15:30:28 2015 From: mailing-lists at asatiifm.net (=?windows-1252?Q?Ville_M=E4=E4tt=E4?=) Date: Fri, 20 Feb 2015 16:30:28 +0200 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: <2786DC31-AEAC-4406-9143-94F32C74A644@webkeks.org> References: <68F2AA9B-B192-4727-9AA3-2BC33CBE5434@mykolab.com> <87sie3i7kb.fsf@vigenere.g10code.de> <873861d8eq.fsf@vigenere.g10code.de> <483FE4A0-C58E-44AB-AD78-EA5E1A80C8D1@gpgtools.org> <2786DC31-AEAC-4406-9143-94F32C74A644@webkeks.org> Message-ID: <54E74504.2070105@asatiifm.net> On 20.02.15 12:42, Jonathan Schleifer wrote: > Might I suggest that you start with pinentry? Agreed. > It would be really helpful if you could instead create a new subdirectory cocoa and do it like the other pinentries. Oh yes, definitely agreed. Integrate the necessary changes to the upstream build of pinentry as just one more front end option. -- Ville -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 648 bytes Desc: OpenPGP digital signature URL: From mailing-lists at asatiifm.net Fri Feb 20 15:45:32 2015 From: mailing-lists at asatiifm.net (=?windows-1252?Q?Ville_M=E4=E4tt=E4?=) Date: Fri, 20 Feb 2015 16:45:32 +0200 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: <3A25D3B5-4614-4353-80F4-EF5768C8DD55@gpgtools.org> References: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> <87oaospsum.fsf@vigenere.g10code.de> <8CBC97E5-C896-4989-814D-45E67C9014CF@asatiifm.net> <87vbizn6ad.fsf@vigenere.g10code.de> <54E62E53.7030608@asatiifm.net> <3A25D3B5-4614-4353-80F4-EF5768C8DD55@gpgtools.org> Message-ID: <54E7488C.4000605@asatiifm.net> On 20.02.15 11:29, Lukas Pitschl wrote: > It would be great if there?s an outline of the changes which might break backwards compatibility (if any). From usage point of view: https://gnupg.org/faq/whats-new-in-2.1.html >> The things that would require a little changing are the launchd >> templates that are used to start gpg-agent et al. I've been using my own >> templates already before and with 2.1 it's even simpler as per the >> changes to related gpg-agent. This sort of a script is not even >> necessary unless one needs SSH support which I do. I've attached my new >> template here. >> > > Since gpg-agent was changed to be started on demand we?ve not been using any launchd scripts, as there no longer seems to be a need for them. > Well sure you do, with 2.0.* branch? At leasts the templates are being installed by the suite installer. The on-demand change is with 2.1. > since all the communication goes through our Libmacgpg framework. What is the need for Libmacgpg and its dependencies to MacGPG? I.e. why don't the tools just directly communicate with gpg-agent et al.? (Not including basic abstraction of functionality.) > One that was recently mentioned on our support platform is that pinentry doesn?t store pass phrases if used with homebrew?s gnupg, it does however if they?re using MacGPG2 Hmm, why would pinentry cache anything? I might be quite wrong but shouldn't gpg-agent be responsible for this? -- Ville -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 648 bytes Desc: OpenPGP digital signature URL: From mailing-lists at asatiifm.net Fri Feb 20 15:52:18 2015 From: mailing-lists at asatiifm.net (=?windows-1252?Q?Ville_M=E4=E4tt=E4?=) Date: Fri, 20 Feb 2015 16:52:18 +0200 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: References: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> <87oaospsum.fsf@vigenere.g10code.de> <8CBC97E5-C896-4989-814D-45E67C9014CF@asatiifm.net> <87vbizn6ad.fsf@vigenere.g10code.de> <54E6312A.5030408@asatiifm.net> Message-ID: <54E74A22.2070602@asatiifm.net> On 20.02.15 11:36, Lukas Pitschl wrote: >> No pinentry, nothing just happens. /Will need to >> > troubleshoot this further on 2.1.2 to try to find out more./ > We?ve noticed that the hang occurs in pcsc_get_status_change. Instead of receiving a timeout, it simply hangs forever, due to a bug in Yosemite?s PCSC implementation. And it happened again when sending one of the replies. Sending of email and gpg 2.1 process hanging around waiting for something. Killed /scdaemon/, sending of email failed with error, and on retry pinentry popped up and everything worked again. -- Ville -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 648 bytes Desc: OpenPGP digital signature URL: From mailing-lists at asatiifm.net Fri Feb 20 15:47:50 2015 From: mailing-lists at asatiifm.net (=?windows-1252?Q?Ville_M=E4=E4tt=E4?=) Date: Fri, 20 Feb 2015 16:47:50 +0200 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: References: <68F2AA9B-B192-4727-9AA3-2BC33CBE5434@mykolab.com> <87sie3i7kb.fsf@vigenere.g10code.de> <873861d8eq.fsf@vigenere.g10code.de> <483FE4A0-C58E-44AB-AD78-EA5E1A80C8D1@gpgtools.org> <2786DC31-AEAC-4406-9143-94F32C74A644@webkeks.org> <54E74504.2070105@asatiifm.net> Message-ID: <54E74916.9060003@asatiifm.net> On 20.02.15 16:44, Lukas Pitschl wrote: > Pinentry-mac is one project we?ve ?revived? and thus only added stuff on top of the old code instead of refactoring it. > We?ve been planning to do that for a long time now though, so we?ll definitely look into that and check out how other UIs do it, like GTK. And it might make sense to start clean with the premise of it being a front end like the others. -- Ville -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 648 bytes Desc: OpenPGP digital signature URL: From lukele at gpgtools.org Fri Feb 20 15:54:50 2015 From: lukele at gpgtools.org (Lukas Pitschl) Date: Fri, 20 Feb 2015 15:54:50 +0100 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: <54E7488C.4000605@asatiifm.net> References: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> <87oaospsum.fsf@vigenere.g10code.de> <8CBC97E5-C896-4989-814D-45E67C9014CF@asatiifm.net> <87vbizn6ad.fsf@vigenere.g10code.de> <54E62E53.7030608@asatiifm.net> <3A25D3B5-4614-4353-80F4-EF5768C8DD55@gpgtools.org> <54E7488C.4000605@asatiifm.net> Message-ID: <686BAB4A-1F5F-495D-9ABE-7DD7D035D64D@gpgtools.org> > > Well sure you do, with 2.0.* branch? At leasts the templates are being > installed by the suite installer. The on-demand change is with 2.1. > If I?m not mistaken it has been added in 2.0.24 or the like. The template for launchd is no longer installed by our installer. If it?s still on your system, it might not have been properly removed. >> since all the communication goes through our Libmacgpg framework. > > What is the need for Libmacgpg and its dependencies to MacGPG? I.e. why > don't the tools just directly communicate with gpg-agent et al.? (Not > including basic abstraction of functionality.) > Libmacgpg is similar to gpgme, but more friendly and easier to integrate for Objective-C projects. We communicate with the gnupg binary, which then invokes gpg-agent when necessary. >> One that was recently mentioned on our support platform is that pinentry doesn?t store pass phrases if used with homebrew?s gnupg, it does however if they?re using MacGPG2 > > Hmm, why would pinentry cache anything? I might be quite wrong but > shouldn't gpg-agent be responsible for this? > gpg-agent does the caching, but pinentry communicates with gpg-agent. We?ve not been able to look into the homebrew issue yet, so not sure why that?s not working properly there. Unless the users chooses to store their passphrase in OS X?s Keychain, then the lookup occurs directly in pinentry. (this is OS X only stuff, not sure if there?s something similar on Linux) > -- > Ville > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 236 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mailing-lists at asatiifm.net Fri Feb 20 16:07:12 2015 From: mailing-lists at asatiifm.net (=?windows-1252?Q?Ville_M=E4=E4tt=E4?=) Date: Fri, 20 Feb 2015 17:07:12 +0200 Subject: Whishlist for next-gen card In-Reply-To: <54E73645.7020609@gmail.com> References: <54E6F12D.40504@gmail.com> <54E73645.7020609@gmail.com> Message-ID: <54E74DA0.4080400@asatiifm.net> On 20.02.15 15:27, NdK wrote: >>> 5 - possibility to export private keys to user-certified devices >> > That pretty much defeats the point of using a smart card in the first place. > That's not "uncontrolled export", and in fact? > ?(snip)? > while importing a key (so that you "can't" alter -actually > it's just "really hard", but doing that should invalidate signatures on > your master key!- the policy by exporting from a device and importing on > another). > There in lies the problem. It's really hard -> it's doable. What is the use case that absolutely needs exportable master keys? -- Ville -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 648 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Fri Feb 20 16:45:06 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 20 Feb 2015 10:45:06 -0500 Subject: Help need to use truecryt + openpgp applet. In-Reply-To: References: <54E6CD94.4050106@dougbarton.email> Message-ID: <54E75682.90107@sixdemonbag.org> > I just feel that using publicly-abandoned security software, > particularly when it hadn't been updated in the two years leading up > to its abandonment and used old, crufty build dependencies[1] that > hadn't been updated in decades, is probably unwise if one desires a > high degree of security. People put a lot more faith in encrypted filesystems than perhaps they should. They're a great way to protect data against casual theft, but their track records against well-funded opponents are badly mixed. http://delogrand.blogspot.fi/2013/04/cyber-defense-exercise-2013-extracting.html From ndk.clanbo at gmail.com Fri Feb 20 17:21:57 2015 From: ndk.clanbo at gmail.com (NdK) Date: Fri, 20 Feb 2015 17:21:57 +0100 Subject: Whishlist for next-gen card In-Reply-To: <54E74DA0.4080400@asatiifm.net> References: <54E6F12D.40504@gmail.com> <54E73645.7020609@gmail.com> <54E74DA0.4080400@asatiifm.net> Message-ID: <54E75F25.2050906@gmail.com> Il 20/02/2015 16:07, Ville M??tt? ha scritto: >>>> 5 - possibility to export private keys to user-certified devices >>>> That pretty much defeats the point of using a smart card in the first place. >> That's not "uncontrolled export", and in fact? >> ?(snip)? >> while importing a key (so that you "can't" alter -actually >> it's just "really hard", but doing that should invalidate signatures on >> your master key!- the policy by exporting from a device and importing on >> another). > There in lies the problem. It's really hard -> it's doable. Yes, by someone who controls the trusted export key. On the other hand, current method to generate on a "secure" system and move to card makes it easy to lose control of the key. > What is the use case that absolutely needs exportable master keys? Safe key recovery in case sc gets damaged. With the current system you have to always generate new keys on the "secure system" and store the backup in a safe place that is *not* a smartcard. BYtE, Diego. From lukele at dressyvagabonds.com Fri Feb 20 10:36:22 2015 From: lukele at dressyvagabonds.com (Lukas Pitschl) Date: Fri, 20 Feb 2015 10:36:22 +0100 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: <54E6312A.5030408@asatiifm.net> References: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> <87oaospsum.fsf@vigenere.g10code.de> <8CBC97E5-C896-4989-814D-45E67C9014CF@asatiifm.net> <87vbizn6ad.fsf@vigenere.g10code.de> <54E6312A.5030408@asatiifm.net> Message-ID: > Yep, unfortunately it would appear the same or identical issue does > occur with a speedo build of 2.1.2. The issue is essentially that > smartcard works for the first time but once some-indeterminate-time has > passed, gpg just hangs. No pinentry, nothing just happens. /Will need to > troubleshoot this further on 2.1.2 to try to find out more./ We?ve noticed that the hang occurs in pcsc_get_status_change. Instead of receiving a timeout, it simply hangs forever, due to a bug in Yosemite?s PCSC implementation. In order to work around the hang, we?re running this call in a separate thread now, and if it doesn?t return within a few seconds (5 at the moment), it sends a timeout to the scdaemon. That fixed the issues for a lot of users, but there?s still one running into problems, yet it?s not entirely clear if that user?s problem is the same as this one. https://github.com/GPGTools/MacGPG2/blob/dev/Formula/Patches/gnupg2/pcsc-wrapper.patch > -- > Ville > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users Best, Lukas GPGTools -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 236 bytes Desc: Message signed with OpenPGP using GPGMail URL: From lukele at dressyvagabonds.com Fri Feb 20 11:48:15 2015 From: lukele at dressyvagabonds.com (Lukas Pitschl) Date: Fri, 20 Feb 2015 11:48:15 +0100 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: <2786DC31-AEAC-4406-9143-94F32C74A644@webkeks.org> References: <68F2AA9B-B192-4727-9AA3-2BC33CBE5434@mykolab.com> <87sie3i7kb.fsf@vigenere.g10code.de> <873861d8eq.fsf@vigenere.g10code.de> <483FE4A0-C58E-44AB-AD78-EA5E1A80C8D1@gpgtools.org> <2786DC31-AEAC-4406-9143-94F32C74A644@webkeks.org> Message-ID: Pinentry-mac is one project we?ve ?revived? and thus only added stuff on top of the old code instead of refactoring it. We?ve been planning to do that for a long time now though, so we?ll definitely look into that and check out how other UIs do it, like GTK. Best, Lukas GPGTools Am 20.02.2015 um 11:42 schrieb Jonathan Schleifer : > Great to see that you are planning on trying to bring things into shape so they can get upstreamed. > > Might I suggest that you start with pinentry? Currently, you import an old pinentry release and then build a lot of things around it. It would be really helpful if you could instead create a new subdirectory cocoa and do it like the other pinentries. That would allow to review it more easily (only the new directory needs to be reviewed) and would allow upstreaming it. I think that would be a lot more helpful than having a pinentry-mac fork. > > -- > Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 236 bytes Desc: Message signed with OpenPGP using GPGMail URL: From lukele at dressyvagabonds.com Fri Feb 20 15:44:17 2015 From: lukele at dressyvagabonds.com (Lukas Pitschl) Date: Fri, 20 Feb 2015 15:44:17 +0100 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: <54E74504.2070105@asatiifm.net> References: <68F2AA9B-B192-4727-9AA3-2BC33CBE5434@mykolab.com> <87sie3i7kb.fsf@vigenere.g10code.de> <873861d8eq.fsf@vigenere.g10code.de> <483FE4A0-C58E-44AB-AD78-EA5E1A80C8D1@gpgtools.org> <2786DC31-AEAC-4406-9143-94F32C74A644@webkeks.org> <54E74504.2070105@asatiifm.net> Message-ID: I?m not sure if my last emails made it through the list. Pinentry-mac is one project we?ve ?revived? and thus only added stuff on top of the old code instead of refactoring it. We?ve been planning to do that for a long time now though, so we?ll definitely look into that and check out how other UIs do it, like GTK. Best, Lukas GPGTools Am 20.02.2015 um 15:30 schrieb Ville M??tt? : > On 20.02.15 12:42, Jonathan Schleifer wrote: >> Might I suggest that you start with pinentry? > > Agreed. > >> It would be really helpful if you could instead create a new subdirectory cocoa and do it like the other pinentries. > > Oh yes, definitely agreed. Integrate the necessary changes to the > upstream build of pinentry as just one more front end option. > > -- > Ville > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 236 bytes Desc: Message signed with OpenPGP using GPGMail URL: From lukele at dressyvagabonds.com Fri Feb 20 15:49:07 2015 From: lukele at dressyvagabonds.com (Lukas Pitschl) Date: Fri, 20 Feb 2015 15:49:07 +0100 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: <54E74916.9060003@asatiifm.net> References: <68F2AA9B-B192-4727-9AA3-2BC33CBE5434@mykolab.com> <87sie3i7kb.fsf@vigenere.g10code.de> <873861d8eq.fsf@vigenere.g10code.de> <483FE4A0-C58E-44AB-AD78-EA5E1A80C8D1@gpgtools.org> <2786DC31-AEAC-4406-9143-94F32C74A644@webkeks.org> <54E74504.2070105@asatiifm.net> <54E74916.9060003@asatiifm.net> Message-ID: Am 20.02.2015 um 15:47 schrieb Ville M??tt? : > On 20.02.15 16:44, Lukas Pitschl wrote: >> Pinentry-mac is one project we?ve ?revived? and thus only added stuff on top of the old code instead of refactoring it. >> We?ve been planning to do that for a long time now though, so we?ll definitely look into that and check out how other UIs do it, like GTK. > > And it might make sense to start clean with the premise of it being a > front end like the others. > Agreed. > -- > Ville > Best, Lukas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 236 bytes Desc: Message signed with OpenPGP using GPGMail URL: From ott at mirix.org Sat Feb 21 03:01:51 2015 From: ott at mirix.org (Matthias-Christian Ott) Date: Sat, 21 Feb 2015 03:01:51 +0100 Subject: Help need to use truecryt + openpgp applet. In-Reply-To: References: <54E61BE2.30305@mirix.org> <87bnkpd8vr.fsf@vigenere.g10code.de> <54E64575.8020505@mirix.org> Message-ID: <54E7E70F.9070100@mirix.org> On 2015-02-20 06:32, Ranjini H.K wrote: > Yes i used Scute. No success with it. I better ask OpenSC mailing list with > the help asking for the support for handle data objects even if the card > could store them.. As mentioned in my more detailed follow-up email on how TrueCrypt accesses the "keyfile" on the smartcard, Scute is not able to do this. GnuPG however can access the (optional) private data objects on the card that could be used to store the "keyfile" on the card (as they are PIN protected). If I'm not mistaken, you should be able to add this to Scute through scdaemon and the GETATTR PRIVATE-DO-3 and SETATTR PRIVATE-DO-3 commands over scdaemon's Assuan protocol that you would have to map to the appropriate PKCS #11 in Scute (see TrueCrypt's source code for how it finds PKCS #11 objects on the card). That said, I doubt using the private DOs for PKCS #11 objects and associated metadata will be generally accepted (other people could be storing other data in these data objects), so you would probably have to add a compile-time option or maintain a fork. If you are trying to implement this as part of job/on behalf of your employer (guessing from your website and work email address that seems to be the case), I would also advice you to subcontract somebody else to implement this feature (see Werner Koch's email). Regards, Matthias-Christian From gniibe at fsij.org Sat Feb 21 05:22:22 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Sat, 21 Feb 2015 13:22:22 +0900 Subject: Help need to use truecryt + openpgp applet. In-Reply-To: <54E7E70F.9070100@mirix.org> References: <54E61BE2.30305@mirix.org> <87bnkpd8vr.fsf@vigenere.g10code.de> <54E64575.8020505@mirix.org> <54E7E70F.9070100@mirix.org> Message-ID: <54E807FE.10206@fsij.org> Hello, I maintain Scute and Poldi packages in Debian. I also do minimum efforts for those software in the upstream. Perhaps, it's better for me to put my business on the service.html, but my environment is free software only which won't match most potential customers' requests. Well, please note that Scute or Poldi is not mature enough yet, and somehow not well maintained these days. On 02/21/2015 11:01 AM, Matthias-Christian Ott wrote: > As mentioned in my more detailed follow-up email on how TrueCrypt > accesses the "keyfile" on the smartcard, Scute is not able to do this. Interesting. I don't recommend using data objects on a smartcard for such a use, because it's size is usually limited. Say, 255-byte or so, at most. Here, I explain a bit of existing code (of scdaemon, scute and poldi) and OpenPGPcard v2. We also have the data object of 0x7F21 "Cardholder certificate". I guess that it was intended to hold the X.509 client certificate in OpenPGPcard v2, which corresponds to the authentication private key on the card. We have READCERT command in scdaemon to access this specific data object. However, this command and the data object itself are not used any more by GnuPG, Scute, or Poldi. Thus, it would be possible to use this data object for your experiment. This is abuse, so, I don't recommend, in general, but only for your experimental usage. This data object is exceptionally large. I don't remember how large it is for the original OpenPGPcard, but I know it's 2KiB for Gnuk (if enabled on compile time). The access to the data object of 0x7f21 is not controlled by PIN. It can be accessed by anyone. I think that it could be possible for the host PC to encrypt the data to be stored, using card's encryption key. -- From ndk.clanbo at gmail.com Sat Feb 21 08:48:07 2015 From: ndk.clanbo at gmail.com (NdK) Date: Sat, 21 Feb 2015 08:48:07 +0100 Subject: Help need to use truecryt + openpgp applet. In-Reply-To: <54E7E70F.9070100@mirix.org> References: <54E61BE2.30305@mirix.org> <87bnkpd8vr.fsf@vigenere.g10code.de> <54E64575.8020505@mirix.org> <54E7E70F.9070100@mirix.org> Message-ID: <54E83837.8020004@gmail.com> Il 21/02/2015 03:01, Matthias-Christian Ott ha scritto: [...] > it finds PKCS #11 objects on the card). That said, I doubt using the > private DOs for PKCS #11 objects and associated metadata will be > generally accepted (other people could be storing other data in these > data objects), so you would probably have to add a compile-time option > or maintain a fork. Then maybe, a simple (disabled) SIM card from an old phone contract (I usually have about a dozen around) could be better suited for the job, since there's no on-card crypto involved. Just store the secret in an SMS, with the "sender" set to the ID of the protected storage :) Ok, end of OT. BYtE, Diego From wk at gnupg.org Sat Feb 21 12:18:42 2015 From: wk at gnupg.org (Werner Koch) Date: Sat, 21 Feb 2015 12:18:42 +0100 Subject: Help need to use truecryt + openpgp applet. In-Reply-To: <54E83837.8020004@gmail.com> (NdK's message of "Sat, 21 Feb 2015 08:48:07 +0100") References: <54E61BE2.30305@mirix.org> <87bnkpd8vr.fsf@vigenere.g10code.de> <54E64575.8020505@mirix.org> <54E7E70F.9070100@mirix.org> <54E83837.8020004@gmail.com> Message-ID: <87y4nr7bsd.fsf@vigenere.g10code.de> On Sat, 21 Feb 2015 08:48, ndk.clanbo at gmail.com said: > since there's no on-card crypto involved. Just store the secret in an > SMS, with the "sender" set to the ID of the protected storage :) Or use a plain USB stick. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From peter at digitalbrains.com Sat Feb 21 12:26:47 2015 From: peter at digitalbrains.com (Peter Lebbing) Date: Sat, 21 Feb 2015 12:26:47 +0100 Subject: Help need to use truecryt + openpgp applet. In-Reply-To: <87y4nr7bsd.fsf@vigenere.g10code.de> References: <54E61BE2.30305@mirix.org> <87bnkpd8vr.fsf@vigenere.g10code.de> <54E64575.8020505@mirix.org> <54E7E70F.9070100@mirix.org> <54E83837.8020004@gmail.com> <87y4nr7bsd.fsf@vigenere.g10code.de> Message-ID: <54E86B77.90308@digitalbrains.com> On 21/02/15 12:18, Werner Koch wrote: > Or use a plain USB stick. Hehe :). I think what Diego means, is that a SIM card can still be protected by a PIN. You would need to enter the PIN before you had access to the SMS, similarly as the private DO's on the OpenPGP card. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From wk at gnupg.org Sat Feb 21 12:26:30 2015 From: wk at gnupg.org (Werner Koch) Date: Sat, 21 Feb 2015 12:26:30 +0100 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: (Lukas Pitschl's message of "Fri, 20 Feb 2015 10:36:22 +0100") References: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> <87oaospsum.fsf@vigenere.g10code.de> <8CBC97E5-C896-4989-814D-45E67C9014CF@asatiifm.net> <87vbizn6ad.fsf@vigenere.g10code.de> <54E6312A.5030408@asatiifm.net> Message-ID: <87twyf7bfd.fsf@vigenere.g10code.de> On Fri, 20 Feb 2015 10:36, lukele at dressyvagabonds.com said: > In order to work around the hang, we?re running this call in a separate thread now, and if it doesn?t return within a few seconds (5 at the moment), it sends a timeout to the scdaemon. Why not using a simple alarm() based watchdog and termintate pcsc-wrapper in this case? We do the same in the keyserver helpers. If would also be possible to do tomeout in the read call of apdu.c but that adds complexity at the wrong place. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ndk.clanbo at gmail.com Sat Feb 21 12:30:51 2015 From: ndk.clanbo at gmail.com (NdK) Date: Sat, 21 Feb 2015 12:30:51 +0100 Subject: Help need to use truecryt + openpgp applet. In-Reply-To: <54E86B77.90308@digitalbrains.com> References: <54E61BE2.30305@mirix.org> <87bnkpd8vr.fsf@vigenere.g10code.de> <54E64575.8020505@mirix.org> <54E7E70F.9070100@mirix.org> <54E83837.8020004@gmail.com> <87y4nr7bsd.fsf@vigenere.g10code.de> <54E86B77.90308@digitalbrains.com> Message-ID: <54E86C6B.8090701@gmail.com> Il 21/02/2015 12:26, Peter Lebbing ha scritto: >> Or use a plain USB stick. > Hehe :). I think what Diego means, is that a SIM card can still be protected by > a PIN. You would need to enter the PIN before you had access to the SMS, > similarly as the private DO's on the OpenPGP card. Exactly. Moreover, it's often "free" since you don't have to buy a new card just for that use, just recycle an unused one. BYtE, Diego From peter at digitalbrains.com Sat Feb 21 12:51:15 2015 From: peter at digitalbrains.com (Peter Lebbing) Date: Sat, 21 Feb 2015 12:51:15 +0100 Subject: Whishlist for next-gen card In-Reply-To: <54E6F12D.40504@gmail.com> References: <54E6F12D.40504@gmail.com> Message-ID: <54E87133.2040202@digitalbrains.com> On 20/02/15 09:32, NdK wrote: > 1 - support for more keys (expired ENC keys, multiple signature keys) Yes! This would be a great feature to keep expired encryption keys on a card. I personally would have no use for more than 1 signature and 1 authentication key, but I don't see a reason why you wouldn't just have a whole bunch of generic key slots and only indicate its intended usage on creation/upload so people can do that as well.[1] If ECC were supported by the card, you'd need quite a lot less storage to keep all these keys. > 2 - different PINs for different keys This would partly amount to resurrecting an old feature. IIRC, there were 2 user PINs in the v1.1 spec, but the v2 spec pretty much retired the second PIN. Don't take my word for it, though, check the spec. I suppose it makes sense. Especially when combined with 2 signature keys: one could be your primary key, and the other your subkey. You would still keep them on the same card, but would be more careful about entering the PIN that belongs to your primary key. However, I think the primary key/subkey feature is already covered pretty well by simply having two smartcards (it's what I do). > 3 - separate key for NFC auth (with its own optional PIN) Sounds like an interesting concept. I don't know how much work it would be to have the ISO 7816 parts needed by the OpenPGP card really working for NFC. Do you just exchange the lower few communication layers (physical, data, ...) and is everything above the same for the subset of ISO 7816 you need? I haven't looked at NFC yet. What I'm hinting at: NFC and cards with contacts are different enough that it might warrant handling NFC separately from the rest and hence doesn't need to be "integrated into" the process for determining the next cards-with-contacts standard and implementation. But NFC authentication through asymmetric crypto sounds interesting. > 4 - HOTP PINs for signature/certification keys What generates the HOTP then? Do you type a PIN on the HOTP device to get the HOTP? What I'm guessing you might mean, is that the HOTP device might be more trusted than the pinpad of the card reader: the card reader is connected to the PC. The HOTP device is simply a standalone device; is air-gapped. So even if the PC is compromised, it will not be able to learn your PIN, which you entered on the HOTP device. Is this what you're getting at? I don't really see the use. Smartcards protect extraction of the private key; they're not equipped to prevent usage of the key material through a compromised PC. So what they can't learn your PIN; they'll just get you to enter it for them. I don' see this adding something beyond your point 6, which I'll treat there. > 5 - possibility to export private keys to user-certified devices I'm not terribly interested in that. Firstly, you would still need a backup of the key the data is encrypted to; the chain has to start somewhere. Secondly, provided you can have a trusted system for the generation of the keys, you could simply generate them on that trusted system, encrypt them to the key you wish to encrypt it to, and then store the encrypted data as you see fit. On-card generation is putting a lot of trust in the on-card RNG as well; I put more trust in Linux's PRNG on a trusted system. As long as you're generating the keys on a PC anyway, you might as well handle all the backup thingies there. > 6 - support for out-of-band authorization (HW) This and 7 have been discussed in this[2] thread as well; just as a reference. I think it serves a useful canary role, in that as long as I only press the button once for each decryption/signature, I'm fairly sure that it's doing the decryption or signature that I want. As soon as stuff starts to exhibit hickups, I can at least account for the fact that perhaps it's not hardware failing but someone playing me. Robert J Hansen clearly strongly disagrees with me on that subject, as evidenced in the thread I indicated. It's not watertight. Neither is a canary. I see it as defence in depth. But it is clearly a contested subject. And I've never seen any indication that Werner believes in this solution; I get the feeling he doesn't. I suppose he's the main influence on what goes in the card specification and what doesn't. > 7 - support for more informative signing (requires a small display: HW) See below for my view. > 3 to 6 should be under a "policy" object connected to the main key to > make it public and let relying parties evaluate how much trust to give. This seems to preclude ever allowing the user access to their own private key material; otherwise you're moving your trust back again from the smartcard attesting this policy to the user attesting this policy, since they can do what they want, whatevah! I don't think we should limit the user in handling their own keys; it reeks like DRM to me. But if you don't limit the user, there's no reason to have the smartcard attest to any attributes, since the card can't guard them anyway. Just leave the policy to the user. > 2 - If I have to use my card to login on a possibly untrusted computer Hmmm. I would definitely use a different card for this, regardless of all the cool protections on the card. Say I have a card with my work identity, and one with my private identity. I wouldn't ever stick the private identity in a work PC, even if the keys were protected by a different PIN. It only seems to serve the purpose of having one piece of plastic less in your wallet; but I already need a separate card wallet because of all the cards I have, one more isn't going to matter. > 4 - since HOTP changes at every use, it makes keyloggers nearly useless > and gives a third factor to the auth process (might be combined by > simple means -like digit-by-digit addition modulo 10- to the PIN) Third factor IMHO implies a different *kind* of factor. You already have possession (the OpenPGP card) and knowledge (the PIN). What's your third factor; biometrics? To bend the terms to breaking point: I currently employ 9-factor authentication. I have the OpenPGP card, and I know 8 PIN digits. This is a useless definition; I think "factor" only makes sense as a *kind* of authentication. Still, this is just about terminology; my substantial answer is above. > 7 - malaware currently can replace the hash of the object being signed > and the user can't know it till it's late... a small display could be > used to report some metadata (file name type and size for signature, > keyID and owner data for certification, peer ID for auth...) to give the > user more feedback Malware can replace the hash of the object being signed... and still display the correct file name type and size, etcetera, everything you mention. So I'm not sure what you're getting at. You need to present data that is actually *signed* for this to be useful in any way. It might be that SSH authentication does include a "peer ID" in its challenge; I haven't checked. But that is all. What is signed[3] is a hash computed over the data and a few OpenPGP (sub)packets. People can't compute hashes. So you need a computer to do it. If there's a computer you trust to do this for you, just sign the data there already. I only see this work with trust in numbers: compute the hash on many computers, and if they all agree, they're probably not all hacked. I say I see this work, but I don't, really: I don't believe in this mechanism. And it's a tremendous amount of work for the user for one single signature. [... half a proofread of this mail later ...] Oh ouch. I suddenly realise something about the canary press-to-decrypt button (point 6). I've thought of a nasty attack. Maybe it's not such a great canary for decryption keys... So I access mail A, which is encrypted, and my PC is compromised. The malware listens in, and, crucially, secretly saves the session key for mail A! A few days later, I again access mail A. Now, I expect to be prompted for my PIN: that's how it normally works when I access an encrypted mail. However, the malware arranges that a document it is interested in is decrypted instead. And since it has saved the session key for mail A, it still presents to me mail A as expected. Now I haven't pressed the button any more than I expect to do, but still it decrypts other data than I expect it to. I've just helped the malware access my encrypted documents, and I'm totally unaware. Detecting false signatures is already more complicated. Now I'm really starting to have doubts about the canary button. My 2 cents, Peter. [1] It would probably be reasonable to not be able to change its usage. If you really want to do that, you could also upload the key again, proving you already have the secret material. If your point 5 were to be implemented, the usage indicator could be combined with that. [2] http://lists.gnupg.org/pipermail/gnupg-users/2013-February/045994.html [3] Forgetting about authentication for a moment; as I said, the "peer ID" might actually work for authentication. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From xavier at maillard.im Sat Feb 21 14:55:54 2015 From: xavier at maillard.im (Xavier Maillard) Date: Sat, 21 Feb 2015 14:55:54 +0100 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: <8CBC97E5-C896-4989-814D-45E67C9014CF@asatiifm.net> References: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> <87oaospsum.fsf@vigenere.g10code.de> <8CBC97E5-C896-4989-814D-45E67C9014CF@asatiifm.net> Message-ID: Hi Ville, Ville M??tt? writes: > I happen to use Mail so for a long time I?ve been using the GPGMail > plugin with a brewed[2] upstream GnuPG. I.e. *just one of the > things in the GPG Suite*. I?ve talked about this setup before in > the thread [3]. If one doesn?t use Apple Mail there is no reason to > use GPGTools at all. Thanks for that ! I thought I had to install it. So, I can drop it and install GPG via brew ? Regards -- Sent with my mu4e -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1494 bytes Desc: not available URL: From xavier at maillard.im Sat Feb 21 15:12:00 2015 From: xavier at maillard.im (Xavier Maillard) Date: Sat, 21 Feb 2015 15:12:00 +0100 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: <48c92342ece9a4e2f30b3f382523ed72@butters.digitalbrains.com> References: <68F2AA9B-B192-4727-9AA3-2BC33CBE5434@mykolab.com> <87sie3i7kb.fsf@vigenere.g10code.de> <48c92342ece9a4e2f30b3f382523ed72@butters.digitalbrains.com> Message-ID: Peter Lebbing writes: > On 2015-02-19 18:16, Jonathan Schleifer wrote: >> I also like @ to hide useless output, but is downloading *and >> executing* from a remote location really something you should hide? >> Especially if everything else isn't hidden? > > I can understand you're pretty darn pissed off that they executed > untrusted remote code on your computer, which, I think, explains why > you're "lashing out" so strongly. And I also think that it was truly > poorly designed. But I find your quest for bad faith on their part a bit > far fetched... Never attribute to malice that which is adequately > explained by stupidity.[1][2] > > By now, you should probably cool down a bit. I'd say you've made your > point. I could not agree more ! -- Xavier -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1494 bytes Desc: not available URL: From mailing-lists at asatiifm.net Sat Feb 21 15:40:17 2015 From: mailing-lists at asatiifm.net (=?utf-8?Q?Ville_M=C3=A4=C3=A4tt=C3=A4?=) Date: Sat, 21 Feb 2015 16:40:17 +0200 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: References: <7C550444-7F4F-4A88-A41D-036EC144DEFC@webkeks.org> <87oaospsum.fsf@vigenere.g10code.de> <8CBC97E5-C896-4989-814D-45E67C9014CF@asatiifm.net> Message-ID: <93419D49-F726-4BDE-BE99-76A22AC9E01D@asatiifm.net> On 21 Feb 2015, at 15:55, Xavier Maillard wrote: > > Hi Ville, > > Ville M??tt? writes: > >> I happen to use Mail so for a long time I?ve been using the GPGMail >> plugin with a brewed[2] upstream GnuPG. I.e. *just one of the >> things in the GPG Suite*. I?ve talked about this setup before in >> the thread [3]. If one doesn?t use Apple Mail there is no reason to >> use GPGTools at all. > > Thanks for that ! I thought I had to install it. So, I can drop it > and install GPG via brew ? > > Regards > -- > Sent with my mu4e Yes that's right. You can also use the 2.1 installer linked to from gnupg.org downloads. gpg-agent and pinentry-mac can also be installed via brew. For 2.0.27 you can use the write up on this list I linked to. You might need to adapt it a little bit. For 2.1 you shouldn't need the launchd stuff* unless you use SSH. Btw. I noticed there's now a brewed 2.1. Wasn't 2.1.2 yesterday but didn't look at it any more closely yet. * it was mentioned that 2.0.24 already made the agent on-demand changes which make launchd unnecessary (when not using SSH). The scripts don't hurt anyway. From xavier at maillard.im Sat Feb 21 16:18:48 2015 From: xavier at maillard.im (Xavier Maillard) Date: Sat, 21 Feb 2015 16:18:48 +0100 Subject: Double sign a document In-Reply-To: <6143978.jS9ZTdej7d@inno> References: <54E4386E.3020506@graffen.dk> <6143978.jS9ZTdej7d@inno> Message-ID: Hauke Laging writes: > Am Mi 18.02.2015, 21:29:40 schrieb Xavier Maillard: > >> Just a quick question: do I need to have both keypairs in my keyring >> ? I mean both my old secret key and my new secret key. > > Of course. Would be strange if you could make a signature without the > respective secret key. Arguably, I should have thought twice before posting :) Regards -- Sent with my mu4e -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1494 bytes Desc: not available URL: From daniele at grinta.net Sat Feb 21 17:42:40 2015 From: daniele at grinta.net (Daniele Nicolodi) Date: Sat, 21 Feb 2015 17:42:40 +0100 Subject: Unattended signing In-Reply-To: <54E4DDFB.1010405@grinta.net> References: <54E4DDFB.1010405@grinta.net> Message-ID: <54E8B580.9000509@grinta.net> On 18/02/15 19:46, Daniele Nicolodi wrote: > I have an automated process that collects some data and unattended sends > it via email. I want that data to be encrypted and signed. The > encryption part is easy as it requires only public keys of the > recipients. Signing, however, requires to make the private key used > available to the process. > > I have a sufficient trust in the security of the server where the > automated process runs, but I would like to reduce to a minimum the risks. > > What is the best practices in such cases? I can imagine several > possible options: using a subkey of my key (is it possible to remove > passphrase protection from a subkey?), using a dedicated key, using a > subkey of a dedicated key and periodically rotate such subkey. Hello, I haven't received any comment on this. Is ti because the question is too dummy, I'm being too naive, or the context is not explained with sufficient detail? Thanks for your attention :) Cheers, Daniele From dkg at fifthhorseman.net Sat Feb 21 17:54:35 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 21 Feb 2015 11:54:35 -0500 Subject: Whishlist for next-gen card In-Reply-To: <54E87133.2040202@digitalbrains.com> References: <54E6F12D.40504@gmail.com> <54E87133.2040202@digitalbrains.com> Message-ID: <87k2zb5ho4.fsf@alice.fifthhorseman.net> On Sat 2015-02-21 06:51:15 -0500, Peter Lebbing wrote: > Oh ouch. I suddenly realise something about the canary press-to-decrypt button > (point 6). I've thought of a nasty attack. Maybe it's not such a great canary > for decryption keys... > > So I access mail A, which is encrypted, and my PC is compromised. The malware > listens in, and, crucially, secretly saves the session key for mail A! A few > days later, I again access mail A. Now, I expect to be prompted for my PIN: > that's how it normally works when I access an encrypted mail. However, the > malware arranges that a document it is interested in is decrypted instead. And > since it has saved the session key for mail A, it still presents to me mail A as > expected. Now I haven't pressed the button any more than I expect to do, but > still it decrypts other data than I expect it to. I've just helped the malware > access my encrypted documents, and I'm totally unaware. If the malware is keeping the session keys around, it can just keep the session keys for everything you ever decrypt, and use them anyway to access your encrypted documents, independent of your button-presses. You're right in the abstract: the bandwidth of the "canary button" (one bit of LED output "secret key action requested", one bit of input "ok to use secret key") is too limited to protect against the sophisticated attack you describe, and increasing the bandwidth of the channel (e.g. on-device display screen, keypad) makes the UI/UX even more infeasibile. At some point, you just have a second computer attached to your computer, and now there is room for that second computer to be compromised :/ > Detecting false signatures is already more complicated. > > Now I'm really starting to have doubts about the canary button. None of these tools are perfect, and the goals of a "canary button"-like scheme are (a) defense in depth, and (b) increased chance of detection. An adversary *could* mount the sophisticated attack you describe above, but it's an awful lot of work. It's much easier to exploit a card that just accepts the (possibly malware-cached) PIN without one. The sophisticated attack is also a piecemeal re-use of secret key material, and not a flood. And, if the attacker slips up, it's much easier for the legitimate user to notice that something funny is happening. I don't think anyone is claiming that this sort of scheme renders the device impervious to misuse -- it's connected to a general-purpose computer with all of its complexity! -- but it raises the bar to an attacker and provides more defense than an unguarded device. The non-crypto parts of the system are unlikely to reach the level of guarantees that modern crypto is capable of providing. But that doesn't mean we shouldn't try to improve them. --dkg From antony at blazrsoft.com Sat Feb 21 19:07:38 2015 From: antony at blazrsoft.com (Antony Prince) Date: Sat, 21 Feb 2015 13:07:38 -0500 Subject: Unattended signing In-Reply-To: <54E8B580.9000509@grinta.net> References: <54E4DDFB.1010405@grinta.net> <54E8B580.9000509@grinta.net> Message-ID: <54E8C96A.8030806@blazrsoft.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2/21/2015 11:42 AM, Daniele Nicolodi wrote: > On 18/02/15 19:46, Daniele Nicolodi wrote: >> I have an automated process that collects some data and unattended sends >> it via email. I want that data to be encrypted and signed. The >> encryption part is easy as it requires only public keys of the >> recipients. Signing, however, requires to make the private key used >> available to the process. >> >> I have a sufficient trust in the security of the server where the >> automated process runs, but I would like to reduce to a minimum the risks. >> >> What is the best practices in such cases? I can imagine several >> possible options: using a subkey of my key (is it possible to remove >> passphrase protection from a subkey?), using a dedicated key, using a >> subkey of a dedicated key and periodically rotate such subkey. > > Hello, > > I haven't received any comment on this. Is ti because the question is > too dummy, I'm being too naive, or the context is not explained with > sufficient detail? > > Thanks for your attention :) > > Cheers, > Daniele > I'm no expert on the subject, but it seems the simplest and safest solution would be to use a subkey of a dedicated key and rotate it periodically if you're concerned about the key being compromised, especially since the key will not be password protected. I could be horribly wrong, but that's my two cents on it. - -- Antony Prince Key ID: 0x4F040744 Fingerprint: FE96 5B7F A708 18D3 B74B 959F A6E1 6242 4F04 0744 URL: https://hkps.pool.sks-keyservers.net/pks/lookup?op=get&search=0xA6E162424F040744 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJU6MljAAoJEKbhYkJPBAdEKF4H/1tFpKKSptF0fBt8uHmW1urf awYO+4KkcJ809C/5BYb+bMvnhSx2yPOIJUN0NNnrnxEz7rQsw1a70GgmJjyvS5zA gaIfXfGGS9dGesd5qgt0YuER7d5BqJgFRViBqxjXqbAqN72c64Oh9eADXeZ6fBfJ Q/6KuRo+wfeoWKiY2OJIZNzOxPWFladnfpM8Rj9HUK+mh+VX5q637LnBprbTXYym RvgEahQCgYmO88xjhbFLoVi12su+uw4PihVztudDbz3bxZKD4azoDFnikXX1Omjs q72LLuTwdkMExzNuxU+Ilmv+dGi17+gbc2ssPVs//PuAtqaGU3qX2KHUxaCzvTU= =gXjO -----END PGP SIGNATURE----- From ndk.clanbo at gmail.com Sat Feb 21 19:54:38 2015 From: ndk.clanbo at gmail.com (NdK) Date: Sat, 21 Feb 2015 19:54:38 +0100 Subject: Whishlist for next-gen card In-Reply-To: <54E87133.2040202@digitalbrains.com> References: <54E6F12D.40504@gmail.com> <54E87133.2040202@digitalbrains.com> Message-ID: <54E8D46E.1080408@gmail.com> Il 21/02/2015 12:51, Peter Lebbing ha scritto: >> 1 - support for more keys (expired ENC keys, multiple signature keys) > Yes! This would be a great feature to keep expired encryption keys on a card. I > personally would have no use for more than 1 signature and 1 authentication key, > but I don't see a reason why you wouldn't just have a whole bunch of generic key > slots and only indicate its intended usage on creation/upload so people can do > that as well.[1] Yup. But if those are too generic, then it could be way cheaper to just use a generic PKCS#15 card (I've had some experiences with Aventra ones: they've got space for many keys and 14 PINs... and are quite cheap!). > If ECC were supported by the card, you'd need quite a lot less storage to keep > all these keys. Yup. But on a device like GnuK space is really not the limiting factor. >> 2 - different PINs for different keys > This would partly amount to resurrecting an old feature. IIRC, there were 2 user > PINs in the v1.1 spec, but the v2 spec pretty much retired the second PIN. Don't > take my word for it, though, check the spec. I remember seeing an unused PIN object. [...] > However, I think the primary key/subkey feature is already covered pretty well > by simply having two smartcards (it's what I do). Twice the cost, twice the risk of losing one, twice the management burden... >> 3 - separate key for NFC auth (with its own optional PIN) > Sounds like an interesting concept. I don't know how much work it would be to > have the ISO 7816 parts needed by the OpenPGP card really working for NFC. Do > you just exchange the lower few communication layers (physical, data, ...) and > is everything above the same for the subset of ISO 7816 you need? I haven't > looked at NFC yet. I started implementing it on MyPGPid. From JavaCards it's quite easy to differentiate between wired and wireless, since the applet receives the protocol used to transmit the APDU. > What I'm hinting at: NFC and cards with contacts are different enough that it > might warrant handling NFC separately from the rest and hence doesn't need to be > "integrated into" the process for determining the next cards-with-contacts > standard and implementation. There are dual-interface cards, and I think they're not so disjoint, once you're using secure messaging. > But NFC authentication through asymmetric crypto sounds interesting. Way more than EM4100 tags or MIFARE cards. >> 4 - HOTP PINs for signature/certification keys > What generates the HOTP then? Do you type a PIN on the HOTP device to get the HOTP? No need. Just an applet on the phone could do. At least if you aren't using the same phone to do the crypto. > What I'm guessing you might mean, is that the HOTP device might be more trusted > than the pinpad of the card reader: the card reader is connected to the PC. The > HOTP device is simply a standalone device; is air-gapped. So even if the PC is > compromised, it will not be able to learn your PIN, which you entered on the > HOTP device. As I said, no need for a PIN on the HOTP device. The only important thing is that it's a *different* device, better if air-gapped. > Is this what you're getting at? > I don't really see the use. Smartcards protect extraction of the private key; > they're not equipped to prevent usage of the key material through a compromised > PC. So what they can't learn your PIN; they'll just get you to enter it for > them. I don' see this adding something beyond your point 6, which I'll treat there. You're authorizing a *single* operation. As you noticed, malaware could be smart enough to fool the user for decryption (where using HOTP would be foolish: you'd have to continuously generate new codes just to scan the mail), but signature is another beast. HOTP could be seen as a stronger 'alwaysauthenticate' flag. >> 5 - possibility to export private keys to user-certified devices > I'm not terribly interested in that. Firstly, you would still need a backup of > the key the data is encrypted to; the chain has to start somewhere. Secondly, > provided you can have a trusted system for the generation of the keys, you could > simply generate them on that trusted system, encrypt them to the key you wish to > encrypt it to, and then store the encrypted data as you see fit. Unless you're doing something like SmartcardHSM, where each card gets initialized with a device attestation key (generated on-card) and its certificate, so you can choose to trust other cards as long as they're certified. A more user-centric approach would require a "temporary" CA (no need for long-term storage of its secret key) that the user uses to certify keys generated on his own cards. Once the cards have been certified, the CA key can be deleted. In the worst case, the user won't be able to transfer his keys to other (newer) devices. > On-card generation is putting a lot of trust in the on-card RNG as well; I put > more trust in Linux's PRNG on a trusted system. As long as you're generating the > keys on a PC anyway, you might as well handle all the backup thingies there. On the other hand I think a TRNG that accumulates entropy under user control (like GnuK) can be trusted more than something relying on software only. >> 6 - support for out-of-band authorization (HW) [...] > It's not watertight. Neither is a canary. I see it as defence in depth. But it > is clearly a contested subject. And I've never seen any indication that Werner > believes in this solution; I get the feeling he doesn't. I suppose he's the main > influence on what goes in the card specification and what doesn't. Maybe its addition to the security is marginal, but can be *way* more practical than having to reenter a complex PIN every time. >> 3 to 6 should be under a "policy" object connected to the main key to >> make it public and let relying parties evaluate how much trust to give. > This seems to preclude ever allowing the user access to their own private key > material; otherwise you're moving your trust back again from the smartcard > attesting this policy to the user attesting this policy, since they can do what > they want, whatevah! I don't think we should limit the user in handling their > own keys; it reeks like DRM to me. But if you don't limit the user, there's no > reason to have the smartcard attest to any attributes, since the card can't > guard them anyway. Just leave the policy to the user. Well, on one hand the user could *choose* to use his own CA, thus being free to do what he likes with the keys. On the other had he could *choose* to trust another CA (the one managed by the card producer, maybe) and in that case he won't be able to access his keys and other users will know that. >> 2 - If I have to use my card to login on a possibly untrusted computer > Hmmm. I would definitely use a different card for this, regardless of all the > cool protections on the card. Say I have a card with my work identity, and one > with my private identity. I wouldn't ever stick the private identity in a work > PC, even if the keys were protected by a different PIN. It only seems to serve > the purpose of having one piece of plastic less in your wallet; but I already > need a separate card wallet because of all the cards I have, one more isn't > going to matter. Separate cards for separate identities is one thing, but separate cards for separate roles of a single identity could quickly become too cumbersome to manage. For me it wouldn't be a problem to plug my card in a work PC, as long as I can be "confident enough" that I'm in control of which keys are being used. >> 4 - since HOTP changes at every use, it makes keyloggers nearly useless >> and gives a third factor to the auth process (might be combined by >> simple means -like digit-by-digit addition modulo 10- to the PIN) > Third factor IMHO implies a different *kind* of factor. You already have > possession (the OpenPGP card) and knowledge (the PIN). What's your third factor; > biometrics? You're quite right. Maybe third factor is not the correct term. What I meant was that the user had to have another object. Better if it's something he's used to bring around and guard (like the phone). > Malware can replace the hash of the object being signed... and still display the > correct file name type and size, etcetera, everything you mention. So I'm not > sure what you're getting at. You need to present data that is actually *signed* > for this to be useful in any way. If that info is embedded in the signature packet, it could add something to the signature value (if the receiving party sees that signature is about a txt file and the presented object is a doc, there's something wrong and suspect). BTW the card could even (randpmly?) ask to be passed the whole file to-be-signed to compute on its own the hashing. If it's different from the one presented in the "summary", alert the user. I know card interfaces are quite slow, but I think it should be allowed anyway because 1) you can have faster interfaces, if needed (see GnuK) and 2) it's an user's choice (I never sign ISO files, and even if I did I can stand that once in a while it takes some hours... if I signed ISOs everyday I'd probably choose NOT to enable such a feature, or just use a card/token without display). > It might be that SSH authentication does > include a "peer ID" in its challenge; I haven't checked. But that is all. That's the fingerprint ssh shows you. It should be computed from the complete public key. > What is signed[3] is a hash computed over the data and a few OpenPGP > (sub)packets. People can't compute hashes. So you need a computer to do it. If > there's a computer you trust to do this for you, just sign the data there > already. I only see this work with trust in numbers: compute the hash on many > computers, and if they all agree, they're probably not all hacked. I say I see > this work, but I don't, really: I don't believe in this mechanism. And it's a > tremendous amount of work for the user for one single signature. See above. In poker terms there's a chance that the card asks to see your hand. And if you cheated the user is alerted. > [... half a proofread of this mail later ...] > Oh ouch. I suddenly realise something about the canary press-to-decrypt button > (point 6). I've thought of a nasty attack. Maybe it's not such a great canary > for decryption keys... I didn't mean it for decryption, just for signature/certification. > So I access mail A, which is encrypted, and my PC is compromised. The malware > listens in, and, crucially, secretly saves the session key for mail A! A few > days later, I again access mail A. Now, I expect to be prompted for my PIN: > that's how it normally works when I access an encrypted mail. However, the > malware arranges that a document it is interested in is decrypted instead. And > since it has saved the session key for mail A, it still presents to me mail A as > expected. Now I haven't pressed the button any more than I expect to do, but > still it decrypts other data than I expect it to. I've just helped the malware > access my encrypted documents, and I'm totally unaware. Well, currently it could simply cache your PIN and do *everything*. Do you agree that developing the depicted attack costs *way* more than a simple keylogger (about 5? for one that intercepts the PS2 connector, IIRC)? > Detecting false signatures is already more complicated. > Now I'm really starting to have doubts about the canary button. Maybe it's just convenience that *eventually* adds some marginal security. Can't see it doing harm. BYtE, Diego. From dkg at fifthhorseman.net Sat Feb 21 20:11:55 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 21 Feb 2015 14:11:55 -0500 Subject: Unattended signing In-Reply-To: <54E4DDFB.1010405@grinta.net> References: <54E4DDFB.1010405@grinta.net> Message-ID: <87egpj5bb8.fsf@alice.fifthhorseman.net> On Wed 2015-02-18 13:46:19 -0500, Daniele Nicolodi wrote: > I have a sufficient trust in the security of the server where the > automated process runs, but I would like to reduce to a minimum the risks. there are risks with unattended signing in general, related to what messages you allow to get passed to your system. I'm sure you've already thought about this, but i'll just put it out there in case someone else reading this later hasn't thought about it enough. > What is the best practices in such cases? I can imagine several > possible options: using a subkey of my key (is it possible to remove > passphrase protection from a subkey?), using a dedicated key, using a > subkey of a dedicated key and periodically rotate such subkey. Using a dedicated key for your system would clearly be better than using your own personal key, but i don't know if it meets your other requirements (we don't know your requirements for the system). Using a subkey is a reasonable approach, and rotating (and destroying) the secret key of the rotated subkey is not a bad idea. Take a look at --export-secret-subkeys and the --export-options "export-reset-subkey-passwd" in the gpg manual for your next steps. Please report back here if you have any problems. hth, --dkg From ndk.clanbo at gmail.com Sat Feb 21 20:26:00 2015 From: ndk.clanbo at gmail.com (NdK) Date: Sat, 21 Feb 2015 20:26:00 +0100 Subject: Whishlist for next-gen card In-Reply-To: <87k2zb5ho4.fsf@alice.fifthhorseman.net> References: <54E6F12D.40504@gmail.com> <54E87133.2040202@digitalbrains.com> <87k2zb5ho4.fsf@alice.fifthhorseman.net> Message-ID: <54E8DBC8.60400@gmail.com> Il 21/02/2015 17:54, Daniel Kahn Gillmor ha scritto: > If the malware is keeping the session keys around, it can just keep the > session keys for everything you ever decrypt, and use them anyway to > access your encrypted documents, independent of your button-presses. Or just sniff the PIN. > You're right in the abstract: the bandwidth of the "canary button" (one > bit of LED output "secret key action requested", one bit of input "ok to > use secret key") is too limited to protect against the sophisticated > attack you describe, and increasing the bandwidth of the channel > (e.g. on-device display screen, keypad) makes the UI/UX even more > infeasibile. At some point, you just have a second computer attached to > your computer, and now there is room for that second computer to be > compromised :/ Well, at least that one would be a dedicated computer, with very limited connection to the outside world. And if the idea of a display gets implemented, at least the kind of operation can be confirmed. BYtE, Diego. From anthony at cajuntechie.org Sun Feb 22 00:33:46 2015 From: anthony at cajuntechie.org (Anthony Papillion) Date: Sat, 21 Feb 2015 17:33:46 -0600 Subject: Question about group line use in GnuPG Message-ID: <54E915DA.7040004@cajuntechie.org> I belong to a mailing list (PGPNET, a Yahoo Group) that provides me with a "group line" for encrypting to a group of keys. In my gpg.conf file, I put something like: group mygroup at domain.com=key1,key2,key Then, using Enigmail, I can encrypt to the entire group of keys by selecting it in the UI. However... The fact that gpg doesn't complain about the group line in the conf file means it must accept as a valid option. So why can I not use that group address when I am encrypting and signing from the terminal. I should be able to do something like: gpg -ear mygroup at domain.com filename But when I do that, gpg tells it has no key for that address. Why can't gpg understand and properly process my group line from the terminal? Is this anything that's planned for the future? Thanks, Anthony -- Anthony Papillion Phone: 1.918.631.7331 VoIP (SIP): 80774 at iptel.org XMPP Chat: cypher at chat.cpunk.us Fingerprint: 65EF73EC 8B57F6B1 8C475BD4 426088AC FE21B251 PGP Key: http://www.cajuntechie.org/p/my-pgp-key.html To any NSA and FBI agents reading my email: please consider whether defending the US Constitution against all enemies, foreign or domestic, requires you to follow Edward Snowden's example. From dkg at fifthhorseman.net Sun Feb 22 01:19:32 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 21 Feb 2015 19:19:32 -0500 Subject: Question about group line use in GnuPG In-Reply-To: <54E915DA.7040004@cajuntechie.org> References: <54E915DA.7040004@cajuntechie.org> Message-ID: <87egpi4x2j.fsf@alice.fifthhorseman.net> On Sat 2015-02-21 18:33:46 -0500, Anthony Papillion wrote: > I belong to a mailing list (PGPNET, a Yahoo Group) that provides me with > a "group line" for encrypting to a group of keys. In my gpg.conf file, I > put something like: > > group mygroup at domain.com=key1,key2,key > > Then, using Enigmail, I can encrypt to the entire group of keys by > selecting it in the UI. > > However... > > The fact that gpg doesn't complain about the group line in the conf file > means it must accept as a valid option. So why can I not use that group > address when I am encrypting and signing from the terminal. I should be > able to do something like: > > gpg -ear mygroup at domain.com filename > > But when I do that, gpg tells it has no key for that address. Why can't > gpg understand and properly process my group line from the terminal? Is > this anything that's planned for the future? I believe it is supposed to do this already. It works for me. What version of GnuPG are you using? On what platform? can you share the exact configuration and commands you're running? It's hard to help debug from just the example info you provide here. --dkg From js-gnupg-users at webkeks.org Sun Feb 22 01:25:58 2015 From: js-gnupg-users at webkeks.org (Jonathan Schleifer) Date: Sun, 22 Feb 2015 01:25:58 +0100 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: References: <68F2AA9B-B192-4727-9AA3-2BC33CBE5434@mykolab.com> <87sie3i7kb.fsf@vigenere.g10code.de> <873861d8eq.fsf@vigenere.g10code.de> <483FE4A0-C58E-44AB-AD78-EA5E1A80C8D1@gpgtools.org> <2786DC31-AEAC-4406-9143-94F32C74A644@webkeks.org> Message-ID: Am 20.02.2015 um 11:48 schrieb Lukas Pitschl : > Pinentry-mac is one project we?ve ?revived? and thus only added stuff on top of the old code instead of refactoring it. > We?ve been planning to do that for a long time now though, so we?ll definitely look into that and check out how other UIs do it, like GTK. It seems there's http://github.com/GPGTools/pinentry now, which is based on the original pinentry. Unfortunately, as of now, it's just one huge commit on top of it. Still, I did a *very* quick review (so don't blame me if I overlooked something :P) and left a few comments. -- Jonathan From anthony at cajuntechie.org Sun Feb 22 01:32:56 2015 From: anthony at cajuntechie.org (Anthony Papillion) Date: Sat, 21 Feb 2015 18:32:56 -0600 Subject: Question about group line use in GnuPG In-Reply-To: <87egpi4x2j.fsf@alice.fifthhorseman.net> References: <54E915DA.7040004@cajuntechie.org> <87egpi4x2j.fsf@alice.fifthhorseman.net> Message-ID: <54E923B8.2060909@cajuntechie.org> On 02/21/2015 06:19 PM, Daniel Kahn Gillmor wrote: > On Sat 2015-02-21 18:33:46 -0500, Anthony Papillion wrote: >> >> gpg -ear mygroup at domain.com filename >> >> But when I do that, gpg tells it has no key for that address. Why can't >> gpg understand and properly process my group line from the terminal? Is >> this anything that's planned for the future? > > I believe it is supposed to do this already. It works for me. > > What version of GnuPG are you using? On what platform? can you share > the exact configuration and commands you're running? It's hard to help > debug from just the example info you provide here. Thanks for your quick response. It looks like I may have fixed the problem. Basically, when I use Enigmail for the group line, it needs it in the form of group =key1,key2,key3 But when I do it from the terminal, it needs to be in the form of group pgpnet at yahoogroups.com=key1,key2,key3 Copying the group line in my gpg.conf file and removing the brackets made if work as expected. Thanks! Anthony From ug at xcast.jp Sun Feb 22 01:46:57 2015 From: ug at xcast.jp (Yuji -UG- Imai) Date: Sun, 22 Feb 2015 09:46:57 +0900 Subject: Whishlist for next-gen card In-Reply-To: <54E6F12D.40504@gmail.com> References: <54E6F12D.40504@gmail.com> Message-ID: Hi, 2015?2?20?????NdK>????????: > Hello all. > > What I'd like to see addressed in future card > 6 - support for out-of-band authorization (HW) > For token type card, how about appending one more usb port to connect keyboard? It's just for inputing PIN/passphrase or out-of-bound auth by hitting the Enter key. USB ten keys like V7 KP0N1-7N0P Numeric keypad looks suitable for this purpose. Micro USB plug may be prefarable for compact board design. I don't like wireless features by two reasons. It may introduce complexity for middleware of the card. I like KISS. Another is break visibility to check HSM composition validness. For FST-01 spesific request, I ask gniibe to consider about case design with physical hole to tightly bind a token with keyring. Yuji 3 to 6 should be under a "policy" object connected to the main key to > make it public and let relying parties evaluate how much trust to give. > > Since smartcards have evolved (slowly...) and nowadays we have other > much-less-constrained alternatives (GnuK), I feel that many limitations > are just an heavy heritage that's becoming nonsensical. > > The reasons behind my list, point by point: > 1 - I'd like to roll the key used for reading mail every year, but > currently that would mean I'd have to use a new card every year or have > old keys on-disk, defeating the purpose of using a smartcard/token (from > my tests on actual smartcards, it's not hard to have room for 14 to 20 > keys on an 80k smartcard, more than 30 on a 144k one, WAY more are > possible on GnuK) > 2 - If I have to use my card to login on a possibly untrusted computer, > I don't want it to steal my PIN and sign/certify without me knowing it > 3 - Since NFC readers often have no pinpad (or could have easily been > tampered with) I don't want to expose my main PIN nor the same key I use > for "wired" auth > 4 - since HOTP changes at every use, it makes keyloggers nearly useless > and gives a third factor to the auth process (might be combined by > simple means -like digit-by-digit addition modulo 10- to the PIN) > 5 - I know, it's debatable and many see it as dangerous... but is it > more dangerous than keeping an on-disk (or on-paper) copy of the key? > Key export should be protected by a "certificate" (policy object defines > an "allowed KeyID for export" and the private key is exported only > encrypted to that KeyID); might even set a "fuse" to mark the fact that > the key have been exported > 6 - like in Yubikey NEO, a physical button to authorize some operations > can be useful (certification, signature, NFC PIN-less auth) > 7 - malaware currently can replace the hash of the object being signed > and the user can't know it till it's late... a small display could be > used to report some metadata (file name type and size for signature, > keyID and owner data for certification, peer ID for auth...) to give the > user more feedback > > What do you think? Complete BS or could something be considered for > inclusion? > > PS: 1 is the main reason I'm not yet using GPG much, even if I started > using it since DOS & FIDO-BBSs era... > > BYtE, > Diego. > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hugo at barrera.io Sun Feb 22 06:52:55 2015 From: hugo at barrera.io (Hugo Osvaldo Barrera) Date: Sun, 22 Feb 2015 02:52:55 -0300 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: References: <68F2AA9B-B192-4727-9AA3-2BC33CBE5434@mykolab.com> Message-ID: <20150222055255.GA19851@athena.barrera.io> On 2015-02-17 22:32, Lukas Pitschl wrote: > Hi all, > > > > The code that checks out our GPGTools_Core repository is pretty old already and it?s certainly a stupid way to do it. > At the time we assumed that it was safe to check it out via ssl from github, since curl would refuse to do so if there was a certificate error. Passing it directly to bash is definitely a bad idea. > We?ve discussed this internally and decided on removing the automated checkout completely. > By making it a manual task, everyone can checkout the code and verify that it?s in fact the code they wanted to checkout. > We will also look through our build system and check for similar code if there is. > > Hi, How about working using the github flow[1][2] instead of commiting straight to master? This would force at least *one* other dev to quickly code-review anything making it into the master branch. It's not incredibly burdensome, but it adds a second pair of eyes to every line - something quite valueable in a security proyect, IMHO. Just my two cents, [1]: https://guides.github.com/introduction/flow/index.html [2]: http://scottchacon.com/2011/08/31/github-flow.html -- Hugo Osvaldo Barrera A: Because we read from top to bottom, left to right. Q: Why should I start my reply below the quoted text? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From mlisten at hammernoch.net Sun Feb 22 09:29:20 2015 From: mlisten at hammernoch.net (=?windows-1252?Q?Ludwig_H=FCgelsch=E4fer?=) Date: Sun, 22 Feb 2015 09:29:20 +0100 Subject: Question about group line use in GnuPG In-Reply-To: <54E923B8.2060909@cajuntechie.org> References: <54E915DA.7040004@cajuntechie.org> <87egpi4x2j.fsf@alice.fifthhorseman.net> <54E923B8.2060909@cajuntechie.org> Message-ID: <54E99360.6020509@hammernoch.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Anthony, On 22.02.15 01:32, Anthony Papillion wrote: > Thanks for your quick response. It looks like I may have fixed the > problem. Basically, when I use Enigmail for the group line, it > needs it in the form of > > group =key1,key2,key3 > > But when I do it from the terminal, it needs to be in the form of > > group pgpnet at yahoogroups.com=key1,key2,key3 > > Copying the group line in my gpg.conf file and removing the > brackets made if work as expected. Which Enigmail version are you using? Ludwig -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJU6ZNfAAoJEDrb+m0Aoeb+KRsP/iWPAGA5trEZ3GniSDrTVwC8 3g9b3gtN9whV/nwd/LikM5MbzzqjTnVvoETKo2HwWzxRhuS3sCzfwMQZwxjwxGO/ GHFNyRXgvBEbTf8vTCNasLMGracnZZ/iGhFP066sbfRmoxhrf6bqcMzqMec2YGP7 UIWFJXuFjRBWeKSxXDToWbST9VXqyEybZbZVa8fKxjqZTCqMe11wk+pUo+k7dJkt dHUasD5j2BXQOjabS67n+85rqEhS9B4g+x03jTJ5kbJmf7SQHnx2MWnt3dOUWhbq f5Qxw9eLGeIXmFDF5o9TET+wK3OiumHLZl9NJEL5Cgc0APdgtk6gDQ2y2WFtiEYL kaVvkpRZf/Y18B3vQl4pJX+327d4bTMc9s096j4dL0gixBxCjk3E3tccQsLH09HS L3Ei5eF9Qd/gnQ0Q6u6oluM9jldPs45gjImKPq/QfHHXt6HUzV8hBG6DymW9jOy1 KeyIoWxziyEReB0LPMP/9dznyEf8a4Rm+SIVftufxXZ9033gETyUrjQ9CfmnBrxt 5+PTNfy0ZmWir7KAKgwh+O2nAm8S3yKgiunHTGqwiqc9Yh+kd23Q8tyRtl7WGOo0 s1ZWYX9UeN5zFLQOUA/MhahD2IafjX2s13eW6I8Y4WxJlACTFV5GHsZsvBuSjCsW Mq3brP/0NTwSU4oozPMe =mWCU -----END PGP SIGNATURE----- From ndk.clanbo at gmail.com Sun Feb 22 11:53:20 2015 From: ndk.clanbo at gmail.com (NdK) Date: Sun, 22 Feb 2015 11:53:20 +0100 Subject: Whishlist for next-gen card In-Reply-To: References: <54E6F12D.40504@gmail.com> Message-ID: <54E9B520.5040605@gmail.com> Il 22/02/2015 01:46, Yuji -UG- Imai ha scritto: > For token type card, how about appending one more usb port to connect > keyboard? It's just for inputing PIN/passphrase or out-of-bound auth > by hitting the Enter key. USB ten keys like V7 KP0N1-7N0P Numeric keypad > looks suitable for this purpose. Micro USB plug may be prefarable > for compact board design. The problem with off-the-shelf keyboards is that they usually radiate a pattern that's recognizeable from some distance. The usual scan on a matrix keyboard activates one column at a time in fixed order, then checks the rows (possibly one at a time). A safer scan activates all columns at once, senses the rows, then changes columns to inputs and rows to outputs activating only the one where the pressed key is and finally determining the corresponding column. This doesn't generate a recognizeable pattern. > I don't like wireless features by two reasons. Uh? Neither do I. I never understood the reasoning behind IR receiver for FST-01. > It may introduce complexity for middleware > of the card. I like KISS. Another is break visibility to check HSM > composition validness. Yup. And it's easily snoopable. > For FST-01 spesific request, I ask gniibe to consider about case > design with physical hole > to tightly bind a token with keyring. That's good. But I'd avoid plastic in favour of aluminium :) BYtE, Diego. From Mento at gpgtools.org Sun Feb 22 13:17:09 2015 From: Mento at gpgtools.org (Roman Zechmeister) Date: Sun, 22 Feb 2015 13:17:09 +0100 Subject: Integrate pinentry-mac into pinentry In-Reply-To: References: <68F2AA9B-B192-4727-9AA3-2BC33CBE5434@mykolab.com> <87sie3i7kb.fsf@vigenere.g10code.de> <873861d8eq.fsf@vigenere.g10code.de> <483FE4A0-C58E-44AB-AD78-EA5E1A80C8D1@gpgtools.org> <2786DC31-AEAC-4406-9143-94F32C74A644@webkeks.org> Message-ID: Hello! > It seems there's http://github.com/GPGTools/pinentry now, which is based on the original pinentry. This repo is my quick check, if it's possible to integrate pinentry-mac into pinentry. It's more or less our code for pinentry-mac, copied into the sub-dir macosx. The most of the code is old and ugly, but it works. So i'm thinking about a complete rewrite. There are some points, i want to clear, before i start to work on this: 1. On Mac OS X it's standard to use Xcode for builds and we're using it for pinentry-mac and all of our other tools. Is it okay for you, if we're using an Xcode-Project and Xcode, instead of plain automake, to build pinentry for Mac OS X? 2. Should we compile the required source-code from pinentry direct into pinentry-mac (as we do actually) or should we link against the libs? 3. pinentry-mac allows the user to store the passphrase in the Mac OS X keychain, by selecting a checkbox. To make this possible, we're patching gpg-agent, to pass the cacheid to pinentry. (OPTION cache-id=xxx) Without this option ? e.g. upstream gpg-agent ? pinentry-mac doesn't allow the user to store the passphrase. How should we solve this in the future? 4. pinentry-mac allows the calling app to define a custom message to show. This is implemented using PINENTRY_USER_DATA. We allow placeholders like %KEYID and %USERID. To fill the placeholders, we parse the description from pinentry. This works in the most cases. The reason for this feature is, to allow some more informative and readable messages. e.g. We can tell the user for which email/file, he enters the passphrase. What do you think about that? Is this a desirable feature for pinentry? 5. Using PINENTRY_USER_DATA we also allow to set a custom icon to be shown, like the standard Mac OS X security dialog. Opinions? Regards, Mento -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From patrick at enigmail.net Sun Feb 22 13:30:31 2015 From: patrick at enigmail.net (Patrick Brunschwig) Date: Sun, 22 Feb 2015 13:30:31 +0100 Subject: Question about group line use in GnuPG In-Reply-To: <54E99360.6020509__21860.1236273118$1424593855$gmane$org@hammernoch.net> References: <54E915DA.7040004@cajuntechie.org> <87egpi4x2j.fsf@alice.fifthhorseman.net> <54E923B8.2060909@cajuntechie.org> <54E99360.6020509__21860.1236273118$1424593855$gmane$org@hammernoch.net> Message-ID: <54E9CBE7.10702@enigmail.net> On 22.02.15 09:29, Ludwig H?gelsch?fer wrote: > Hi Anthony, > > On 22.02.15 01:32, Anthony Papillion wrote: > >> Thanks for your quick response. It looks like I may have fixed >> the problem. Basically, when I use Enigmail for the group line, >> it needs it in the form of > >> group =key1,key2,key3 > >> But when I do it from the terminal, it needs to be in the form >> of > >> group pgpnet at yahoogroups.com=key1,key2,key3 > >> Copying the group line in my gpg.conf file and removing the >> brackets made if work as expected. > > Which Enigmail version are you using? As far as I know, group entries should be space-separated, not by comma. I.e. group =key1 key2 key3 Furthermore, the current release version of Enigmail cannot handle <> as part of the group name. -Patrick From 2014-667rhzu3dc-lists-groups at riseup.net Sun Feb 22 15:09:11 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Sun, 22 Feb 2015 14:09:11 +0000 Subject: Question about group line use in GnuPG In-Reply-To: <54E923B8.2060909@cajuntechie.org> References: <54E915DA.7040004@cajuntechie.org> <87egpi4x2j.fsf@alice.fifthhorseman.net> <54E923B8.2060909@cajuntechie.org> Message-ID: <124533912.20150222140911@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Sunday 22 February 2015 at 12:32:56 AM, in , Anthony Papillion wrote: > Basically, when I use Enigmail > for the group line, it needs it in the form of > group = [snipped] My email client, The Bat!, requires that as well. It seems The Bat! (at least in the version I use) passes the email address complete with surrounding angle brackets to GnuPG to search for a key. > But when I do it from the terminal, it needs to be in > the form of > group pgpnet at yahoogroups.com= [snipped] If I encrypt from the command line (in Windows XP), including the angle brackets allows GnuPG to match on the group name:- gpg -ear filename > Copying the group line in my gpg.conf file and removing > the brackets made if work as expected. The second copy of the group line that I keep for matching when using GnuPG in a command window begins "group PGPNET = ". That way I only need type "gpg -ear PGPNET filename" for the command. - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net Virtual workspace, Virtual Office, Virtual Job -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJU6eMLXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwlwcH+wbJaB7zuxb2UKWODYa6d3Pf +FJwVbX0CL2yrnVMRKmTnx/NRu6MFNg0/xmSkyyAsDH8l+P2B31kE/OEWJp+S1Cz mK2CLZjDHc47lOnEawTH/9WLEA2bfD24RAatWnMmsdGnUo6l6EbQ6qekbSweyoyz XTw3x02Jd0WmBICYSIFt2oSGZL/C/3Kg/7OphJPPTLmSJNHjb52NWVso3YvIqziV loD0ba/TPgEL4Wab4gGcc4Mn0L234uAfjTmB/CEwC5IuX5tO+DyRg/SyYSG3oW95 x6rceqUZCUMssoHFiHbYwITCRy16PML4nKfJY7F6lWQ7zsG8mzLgYqAtutP3p/+I vgQBFgoAZgUCVOnjEl8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45PkyAQBJd44XDv6ztrG40xSdVoJVwUBc mjIU256eoa231q1cdQEA5tTi7tCXWiCIgnvsYMMFSWbcQnb75NEvVEVRc+DyQQE= =wk5m -----END PGP SIGNATURE----- From js-gnupg-users at webkeks.org Sun Feb 22 16:53:31 2015 From: js-gnupg-users at webkeks.org (Jonathan Schleifer) Date: Sun, 22 Feb 2015 16:53:31 +0100 Subject: Integrate pinentry-mac into pinentry In-Reply-To: References: <68F2AA9B-B192-4727-9AA3-2BC33CBE5434@mykolab.com> <87sie3i7kb.fsf@vigenere.g10code.de> <873861d8eq.fsf@vigenere.g10code.de> <483FE4A0-C58E-44AB-AD78-EA5E1A80C8D1@gpgtools.org> <2786DC31-AEAC-4406-9143-94F32C74A644@webkeks.org> Message-ID: Am 22.02.2015 um 13:17 schrieb Roman Zechmeister : > 1. On Mac OS X it's standard to use Xcode for builds and we're using it for pinentry-mac and all of our other tools. > Is it okay for you, if we're using an Xcode-Project and Xcode, instead of plain automake, to build pinentry for Mac OS X? I've seen a lot of projects where the Mac-specific part is nicely integrated into automake. The huge disadvantage of Xcode project files is that they are huge, can't make much use of the results from configure which often results in basically needing a different .xcproj file per combination of OS version and architecture (or at least different targets) and do not support cross-compiling at all. automake OTOH has none of these problems and is hardly any more work. Plus it's possible to edit build rules with an editor instead of a GUI that is only available for OS X. Oh, and then of course there's the problem that it's not possible to do reproducible builds with .xcproj files! I think Walter mentioned that he never touched OS X, so I'm guessing he'd prefer something that he can read and modify ;). > 4. pinentry-mac allows the calling app to define a custom message to show. > This is implemented using PINENTRY_USER_DATA. We allow placeholders like %KEYID and %USERID. > To fill the placeholders, we parse the description from pinentry. This works in the most cases. > The reason for this feature is, to allow some more informative and readable messages. e.g. We can tell the > user for which email/file, he enters the passphrase. > What do you think about that? Is this a desirable feature for pinentry? Hm, this sounds good at first, but after some thought, there are several issues. This could be used to trick the user into thinking he's doing the right thing when in fact he's not. What if you just don't use %KEYID, but write another key ID there that the user expects, when in fact you sign for something else? I think it would be better to have a dialog that shows all these information and then maybe a free form text for the justification, where no replacing takes place? > 5. Using PINENTRY_USER_DATA we also allow to set a custom icon to be shown, like the standard > Mac OS X security dialog. Opinions? I can't think of any problem with that and this sounds indeed like a good addition. -- Jonathan From lukele at dressyvagabonds.com Sun Feb 22 01:39:41 2015 From: lukele at dressyvagabonds.com (Lukas Pitschl | Dressy Vagabonds) Date: Sun, 22 Feb 2015 01:39:41 +0100 Subject: Please remove MacGPG from gnupg.org due to serious security concerns In-Reply-To: References: <68F2AA9B-B192-4727-9AA3-2BC33CBE5434@mykolab.com> <87sie3i7kb.fsf@vigenere.g10code.de> <873861d8eq.fsf@vigenere.g10code.de> <483FE4A0-C58E-44AB-AD78-EA5E1A80C8D1@gpgtools.org> <2786DC31-AEAC-4406-9143-94F32C74A644@webkeks.org> Message-ID: Hi Jonathan, yes, we've created a quick prototype today which is only a start at looking how it ould best be done. We pushed it to github only, so that our other team members could have a look at it. After we decide how to go forward from hear, we'll split up the commits with proper comments. Thanks for the comments, we'll have a look and incorporate those as we continue. Best, Lukas Von meinem iPhone gesendet > Am 22.02.2015 um 01:25 schrieb Jonathan Schleifer : > >> Am 20.02.2015 um 11:48 schrieb Lukas Pitschl : >> >> Pinentry-mac is one project we?ve ?revived? and thus only added stuff on top of the old code instead of refactoring it. >> We?ve been planning to do that for a long time now though, so we?ll definitely look into that and check out how other UIs do it, like GTK. > > It seems there's http://github.com/GPGTools/pinentry now, which is based on the original pinentry. Unfortunately, as of now, it's just one huge commit on top of it. Still, I did a *very* quick review (so don't blame me if I overlooked something :P) and left a few comments. > > -- > Jonathan > From Mento at gpgtools.org Sun Feb 22 05:18:43 2015 From: Mento at gpgtools.org (Roman Zechmeister) Date: Sun, 22 Feb 2015 05:18:43 +0100 Subject: Integrate pinentry-mac into pinentry In-Reply-To: References: <68F2AA9B-B192-4727-9AA3-2BC33CBE5434@mykolab.com> <87sie3i7kb.fsf@vigenere.g10code.de> <873861d8eq.fsf@vigenere.g10code.de> <483FE4A0-C58E-44AB-AD78-EA5E1A80C8D1@gpgtools.org> <2786DC31-AEAC-4406-9143-94F32C74A644@webkeks.org> Message-ID: <0C1E36FB-F69D-4822-8243-D34C3B6A3644@gpgtools.org> Hello! > It seems there's http://github.com/GPGTools/pinentry now, which is based on the original pinentry. This repo is my quick check, if it's possible to integrate pinentry-mac into pinentry. It's more or less our code for pinentry-mac, copied into the sub-dir macosx. The most of the code is old and ugly, but it works. So i'm thinking about a complete rewrite. There are some points, i want to clear, before i start to work on this: 1. On Mac OS X it's standard to use Xcode for builds and we're using it for pinentry-mac and all of our other tools. Is it okay for you, if we're using an Xcode-Project and Xcode, instead of plain automake, to build pinentry for Mac OS X? 2. Should we compile the required source-code from pinentry direct into pinentry-mac (as we do actually) or should we link against the libs? 3. pinentry-mac allows the user to store the passphrase in the Mac OS X keychain, by selecting a checkbox. To make this possible, we're patching gpg-agent, to pass the cacheid to pinentry. (OPTION cache-id=xxx) Without this option ? e.g. upstream gpg-agent ? pinentry-mac doesn't allow the user to store the passphrase. How should we solve this in the future? 4. pinentry-mac allows the calling app to define a custom message to show. This is implemented using PINENTRY_USER_DATA. We allow placeholders like %KEYID and %USERID. To fill the placeholders, we parse the description from pinentry. This works in the most cases. The reason for this feature is, to allow some more informative and readable messages. e.g. We can tell the user for which email/file, he enters the passphrase. What do you think about that? Is this a desirable feature for pinentry? 5. Using PINENTRY_USER_DATA we also allow to set a custom icon to be shown, like the standard Mac OS X security dialog. Opinions? Regards, Mento -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mail at joed.hu Mon Feb 23 00:33:57 2015 From: mail at joed.hu (=?iso-8859-2?Q?Dubravszky_J=F3zsef?=) Date: Mon, 23 Feb 2015 00:33:57 +0100 Subject: X509 CSR signed with card key Message-ID: <001901d04ef8$0aeec320$20cc4960$@joed.hu> Hello, I was not able to find a solution in the archives, so I post it here. I need to generate X509 Certificate Signing Requests for one of my GnuPG subkeys stored on an OpenPGP card. Now I need a mediator tool (openpgp2ssh from The Monkeysphere Project) to convert my private key to PEM format that can be used to make CSR with OpenSSL. It is rather tedious and I need to use a special separated environment to access private keys. Is there any way to create an X509 CSR signed with the private key stored on the card? Or any means where OpenSSL creates the CSR and asks the card to sign the request with the card key? I know these are different worlds, but I need to make them meet somehow. Thanks. Dubravszky J?zsef mail at joed.hu +36 30 435 7816 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dgouttegattat at incenp.org Mon Feb 23 01:44:22 2015 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Mon, 23 Feb 2015 01:44:22 +0100 Subject: X509 CSR signed with card key In-Reply-To: <001901d04ef8$0aeec320$20cc4960$@joed.hu> References: <001901d04ef8$0aeec320$20cc4960$@joed.hu> Message-ID: <54EA77E6.4060809@incenp.org> On 02/23/2015 12:33 AM, Dubravszky J?zsef wrote: > Is there any way to create an X509 CSR signed with the private key stored on > the card? Yes, you can use the gpgsm(1) tool for that. Make sure your card is in the card reader, then: $ gpgsm --armor --output mycsr.pem --gen-key You?ll be prompted to select what kind of key you want, choose ?Existing key from card? (make sure your card is in the reader). Then select which of the card keys you want to use (the signing key, the encryption key, or the authentication key) and the intended use of the future certificate. At the end of the procedure, you?ll be prompted for your PIN in order to sign the CSR. The documentation of Scute [1] has a complete example (it uses gpgsm-gencert.sh, a deprecated helper script, instead of the above command, but the procedure is almost the same). Damien [1] http://www.scute.org/scute.html/Certificate-Preparation.html#Certificate-Preparation -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From chdiza at gmail.com Mon Feb 23 05:47:01 2015 From: chdiza at gmail.com (Charles Diza) Date: Sun, 22 Feb 2015 23:47:01 -0500 Subject: Integrate pinentry-mac into pinentry In-Reply-To: References: <68F2AA9B-B192-4727-9AA3-2BC33CBE5434@mykolab.com> <87sie3i7kb.fsf@vigenere.g10code.de> <873861d8eq.fsf@vigenere.g10code.de> <483FE4A0-C58E-44AB-AD78-EA5E1A80C8D1@gpgtools.org> <2786DC31-AEAC-4406-9143-94F32C74A644@webkeks.org> Message-ID: On Sun, Feb 22, 2015 at 7:17 AM, Roman Zechmeister wrote: > Hello! > > > It seems there's http://github.com/GPGTools/pinentry now, which is > based on the original pinentry. > > This repo is my quick check, if it's possible to integrate pinentry-mac > into pinentry. > It's more or less our code for pinentry-mac, copied into the sub-dir > macosx. > The most of the code is old and ugly, but it works. So i'm thinking about > a complete rewrite. > > > There are some points, i want to clear, before i start to work on this: > > 1. On Mac OS X it's standard to use Xcode for builds and we're using it > for pinentry-mac and all of our other tools. > Is it okay for you, if we're using an Xcode-Project and Xcode, instead of > plain automake, to build pinentry for Mac OS X? > Whatever happens here, a vanilla pinentry MUST still be buildable on older MacOSX systems. Pinentry-mac and its Xcodeproj have long since abandoned 10.4, 10.5, and (I think) 10.6. Users on those systems should still be able to build a non-GUI pinentry (as they can now), so an Xcode project should only come into play for newer systems. -Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniele at grinta.net Mon Feb 23 23:51:48 2015 From: daniele at grinta.net (Daniele Nicolodi) Date: Mon, 23 Feb 2015 23:51:48 +0100 Subject: Surprising command line options handling Message-ID: <54EBAF04.6010403@grinta.net> Hello, I've been struggling quite a long while today trying to understand why the following command does not do what I expected: gpg --export-secret-subkeys 41E999D7! \ --export-options export-reset-subkey-passwd It does not reset the password on the exported subkey. After some head scratching I recognized that gpg stop parsing arguments when it encounters the key id and ignores what follows. This is probably caused by the fact that whatever follows the first key id is also interpreted as a possible key id, and that gpg by default does not error out on invalid key ids. Please correct me if I'm wrong. There is a reason why gpg does not choke on bad key ids? There is a way to make the key id parsing strict and avoid surprises as the one above? Thanks. Cheers, Daniele From dougb at dougbarton.email Tue Feb 24 00:19:55 2015 From: dougb at dougbarton.email (Doug Barton) Date: Mon, 23 Feb 2015 15:19:55 -0800 Subject: Surprising command line options handling In-Reply-To: <54EBAF04.6010403@grinta.net> References: <54EBAF04.6010403@grinta.net> Message-ID: <54EBB59B.3070501@dougbarton.email> On 2/23/15 2:51 PM, Daniele Nicolodi wrote: > Hello, > > I've been struggling quite a long while today trying to understand why > the following command does not do what I expected: > > gpg --export-secret-subkeys 41E999D7! \ > --export-options export-reset-subkey-passwd > > It does not reset the password on the exported subkey. > > After some head scratching I recognized that gpg stop parsing arguments > when it encounters the key id and ignores what follows. That's not 100% accurate, but I won't quibble. :) The man page makes it very clear that the format is as follows: gpg2 [--homedir dir] [--options file] [options] command [args] options come before commands, and anything after the command is interpreted as an argument to the command. hope this helps, Doug From daniele at grinta.net Tue Feb 24 00:59:07 2015 From: daniele at grinta.net (Daniele Nicolodi) Date: Tue, 24 Feb 2015 00:59:07 +0100 Subject: Surprising command line options handling In-Reply-To: <54EBB59B.3070501@dougbarton.email> References: <54EBAF04.6010403@grinta.net> <54EBB59B.3070501@dougbarton.email> Message-ID: <54EBBECB.5090107@grinta.net> On 24/02/15 00:19, Doug Barton wrote: > On 2/23/15 2:51 PM, Daniele Nicolodi wrote: >> Hello, >> >> I've been struggling quite a long while today trying to understand why >> the following command does not do what I expected: >> >> gpg --export-secret-subkeys 41E999D7! \ >> --export-options export-reset-subkey-passwd >> >> It does not reset the password on the exported subkey. >> >> After some head scratching I recognized that gpg stop parsing arguments >> when it encounters the key id and ignores what follows. > > That's not 100% accurate, but I won't quibble. :) > > The man page makes it very clear that the format is as follows: > > gpg2 [--homedir dir] [--options file] [options] command [args] > > options come before commands, and anything after the command is > interpreted as an argument to the command. In retrospect this is quite clear. However, the ordering is not really enforced: this gpg --export-secret-subkeys \ --export-options export-reset-subkey-passwd --armor \ whatever 41E999D7! or this gpg --export-secret-subkeys \ --export-options export-reset-subkey-passwd whatever --armor \ 41E999D7! appear to be valid command lines. I find it surprising that unrecognized tokens are simply ignored. Wouldn't it be preferable to error out, at least on unrecognized options? Cheers, Daniele From daniele at grinta.net Tue Feb 24 01:36:25 2015 From: daniele at grinta.net (Daniele Nicolodi) Date: Tue, 24 Feb 2015 01:36:25 +0100 Subject: Unattended signing In-Reply-To: <87egpj5bb8.fsf@alice.fifthhorseman.net> References: <54E4DDFB.1010405@grinta.net> <87egpj5bb8.fsf@alice.fifthhorseman.net> Message-ID: <54EBC789.3010704@grinta.net> Hello Daniel, thanks for your reply. On 21/02/15 20:11, Daniel Kahn Gillmor wrote: > On Wed 2015-02-18 13:46:19 -0500, Daniele Nicolodi wrote: >> I have a sufficient trust in the security of the server where the >> automated process runs, but I would like to reduce to a minimum the risks. > > there are risks with unattended signing in general, related to what > messages you allow to get passed to your system. I'm sure you've > already thought about this, but i'll just put it out there in case > someone else reading this later hasn't thought about it enough. I was not very clear on this: the unattended signing is performed by an application that collects some sensible data and sends them by email encrypted and signed. >> What is the best practices in such cases? I can imagine several >> possible options: using a subkey of my key (is it possible to remove >> passphrase protection from a subkey?), using a dedicated key, using a >> subkey of a dedicated key and periodically rotate such subkey. > > Using a dedicated key for your system would clearly be better than using > your own personal key, but i don't know if it meets your other > requirements (we don't know your requirements for the system). > > Using a subkey is a reasonable approach, and rotating (and destroying) > the secret key of the rotated subkey is not a bad idea. What do you exactly mean by "destroying"? Isn't setting a suitable expire date enough? Thanks. Cheers, Daniele From wk at gnupg.org Tue Feb 24 09:34:09 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 24 Feb 2015 09:34:09 +0100 Subject: Surprising command line options handling In-Reply-To: <54EBBECB.5090107@grinta.net> (Daniele Nicolodi's message of "Tue, 24 Feb 2015 00:59:07 +0100") References: <54EBAF04.6010403@grinta.net> <54EBB59B.3070501@dougbarton.email> <54EBBECB.5090107@grinta.net> Message-ID: <8761arzp1a.fsf@vigenere.g10code.de> On Tue, 24 Feb 2015 00:59, daniele at grinta.net said: > However, the ordering is not really enforced: this Right. Options and commands are actuallay interchangeable but that is an undocumented features. In fact the only difference between a command and an option is that tehre may only be one command but many options. And the error message for a command is slightly different. > I find it surprising that unrecognized tokens are simply ignored. > Wouldn't it be preferable to error out, at least on unrecognized options? GnuPG does not follow the common GNU model of interchangeable options and args. It is modeled like a classic Unix tool. Using the special option '--' indicates that everything what follows are args and using this is suggested to avoid args beeing interpreted as options. No, we can't error out on an arg which looks like an option because that may actually be a valid argument. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From peter at digitalbrains.com Tue Feb 24 12:10:20 2015 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 24 Feb 2015 12:10:20 +0100 Subject: Surprising command line options handling In-Reply-To: <8761arzp1a.fsf@vigenere.g10code.de> References: <54EBAF04.6010403@grinta.net> <54EBB59B.3070501@dougbarton.email> <54EBBECB.5090107@grinta.net> <8761arzp1a.fsf@vigenere.g10code.de> Message-ID: <54EC5C1C.7070402@digitalbrains.com> On 24/02/15 09:34, Werner Koch wrote: > No, we can't error out on an arg which looks like an option because that > may actually be a valid argument. However, if running interactively and --batch is not specified, might it be useful to print "Warning: --export-options did not match any key" with the command line Daniele tried in the OP, so people more quickly recognise that GnuPG is trying to match it to a key rather than interpret it as an option? It might save on some struggling and head scratching... The warning would also help in other cases. What if I want to export keys A, B and C, but match B wrongly. GnuPG doesn't complain, and I end up with a file with exported keys. Only later do I realise B is not among them... This surprising command line handling has come up here from time to time, I'm sure it was discussed before... I just can't remember... I think this point isn't covered in the FAQ yet. I suggest we come up with a question and answer that cover this case. Something like "GnuPG ignores options I specify on the command line!" as a question that isn't a question. Preferably, we make the answer an answer, though. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From daniele at grinta.net Tue Feb 24 12:24:09 2015 From: daniele at grinta.net (Daniele Nicolodi) Date: Tue, 24 Feb 2015 12:24:09 +0100 Subject: Surprising command line options handling In-Reply-To: <8761arzp1a.fsf@vigenere.g10code.de> References: <54EBAF04.6010403@grinta.net> <54EBB59B.3070501@dougbarton.email> <54EBBECB.5090107@grinta.net> <8761arzp1a.fsf@vigenere.g10code.de> Message-ID: <54EC5F59.4080404@grinta.net> On 24/02/15 09:34, Werner Koch wrote: >> I find it surprising that unrecognized tokens are simply ignored. >> Wouldn't it be preferable to error out, at least on unrecognized options? > > GnuPG does not follow the common GNU model of interchangeable options > and args. It is modeled like a classic Unix tool. Using the special > option '--' indicates that everything what follows are args and using > this is suggested to avoid args beeing interpreted as options. > > No, we can't error out on an arg which looks like an option because that > may actually be a valid argument. Hello Werner, thank for your answer. Trying to better understand gnupg command line argument parsing I found that the real confusing thing is that arguments can be silently ignored: gpg --list-keys foo results in an error if there is no key matching "foo", however gpg --list-keys 41E999D7 foo does not result in an error and the fact that "foo" does not match any is not signaled to the user, if there is a key that matches "41E999D7". I see that in the 2.1 branch there is indeed a check and a warning for arguments that look like options (start with "--") so I must not be the only one that found this confusing :) Why do not error out if an argument cannot be used to identify a key? I think that signaling to the user that one part of the command line has not been successfully interpreted is good practice. Cheers, Daniele From leonard.dallot at taztag.com Tue Feb 24 15:55:51 2015 From: leonard.dallot at taztag.com (=?ISO-8859-1?Q?L=E9onard?= Dallot) Date: Tue, 24 Feb 2015 15:55:51 +0100 Subject: GNU-divert-to-card S2K format Message-ID: <1424789751.3568.4.camel@taztag.com> Hello, I am trying to write a program that read GPG privates keys that have been exported to a GPG smartcard using GPG. Those keys are encoded unsing a S2K Specifier that is described in RFC 4880 as "experimental" (Tag 101). GPG (using gpg --list-packets) describes this as "gnu-divert-to-card S2K", followed by a serial number. I have tried to find a description of this S2K format, but I haven't found one. Does anyone know where I can find a description of this "experimental" S2K ? Thanks a lot for your help, L?onard From errol at askerrol.org Tue Feb 24 17:23:36 2015 From: errol at askerrol.org (Errol Casey) Date: Tue, 24 Feb 2015 11:23:36 -0500 Subject: Compiled binaries execute but exit with "Abort" In-Reply-To: <8761axbsw8.fsf@vigenere.g10code.de> References: <874mqjooyl.fsf@vigenere.g10code.de> <87a90bjmzl.fsf@vigenere.g10code.de> <8761axbsw8.fsf@vigenere.g10code.de> Message-ID: i will try going back to the older version of libgpg-error This is the order of the build I did; if there are versions of packages that don't require pth. Let me know and I will try to rebuild with different versions 1. Build and install pth 2.07 2. Build and install libgpg-error 1.18 (due to another package saying it needed a newer version that what I had. I think I had older than 1.12) 3. Build and install libgcrypt 1.6.2 4. Build and install libassuan 2.2.0 5. Build and install libksba 1.3.2 6. Build gnupg 2.0.26 On Thu, Feb 19, 2015 at 2:31 PM, Werner Koch wrote: > On Thu, 19 Feb 2015 12:01, errol at askerrol.org said: > > Thanks. Now to figure out why make check fails but make works without > > error. Are there dependencies besides pth for libgpg-error? > > Are you using a recent Pth version? I recall that older Pth versions > had problems when used by programs which also make use of pthreads. > That was actually the reasons for the pcsc-wrapper used by scdaemon. > > My tests indicated that there was no more problem - on Linux. However, > this might be because glibc implements mutex directly and not in > libpthread. Thus we may have the same conflict as we had with older > glibc versions. > > A solution for you might be to go back to libgpg-error 1.12 which has no > mutexes and thus no need for pthreads. > > I doubt that we can do a real fix for that. I dropped Pth support for a > reason ;-). The only thing I can image is an environment variable > forcing libgpg-error to entire disable the mutex support. > > > Shalom-Salam, > > Werner > > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > -- Errol Casey errol at askerrol.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Tue Feb 24 17:52:23 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 24 Feb 2015 17:52:23 +0100 Subject: GNU-divert-to-card S2K format In-Reply-To: <1424789751.3568.4.camel@taztag.com> (=?utf-8?Q?=22L=C3=A9ona?= =?utf-8?Q?rd?= Dallot"'s message of "Tue, 24 Feb 2015 15:55:51 +0100") References: <1424789751.3568.4.camel@taztag.com> Message-ID: <87mw43w8u0.fsf@vigenere.g10code.de> On Tue, 24 Feb 2015 15:55, leonard.dallot at taztag.com said: > I have tried to find a description of this S2K format, but I haven't > found one. Does anyone know where I can find a description of this > "experimental" S2K ? doc/DETAILS shows this * GNU extensions to the S2K algorithm S2K mode 101 is used to identify these extensions. After the hash algorithm the 3 bytes "GNU" are used to make clear that these are extensions for GNU, the next bytes gives the GNU protection mode - 1000. Defined modes are: - 1001 :: Do not store the secret part at all. - 1002 :: A stub to access smartcards (not used in 1.2.x) for everything else you need to look at the code (parse-packet.c) Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From peter at digitalbrains.com Tue Feb 24 19:49:48 2015 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 24 Feb 2015 19:49:48 +0100 Subject: GNU-divert-to-card S2K format In-Reply-To: <87mw43w8u0.fsf@vigenere.g10code.de> References: <1424789751.3568.4.camel@taztag.com> <87mw43w8u0.fsf@vigenere.g10code.de> Message-ID: <54ECC7CC.30404@digitalbrains.com> On 24/02/15 17:52, Werner Koch wrote: > for everything else you need to look at the code (parse-packet.c) RFC 4880 specifies that for a string-to-key usage octet of 255, the final two bytes are a checksum, but it /is/ part of the encrypted data for v4 keys. I was curious and also had a look at the packets and the source. For the divert-to-card s2k, RFC 4880 is not very appropriate, and section 5.5.3 should, I think, be freely interpreted as: > The packet contains: > > - A Public-Key or Public-Subkey packet, as described above. > > - One octet indicating string-to-key usage conventions. Zero > indicates that the secret-key data is not encrypted. 255 or 254 > indicates that a string-to-key specifier is being given. Any > other value is a symmetric-key encryption algorithm identifier. 255 for plain checksum s2k > > - [Optional] If string-to-key usage octet was 255 or 254, a one- > octet symmetric encryption algorithm. cipher algo 0 > > - [Optional] If string-to-key usage octet was 255 or 254, a > string-to-key specifier. The length of the string-to-key > specifier is implied by its type, as described above. specifier 110 hash algo 0 3 bytes prefix GNU (together 5 bytes) > > - [Optional] If secret data is encrypted (string-to-key usage octet > not zero), an Initial Vector (IV) of the same length as the > cipher's block size. Used to store up to 16 bytes of serial number > - Plain or encrypted multiprecision integers comprising the secret > key data. These algorithm-specific fields are as described > below. > > - If the string-to-key usage octet is zero or 255, then a two-octet > checksum of the plaintext of the algorithm-specific portion (sum > of all octets, mod 65536). If the string-to-key usage octet was > 254, then a 20-octet SHA-1 hash of the plaintext of the > algorithm-specific portion. This checksum or hash is encrypted > together with the algorithm-specific fields (if string-to-key > usage octet is not zero). Note that for all other values, a > two-octet checksum is required. This whole block is absent! Somehow I expected no MPI's but two bytes where the checksum should be. This is not the case. Note that the serial number for OpenPGP cards has the following format: D2 76 00 01 24 RID (Registered Application Provider Identifier)[1] for FSFE 01 Application identifier for OpenPGP Application xx xx Version number: I've got 01 01 (1.1) and 02 00 (2.0) cards xx xx Manufacturer: I've got 00 01 PPC Card Systems 00 05 ZeitControl The list is in g10/card-util.c xx xx xx xx Serial number; note the duplicate use of the name; unique for a manufacturer (unless manufacturer in range ff 00 to ff fe) 00 00 Reserved for Future Use 16 bytes in total Cipher algo and hash algo are written as 0, but don't seem to be used/checked on read. I just wrote that up because I think I figured it out and didn't want the effort to go to waste... It is rather unchecked. HTH, Peter. [1] http://www.ansi.org/other_services/registration_programs/rid.aspx?menuid=10 -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From errol at askerrol.org Tue Feb 24 20:07:26 2015 From: errol at askerrol.org (Errol Casey) Date: Tue, 24 Feb 2015 14:07:26 -0500 Subject: Compiled binaries execute but exit with "Abort" In-Reply-To: References: <874mqjooyl.fsf@vigenere.g10code.de> <87a90bjmzl.fsf@vigenere.g10code.de> <8761axbsw8.fsf@vigenere.g10code.de> Message-ID: got a working gpg2! Thanks. Now to figure out automation. Will post a separate thread regarding my issues with removing passphrase,. On Tue, Feb 24, 2015 at 11:23 AM, Errol Casey wrote: > i will try going back to the older version of libgpg-error > > This is the order of the build I did; if there are versions of packages > that don't require pth. > > Let me know and I will try to rebuild with different versions > > 1. Build and install pth 2.07 > 2. Build and install libgpg-error 1.18 (due to another package saying it > needed a newer version that what I had. I think I had older than 1.12) > 3. Build and install libgcrypt 1.6.2 > 4. Build and install libassuan 2.2.0 > 5. Build and install libksba 1.3.2 > 6. Build gnupg 2.0.26 > > > On Thu, Feb 19, 2015 at 2:31 PM, Werner Koch wrote: > >> On Thu, 19 Feb 2015 12:01, errol at askerrol.org said: >> > Thanks. Now to figure out why make check fails but make works without >> > error. Are there dependencies besides pth for libgpg-error? >> >> Are you using a recent Pth version? I recall that older Pth versions >> had problems when used by programs which also make use of pthreads. >> That was actually the reasons for the pcsc-wrapper used by scdaemon. >> >> My tests indicated that there was no more problem - on Linux. However, >> this might be because glibc implements mutex directly and not in >> libpthread. Thus we may have the same conflict as we had with older >> glibc versions. >> >> A solution for you might be to go back to libgpg-error 1.12 which has no >> mutexes and thus no need for pthreads. >> >> I doubt that we can do a real fix for that. I dropped Pth support for a >> reason ;-). The only thing I can image is an environment variable >> forcing libgpg-error to entire disable the mutex support. >> >> >> Shalom-Salam, >> >> Werner >> >> >> -- >> Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. >> >> > > > -- > Errol Casey > errol at askerrol.org > -- Errol Casey errol at askerrol.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From errol at askerrol.org Tue Feb 24 20:12:32 2015 From: errol at askerrol.org (Errol Casey) Date: Tue, 24 Feb 2015 14:12:32 -0500 Subject: Cannot remove passphrase (gnupg 2.0.26/solaris 10) Message-ID: When I use gpg2 --edit-key , and then use passwd to change/remove passphrase by entering a blank passphrase. I get hung in an input loop lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk x Please re-enter this passphrase x x x x Passphrase ________________________________________ x x x x x mqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj You don't want a passphrase - this is probably a *bad* idea! Do you really want to do this? (y/N) I truss the process (this is on Solaris 10), and I see it receiving the "y\r" but it doesn't continue. I can type N enter, and see 'N\r" also. So not sure if it is a local issue with tty, compile issue with pinentry, or gnupg? But it accepts my original passphrase, and hitting enter twice and selecting yes I want to do it, gets me to this last prompt and it will go no further. Hmmm: Thinking the compile/linking of pinentry is the cause. I've seen this before, but just ran pinentry --version ld.so.1: pinentry-curses: fatal: libiconv.so.2: open failed: No such file or directory Killed seems I have to modify LD_LIBRARY_PATH to get pinentry to work; but this change was made en enviornment when I tried changing passphrase above. Not sure where the input problem is being generated. $ pinentry --version pinentry-curses (pinentry) 0.9.0 $ gpg2 --version gpg (GnuPG) 2.0.26 libgcrypt 1.6.2 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: ~/.gnupg Supported algorithms: Pubkey: RSA, RSA, RSA, ELG, DSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 -- Errol Casey errol at askerrol.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From kloecker at kde.org Tue Feb 24 21:25:17 2015 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Tue, 24 Feb 2015 21:25:17 +0100 Subject: Unattended signing In-Reply-To: <54EBC789.3010704@grinta.net> References: <54E4DDFB.1010405@grinta.net> <87egpj5bb8.fsf@alice.fifthhorseman.net> <54EBC789.3010704@grinta.net> Message-ID: <1493958.z2CJGCAW4L@collossus.ingo-kloecker.de> On Tuesday 24 February 2015 01:36:25 Daniele Nicolodi wrote: > Hello Daniel, > > thanks for your reply. > > On 21/02/15 20:11, Daniel Kahn Gillmor wrote: > > On Wed 2015-02-18 13:46:19 -0500, Daniele Nicolodi wrote: > >> I have a sufficient trust in the security of the server where the > >> automated process runs, but I would like to reduce to a minimum the > >> risks. > > > > there are risks with unattended signing in general, related to what > > messages you allow to get passed to your system. I'm sure you've > > already thought about this, but i'll just put it out there in case > > someone else reading this later hasn't thought about it enough. > > I was not very clear on this: the unattended signing is performed by an > application that collects some sensible data and sends them by email > encrypted and signed. I can understand that you want to encrypt the sensible data. But why do you want to sign it? Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From dkg at fifthhorseman.net Tue Feb 24 23:16:20 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 24 Feb 2015 17:16:20 -0500 Subject: Unattended signing In-Reply-To: <54EBC789.3010704@grinta.net> References: <54E4DDFB.1010405@grinta.net> <87egpj5bb8.fsf@alice.fifthhorseman.net> <54EBC789.3010704@grinta.net> Message-ID: <87sidvt0p7.fsf@alice.fifthhorseman.net> On Mon 2015-02-23 19:36:25 -0500, Daniele Nicolodi wrote: > On 21/02/15 20:11, Daniel Kahn Gillmor wrote: >> Using a subkey is a reasonable approach, and rotating (and destroying) >> the secret key of the rotated subkey is not a bad idea. > > What do you exactly mean by "destroying"? Isn't setting a suitable > expire date enough? If your subkey is used for signing, and the subkey is expired, then you know that you will never want to make signatures with that key again. That is, only a malicious person who manages to compromise that key material can make signatures with it. So why are you keeping it around? setting a suitable expiry date *should* be enough, but destroying it is safer, and you have no need to keep the secret part of that key. --dkg From peter at digitalbrains.com Wed Feb 25 00:01:21 2015 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 25 Feb 2015 00:01:21 +0100 Subject: Unattended signing In-Reply-To: <87sidvt0p7.fsf@alice.fifthhorseman.net> References: <54E4DDFB.1010405@grinta.net> <87egpj5bb8.fsf@alice.fifthhorseman.net> <54EBC789.3010704@grinta.net> <87sidvt0p7.fsf@alice.fifthhorseman.net> Message-ID: <54ED02C1.2020302@digitalbrains.com> On 24/02/15 23:16, Daniel Kahn Gillmor wrote: > So why are you keeping it around? I suppose it depends on your definition of "destroying"... I think you'd be fine with setting an expiry date and "--delete-secret-key"-ing the subkey when the time comes. If you asked me to /destroy/ the key, I would look through my drawers for all backups I have and do a "shred" on them, and think really hard where any further copies might have ended up. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From Cathy.Smith at pnnl.gov Wed Feb 25 02:01:27 2015 From: Cathy.Smith at pnnl.gov (Smith, Cathy) Date: Wed, 25 Feb 2015 01:01:27 +0000 Subject: how to disable pinentry Message-ID: <270838A78E5A5342BB9669898FB4CF2011CF269C@EX10MBOX01.pnnl.gov> Hi Can someone tell the how to disable pinentry? I'd like to be able to run gpg --edit-key, or to open a password encrypted file without a GUI. I was able to do that in RHEL5, but so far, not in RHEL6 or CentOS 6. I have gpg 2.0.14 on CentOS 6.6 and RHEL6U6. I've tried to disable pinentry, without success, with the following 1. comment out use-agent in ~/.gnupg/gpg.conf 2. unset the following variables GPG_AGENT_INFO SSH_ASKPASS I've had less success on RHEL6 box as there is not a default line, use-agent, in the gpg.conf file. On the CentOS box, when I try to run the passwd command in gpg --edit-key, I get the message: can't connect to /home/foo/.gnupg/S.gpg-agent': No such file or directory I did not see a gpg-agent daemon running on either box. I ran a ps command while the gpg-edit-key was running. Thank you. Cathy --- Cathy L. Smith IT Engineer Pacific Northwest National Laboratory Operated by Battelle for the U.S. Department of Energy Phone:????? 509.375.2687 Fax:??? ????509.375.2330 Email:????? cathy.smith at pnnl.gov -----Original Message----- From: gnupg-users-bounces at gnupg.org [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of Robert J. Hansen Sent: Wednesday, March 23, 2011 12:32 PM To: gnupg-users at gnupg.org Subject: Re: Deniability On 3/23/11 3:06 PM, Mark H. Wood wrote: > My suspicion is that we never had anywhere near as much privacy as > many believe. A hundred years ago... I grew up in a small town of under 5,000, where the nearest city of more than 20,000 was an hour's drive away. Forget "a hundred years ago": having been back there recently for a funeral, I can tell you small towns are still that same way today. In a sense, I think this validates my thesis. In a small town the cost of sharing information about people within the town, to people within the town, is just about nil: you wind up having these conversations while you're at the service station filling up your tank, when you're in line at the grocery store, when you're ... etc. But having these same conversations with people outside the town involves effort, which in turn means that you can travel 100 miles and be reasonably confident nobody there has heard of you. I agree that the small-town phenomenon argues against the idea of an idyllic privacy past. I just think modern communications means the entire world is turning into a small-town phenomena. _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users From ndk.clanbo at gmail.com Wed Feb 25 06:49:52 2015 From: ndk.clanbo at gmail.com (NdK) Date: Wed, 25 Feb 2015 06:49:52 +0100 Subject: Unattended signing In-Reply-To: <54ED02C1.2020302@digitalbrains.com> References: <54E4DDFB.1010405@grinta.net> <87egpj5bb8.fsf@alice.fifthhorseman.net> <54EBC789.3010704@grinta.net> <87sidvt0p7.fsf@alice.fifthhorseman.net> <54ED02C1.2020302@digitalbrains.com> Message-ID: <54ED6280.2080906@gmail.com> Il 25/02/2015 00:01, Peter Lebbing ha scritto: > On 24/02/15 23:16, Daniel Kahn Gillmor wrote: > If you asked me to /destroy/ the key, I would look through my drawers for all > backups I have and do a "shred" on them, and think really hard where any further > copies might have ended up. Use a smartcard and generate on-card a new key that replaces the expired one. So an attacker could still abuse the key (it's not protected) but can not extract it to keep copies around. I really like SCs for signature and authentication[*] keys since often even if those keys are lost it's not a big deal as long as they can't be abused. [*] for auth, only if there's a centralized repository for the public key, else updating all instances of the pub key stored in devices could be a major hassle. BYtE, Diego. From dgouttegattat at incenp.org Wed Feb 25 10:06:24 2015 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Wed, 25 Feb 2015 10:06:24 +0100 Subject: how to disable pinentry In-Reply-To: <270838A78E5A5342BB9669898FB4CF2011CF269C@EX10MBOX01.pnnl.gov> References: <270838A78E5A5342BB9669898FB4CF2011CF269C@EX10MBOX01.pnnl.gov> Message-ID: <54ED9090.5060408@incenp.org> On 02/25/2015 02:01 AM, Smith, Cathy wrote: > Can someone tell the how to disable pinentry? I'd like to be able to run gpg --edit-key, or to open a password encrypted file without a GUI. You could use a console-only pinentry, such as pinentry-curses or pinentry-tty. Add the following line in your ~/.gnupg/gpg-agent.conf: pinentry-program /usr/bin/pinentry-tty > I have gpg 2.0.14 on CentOS 6.6 and RHEL6U6. > > I've tried to disable pinentry, without success, with the following > 1. comment out use-agent in ~/.gnupg/gpg.conf You cannot avoid using GnuPG Agent with gpg 2. As stated in the man page, gpg 2 always requires the agent, and the use-agent option has no effect. Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Wed Feb 25 10:49:52 2015 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 25 Feb 2015 10:49:52 +0100 Subject: GNU-divert-to-card S2K format In-Reply-To: <54ECC7CC.30404@digitalbrains.com> References: <1424789751.3568.4.camel@taztag.com> <87mw43w8u0.fsf@vigenere.g10code.de> <54ECC7CC.30404@digitalbrains.com> Message-ID: <54ED9AC0.9060502@digitalbrains.com> Oops, I realised I made a mistake. On 24/02/15 19:49, Peter Lebbing wrote: >> - [Optional] If string-to-key usage octet was 255 or 254, a >> string-to-key specifier. The length of the string-to-key >> specifier is implied by its type, as described above. > > specifier 110 > hash algo 0 > 3 bytes prefix GNU > (together 5 bytes) As is apparent from the part of doc/DETAILS Werner quoted from, this is missing something. It should be: S2K specifier 110 hash algo 0 3 bytes prefix GNU GNU protection mode specifier 2 (for mode 1002) Serial number length 16 (together 7 bytes) If the specified serial number length (16 for OpenPGP cards) is greater than 16, only 16 bytes of serial number are read regardless. Obviously, I could have made more mistakes. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From peter at digitalbrains.com Wed Feb 25 10:56:07 2015 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 25 Feb 2015 10:56:07 +0100 Subject: Unattended signing In-Reply-To: <54ED6280.2080906@gmail.com> References: <54E4DDFB.1010405@grinta.net> <87egpj5bb8.fsf@alice.fifthhorseman.net> <54EBC789.3010704@grinta.net> <87sidvt0p7.fsf@alice.fifthhorseman.net> <54ED02C1.2020302@digitalbrains.com> <54ED6280.2080906@gmail.com> Message-ID: <54ED9C37.5000506@digitalbrains.com> On 25/02/15 06:49, NdK wrote: > Use a smartcard and generate on-card a new key that replaces the expired > one. While I agree this could be a neat setup for OP, it might be overkill or even impractical given the signing speed of a smartcard. I don't know what volume of signatures will be issued. Anyway, I said "destroy backups". I would arrange for backups not to include the signing key in the first place. If the system needs to be restored from backup (which would be very seldomly), just issue a new signing key. Still, you might have forgotten to exclude it on a one-off backup you made at one time or another. And the point was that it is not /needed/ to destroy the key, so I'll stop focussing on destroying the key... heh... :S HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From michard.antoine at gmail.com Wed Feb 25 14:07:09 2015 From: michard.antoine at gmail.com (Antoine Michard) Date: Wed, 25 Feb 2015 14:07:09 +0100 Subject: Can't Encrypt in Freebsd 10.1 In-Reply-To: References: <87ppbsq4ff.fsf@vigenere.g10code.de> Message-ID: Hi, Still not working :( Got no idea why... #gpg -r 6349E5E0 -e test.txt Abort I've deleted my ~.gnupg directory and generate another key # gpg --list-keys /root/.gnupg/pubring.gpg ------------------------ pub 4096R/F2E7CBA5 2015-02-25 [expires: 2015-04-26] uid [ultimate] FreeBSD sub 4096R/BD0398E3 2015-02-25 [expires: 2015-04-26] And then try to encryp a file: # gpg -r F2E7CBA5 -e test.txt Abort 2014-12-09 16:50 GMT+01:00 Antoine Michard : > For the GPG Version > gpg (GnuPG) 2.0.26 > libgcrypt 1.6.1 > Copyright (C) 2013 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later < > http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > > Home: ~/.gnupg > Supported algorithms: > Pubkey: RSA, ELG, DSA > Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, > CAMELLIA128, CAMELLIA192, CAMELLIA256 > Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 > Compression: Uncompressed, ZIP, ZLIB, BZIP2 > > And the output of pkg info: > Name : libgpg-error > Version : 1.17 > Installed on : Mon Dec 8 15:32:57 CET 2014 > > Install is from port up-to-date and I reinstall later with recompil of all > dependencie > > Thanks for help me > > 2014-12-09 15:32 GMT+01:00 Werner Koch : > >> On Mon, 8 Dec 2014 17:34, michard.antoine at gmail.com said: >> >> > I've install it from port, everthing was fine but when I wanna try to >> > encryt, it says Abort ! >> >> Which GnuPG version is that? ("gpg --version"). >> What version of libgpg-error do you use? >> >> >> Shalom-Salam, >> >> Werner >> >> -- >> Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. >> >> > > > -- > Antoine Michard > -- Antoine Michard -------------- next part -------------- An HTML attachment was scrubbed... URL: From Cathy.Smith at pnnl.gov Wed Feb 25 17:51:23 2015 From: Cathy.Smith at pnnl.gov (Smith, Cathy) Date: Wed, 25 Feb 2015 16:51:23 +0000 Subject: how to disable pinentry In-Reply-To: <54ED9090.5060408@incenp.org> References: <270838A78E5A5342BB9669898FB4CF2011CF269C@EX10MBOX01.pnnl.gov> <54ED9090.5060408@incenp.org> Message-ID: <270838A78E5A5342BB9669898FB4CF2011CF30F6@EX10MBOX01.pnnl.gov> Damien Adding this line didn't work: pinentry-program /usr/bin/pinentry-tty The message was invalid option gpg: /home/foo/.gunpg/gpg.conf:242: invalid option The CentOS6 and RHEL6 distributions don't provide a /usr/bin/pinentry-tty. One of my goals of this is to be able to set a passphrase on a key in batch processing. Perhaps, there is another way to accomplish that? Thank you Cathy --- Cathy L. Smith IT Engineer Pacific Northwest National Laboratory Operated by Battelle for the U.S. Department of Energy Phone:????? 509.375.2687 Fax:??? ????509.375.2330 Email:????? cathy.smith at pnnl.gov -----Original Message----- From: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of Damien Goutte-Gattat Sent: Wednesday, February 25, 2015 1:06 AM To: gnupg-users at gnupg.org Subject: Re: how to disable pinentry On 02/25/2015 02:01 AM, Smith, Cathy wrote: > Can someone tell the how to disable pinentry? I'd like to be able to run gpg --edit-key, or to open a password encrypted file without a GUI. You could use a console-only pinentry, such as pinentry-curses or pinentry-tty. Add the following line in your ~/.gnupg/gpg-agent.conf: pinentry-program /usr/bin/pinentry-tty > I have gpg 2.0.14 on CentOS 6.6 and RHEL6U6. > > I've tried to disable pinentry, without success, with the following > 1. comment out use-agent in ~/.gnupg/gpg.conf You cannot avoid using GnuPG Agent with gpg 2. As stated in the man page, gpg 2 always requires the agent, and the use-agent option has no effect. Damien From Rob.Fries at ascensus.com Wed Feb 25 18:14:15 2015 From: Rob.Fries at ascensus.com (Rob Fries) Date: Wed, 25 Feb 2015 17:14:15 +0000 Subject: 7. RE: how to disable pinentry (Smith, Cathy) Message-ID: <3427d53bb41e409bb1429e81ed37e3ec@RDRE1-PEXCH02.rsd.crumprsd.com> Hi Cathy, We use /usr/libexec/gpg-preset-passphrase to set our passphrase. /usr/libexec/gpg-preset-passphrase -cP "$passphrase" $keygrip You would need to add this to your .gpg-agent.conf: allow-preset-passphrase you will need to get the KEYGRIP. The easiest way I found is: gpg2 --fingerprint --fingerprint --list-secret-keys | grep "fingerprint" | cut -d= -f2 | tr -d ' ' make sure you get the correct one for the correct key( note the above command shows double the number of keygrips for what you need.. ). and you may want to adjust your max-cache-ttl gpg-agent.conf too. If you want to forget a passphrase before the ttl is up, you can use gpg-preset-passphrase to forget it. Rel6 does provide a pinentry-curses program: /usr/bin/pinentry-curses Hope that helps! Message: 7 Date: Wed, 25 Feb 2015 16:51:23 +0000 From: "Smith, Cathy" To: Damien Goutte-Gattat , "gnupg-users at gnupg.org" Subject: RE: how to disable pinentry Message-ID: <270838A78E5A5342BB9669898FB4CF2011CF30F6 at EX10MBOX01.pnnl.gov> Content-Type: text/plain; charset="iso-8859-1" Damien Adding this line didn't work: pinentry-program /usr/bin/pinentry-tty The message was invalid option gpg: /home/foo/.gunpg/gpg.conf:242: invalid option The CentOS6 and RHEL6 distributions don't provide a /usr/bin/pinentry-tty. One of my goals of this is to be able to set a passphrase on a key in batch processing. Perhaps, there is another way to accomplish that? Thank you Cathy --- Cathy L. Smith IT Engineer Pacific Northwest National Laboratory Operated by Battelle for the U.S. Department of Energy Phone:????? 509.375.2687 Fax:??? ????509.375.2330 Email:????? cathy.smith at pnnl.gov CONFIDENTIALITY NOTICE: This message, including attachments, is intended to be viewed only by the addressee. It may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. No confidentiality or privilege is lost by any transmission error. This message may contain nonpublic personal information about consumers subject to the restrictions of the Gramm-Leach-Bliley Act and the Sarbanes-Oxley Act. You may not directly or indirectly reuse or disclose such information for any purpose except as permitted by law. Any dissemination, distribution or copying of this message is strictly prohibited without our prior written permission. If you are not an intended recipient, or if you have received this message in error, please notify us immediately by return e-mail and permanently remove the original message and any copies from your computer and all back-up systems. From matt at monaco.cx Wed Feb 25 19:22:50 2015 From: matt at monaco.cx (Matthew Monaco) Date: Wed, 25 Feb 2015 11:22:50 -0700 Subject: disconnected binding of sub and master keys Message-ID: <54EE12FA.6010207@monaco.cx> I think we should easily be able to create subkeys on our day-to-day machine, while maintaining an air-gapped master, without transferring secret material back and forth. This seems possible [1][2] using gpgsplit and possibly some hand editing of hex files. By operating an offline master setup, we are agreeing to more complexity and knowledge about openpgp details, but I think the leap from basic to offline master is a lot smaller than from offline master to "merging" subkeys. So, is there technical reason as to why this isn't straightforward? Is it a "patches welcome =)" type of thing? Or maybe you want to argue that I'm wasting my time trying to avoid writing secret data to a cd/sdcard/etc to bridge my airgap. The workflow that makes sense to me is for addkey to work even when "Secret parts of primary key are not available" (possibly with --expert flag), resulting an a file such as -bind-request.asc. On the master, --import -bind-request.asc should do the trick, but a dedicated command would be fine to. After this, an --export > .pub should be able to communicate the binding back to the active machine; however a -bind-ack.asc might be nice so the ultra-paranoid can inspect as little data as possible. This is for discussion. I'm not complaining that this hasn't been implemented or that someone needs to get to work! [1] http://atom.smasher.org/gpg/gpg-migrate.txt [2] https://lists.gnupg.org/pipermail/gnupg-users/2010-August/039307.html -Matt From Cathy.Smith at pnnl.gov Wed Feb 25 21:20:46 2015 From: Cathy.Smith at pnnl.gov (Smith, Cathy) Date: Wed, 25 Feb 2015 20:20:46 +0000 Subject: 7. RE: how to disable pinentry (Smith, Cathy) Message-ID: <270838A78E5A5342BB9669898FB4CF2011CF38E0@EX10MBOX01.pnnl.gov> Rob Thanks. I got an error when trying to do this. I created the gpg-agent.conf file in my home directory and added the directive: [cathy at foo ~]$ cat gpg-agent.conf allow-preset-passphrase [cathy at foo ~]$ [cathy at foo ~]$ /usr/libexec/gpg-preset-passphrase -cP"cry123" "4611 E023 7B7A 31FE 1388 0FAC 491E FBE6 302B 7D2D" gpg-preset-passphrase: can't connect to `/home/cathy/.gnupg/S.gpg-agent': No such file or directory gpg-preset-passphrase: caching passphrase failed: Input/output error Cathy --- Cathy L. Smith IT Engineer Pacific Northwest National Laboratory Operated by Battelle for the U.S. Department of Energy Phone:????? 509.375.2687 Fax:??? ????509.375.2330 Email:????? cathy.smith at pnnl.gov -----Original Message----- From: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of Rob Fries Sent: Wednesday, February 25, 2015 9:14 AM To: 'gnupg-users at gnupg.org' Subject: 7. RE: how to disable pinentry (Smith, Cathy) Hi Cathy, We use /usr/libexec/gpg-preset-passphrase to set our passphrase. /usr/libexec/gpg-preset-passphrase -cP "$passphrase" $keygrip You would need to add this to your .gpg-agent.conf: allow-preset-passphrase you will need to get the KEYGRIP. The easiest way I found is: gpg2 --fingerprint --fingerprint --list-secret-keys | grep "fingerprint" | cut -d= -f2 | tr -d ' ' make sure you get the correct one for the correct key( note the above command shows double the number of keygrips for what you need.. ). and you may want to adjust your max-cache-ttl gpg-agent.conf too. If you want to forget a passphrase before the ttl is up, you can use gpg-preset-passphrase to forget it. Rel6 does provide a pinentry-curses program: /usr/bin/pinentry-curses Hope that helps! Message: 7 Date: Wed, 25 Feb 2015 16:51:23 +0000 From: "Smith, Cathy" To: Damien Goutte-Gattat , "gnupg-users at gnupg.org" Subject: RE: how to disable pinentry Message-ID: <270838A78E5A5342BB9669898FB4CF2011CF30F6 at EX10MBOX01.pnnl.gov> Content-Type: text/plain; charset="iso-8859-1" Damien Adding this line didn't work: pinentry-program /usr/bin/pinentry-tty The message was invalid option gpg: /home/foo/.gunpg/gpg.conf:242: invalid option The CentOS6 and RHEL6 distributions don't provide a /usr/bin/pinentry-tty. One of my goals of this is to be able to set a passphrase on a key in batch processing. Perhaps, there is another way to accomplish that? Thank you Cathy --- Cathy L. Smith IT Engineer Pacific Northwest National Laboratory Operated by Battelle for the U.S. Department of Energy Phone:????? 509.375.2687 Fax:??? ????509.375.2330 Email:????? cathy.smith at pnnl.gov CONFIDENTIALITY NOTICE: This message, including attachments, is intended to be viewed only by the addressee. It may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. No confidentiality or privilege is lost by any transmission error. This message may contain nonpublic personal information about consumers subject to the restrictions of the Gramm-Leach-Bliley Act and the Sarbanes-Oxley Act. You may not directly or indirectly reuse or disclose such information for any purpose except as permitted by law. Any dissemination, distribution or copying of this message is strictly prohibited without our prior written permission. If you are not an intended recipient, or if you have received this message in error, please notify us immediately by return e-mail and permanently remove the original message and any copies from your computer and all back-up systems. _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users From Rob.Fries at ascensus.com Wed Feb 25 21:26:37 2015 From: Rob.Fries at ascensus.com (Rob Fries) Date: Wed, 25 Feb 2015 20:26:37 +0000 Subject: 7. RE: how to disable pinentry (Smith, Cathy) In-Reply-To: <270838A78E5A5342BB9669898FB4CF2011CF38E0@EX10MBOX01.pnnl.gov> References: <270838A78E5A5342BB9669898FB4CF2011CF38E0@EX10MBOX01.pnnl.gov> Message-ID: <824fe6f6ac164f6ea85b32175dc27954@RDRE1-PEXCH02.rsd.crumprsd.com> Hey Cathy, You need gpg-agent running with this setup. Per the error message, it can not connect to a running gpg-agent to enter the passphrase. Your gpg-agent.conf also needs to be with your other gpg configs under .gnupg. -Rob -----Original Message----- From: Smith, Cathy [mailto:Cathy.Smith at pnnl.gov] Sent: Wednesday, February 25, 2015 3:21 PM To: Rob Fries; 'gnupg-users at gnupg.org' Subject: RE: 7. RE: how to disable pinentry (Smith, Cathy) Rob Thanks. I got an error when trying to do this. I created the gpg-agent.conf file in my home directory and added the directive: [cathy at foo ~]$ cat gpg-agent.conf allow-preset-passphrase [cathy at foo ~]$ [cathy at foo ~]$ /usr/libexec/gpg-preset-passphrase -cP"cry123" "4611 E023 7B7A 31FE 1388 0FAC 491E FBE6 302B 7D2D" gpg-preset-passphrase: can't connect to `/home/cathy/.gnupg/S.gpg-agent': No such file or directory gpg-preset-passphrase: caching passphrase failed: Input/output error Cathy --- Cathy L. Smith IT Engineer Pacific Northwest National Laboratory Operated by Battelle for the U.S. Department of Energy Phone:????? 509.375.2687 Fax:??? ????509.375.2330 Email:????? cathy.smith at pnnl.gov -----Original Message----- From: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of Rob Fries Sent: Wednesday, February 25, 2015 9:14 AM To: 'gnupg-users at gnupg.org' Subject: 7. RE: how to disable pinentry (Smith, Cathy) Hi Cathy, We use /usr/libexec/gpg-preset-passphrase to set our passphrase. /usr/libexec/gpg-preset-passphrase -cP "$passphrase" $keygrip You would need to add this to your .gpg-agent.conf: allow-preset-passphrase you will need to get the KEYGRIP. The easiest way I found is: gpg2 --fingerprint --fingerprint --list-secret-keys | grep "fingerprint" | cut -d= -f2 | tr -d ' ' make sure you get the correct one for the correct key( note the above command shows double the number of keygrips for what you need.. ). and you may want to adjust your max-cache-ttl gpg-agent.conf too. If you want to forget a passphrase before the ttl is up, you can use gpg-preset-passphrase to forget it. Rel6 does provide a pinentry-curses program: /usr/bin/pinentry-curses Hope that helps! Message: 7 Date: Wed, 25 Feb 2015 16:51:23 +0000 From: "Smith, Cathy" To: Damien Goutte-Gattat , "gnupg-users at gnupg.org" Subject: RE: how to disable pinentry Message-ID: <270838A78E5A5342BB9669898FB4CF2011CF30F6 at EX10MBOX01.pnnl.gov> Content-Type: text/plain; charset="iso-8859-1" Damien Adding this line didn't work: pinentry-program /usr/bin/pinentry-tty The message was invalid option gpg: /home/foo/.gunpg/gpg.conf:242: invalid option The CentOS6 and RHEL6 distributions don't provide a /usr/bin/pinentry-tty. One of my goals of this is to be able to set a passphrase on a key in batch processing. Perhaps, there is another way to accomplish that? Thank you Cathy --- Cathy L. Smith IT Engineer Pacific Northwest National Laboratory Operated by Battelle for the U.S. Department of Energy Phone:????? 509.375.2687 Fax:??? ????509.375.2330 Email:????? cathy.smith at pnnl.gov CONFIDENTIALITY NOTICE: This message, including attachments, is intended to be viewed only by the addressee. It may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. No confidentiality or privilege is lost by any transmission error. This message may contain nonpublic personal information about consumers subject to the restrictions of the Gramm-Leach-Bliley Act and the Sarbanes-Oxley Act. You may not directly or indirectly reuse or disclose such information for any purpose except as permitted by law. Any dissemination, distribution or copying of this message is strictly prohibited without our prior written permission. If you are not an intended recipient, or if you have received this message in error, please notify us immediately by return e-mail and permanently remove the original message and any copies from your computer and all back-up systems. _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users CONFIDENTIALITY NOTICE: This message, including attachments, is intended to be viewed only by the addressee. It may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. No confidentiality or privilege is lost by any transmission error. This message may contain nonpublic personal information about consumers subject to the restrictions of the Gramm-Leach-Bliley Act and the Sarbanes-Oxley Act. You may not directly or indirectly reuse or disclose such information for any purpose except as permitted by law. Any dissemination, distribution or copying of this message is strictly prohibited without our prior written permission. If you are not an intended recipient, or if you have received this message in error, please notify us immediately by return e-mail and permanently remove the original message and any copies from your computer and all back-up systems. From Cathy.Smith at pnnl.gov Thu Feb 26 00:31:44 2015 From: Cathy.Smith at pnnl.gov (Smith, Cathy) Date: Wed, 25 Feb 2015 23:31:44 +0000 Subject: 7. RE: how to disable pinentry (Smith, Cathy) In-Reply-To: <824fe6f6ac164f6ea85b32175dc27954@RDRE1-PEXCH02.rsd.crumprsd.com> References: <270838A78E5A5342BB9669898FB4CF2011CF38E0@EX10MBOX01.pnnl.gov> <824fe6f6ac164f6ea85b32175dc27954@RDRE1-PEXCH02.rsd.crumprsd.com> Message-ID: <270838A78E5A5342BB9669898FB4CF2011CF3BBA@EX10MBOX01.pnnl.gov> Rob I'm not familiar with running gpg-agent. I've started with the man page. I don't see a process running. Cathy --- Cathy L. Smith IT Engineer Pacific Northwest National Laboratory Operated by Battelle for the U.S. Department of Energy Phone:????? 509.375.2687 Fax:??? ????509.375.2330 Email:????? cathy.smith at pnnl.gov -----Original Message----- From: Rob Fries [mailto:Rob.Fries at ascensus.com] Sent: Wednesday, February 25, 2015 12:27 PM To: Smith, Cathy; 'gnupg-users at gnupg.org' Subject: RE: 7. RE: how to disable pinentry (Smith, Cathy) Hey Cathy, You need gpg-agent running with this setup. Per the error message, it can not connect to a running gpg-agent to enter the passphrase. Your gpg-agent.conf also needs to be with your other gpg configs under .gnupg. -Rob -----Original Message----- From: Smith, Cathy [mailto:Cathy.Smith at pnnl.gov] Sent: Wednesday, February 25, 2015 3:21 PM To: Rob Fries; 'gnupg-users at gnupg.org' Subject: RE: 7. RE: how to disable pinentry (Smith, Cathy) Rob Thanks. I got an error when trying to do this. I created the gpg-agent.conf file in my home directory and added the directive: [cathy at foo ~]$ cat gpg-agent.conf allow-preset-passphrase [cathy at foo ~]$ [cathy at foo ~]$ /usr/libexec/gpg-preset-passphrase -cP"cry123" "4611 E023 7B7A 31FE 1388 0FAC 491E FBE6 302B 7D2D" gpg-preset-passphrase: can't connect to `/home/cathy/.gnupg/S.gpg-agent': No such file or directory gpg-preset-passphrase: caching passphrase failed: Input/output error Cathy --- Cathy L. Smith IT Engineer Pacific Northwest National Laboratory Operated by Battelle for the U.S. Department of Energy Phone:????? 509.375.2687 Fax:??? ????509.375.2330 Email:????? cathy.smith at pnnl.gov -----Original Message----- From: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of Rob Fries Sent: Wednesday, February 25, 2015 9:14 AM To: 'gnupg-users at gnupg.org' Subject: 7. RE: how to disable pinentry (Smith, Cathy) Hi Cathy, We use /usr/libexec/gpg-preset-passphrase to set our passphrase. /usr/libexec/gpg-preset-passphrase -cP "$passphrase" $keygrip You would need to add this to your .gpg-agent.conf: allow-preset-passphrase you will need to get the KEYGRIP. The easiest way I found is: gpg2 --fingerprint --fingerprint --list-secret-keys | grep "fingerprint" | cut -d= -f2 | tr -d ' ' make sure you get the correct one for the correct key( note the above command shows double the number of keygrips for what you need.. ). and you may want to adjust your max-cache-ttl gpg-agent.conf too. If you want to forget a passphrase before the ttl is up, you can use gpg-preset-passphrase to forget it. Rel6 does provide a pinentry-curses program: /usr/bin/pinentry-curses Hope that helps! Message: 7 Date: Wed, 25 Feb 2015 16:51:23 +0000 From: "Smith, Cathy" To: Damien Goutte-Gattat , "gnupg-users at gnupg.org" Subject: RE: how to disable pinentry Message-ID: <270838A78E5A5342BB9669898FB4CF2011CF30F6 at EX10MBOX01.pnnl.gov> Content-Type: text/plain; charset="iso-8859-1" Damien Adding this line didn't work: pinentry-program /usr/bin/pinentry-tty The message was invalid option gpg: /home/foo/.gunpg/gpg.conf:242: invalid option The CentOS6 and RHEL6 distributions don't provide a /usr/bin/pinentry-tty. One of my goals of this is to be able to set a passphrase on a key in batch processing. Perhaps, there is another way to accomplish that? Thank you Cathy --- Cathy L. Smith IT Engineer Pacific Northwest National Laboratory Operated by Battelle for the U.S. Department of Energy Phone:????? 509.375.2687 Fax:??? ????509.375.2330 Email:????? cathy.smith at pnnl.gov CONFIDENTIALITY NOTICE: This message, including attachments, is intended to be viewed only by the addressee. It may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. No confidentiality or privilege is lost by any transmission error. This message may contain nonpublic personal information about consumers subject to the restrictions of the Gramm-Leach-Bliley Act and the Sarbanes-Oxley Act. You may not directly or indirectly reuse or disclose such information for any purpose except as permitted by law. Any dissemination, distribution or copying of this message is strictly prohibited without our prior written permission. If you are not an intended recipient, or if you have received this message in error, please notify us immediately by return e-mail and permanently remove the original message and any copies from your computer and all back-up systems. _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users CONFIDENTIALITY NOTICE: This message, including attachments, is intended to be viewed only by the addressee. It may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. No confidentiality or privilege is lost by any transmission error. This message may contain nonpublic personal information about consumers subject to the restrictions of the Gramm-Leach-Bliley Act and the Sarbanes-Oxley Act. You may not directly or indirectly reuse or disclose such information for any purpose except as permitted by law. Any dissemination, distribution or copying of this message is strictly prohibited without our prior written permission. If you are not an intended recipient, or if you have received this message in error, please notify us immediately by return e-mail and permanently remove the original message and any copies from your computer and all back-up systems. From gniibe at fsij.org Thu Feb 26 01:43:39 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 26 Feb 2015 09:43:39 +0900 Subject: disconnected binding of sub and master keys In-Reply-To: <54EE12FA.6010207@monaco.cx> References: <54EE12FA.6010207@monaco.cx> Message-ID: <54EE6C3B.80009@fsij.org> On 02/26/2015 03:22 AM, Matthew Monaco wrote: > I think we should easily be able to create subkeys on our day-to-day machine, I'd understand your point. IIUC, you don't want to export "secret" from an air-gapped machine by any chance. The practice of having air-gapped master key is because of risk of attacks. In that practice, it is considered OK, having subkey on your day-to-day machine. But, your proposal goes further: creating subkey on a day-to-day machine. It worries me, a bit. There would be some cases (or troubles) that an air-gapped machine wouldn't have enough entropy (like using LiveCD or embedded). But, this particular issue should be fixed on that specific environment. Other than this point, it is highly recommended, in general, to create a key (master or subkey) on an air-gapped environment (if that's your practice). -- From Cathy.Smith at pnnl.gov Thu Feb 26 02:01:37 2015 From: Cathy.Smith at pnnl.gov (Smith, Cathy) Date: Thu, 26 Feb 2015 01:01:37 +0000 Subject: 7. RE: how to disable pinentry (Smith, Cathy) References: <270838A78E5A5342BB9669898FB4CF2011CF38E0@EX10MBOX01.pnnl.gov> <824fe6f6ac164f6ea85b32175dc27954@RDRE1-PEXCH02.rsd.crumprsd.com> Message-ID: <270838A78E5A5342BB9669898FB4CF2011CF3DBA@EX10MBOX01.pnnl.gov> Rob Apparently gpg-agent doesn't start automatically by default on CentOS6. I've read some different recommendations for how to configure that. Do you have any recommendations? Thanks Cathy --- Cathy L. Smith IT Engineer Pacific Northwest National Laboratory Operated by Battelle for the U.S. Department of Energy Phone:????? 509.375.2687 Fax:??? ????509.375.2330 Email:????? cathy.smith at pnnl.gov -----Original Message----- From: Smith, Cathy Sent: Wednesday, February 25, 2015 3:32 PM To: 'Rob Fries'; 'gnupg-users at gnupg.org' Subject: RE: 7. RE: how to disable pinentry (Smith, Cathy) Rob I'm not familiar with running gpg-agent. I've started with the man page. I don't see a process running. Cathy --- Cathy L. Smith IT Engineer Pacific Northwest National Laboratory Operated by Battelle for the U.S. Department of Energy Phone:????? 509.375.2687 Fax:??? ????509.375.2330 Email:????? cathy.smith at pnnl.gov -----Original Message----- From: Rob Fries [mailto:Rob.Fries at ascensus.com] Sent: Wednesday, February 25, 2015 12:27 PM To: Smith, Cathy; 'gnupg-users at gnupg.org' Subject: RE: 7. RE: how to disable pinentry (Smith, Cathy) Hey Cathy, You need gpg-agent running with this setup. Per the error message, it can not connect to a running gpg-agent to enter the passphrase. Your gpg-agent.conf also needs to be with your other gpg configs under .gnupg. -Rob -----Original Message----- From: Smith, Cathy [mailto:Cathy.Smith at pnnl.gov] Sent: Wednesday, February 25, 2015 3:21 PM To: Rob Fries; 'gnupg-users at gnupg.org' Subject: RE: 7. RE: how to disable pinentry (Smith, Cathy) Rob Thanks. I got an error when trying to do this. I created the gpg-agent.conf file in my home directory and added the directive: [cathy at foo ~]$ cat gpg-agent.conf allow-preset-passphrase [cathy at foo ~]$ [cathy at foo ~]$ /usr/libexec/gpg-preset-passphrase -cP"cry123" "4611 E023 7B7A 31FE 1388 0FAC 491E FBE6 302B 7D2D" gpg-preset-passphrase: can't connect to `/home/cathy/.gnupg/S.gpg-agent': No such file or directory gpg-preset-passphrase: caching passphrase failed: Input/output error Cathy --- Cathy L. Smith IT Engineer Pacific Northwest National Laboratory Operated by Battelle for the U.S. Department of Energy Phone:????? 509.375.2687 Fax:??? ????509.375.2330 Email:????? cathy.smith at pnnl.gov -----Original Message----- From: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of Rob Fries Sent: Wednesday, February 25, 2015 9:14 AM To: 'gnupg-users at gnupg.org' Subject: 7. RE: how to disable pinentry (Smith, Cathy) Hi Cathy, We use /usr/libexec/gpg-preset-passphrase to set our passphrase. /usr/libexec/gpg-preset-passphrase -cP "$passphrase" $keygrip You would need to add this to your .gpg-agent.conf: allow-preset-passphrase you will need to get the KEYGRIP. The easiest way I found is: gpg2 --fingerprint --fingerprint --list-secret-keys | grep "fingerprint" | cut -d= -f2 | tr -d ' ' make sure you get the correct one for the correct key( note the above command shows double the number of keygrips for what you need.. ). and you may want to adjust your max-cache-ttl gpg-agent.conf too. If you want to forget a passphrase before the ttl is up, you can use gpg-preset-passphrase to forget it. Rel6 does provide a pinentry-curses program: /usr/bin/pinentry-curses Hope that helps! Message: 7 Date: Wed, 25 Feb 2015 16:51:23 +0000 From: "Smith, Cathy" To: Damien Goutte-Gattat , "gnupg-users at gnupg.org" Subject: RE: how to disable pinentry Message-ID: <270838A78E5A5342BB9669898FB4CF2011CF30F6 at EX10MBOX01.pnnl.gov> Content-Type: text/plain; charset="iso-8859-1" Damien Adding this line didn't work: pinentry-program /usr/bin/pinentry-tty The message was invalid option gpg: /home/foo/.gunpg/gpg.conf:242: invalid option The CentOS6 and RHEL6 distributions don't provide a /usr/bin/pinentry-tty. One of my goals of this is to be able to set a passphrase on a key in batch processing. Perhaps, there is another way to accomplish that? Thank you Cathy --- Cathy L. Smith IT Engineer Pacific Northwest National Laboratory Operated by Battelle for the U.S. Department of Energy Phone:????? 509.375.2687 Fax:??? ????509.375.2330 Email:????? cathy.smith at pnnl.gov CONFIDENTIALITY NOTICE: This message, including attachments, is intended to be viewed only by the addressee. It may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. No confidentiality or privilege is lost by any transmission error. This message may contain nonpublic personal information about consumers subject to the restrictions of the Gramm-Leach-Bliley Act and the Sarbanes-Oxley Act. You may not directly or indirectly reuse or disclose such information for any purpose except as permitted by law. Any dissemination, distribution or copying of this message is strictly prohibited without our prior written permission. If you are not an intended recipient, or if you have received this message in error, please notify us immediately by return e-mail and permanently remove the original message and any copies from your computer and all back-up systems. _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users CONFIDENTIALITY NOTICE: This message, including attachments, is intended to be viewed only by the addressee. It may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. No confidentiality or privilege is lost by any transmission error. This message may contain nonpublic personal information about consumers subject to the restrictions of the Gramm-Leach-Bliley Act and the Sarbanes-Oxley Act. You may not directly or indirectly reuse or disclose such information for any purpose except as permitted by law. Any dissemination, distribution or copying of this message is strictly prohibited without our prior written permission. If you are not an intended recipient, or if you have received this message in error, please notify us immediately by return e-mail and permanently remove the original message and any copies from your computer and all back-up systems. From stebe at mailbox.org Thu Feb 26 05:06:59 2015 From: stebe at mailbox.org (Stephan Beck) Date: Thu, 26 Feb 2015 05:06:59 +0100 Subject: how to disable pinentry In-Reply-To: <270838A78E5A5342BB9669898FB4CF2011CF30F6@EX10MBOX01.pnnl.gov> References: <270838A78E5A5342BB9669898FB4CF2011CF269C@EX10MBOX01.pnnl.gov> <54ED9090.5060408@incenp.org> <270838A78E5A5342BB9669898FB4CF2011CF30F6@EX10MBOX01.pnnl.gov> Message-ID: <54EE9BE3.1090600@mailbox.org> Hi, Cathy, Am 25.02.2015 um 17:51 schrieb Smith, Cathy: > > One of my goals of this is to be able to set a passphrase on a key in batch processing. Perhaps, there is another way to accomplish that? > > I am not sure if that's the solution to your problem, but according to the *Unattended Key Generation* chapter in the DETAILS doc in /usr/share/doc/gnupg2/DETAILS, you can use the "passphrase " parameter as part of the parameter file. Hope that helps Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Thu Feb 26 11:58:37 2015 From: wk at gnupg.org (Werner Koch) Date: Thu, 26 Feb 2015 11:58:37 +0100 Subject: GNU-divert-to-card S2K format In-Reply-To: <54ED9AC0.9060502@digitalbrains.com> (Peter Lebbing's message of "Wed, 25 Feb 2015 10:49:52 +0100") References: <1424789751.3568.4.camel@taztag.com> <87mw43w8u0.fsf@vigenere.g10code.de> <54ECC7CC.30404@digitalbrains.com> <54ED9AC0.9060502@digitalbrains.com> Message-ID: <87y4nlrlb6.fsf@vigenere.g10code.de> On Wed, 25 Feb 2015 10:49, peter at digitalbrains.com said: > something. It should be: > > S2K specifier 110 Well, it is 101. I just updated doc/DETAILS> It now reads: * GNU extensions to the S2K algorithm 1 octet - S2K Usage: either 254 or 255. 1 octet - S2K Cipher Algo: 0 1 octet - S2K Specifier: 101 3 octets - "GNU" 1 octet - GNU S2K Extension Number. If such a GNU extension is used neither an IV nor any kind of checksum is used. The defined GNU S2K Extension Numbers are: - 1 :: Do not store the secret part at all. No specific data follows. - 2 :: A stub to access smartcards. This data follows: - One octet with the length of the following serial number. - The serial number. Regardless of what the length octet indicates no more than 16 octets are stored. Note that gpg stores the GNU S2K Extension Number internally as an S2K Specifier with an offset of 1000. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From stebe at mailbox.org Thu Feb 26 14:29:48 2015 From: stebe at mailbox.org (Stephan Beck) Date: Thu, 26 Feb 2015 14:29:48 +0100 Subject: Can't Encrypt in Freebsd 10.1 In-Reply-To: References: <87ppbsq4ff.fsf@vigenere.g10code.de> Message-ID: <54EF1FCC.9040305@mailbox.org> Hi, Antoine, Am 25.02.2015 um 14:07 schrieb Antoine Michard: > Hi, > > Still not working :( > Got no idea why... > > #gpg -r 6349E5E0 -e test.txt > Abort [...] > And then try to encryp a file: > # gpg -r F2E7CBA5 -e test.txt > Abort > I am not familiar with BSD but this should apply to BSD installations of GnuPG as well. Try gpg -e -r NAME test.txt where NAME is the user id of the recipient's key. If you want to encrypt for uid NAME and explicitly hide a given recipient's keyID when sending the message you may use the -R option. Well, that's what the man page tells us, IIUC. HTH Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: OpenPGP digital signature URL: From bre at pagekite.net Thu Feb 26 15:57:06 2015 From: bre at pagekite.net (Bjarni Runar Einarsson) Date: Thu, 26 Feb 2015 14:57:06 -0000 Subject: Thoughts on GnuPG and automation Message-ID: <20150226145705-3804-73406-mailpile@slinky> Hello GnuPG users! I just published a follow-up to Sm?ri's blog post about the Mailpile team's frustration while working with GnuPG. The post is here: https://www.mailpile.is/blog/2015-02-26_Revisiting_the_GnuPG_discussion.html As it's rather long, I won't paste the whole thing in here, but I do welcome any and all feedback. The gist of it is: the GnuPG CLI is not very well suited for automation and the 2.x design appears to make some things we want to do almost impossible. Corrections (if I made any factual errors) will be posted to the web ASAP, and I'll link back to this thread in the archives so webby people can see your replies. I hope this qualifies as constructive critism! As I said on our IRC channel: If we're lucky it'll be a humiliating "you're just doing it wrong, here is the solution". ;-) Cheers, - Bjarni -- Sent using Mailpile, Free Software from www.mailpile.is From wk at gnupg.org Thu Feb 26 18:50:35 2015 From: wk at gnupg.org (Werner Koch) Date: Thu, 26 Feb 2015 18:50:35 +0100 Subject: Thoughts on GnuPG and automation In-Reply-To: <20150226145705-3804-73406-mailpile@slinky> (Bjarni Runar Einarsson's message of "Thu, 26 Feb 2015 14:57:06 -0000") References: <20150226145705-3804-73406-mailpile@slinky> Message-ID: <87r3tcr28k.fsf@vigenere.g10code.de> On Thu, 26 Feb 2015 15:57, bre at pagekite.net said: > As it's rather long, I won't paste the whole thing in here, but I do Please give me a few days to comment on this. I have some urgent tasks right now. But as a first hint: automation has never been second class citizen and has been build into gpg more or less right from the beginning (0.2.12, spring 1998). I know of one university in Germany which runs its webmail system using GnuPG 2 and with pinentry. This was actually the reasons to add the PINENTRY_USER_DATA kludge. Back to release work. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ml.throttle at xoxy.net Thu Feb 26 18:15:33 2015 From: ml.throttle at xoxy.net (Helmut Waitzmann) Date: Thu, 26 Feb 2015 18:15:33 +0100 Subject: How to send a key to a keyserver? Message-ID: <87egpcwq41.fsf@helmutwaitzmann.news.arcor.de> Hello, I tried gpg2 --verbose --keyserver hkp://pool.sks-keyservers.net --send-keys -- 72ABFF0923A87CF22D0ED7C4FDEE765D017077F1 and got the message gpg: sending key FDEE765D017077F1 to hkp server pool.sks-keyservers.net gpgkeys: HTTP post error 22: The requested URL returned error: 417 gpg: keyserver internal error gpg: keyserver send failed: Keyserver error What's wrong here? Does the problem sit in front of the keyboard? Any help will be appreciated. From mwalter at paragon-csi.com Thu Feb 26 19:18:12 2015 From: mwalter at paragon-csi.com (Mark Walter) Date: Thu, 26 Feb 2015 13:18:12 -0500 Subject: Problem with PassPhrase in Batch. Message-ID: <79E1EB8865153D49AC2ACFBDED5F2584A4121974AA@pcsimail.paragon-csi.com> From: Mark Walter Sent: Thursday, February 26, 2015 1:17 PM To: 'gnupg-users at gnupg.org' Subject: Problem with PassPhrase in Batch. I have a pass phrase that contains an exclamation mark (!). I can decrypt fine manually, however when I try to put this into a batch file, and pipe the the pass phrase to the gpg command to decrypt the file, it doesn't work. Could the exclamation mark be causing the problem? Also, is there a way, in a batch file to escape this character? Thanks in advance, Mark Walter Business to Business Data Integration Specialist Certified IBM System i Specialist Paragon Consulting Services, Inc. mwalter at paragon-csi.com 717-764-7909 ext. 20 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwalter at paragon-csi.com Thu Feb 26 19:16:45 2015 From: mwalter at paragon-csi.com (Mark Walter) Date: Thu, 26 Feb 2015 13:16:45 -0500 Subject: Problem with PassPhrase in Batch. Message-ID: <79E1EB8865153D49AC2ACFBDED5F2584A4121974A8@pcsimail.paragon-csi.com> I have a pass phrase that contains an exclamation mark (!). I can decrypt fine manually, however when I try to put this into a batch file, and pipe the the pass phrase to the gpg command to decrypt the file, it doesn't work. Could the exclamation mark be causing the problem? Also, is there a way, in a batch file to escape this character? Thanks in advance, Mark Walter Business to Business Data Integration Specialist Certified IBM System i Specialist Paragon Consulting Services, Inc. mwalter at paragon-csi.com 717-764-7909 ext. 20 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bre at pagekite.net Thu Feb 26 20:04:32 2015 From: bre at pagekite.net (Bjarni Runar Einarsson) Date: Thu, 26 Feb 2015 19:04:32 -0000 Subject: Thoughts on GnuPG and automation In-Reply-To: <87r3tcr28k.fsf@vigenere.g10code.de> References: <87r3tcr28k.fsf@vigenere.g10code.de> Message-ID: <20150226190431-3804-53521-mailpile@slinky> Hey Werner, Yes, please do take your time. I'm happy to hear you consider automation an important thing. I assume that means the current limitations on that front are largely due to a lack of developer resources - which I don't intend to badger you about, my project suffers from the same. Related to that though, I'll add one question to your backlog: does the GnuPG 2.1 cycle hope to bridge the 2.0/1.4 divide, so 1.4 can retire and everyone can move to 2.1? If not, why not? In the meantime, I'll go see if I can find information about this kludge you speak of. Take care, - Bjarni -- Sent using Mailpile, Free Software from www.mailpile.is From pit_hoessler at yahoo.de Thu Feb 26 20:19:05 2015 From: pit_hoessler at yahoo.de (Juergen Hoessler) Date: Thu, 26 Feb 2015 19:19:05 +0000 (UTC) Subject: Can't Encrypt in Freebsd 10.1 In-Reply-To: <54EF1FCC.9040305@mailbox.org> References: <54EF1FCC.9040305@mailbox.org> Message-ID: <1742701357.1144639.1424978345950.JavaMail.yahoo@mail.yahoo.com> Hi Antoine, please try it as a normal user, not as root. Normaly the key-ring-file depends to a real user and not to root, who isn't a normal user. May be it will help you. ? --pit Von: Stephan Beck An: gnupg-users at gnupg.org Gesendet: 14:29 Donnerstag, 26.Februar 2015 Betreff: Re: Can't Encrypt in Freebsd 10.1 Hi, Antoine, Am 25.02.2015 um 14:07 schrieb Antoine Michard: > Hi, > > Still not working :( > Got no idea why... > > #gpg -r 6349E5E0 -e test.txt > Abort [...] > And then try to encryp a file: > # gpg -r F2E7CBA5 -e test.txt > Abort > I am not familiar with BSD but this should apply to BSD installations of GnuPG as well. Try gpg -e -r NAME test.txt where NAME is the user id of the recipient's key. If you want to encrypt for uid NAME and explicitly hide a given recipient's keyID when sending the message you may use the -R option. Well, that's what the man page tells us, IIUC. HTH Stephan _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From errol at askerrol.org Thu Feb 26 21:48:36 2015 From: errol at askerrol.org (Errol Casey) Date: Thu, 26 Feb 2015 15:48:36 -0500 Subject: Cannot remove passphrase (gnupg 2.0.26/solaris 10) In-Reply-To: References: Message-ID: I've tried recompiling things, and was able to initially set a key with a empty passphrase (pressing return twice). But if I use --edit-key to change passwd, and then try to set it back to blank...I get the warning, and infinite loop asking for "y/N" but never accepts either answer... On Tue, Feb 24, 2015 at 2:12 PM, Errol Casey wrote: > When I use gpg2 --edit-key , and then use passwd to > change/remove > passphrase by entering a blank passphrase. I get hung in an input loop > > lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk > x Please re-enter this passphrase x > x x > x Passphrase ________________________________________ x > x x > x x > mqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj > > > > > > > > > You don't want a passphrase - this is probably a *bad* idea! > > Do you really > want to do this? (y/N) > > I truss the process (this is on Solaris 10), and I see it receiving the > "y\r" but it doesn't continue. > > I can type N enter, and see 'N\r" also. > > So not sure if it is a local issue with tty, compile issue with pinentry, > or gnupg? > > But it accepts my original passphrase, and hitting enter twice and > selecting yes I want to do it, gets me to this last prompt and it will go > no further. > > Hmmm: > > Thinking the compile/linking of pinentry is the cause. I've seen this > before, but just ran > > pinentry --version > ld.so.1: pinentry-curses: fatal: libiconv.so.2: open failed: No such file > or directory > Killed > > > seems I have to modify LD_LIBRARY_PATH to get pinentry to work; but this > change was made en enviornment when I tried changing passphrase above. Not > sure where the input problem is being generated. > > $ pinentry --version > pinentry-curses (pinentry) 0.9.0 > $ gpg2 --version > gpg (GnuPG) 2.0.26 > libgcrypt 1.6.2 > Copyright (C) 2013 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later < > http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > > Home: ~/.gnupg > Supported algorithms: > Pubkey: RSA, RSA, RSA, ELG, DSA > Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, > CAMELLIA128, CAMELLIA192, CAMELLIA256 > Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 > Compression: Uncompressed, ZIP, ZLIB, BZIP2 > -- > Errol Casey > errol at askerrol.org > -- Errol Casey errol at askerrol.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From stebe at mailbox.org Thu Feb 26 23:50:20 2015 From: stebe at mailbox.org (Stephan Beck) Date: Thu, 26 Feb 2015 23:50:20 +0100 Subject: Can't Encrypt in Freebsd 10.1 In-Reply-To: <1742701357.1144639.1424978345950.JavaMail.yahoo@mail.yahoo.com> References: <54EF1FCC.9040305@mailbox.org> <1742701357.1144639.1424978345950.JavaMail.yahoo@mail.yahoo.com> Message-ID: <54EFA32C.9020904@mailbox.org> Hi pit or J?rgen, sorry (Antoine), I did not interpret the # as root but just as a way of commenting, and I checked it again and realized that the order of the options is not important. Anyway, is it necessary to copy the whole header of my message to make it stand out who made a mistake? I think that's a bit childish and impolite. In case you "configured" your email that way, just change it. Best regards Stephan Am 26.02.2015 um 20:19 schrieb Juergen Hoessler: > Hi Antoine, > please try it as a normal user, not as root. > Normaly the key-ring-file depends to a real user > and not to root, who isn't a normal user. > May be it will help you. > --pit > > Von: Stephan Beck > An: gnupg-users at gnupg.org > Gesendet: 14:29 Donnerstag, 26.Februar 2015 > Betreff: Re: Can't Encrypt in Freebsd 10.1 > > Hi, Antoine, > > > > > Am 25.02.2015 um 14:07 schrieb Antoine Michard: >> Hi, >> >> Still not working :( >> Got no idea why... >> >> #gpg -r 6349E5E0 -e test.txt >> Abort > [...] >> And then try to encryp a file: >> # gpg -r F2E7CBA5 -e test.txt >> Abort >> > I am not familiar with BSD but this should apply to BSD installations of GnuPG > as well. > > Try > gpg -e -r NAME test.txt > > where NAME is the user id of the recipient's key. > > If you want to encrypt for uid NAME and explicitly hide a given recipient's > keyID when sending the message you may use the -R option. > > Well, that's what the man page tells us, IIUC. > > HTH > > Stephan > > > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > > > > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: OpenPGP digital signature URL: From xavier at maillard.im Fri Feb 27 06:36:28 2015 From: xavier at maillard.im (Xavier Maillard) Date: Fri, 27 Feb 2015 06:36:28 +0100 Subject: Problem with PassPhrase in Batch. In-Reply-To: <79E1EB8865153D49AC2ACFBDED5F2584A4121974A8@pcsimail.paragon-csi.com> References: <79E1EB8865153D49AC2ACFBDED5F2584A4121974A8@pcsimail.paragon-csi.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Mark, Mark Walter writes: > I have a pass phrase that contains an exclamation mark (!). I can > decrypt fine manually, however when I try to put this into a batch > file, and pipe the the pass phrase to the gpg command to decrypt > the file, it doesn't work. Could the exclamation mark be causing > the problem? Also, is there a way, in a batch file to escape this > character? Do you have any testcase I could try by my side ? I mean, how you "put this in a batch file" ? I also put an exclamation mark in my passphrase. Regards - -- Xavier. -----BEGIN PGP SIGNATURE----- iQQcBAEBCgAGBQJU8AJZAAoJEN4v/Iaa+lFlkcIf/ilD+vTRhjyW5ZigQ0mP06DW tEAApUFS6MIg8Hccp8QZm5qmTWUkhjvTD4wnbaCYmGDav5VG8PPokAyNwTJNDO7q 2K/WhSTlamIBnWFXXIZwO7LHl6T96oFmFvWsTUMG9+TaQhuEk4uAmKjAdeeS1J8K DWtVmWZaH/LEUxy2EFkRXCHxuo0o8W1V8rRSpNJXuGgKnVakBQP+aLJxsHpHqzKD ubnZkZ1Q/07WGrTzeH+kweyOt91qOmiwRfYXayiP3CS+9zD+1xQ813BoTCltKpBT KnLWEX6ui/o1X+FTGnFqPxH16vpATMbfTEqKLohE0Eg6asUbDKeTS8nOaogDJ98a N5tW8lkXEdnt7P/58kQt6BabmZ36G8gAcZyLak+DFOuj/BgNQIrXWW4a2HO6fZDQ 9ilKalWdQqDPJU3wdsCixggr55IZEBDe/PepvlKEcQUl1YfBQ/mfhhRtlssApv81 MgGX3ZqaweOEbSFMj4hkuYRQ4ir/x8g9IBq/VuN4naIJl21O6r6NZZjgnJSvBuXi IvyJAnlGfuAlRXBTDEzPqf+k8EQma8tLp84ZaOOdROAkg9uIkpMWpFD4QW/thAzY yjBi6ZZt4TZ7P8j3hVNgWCq1+qMPFH286/+6BqEZ0XdV73R+IAIXUoy+jAQRCUqU 3O81O+H12YOWKgjQKJx3mNU6YXMOEf5KqHJfm6X9JuRysoItaFYlrzaz2Sq0VV0i lPRvZefA5eSwOU59zTAbMGmIUGxBbTXoPIngV9NC6QWC27RZLsbwlhGcJB3sSzAx Mtgc0qsgPI4/Mg70qvMZ+9qQs0sA9M+53EAa1RnieI0hmcxdwoaG/ccQ3P+n+Zpj HZrCPbgQ3GircKoZddiI6xfLpDzopWQLezTZdYIymJFpmZuAZN7T1/xQAGbcSYKB 9BSZMavNniSsGCCr9c5PFpyeGz8B7YpmoqBBTIV50Cdg8S8TipvaigFpFc/Iqe0E 6eQlDMMUqdmtYn0Pk6ct2+90DYMHl7WhP3LH+DqhSeyOuJP7Lx6szdx38jJjE3q0 wBgK92zhTDvH+ipB4kpdK2vAiWnecP9jBHMABG/HpSFyGVSZszWmB+956NC2tCT6 rrUOteCmYlQLNdg6zn7smpR1inLdntmCiCm5LztMGUXupco6XmvcA8nOvMdif1Tv obXKCXta3oKeUHGJOtmBQyTyCh2+O/0IreJSmFvvbJKg/EXOCmQwMYm483juOKhi 4AZ6CPIj45Upz9woD20LFqx27V7bg6ohZ+amiCAgB1nLv7p8bj7FK6AR52VLUttf XLqxWdxOXGQlJQsJXECaaC1V0wioa5mGioeTOzx6CKmT3kyK/AEXPgccfrETfYk= =z+om -----END PGP SIGNATURE----- From xavier at maillard.im Fri Feb 27 06:54:40 2015 From: xavier at maillard.im (Xavier Maillard) Date: Fri, 27 Feb 2015 06:54:40 +0100 Subject: How to send a key to a keyserver? In-Reply-To: <87egpcwq41.fsf@helmutwaitzmann.news.arcor.de> References: <87egpcwq41.fsf@helmutwaitzmann.news.arcor.de> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello Helmut Helmut Waitzmann writes: > gpg2 --verbose --keyserver hkp://pool.sks-keyservers.net --send-keys -- 72ABFF0923A87CF22D0ED7C4FDEE765D017077F1 try without the -- stuff: gpg2 --verbose --keyserver hkp://pool.sks-keyservers.net --send-keys 72ABFF0923A87CF22D0ED7C4FDEE765D017077F1 and see how it goes. - -- Xavier. -----BEGIN PGP SIGNATURE----- iQQcBAEBCgAGBQJU8AaeAAoJEN4v/Iaa+lFl0qEgAKkMLssdiQNkUunotYfSMs1F ndPLNXOy3GuCyJJ2GGLE0RQv2OafBJ0xHc6WNWQD93CvSTY7GP2x8jIodAyb7Wbr 7Gp6fnmFCs+p8Lg4qjAynRkmiCZOD5yO/JMMAGeaBFkvMEMG+7alMDSso7fPqTJh TXZqrBviOCHevOruv5GILpswbGjBw+yZ4KwQYMtimwQE2Idv5okaD3eNysJms5Jq bYG+eSandfC8+yOPtGrxMB1pGWoZEdmWlhSe6rHxO/0jqKywEurFkQahotNMiCV/ +ZiD0r6pClQVfSPbXYOsrqbW2S0NeOhDVthLLSSgw+2FLVwqsgMZ6/xTsFd7gkqg u727aFSaLnUQD1XM7ml5TZMvbXBP3KUlJf5btqoJWuxbkeZJrLa+ydYWsr3M9iUx iGso86HTZ7uV4WJUgmybxhuT07XaUwyq8OEIiy2kNo/0WBK43al4RVacIbck9ZLP tVppW98+P1O0vmJcZb1iUakj2yYY+I5E+D3KSiOkLYd8i8ZcrsB0Pelcl1KXEi2X BUBMzJqIVcGBjCEKewORXs+NFndp/aYPQzYGvCFu34qnSGBJyKTGI9uZSRljGUTI QbAvIJB+KGYVoAjPajFPk8taEtN/8iNltMp/odqtSi8JY/JMYMDuz1sct4wxVmpQ dFjPhLkUKraZ6L+j8giPv8AzB4W8Sg3FVbUD0HZPbr3BcTPMDeozA4iAthoYIb3E m1NUHDKtRfnFkxBy1iMkhGsoVilUX8Zn03C3QS9py9ToyR7Xka3Clc2nSDE6wWC5 R28ORWk1tqETXjg8ndaIQcaW54+bRjoymUPzpgtvZmBV9+liwfJwwZPsGqklg9tF MTEqavBVPVOXu4j1bSrCiUQnhLMsXuvSg11Cl3MZuC7REDkOsHZstOXZTiMvhnXB 7ZXWyUn7Xx6PUYYlp/OJkg+2Qr9fRLikNvF9PZ0vuKmPxpbYoG6UJ2NKGvpGOMmr FjtPyEKJlYQWsdKf6w1PGJ/1+lVNzcwJkMh+Jz/YYVE0yH0cQDV2nINe3gVv+pyf V6s+zsaBa/RBJCYuA59U4tIDQFbBrbBTZ5IurIlGTIIB6xiG+SUaMW6nnswZQIwm rZFoK9VQyxKBPoj4OBEOQg2q0t3+hvBnQxI+hffCsx9QOcuN/WdnigEO/Khv2lXM xrRyZmCp79UJTNDI5TTy/ra+jjfmOVkHVd/o/fAkAVST3l2eRdGDcUXXoofbxcjj KajRybChjRF0yAPYkIts9FsoD0fLBP3uxrfO23Lzxz7Jwrzv6PaQulG/9rrXLWwU 9k96364Ldf3PaEZ9qIqRXqGx81IbHoxWgQt40BtrX86mZ+K7cMSXTMDTKHcvb7M= =Yuco -----END PGP SIGNATURE----- From wk at gnupg.org Fri Feb 27 08:53:49 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 27 Feb 2015 08:53:49 +0100 Subject: Can't Encrypt in Freebsd 10.1 In-Reply-To: (Antoine Michard's message of "Wed, 25 Feb 2015 14:07:09 +0100") References: <87ppbsq4ff.fsf@vigenere.g10code.de> Message-ID: <87lhjjpz76.fsf@vigenere.g10code.de> On Wed, 25 Feb 2015 14:07, michard.antoine at gmail.com said: > #gpg -r 6349E5E0 -e test.txt > Abort You should run it under a gdb to see the reason for the abort. This should not happen. $ gdb gpg gdb> run -r 6349E5E0 -e test.txt [...] gdb> bt Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From 2014-667rhzu3dc-lists-groups at riseup.net Fri Feb 27 09:07:39 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Fri, 27 Feb 2015 08:07:39 +0000 Subject: Unattended signing In-Reply-To: <87sidvt0p7.fsf@alice.fifthhorseman.net> References: <54E4DDFB.1010405@grinta.net> <87egpj5bb8.fsf@alice.fifthhorseman.net> <54EBC789.3010704@grinta.net> <87sidvt0p7.fsf@alice.fifthhorseman.net> Message-ID: <176151659.20150227080739@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Tuesday 24 February 2015 at 10:16:20 PM, in , Daniel Kahn Gillmor wrote: > That is, only a malicious person who manages to > compromise that key material can make signatures with > it. So why are you keeping it around? To verify existing signatures? - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net Two rights do not make a wrong. They make an airplane. -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJU8CXQXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXw0HsH/1+lwgL/jBJ6LeVaRbSKhopG +kZ6Wer0LxLWxMhde6hNrGfvwAf+j6y5MtLsnREZCK2wOFuLrLCZc4VjJGBX33zs NMxX0ws2/b+oskJ+tpB6TvaENsnYKdjCfA+QQ00143gNHhvoOaMeMgLw/Lhuyigp uc6k9l0Gcp8wV6BfnGXHnk6xPQnx9sRBtN5as1x+0Taf1BCfqNEhAfsNfhPxWU10 wD3GhSelvv4FkY/BuBgCfDNptrxsMPQhAGeT3nWHB+Xk+lApUNrAgmORRvemh+w2 BY6pEykRjqUScb/SXwVbItxuA9GgbBVYdWiW9oHsAMseIqxGScQ4upy6oRhDwuOI vgQBFgoAZgUCVPAl118UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45OG5AQD4w0b7WHumsaehjxkpwJwUM998 dLs1pQrWZ7IVqXmM7QEAT5M9hA8LUgW1bgfnq1Ka5v9AbEh5VzSc7id62zQACQU= =aKz3 -----END PGP SIGNATURE----- From gnupgpacker at on.yourweb.de Fri Feb 27 09:45:36 2015 From: gnupgpacker at on.yourweb.de (gnupgpacker) Date: Fri, 27 Feb 2015 09:45:36 +0100 Subject: German ct magazine postulates death of pgp encryption Message-ID: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> Hello, there is a discussion ongoing regarding future of pgp/gpg encryption. German ct magazine has postulated in their last edition that our pgp handling seems to be too difficult for mass usage, keyserver infrastructure seems to be vulnerable for faked keys, published mail addresses are collected from keyservers and so on... Pls refer to: Massentaugliche E-Mail-Verschl?sselung gesucht http://heise.de/-2557237 Editorial: Lasst PGP sterben! http://heise.de/-2551008 M.Marlinspike Blog: GPG And Me http://www.thoughtcrime.org/blog/gpg-and-me/ I am a little bit unhappy about this discussion because pgp still offers secure end-to-end encryption without the need of a superior CA, no compromising had been detected so far. Your positions to this ct approach? Regards, Chris From mailinglisten at hauke-laging.de Fri Feb 27 11:59:14 2015 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Fri, 27 Feb 2015 11:59:14 +0100 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> Message-ID: <1890860.SDiBssEjyI@inno> Am Fr 27.02.2015, 09:45:36 schrieb gnupgpacker: > German ct magazine has postulated in their last edition that our pgp > handling seems to be too difficult for mass usage, keyserver > infrastructure seems to be vulnerable for faked keys, published mail > addresses are collected from keyservers and so on... Werner has replied to that (on gnupg-de at gnupg.org and here): http://rem.eifzilla.de/archives/2015/02/24/re-die-schlssel-falle -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 603 bytes Desc: This is a digitally signed message part. URL: From peter at digitalbrains.com Fri Feb 27 12:15:36 2015 From: peter at digitalbrains.com (Peter Lebbing) Date: Fri, 27 Feb 2015 12:15:36 +0100 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> Message-ID: <54F051D8.8080104@digitalbrains.com> On 27/02/15 09:45, gnupgpacker wrote: > German ct magazine has postulated [...] published mail addresses are collected from keyservers They are? I can read German, but it is veeerryyyy slooowwww. So I'll probably not do that. But I have a honeypot key on the keyservers that has a computer-generated random e-mail address that does however exist. Anybody who looks at the name thinks "huh?" but the purpose is to not catch spammers that simply address kathy@ peter@ john@ and variations on that, because they would be false positives for the experiment. Because the experiment is: does having an e-mail address on the keyserver attract spam? I reckoned that there's a good chance e-mail harvesters don't do any filtering on unlikely local parts in the e-mail address; I think they'd rather not spend effort on that and simply mail any and all addresses you find. That's insanely cheap to do (since you use a botnet), and filtering might remove actual spam targets. So what did this key attract, being on the keyserver for four years now? 22 Nigerian 419 scams. That's it. Twenty-two! They came in batches; I haven't seen anything since March last year. I've kept this little experiment (which admittedly is rather small) secret for a year, to avoid people with an agenda biassing the results. By then I had only had one 419 scam. Even after I talked about it just a 419 scam every few months. The latest one will celebrate its first birthday in 3 weeks! Hmmm.... I think they might have stopped spamming that address. I wonder if it says anything that all spams are 419 scams. Do they as a group collect addresses differently than other spammers? Or is it simply that there is only one person who harvests keys from keyservers, and his only customers are 419 scammers? Hell, the harvester could be the spammer; just one person. Sooooo...... back to c't. Since they were writing an article, since they're journalists, they should do some fact checking, right? Do they have proof, or a strong indication that spammers use the keyservers? Or is it the crystal ball "yes, but if more people start to use the keyservers, then it will surely happen"? I've gazed in there and thought the same, but it's not a fact and neither is the current keyserver network necessary for widespread OpenPGP usage, IMHO. Also, I've said it before: instead of saying "Let OpenPGP die", put effort in getting something accepted by the mainstream that deserves to live! I think right now we need an alternative for the e-mail infrastructure more than we need an alternative to OpenPGP for our current e-mail. Work your way from the ground up with security and privacy as a goal right from the outset. You could keep legacy interfaces to the end-user (IMAP, SMTP), but the core should be replaced. Upon this renewed core, we can build security and privacy. When your housekeeper, mister Jones, is in his 70's and you need a new housekeeper because the good man is simply getting too old for the job, what do you say? "Wanted: good housekeeper, for two days a week, ..." etcetera? Or "Let mister Jones die"? Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From hans at guardianproject.info Fri Feb 27 12:02:29 2015 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Fri, 27 Feb 2015 12:02:29 +0100 Subject: Thoughts on GnuPG and automation Message-ID: <54F04EC5.3000107@guardianproject.info> Bjarni Runar Einarsson wrote: > Hello GnuPG users! > > I just published a follow-up to Sm?ri's blog post about the Mailpile > team's frustration while working with GnuPG. The post is here: > > https://www.mailpile.is/blog/2015-02-26_Revisiting_the_GnuPG_discussion.html > > As it's rather long, I won't paste the whole thing in here, but I do > welcome any and all feedback. The gist of it is: the GnuPG CLI is not > very well suited for automation and the 2.x design appears to make some > things we want to do almost impossible. > > Corrections (if I made any factual errors) will be posted to the web > ASAP, and I'll link back to this thread in the archives so webby people > can see your replies. I hope this qualifies as constructive critism! > > As I said on our IRC channel: If we're lucky it'll be a humiliating > "you're just doing it wrong, here is the solution". ;-) > > Cheers, > - Bjarni > > -- > Sent using Mailpile, Free Software from www.mailpile.is As the lead dev on the Android port of GnuPG, I definitely can share your pain on working with the GnuPG suite. For example, GnuPG is built heavily around UNIX assumptions, and Android is not UNIX at all, and it is much further from UNIX than Windows is. We ultimately got pinentry working on Android, with much struggle. After going through that, I also had lots of grips, which I probably should have written up like you did. With all the recent attention to GnuPG and Werner's work, I have begun to think about things differently. GnuPG has an amazing security track record. It has had few serious security bugs, nothing even close to heartbleed that I know of, and yet it is core to providing security to GNU/Linux distros, as well as protecting people like Laura Poitras and Edward Snowden. So instead of complaining about the difficulties, I now try to think about whether such difficulties might actually be related to what makes GnuPG so solid. I think anyone interested in providing usable security needs to think hard about this. Sure we can make things easier to use, but it is a very slippery slope towards reducing security. I also have to call out that part of the problem that mailpile is continuing: it is generally more fun to write code, rather than figure out someone else's library. That is especially true when its a complicated thing like GnuPG. But in order to have shared maintenance and work, we all need to take responsibility and try to build upon the work of others whenever possible. Mailpile did not do that, and instead wrote yet another incomplete python API for GnuPG. Now all that said, we definitely need to be debating how to improve working with GnuPG so that we can build software that is intuitive and private by design, on top of the solid GnuPG track record. For example, I think that `gpg --json` is great idea. I ended up using a Java wrapper of GPGME, which is in turn a wrapper of GnuPG. I think it makes a lot more sense to have `gpg --json` as the parseble interface, then implement a GPGME-style framework in each language (Python, Java, etc). Another possibility is making ASSUAN, the internal protocol between GnuPG components, the API instead of `gpg --json`. This only works on GnuPG 2.1, as far as I understand it, since in 2.1, even commands like gpg communicate with gpg-agent using ASSUAN, and it is actually gpg-agent that does all the work. Contrary to the mailpile write-ups, I think that having all the work happen in gpg-agent makes sense, as long as there is a good API to it. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 https://pgp.mit.edu/pks/lookup?op=vindex&search=0x9F0FE587374BBE81 From gnupgpacker at on.yourweb.de Fri Feb 27 12:27:40 2015 From: gnupgpacker at on.yourweb.de (gnupgpacker) Date: Fri, 27 Feb 2015 12:27:40 +0100 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: <1890860.SDiBssEjyI@inno> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <1890860.SDiBssEjyI@inno> Message-ID: <000e01d05280$656fed70$304fc850$@on.yourweb.de> Thx. Maybe implementation with an opt-in could preserve publishing of faked keys on public keyservers? So if new key is uploaded an email with verification link is sent from keyserver to issuer. If embedded link is verified by issuer in 10 Minutes => uploaded public key is published If embedded link is NOT verified by issuer in 10 Minutes => uploaded public key is deleted Forums are working with this technique since years. Regards, Chris > -----Original Message----- > From: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of > Hauke Laging > Sent: Friday, February 27, 2015 11:59 AM > Werner has replied to that (on gnupg-de at gnupg.org and here): > http://rem.eifzilla.de/archives/2015/02/24/re-die-schlssel-falle From michard.antoine at gmail.com Fri Feb 27 12:34:24 2015 From: michard.antoine at gmail.com (Antoine Michard) Date: Fri, 27 Feb 2015 12:34:24 +0100 Subject: Can't Encrypt in Freebsd 10.1 In-Reply-To: <87lhjjpz76.fsf@vigenere.g10code.de> References: <87ppbsq4ff.fsf@vigenere.g10code.de> <87lhjjpz76.fsf@vigenere.g10code.de> Message-ID: Here the result: GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)... (gdb) run -r 6349E5E0 -e test.txt Starting program: /usr/local/bin/gpg -r 6349E5E0 -e test.txt (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... Program received signal SIGABRT, Aborted. 0x0000000801981a1a in kill () from /lib/libc.so.7 (gdb) bt #0 0x0000000801981a1a in kill () from /lib/libc.so.7 #1 0x00000008019181c0 in __stack_chk_fail () from /lib/libc.so.7 #2 0x0000000801918130 in __stack_chk_fail () from /lib/libc.so.7 #3 0x0000000801179e43 in _gcry_cast5_amd64_cfb_dec () from /usr/local/lib/libgcrypt.so.20 #4 0x83e930ecf32ef05e in ?? () #5 0x855e231630c0d67c in ?? () #6 0xd9ee116bdf79d00b in ?? () #7 0x35cac9fc3c713545 in ?? () #8 0xf615ffe477355a91 in ?? () #9 0x1d49d410956f71f6 in ?? () #10 0xc2aeceae9c748a44 in ?? () #11 0xa8ba383b702ace6e in ?? () #12 0xc190ca44a082735d in ?? () #13 0x0000000000000000 in ?? () So, it's libc problem ??? 2015-02-27 8:53 GMT+01:00 Werner Koch : > On Wed, 25 Feb 2015 14:07, michard.antoine at gmail.com said: > > > #gpg -r 6349E5E0 -e test.txt > > Abort > > You should run it under a gdb to see the reason for the abort. This > should not happen. > > $ gdb gpg > gdb> run -r 6349E5E0 -e test.txt > [...] > gdb> bt > > > > Shalom-Salam, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > -- Antoine Michard -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailinglisten at hauke-laging.de Fri Feb 27 12:43:12 2015 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Fri, 27 Feb 2015 12:43:12 +0100 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: <000e01d05280$656fed70$304fc850$@on.yourweb.de> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <1890860.SDiBssEjyI@inno> <000e01d05280$656fed70$304fc850$@on.yourweb.de> Message-ID: <7920271.MAWFr6xyvP@inno> Am Fr 27.02.2015, 12:27:40 schrieb gnupgpacker: > Maybe implementation with an opt-in could preserve publishing of faked > keys on public keyservers? We need keyservers which are a lot better that today's. IMHO that also means that a keyserver should tell a client for each offered certificate whether it (or a trusted keyserver) has made such an email verification. Work in progress by me about that (in German): http://www.crypto-fuer-alle.de/wishlist/keyserver/ In addition to that I will soon publish a description of my idea how crypto life can become much easier (especially for those non-cryotp loving people) by using a keyserver proxy (one software suitable for all clients instead of improving all clients separately or GnuPG itself which is rather not going to happen) which can be configured for key selection policies. Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 603 bytes Desc: This is a digitally signed message part. URL: From jhs at berklix.com Fri Feb 27 11:54:06 2015 From: jhs at berklix.com (Julian H. Stacey) Date: Fri, 27 Feb 2015 11:54:06 +0100 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: Your message "Fri, 27 Feb 2015 09:45:36 +0100." <000d01d05269$c1726dd0$44574970$@on.yourweb.de> Message-ID: <201502271054.t1RAs6en011186@fire.js.berklix.net> Hi, Reference: > From: "gnupgpacker" > Date: Fri, 27 Feb 2015 09:45:36 +0100 "gnupgpacker" wrote: > Hello, > > there is a discussion ongoing regarding future of pgp/gpg encryption. > > German ct magazine has postulated in their last edition that our pgp > handling seems to be too difficult for mass usage, keyserver infrastructure > seems to be vulnerable for faked keys, published mail addresses are > collected from keyservers and so on... > > Pls refer to: > Massentaugliche E-Mail-Verschl?sselung gesucht > http://heise.de/-2557237 > > Editorial: Lasst PGP sterben! > http://heise.de/-2551008 > > M.Marlinspike Blog: GPG And Me > http://www.thoughtcrime.org/blog/gpg-and-me/ > > I am a little bit unhappy about this discussion because pgp still offers > secure end-to-end encryption without the need of a superior CA, no > compromising had been detected so far. > > Your positions to this ct approach? > > Regards, Chris CT is usually a good mag. for technical articles; however back in the 1980s other UK wind bag journalists regularly sold columns with "Unix about to die!" PS Some translator engine links: http://berklix.com/~jhs/trans/ Cheers, Julian -- Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com Indent previous with "> ". Reply Below as a play script. Send plain text, Not quoted-printable, HTML, or base64. From hans at guardianproject.info Fri Feb 27 11:32:13 2015 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Fri, 27 Feb 2015 11:32:13 +0100 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> Message-ID: <54F047AD.1040608@guardianproject.info> First, most of these "let PGP die" rants only really apply to OpenPGP email. GPG does a wonderful job of signing and verifying packages for Debian, Ubuntu, Fedora, etc. Second, OpenPGP email exists now, can be installed and used right now, and provides proven protection for the body of an email message. Millions of people know how to use it, and can teach others. That said, yes, I agree that OpenPGP email is a very flawed system, and we should also be working on a modern replacement. But that does not exist, not really even close. So if you need privacy in email now, OpenPGP email is the main realistic choice. .hc gnupgpacker: > Hello, > > there is a discussion ongoing regarding future of pgp/gpg encryption. > > German ct magazine has postulated in their last edition that our pgp > handling seems to be too difficult for mass usage, keyserver infrastructure > seems to be vulnerable for faked keys, published mail addresses are > collected from keyservers and so on... > > Pls refer to: > Massentaugliche E-Mail-Verschl?sselung gesucht > http://heise.de/-2557237 > > Editorial: Lasst PGP sterben! > http://heise.de/-2551008 > > M.Marlinspike Blog: GPG And Me > http://www.thoughtcrime.org/blog/gpg-and-me/ > > I am a little bit unhappy about this discussion because pgp still offers > secure end-to-end encryption without the need of a superior CA, no > compromising had been detected so far. > > Your positions to this ct approach? > > Regards, Chris > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 https://pgp.mit.edu/pks/lookup?op=vindex&search=0x9F0FE587374BBE81 From ml.throttle at xoxy.net Fri Feb 27 12:52:42 2015 From: ml.throttle at xoxy.net (Helmut Waitzmann) Date: Fri, 27 Feb 2015 12:52:42 +0100 Subject: How to send a key to a keyserver? In-Reply-To: (Xavier Maillard's message of "Fri, 27 Feb 2015 06:54:40 +0100") References: <87egpcwq41.fsf@helmutwaitzmann.news.arcor.de> Message-ID: <877fv3sh98.fsf@helmutwaitzmann.news.arcor.de> Xavier Maillard writes: >Helmut Waitzmann writes: >> gpg2 --verbose --keyserver hkp://pool.sks-keyservers.net --send-keys -- 72ABFF0923A87CF22D0ED7C4FDEE765D017077F1 > >try without the -- stuff: > >gpg2 --verbose --keyserver hkp://pool.sks-keyservers.net --send-keys 72ABFF0923A87CF22D0ED7C4FDEE765D017077F1 Same error as before. What else could I do? From kristian.fiskerstrand at sumptuouscapital.com Fri Feb 27 13:04:10 2015 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Fri, 27 Feb 2015 13:04:10 +0100 Subject: Thoughts on GnuPG and automation In-Reply-To: <54F04EC5.3000107@guardianproject.info> References: <54F04EC5.3000107@guardianproject.info> Message-ID: <54F05D3A.9060302@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 02/27/2015 12:02 PM, Hans-Christoph Steiner wrote: > > Bjarni Runar Einarsson wrote: >> Hello GnuPG users! .. > > With all the recent attention to GnuPG and Werner's work, I have > begun to think about things differently. GnuPG has an amazing > security track record. It has had few serious security bugs, > nothing even close to heartbleed that I know of, and yet it is core > to providing security to GNU/Linux distros, as well as protecting > people like Laura Poitras and Edward Snowden. So instead of > complaining about the difficulties, I now try to think about > whether such difficulties might actually be related to what makes > GnuPG so solid. I think anyone interested in providing usable > security needs to think hard about this. Sure we can make things > easier to use, but it is a very slippery slope towards reducing > security. > Hear hear, you can't have proper security without proper operational security surrounding it, and that require an educated population to use it. Security is not something that can be solved technically (alone). What we would need are better ways to educate people, and get it into school earlier, like the algorithm classes in kindergarden in britain teching kids algos through games (i.e physical games) - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- Manus manum lavat One hand washes the other -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJU8F0yAAoJEP7VAChXwav6UrsH+wWhafqn1fDjW3SE789jdsRm /9M3e8ZPmueNB4CDadig3/4nFrl5WTcMrXfDMC62xXLTwftu2mSe8K8t7QX2CDRn VgdTU07gARqnkwEcV+I82Y9SKeUaDfGRmoWUgh0+T3Z4MozXvp23BlFoqcHrKK5H 9ld/Sj5Ncd63JfUQKlEi4kakyGIShctoJ+P0gDje31pqVP65znWw+xi4F06sW0dm FYPtogg73vtpJkQI6is9Luw7BFR+dE+pWGrxP6166igu1Mwn8I5bg05tqxjFe7dL weIZffLCd8+iRsNnsr29xbKahsvvfyIrimKZX0nXvuflHftMC2uYARKdx+q8eUw= =Xs+E -----END PGP SIGNATURE----- From philip.jackson at nordnet.fr Fri Feb 27 12:57:38 2015 From: philip.jackson at nordnet.fr (Philip Jackson) Date: Fri, 27 Feb 2015 12:57:38 +0100 Subject: How to send a key to a keyserver? In-Reply-To: <87egpcwq41.fsf@helmutwaitzmann.news.arcor.de> References: <87egpcwq41.fsf@helmutwaitzmann.news.arcor.de> Message-ID: <54F05BB2.9030405@nordnet.fr> On 26/02/15 18:15, Helmut Waitzmann wrote: > I tried > > gpg2 --verbose --keyserver hkp://pool.sks-keyservers.net --send-keys -- 72ABFF0923A87CF22D0ED7C4FDEE765D017077F1 > > and got the message > > gpg: sending key FDEE765D017077F1 to hkp server pool.sks-keyservers.net > gpgkeys: HTTP post error 22: The requested URL returned error: 417 > gpg: keyserver internal error > gpg: keyserver send failed: Keyserver error > > What's wrong here? Does the problem sit in front of the keyboard? > > Any help will be appreciated. I cut and pasted your command string and then substituted my key identity for yours. It worked ok. I tried the long id version like you used and also the short id version. All worked ok. So maybe it was just a keyserver glitch ? Philip -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From kristian.fiskerstrand at sumptuouscapital.com Fri Feb 27 13:11:33 2015 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Fri, 27 Feb 2015 13:11:33 +0100 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: <7920271.MAWFr6xyvP@inno> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <1890860.SDiBssEjyI@inno> <000e01d05280$656fed70$304fc850$@on.yourweb.de> <7920271.MAWFr6xyvP@inno> Message-ID: <54F05EF5.6050105@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 02/27/2015 12:43 PM, Hauke Laging wrote: > Am Fr 27.02.2015, 12:27:40 schrieb gnupgpacker: > >> Maybe implementation with an opt-in could preserve publishing of >> faked keys on public keyservers? > > We need keyservers which are a lot better that today's. IMHO that > also means that a keyserver should tell a client for each offered > certificate whether it (or a trusted keyserver) has made such an > email verification. The keyservers have no role in this, they are pure data store and can never act as a CA. That would bring up a can of worm of issues, both politically and legally, I wouldn't want to see the first case where a keyserver operator was sued for permitting a "fake key" (the term itself is very misleading, the key itself isn't fake at all, but a fully valid key where the UID has not been mated to its holder through proper validation). Another way this is being handled in some systems is dedicated keyservers for an organization (standard is keys.[domain] in the cases I've seen) that looks up key using LDAP. This is a read-only store that is connected to the Domain Controller / Active Directory in the system I'm thinking of. So at least Symantec Encryption Server checks for the existence of such a keyserver when sending and asking it for it. The keys are automatically maintained with a short time to expiry requiring frequent refreshes. I understand the rationale, but would rather see a CA involved in this (i.e a Company Employee CA). People need to understand that operational security is critical for any security of a system and validate the key through secondary channel (fingerprint, algorithm type, key length etc verifiable directly or through probabilistic measures e.g. based on historical postings on mailing lists over a long time for a project etc). - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- Ubi mel ibi apes Where there's honey, there are bees -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJU8F7vAAoJEP7VAChXwav6yrwIAI95x/GZrq+5gCYhHjDuCWhv a2FB1ki5c5unMzN6gtBjwY0Tf8SfAicnR2NpRn2VUkb68/hVG5H3JEhQcVsLt6Je 5LUFR9gjyN8VGoDnMl0g1khxfNcakYh6f1vPmLihfiP4Yh6Pf6PebIkurqhvhwkf NnwtIipSipDeXuQgJBMmN9fMXUqkO1uA2tt0tewtIaJy2y+BMmzVbRkpqZocl2z6 VcwBT/7FUUv4ePdV16xTuim9DvmbsCoPmwl+1XRauEeJsN3AOyE0X/Y/gKYX4QX0 RWUaCu2b7YRqMYyaYs053EsH+XEAPVOVDnBHUFst/c6j4hIJV7T4zB2mpi5+VKw= =IZT3 -----END PGP SIGNATURE----- From kristian.fiskerstrand at sumptuouscapital.com Fri Feb 27 13:15:29 2015 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Fri, 27 Feb 2015 13:15:29 +0100 Subject: How to send a key to a keyserver? In-Reply-To: <54F05BB2.9030405@nordnet.fr> References: <87egpcwq41.fsf@helmutwaitzmann.news.arcor.de> <54F05BB2.9030405@nordnet.fr> Message-ID: <54F05FE1.5030101@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 02/27/2015 12:57 PM, Philip Jackson wrote: > On 26/02/15 18:15, Helmut Waitzmann wrote: >> I tried >> >> gpg2 --verbose --keyserver hkp://pool.sks-keyservers.net >> --send-keys -- 72ABFF0923A87CF22D0ED7C4FDEE765D017077F1 >> >> and got the message >> >> gpg: sending key FDEE765D017077F1 to hkp server >> pool.sks-keyservers.net gpgkeys: HTTP post error 22: The >> requested URL returned error: 417 gpg: keyserver internal error >> gpg: keyserver send failed: Keyserver error >> ... > So maybe it was just a keyserver glitch ? > 417 really shouldn't happen for any of the servers in the pool, as it is explicitly checked that this return code should not be used. What is the DNS SOA of the response? For 1.4/2.0, please use --keyserver-options debug,verbose to get more information about the interaction from the curl helpers, this will be useful for debugging. - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- "Money is better than poverty, if only for financial reasons." (Woody Allen) -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJU8F/dAAoJEP7VAChXwav6RH4IAJyVhZ8mukMrweBggwM6dZbi qdiU59AOEc2Z3J2r2FX+/CxNW0H44nqoFIJb6UEf1nOKrFqVqy2T6F2CstZ5RgE4 MtT3GQIu3ci/YtwjA0PcXfrhwKvszvPU6UMaCXY5qa2bplNJAumX9dSsMub/JYc8 /wX6BS6IaXyq5g45CousumnK/7PDeJGOVy23+S7QI51pwFQ2Izr0AExGTZX3QnUc JihmNkBuwGDeoTXhkbWtxpTq8x8dyf0J/TylbDe4DeG2CJHsMmebFcN1MvFqkdi+ n288LmwpCLT4RxASrYfjTfouJBWAxz8vV7RxhiuPFvLSXC+YS9cUz9fj7zmyGiQ= =1H7l -----END PGP SIGNATURE----- From bre at pagekite.net Fri Feb 27 13:19:41 2015 From: bre at pagekite.net (Bjarni Runar Einarsson) Date: Fri, 27 Feb 2015 12:19:41 -0000 Subject: Thoughts on GnuPG and automation In-Reply-To: <54F04EC5.3000107@guardianproject.info> References: <54F04EC5.3000107@guardianproject.info> Message-ID: <20150227121834-25258-9117-mailpile@slinky> Hi Hans-Christoph! Hans-Christoph Steiner wrote: > With all the recent attention to GnuPG and Werner's work, I have begun to > think about things differently. GnuPG has an amazing security track record. > It has had few serious security bugs, nothing even close to heartbleed that I > know of, and yet it is core to providing security to GNU/Linux distros, as > well as protecting people like Laura Poitras and Edward Snowden. So instead > of complaining about the difficulties, I now try to think about whether such > difficulties might actually be related to what makes GnuPG so solid. Some of the more jaded will call this Stockholm syndrome. :-P I don't agree with the voices that want to discard PGP and start from scratch. There is valuable experience and maturity in this project, which is why we care enough to complain when it is hard to work with. > anyone interested in providing usable security needs to think hard about this. > Sure we can make things easier to use, but it is a very slippery slope > towards reducing security. I really disagree with this. If a security tool is too hard to understand, whether for a developer or user, then insecurity will be the inevitable result: people will use it wrong. This is only in part GnuPG's resposibility, most of the complexity is inherited from OpenPGP and the fact that public/private key crypto and key management are just very complex topics. This is the one point where I agree with the voices calling for abandoning OpenPGP entirely. It can well be argued that the whole cryptoscheme has been field tested and proven too complex for humans to use correctly. That's not exactly GnuPG's problem either, but these voices are becoming louder and, increasingly, there is finally competition in this space. The project will get marginalized if usability is ignored completely. Mailpile's attempt to make OpenPGP easy to use is us stubbornly trying to prove that it can be done. But I'm only somewhat optimistic that we'll succeed, and we'll only do so if we face reality and drop a large number of the features that make PGP what it is - in particular the web of trust and default trust model, and who knows what else. I don't mind if that code exists inside GnuPG, but Mailpile is absolutely not going to be using it. > I also have to call out that part of the problem that mailpile is continuing: > it is generally more fun to write code, rather than figure out someone else's > library. That is especially true when its a complicated thing like GnuPG. > But in order to have shared maintenance and work, we all need to take > responsibility and try to build upon the work of others whenever possible. > Mailpile did not do that, and instead wrote yet another incomplete > python API for GnuPG. Fair enough. We were in a hurry, and we probably did make a mistake here. There is a reason why we haven't broken our library out and published separately though: we do hope to tear it out and replace it with something more standard down the line. However, having done the work, I can now state with confidence that the complexity of our library is not because GnuPG is doing complex things. It is because the GnuPG command line interfaces for automation are incomplete and very hard to work with. Libraries might be able to hide this fact, but that doesn't make the problem go away - sysadmins and scripters everywhere have to deal with this all the time. It's a real burden and the source of many, many posts to this list and others. It's easy for developers to lose sight of the fact that no matter how many libraries exist, most people first encounter gpg at the command line. Slowly expanding on that and automating what you have learned is the Unix way, and it's a wonderful thing. Whatever the reason, GnuPG is not very good at this today. Unfortunately lots of existing code depends on these things staying unchanged, quirks and all. So it may be too late to fix, realistically speaking. Missing flags could be added, but cleaning up the stuff that already exists may be impossible. If that's Werner's verdict, then I totally understand and promise to stop complaining about it. > Another possibility is making ASSUAN, the internal protocol between GnuPG > components, the API instead of `gpg --json`. This only works on GnuPG 2.1, as > far as I understand it, since in 2.1, even commands like gpg communicate with > gpg-agent using ASSUAN, and it is actually gpg-agent that does all the work. FWIW, I took a lok at Assuan a while back, and I really like it. Replacing Assuan with JSON might help the project interface with the rest of the world, but that's the only argument in its favour; Assuan is definitely more suited to the things that GPG has to do. There is also a nice little Python library for interacting with it, so if gpg-agent ends up exposing an Assuan interface which can do all the stuff people do with GPGME, then I'll be very happy to switch to that. Very happy! :-) > Contrary to the mailpile write-ups, I think that having all the work > happen in gpg-agent makes sense, as long as there is a good API to it. I think you misunderstood my complaint. I don't mind if the agent is a persistance daemon that provides GPG-related services, that's all well and good. It's good process separation and I have no problem with that. My gripe with the agent, is the agent is controlling the UI of authentication. This breaks Mailpile, and this is one of the key areas where GnuPG crosses the imaginary line between library/utility and "application". Fixing this was point 1. in my list of suggestions and explaining why it was necessary was the bulk of the post. I took a look at the kludge Werner directed me towards in his previous mail - as far as I can tell, I can't use it unless I run my own dedicated gpg-agent with a custom configuration and custom keyring. Because gpg-agent controls the UI. I can do that. I can run a dedicated gpg-agent just for Mailpile and have a dedicated keyring. That'll work fine for most people and some may even prefer it. Only the folks on this list and folks that already have PGP keys will be unhappy that suddenly they have two keyrings to worry about, not just one... and for people wanting to keep their keychains in sync, we will have made key management even harder than it already is. As far as I can tell, those are the options available to me at the moment, unless I just stick with gnupg 1.4.x. Thanks for the comments, - Bjarni -- Sent using Mailpile, Free Software from www.mailpile.is From gnupg-ml at seichter.de Fri Feb 27 13:23:18 2015 From: gnupg-ml at seichter.de (Ralph Seichter) Date: Fri, 27 Feb 2015 13:23:18 +0100 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> Message-ID: <54F061B6.3070205@seichter.de> > Your positions to this ct approach? The c't magazine is mostly well respected in Germany and the editors have some valid points; the latest articles are by no means mindless rants or PGP-bashing. The thought of letting PGP die as an e-mail encryption mechanism for the "masses" (the non-tech-savvy average users) and to have it replaced with something my mother could use is valid. The c't editorial also clearly states that PGP works perfectly well and is secure as long as keys are verified, but fake keys and people not verifying fingerprints are a reality. Alice can't just send an e-mail to Bob, she needs to acquire and verify Bob's public key first. Compare this to transparent encryption like Apple's iMessage service uses and it is not hard to answer which mechanism has better usability. I like and use PGP like probably every subscriber on this mailing list, but the number of people I can exchange PGP-encrypted data with is very low when compared to the total number of my e-mail contacts. -Ralph From peter at digitalbrains.com Fri Feb 27 15:09:01 2015 From: peter at digitalbrains.com (Peter Lebbing) Date: Fri, 27 Feb 2015 15:09:01 +0100 Subject: Thoughts on GnuPG and automation In-Reply-To: <54F04EC5.3000107@guardianproject.info> References: <54F04EC5.3000107@guardianproject.info> Message-ID: <54F07A7D.3040709@digitalbrains.com> On 27/02/15 12:02, Hans-Christoph Steiner wrote: > For example, I think that > `gpg --json` is great idea. I ended up using a Java wrapper of GPGME, which > is in turn a wrapper of GnuPG. I think it makes a lot more sense to have `gpg > --json` as the parseble interface, then implement a GPGME-style framework in > each language (Python, Java, etc). I'd say the JSON interface could just be an additional set of functions in GPGME; and GPGME simply talks the old colon-separated protocol to the gpg binary. You can't just take out the colon-separated protocol, and that protocol has all the information. You could simply have GPGME reformat the output. Unless you mean that you want to speak to the gpg binary yourself, without GPGME in between. In that, case, I simply think you might be on the wrong track, and should use a library. If GPGME itself is a problem because you don't know what platform you should compile for, like in Python, then the library could be re-implemented in pure Python instead of using a foreign function interface. The old calling conventions of the binary cannot change, otherwise you'd break everything that already depends on it. And adding multiple ways of doing the same thing in the gpg binary seems the wrong place; more code, more chance of bugs, etcetera. This is where libraries come in, to save you the burden of working with the gpg binary. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From johanw at vulcan.xs4all.nl Fri Feb 27 15:22:54 2015 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Fri, 27 Feb 2015 15:22:54 +0100 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: <54F051D8.8080104@digitalbrains.com> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <54F051D8.8080104@digitalbrains.com> Message-ID: <54F07DBE.7070307@vulcan.xs4all.nl> On 27-02-2015 12:15, Peter Lebbing wrote: > Sooooo...... back to c't. Since they were writing an article, Isn't this just an article that started with the article of Moxie Marlinspike about GnuPG that was also on Slashdot yesterday? (Its at http://www.thoughtcrime.org/blog/gpg-and-me/). -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From wk at gnupg.org Fri Feb 27 15:40:01 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 27 Feb 2015 15:40:01 +0100 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: <54F061B6.3070205@seichter.de> (Ralph Seichter's message of "Fri, 27 Feb 2015 13:23:18 +0100") References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <54F061B6.3070205@seichter.de> Message-ID: <87mw3zo1tq.fsf@vigenere.g10code.de> On Fri, 27 Feb 2015 13:23, gnupg-ml at seichter.de said: > have some valid points; the latest articles are by no means mindless > rants or PGP-bashing. The thought of letting PGP die as an e-mail The article has two problems: - It compares an offline system (mail) with online systems (chat systems). You can't compare them unless you also change the headline to "Let mail die!". - It claims that the protocol is responsible for the problem instead of pin-pointing that the mail providers do not take up on it. Back in the good all days where everyone ran their own MTA and had full control over their DNS zones, fixing the problems would have been very easy. Today virtually everyone uses a large mail provider and thus has no more control over the own mail address including the zone. Given this, it is important to convince the mail providers to support their users doing end-to-end encryption. It would really be simple. I am not calling for a high-end security solution; just for a simple way to get authoritative information on the key associated with the mail address. A few scripts and an optional entry field in the user's mail account management is all what is required. With that in place we can easily fine tune the long existing mechanisms in gpg for key retrieval and then J?rgen Schmidt would not anymore get mails accidentally encrypted so someone else. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Feb 27 15:58:15 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 27 Feb 2015 15:58:15 +0100 Subject: Can't Encrypt in Freebsd 10.1 In-Reply-To: (Antoine Michard's message of "Fri, 27 Feb 2015 12:34:24 +0100") References: <87ppbsq4ff.fsf@vigenere.g10code.de> <87lhjjpz76.fsf@vigenere.g10code.de> Message-ID: <878ufjo0zc.fsf@vigenere.g10code.de> On Fri, 27 Feb 2015 12:34, michard.antoine at gmail.com said: > #2 0x0000000801918130 in __stack_chk_fail () from /lib/libc.so.7 > #3 0x0000000801179e43 in _gcry_cast5_amd64_cfb_dec () from I would try to build libgcrypt 1.6.3, which I just released, and check if that problem still exists. There used to be a problem when using an older as(1). If that still does not work, rebuild libgcrypt with the configure options --disable-asm and test again. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From steve at sawczyn.com Fri Feb 27 15:39:34 2015 From: steve at sawczyn.com (Steven M. Sawczyn) Date: Fri, 27 Feb 2015 08:39:34 -0600 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: <54F061B6.3070205@seichter.de> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <54F061B6.3070205@seichter.de> Message-ID: <085901d0529b$34a08d10$9de1a730$@Sawczyn.com> It saddens me, but I have to agree. Raising interest around PGP encryption is easy, but when it comes to actually using it, that's when people seem to back off quickly. I'm not a developer, so have no idea what would be required, but it seems to me that more focus is needed on making the experience as seamless and user friendly as possible. Steve -----Original Message----- From: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of Ralph Seichter Sent: Friday, February 27, 2015 6:23 AM To: gnupg-users at gnupg.org Subject: Re: German ct magazine postulates death of pgp encryption > Your positions to this ct approach? The c't magazine is mostly well respected in Germany and the editors have some valid points; the latest articles are by no means mindless rants or PGP-bashing. The thought of letting PGP die as an e-mail encryption mechanism for the "masses" (the non-tech-savvy average users) and to have it replaced with something my mother could use is valid. The c't editorial also clearly states that PGP works perfectly well and is secure as long as keys are verified, but fake keys and people not verifying fingerprints are a reality. Alice can't just send an e-mail to Bob, she needs to acquire and verify Bob's public key first. Compare this to transparent encryption like Apple's iMessage service uses and it is not hard to answer which mechanism has better usability. I like and use PGP like probably every subscriber on this mailing list, but the number of people I can exchange PGP-encrypted data with is very low when compared to the total number of my e-mail contacts. -Ralph _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users From dkg at fifthhorseman.net Fri Feb 27 16:39:21 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 27 Feb 2015 10:39:21 -0500 Subject: Unattended signing In-Reply-To: <176151659.20150227080739@my_localhost> References: <54E4DDFB.1010405@grinta.net> <87egpj5bb8.fsf@alice.fifthhorseman.net> <54EBC789.3010704@grinta.net> <87sidvt0p7.fsf@alice.fifthhorseman.net> <176151659.20150227080739@my_localhost> Message-ID: <87r3tbnz2u.fsf@alice.fifthhorseman.net> On Fri 2015-02-27 03:07:39 -0500, MFPA wrote: > On Tuesday 24 February 2015 at 10:16:20 PM, in > , Daniel Kahn Gillmor wrote: > >> That is, only a malicious person who manages to >> compromise that key material can make signatures with >> it. So why are you keeping it around? > > To verify existing signatures? Signatures are verified with the public part of the key. I was only suggesting to destroy the secret part of the key. --dkg From marcozehe-ml at mailbox.org Fri Feb 27 15:29:06 2015 From: marcozehe-ml at mailbox.org (Marco Zehe) Date: Fri, 27 Feb 2015 15:29:06 +0100 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: <54F05EF5.6050105@sumptuouscapital.com> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <1890860.SDiBssEjyI@inno> <000e01d05280$656fed70$304fc850$@on.yourweb.de> <7920271.MAWFr6xyvP@inno> <54F05EF5.6050105@sumptuouscapital.com> Message-ID: <39123D4C-8D17-4FE7-A1B2-4C126DDAD1C7@mailbox.org> Hi everyone! > Am 27.02.2015 um 13:11 schrieb Kristian Fiskerstrand : > > People need to understand that operational security is critical for > any security of a system and validate the key through secondary > channel (fingerprint, algorithm type, key length etc verifiable > directly or through probabilistic measures e.g. based on historical > postings on mailing lists over a long time for a project etc). Perhaps new emerging services like https://keybase.io can help with better key verification if clients like Enigmail and GPGMail (and others) integrate it into their workflows. Keybase works in a way that one creates an account, uploads one?s public key, and adds verification through at least one other means. Those include access to an account on Twitter, Github, Reddit or HackerNews, or a proof of domain ownership either by a DNS TXT entry or a file on the web server that follows a certain format. That way, the owner of a key can stipulate that they are able to access these accounts as well and are probably not fake. Of course, the valid point remains that not only the tweet, gist or other postings that are proof of ownership should be checked, but also other activity on relevant accounts, similar to what Kristian suggested for looking up activity on e-mail addresses. If you?d like to see an example, my profile can be viewed here: https://keybase.io/marcozehe. Marco -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From rjh at sixdemonbag.org Fri Feb 27 16:56:33 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 27 Feb 2015 10:56:33 -0500 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: <87mw3zo1tq.fsf@vigenere.g10code.de> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <54F061B6.3070205@seichter.de> <87mw3zo1tq.fsf@vigenere.g10code.de> Message-ID: <54F093B1.9030405@sixdemonbag.org> > Back in the good all days where everyone ran their own MTA and had > full control over their DNS zones... Ah, yes, back when men were men and sheep were scared. :) (It's an old American joke about the Old West: "when men were men and sheep were scared," mostly due to a shortage of women. I imagine the Australians probably have their own version of it.) > Given this, it is important to convince the mail providers to > support their users doing end-to-end encryption. It would really be > simple. With great respect, Werner, one thing twenty years of watching Classic PGP and OpenPGP not succeed has taught me is that there is nothing simple about increasing our user numbers. In some sense I see GnuPG as a quite successful failure. For the original purpose of PGP -- email security -- OpenPGP has turned out to be a dismal failure. When used correctly by knowledgeable people it offers a remarkable degree of protection, but it's condemned to forever be a niche player. Yet, in places where PGP was never imagined (signing operating system packages, for instance), OpenPGP has turned out to be incredibly important. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3744 bytes Desc: S/MIME Cryptographic Signature URL: From mwood at IUPUI.Edu Fri Feb 27 16:57:38 2015 From: mwood at IUPUI.Edu (Mark H. Wood) Date: Fri, 27 Feb 2015 10:57:38 -0500 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> Message-ID: <20150227155738.GB14628@IUPUI.Edu> On Fri, Feb 27, 2015 at 09:45:36AM +0100, gnupgpacker wrote: > German ct magazine has postulated in their last edition that our pgp > handling seems to be too difficult for mass usage, keyserver infrastructure > seems to be vulnerable for faked keys, published mail addresses are > collected from keyservers and so on... Whenever someone says that X is too complex for people to use, I always remember something attributed to Albert Einstein: In physics, everything should be made as simple as possible. But not simpler. I think it may be more widely applied. Some problems are inherently difficult. Any successful attempt to remove *inherent* complexity means that you are now solving a different problem which, while it may be interesting, might not model reality in a particularly useful way. It's always good to look for patterns that lead to useful simplification. But there comes a point at which no further simplfication can be done without making the system less useful. So: how well does PGP model the problems that people face in communicating securely? Does that model decompose neatly into smaller, simpler models that fit well to distinct communities of communicators? *Are* there useful clusterings of communication needs, w.r.t. security, within the community of communicators? -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: Digital signature URL: From brian at minton.name Fri Feb 27 15:52:12 2015 From: brian at minton.name (Brian Minton) Date: Fri, 27 Feb 2015 09:52:12 -0500 Subject: Thoughts on GnuPG and automation In-Reply-To: <54F07A7D.3040709@digitalbrains.com> References: <54F04EC5.3000107@guardianproject.info> <54F07A7D.3040709@digitalbrains.com> Message-ID: Yes, but the colon protocol doesn't support things like passphrase entry, etc. On Fri, Feb 27, 2015 at 9:09 AM, Peter Lebbing wrote: > On 27/02/15 12:02, Hans-Christoph Steiner wrote: >> For example, I think that >> `gpg --json` is great idea. I ended up using a Java wrapper of GPGME, which >> is in turn a wrapper of GnuPG. I think it makes a lot more sense to have `gpg >> --json` as the parseble interface, then implement a GPGME-style framework in >> each language (Python, Java, etc). > > I'd say the JSON interface could just be an additional set of functions in > GPGME; and GPGME simply talks the old colon-separated protocol to the gpg > binary. You can't just take out the colon-separated protocol, and that protocol > has all the information. You could simply have GPGME reformat the output. > > Unless you mean that you want to speak to the gpg binary yourself, without GPGME > in between. In that, case, I simply think you might be on the wrong track, and > should use a library. If GPGME itself is a problem because you don't know what > platform you should compile for, like in Python, then the library could be > re-implemented in pure Python instead of using a foreign function interface. > > The old calling conventions of the binary cannot change, otherwise you'd break > everything that already depends on it. And adding multiple ways of doing the > same thing in the gpg binary seems the wrong place; more code, more chance of > bugs, etcetera. This is where libraries come in, to save you the burden of > working with the gpg binary. > > HTH, > > Peter. > > > -- > I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. > You can send me encrypted mail if you want some privacy. > My key is available at > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From patrick at enigmail.net Fri Feb 27 17:26:51 2015 From: patrick at enigmail.net (Patrick Brunschwig) Date: Fri, 27 Feb 2015 17:26:51 +0100 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: <54F05EF5.6050105__7398.9701144912$1425039188$gmane$org@sumptuouscapital.com> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <1890860.SDiBssEjyI@inno> <000e01d05280$656fed70$304fc850$@on.yourweb.de> <7920271.MAWFr6xyvP@inno> <54F05EF5.6050105__7398.9701144912$1425039188$gmane$org@sumptuouscapital.com> Message-ID: <54F09ACB.6020108@enigmail.net> On 27.02.15 13:11, Kristian Fiskerstrand wrote: > On 02/27/2015 12:43 PM, Hauke Laging wrote: >> Am Fr 27.02.2015, 12:27:40 schrieb gnupgpacker: > >>> Maybe implementation with an opt-in could preserve publishing >>> of faked keys on public keyservers? > >> We need keyservers which are a lot better that today's. IMHO >> that also means that a keyserver should tell a client for each >> offered certificate whether it (or a trusted keyserver) has made >> such an email verification. > > The keyservers have no role in this, they are pure data store and > can never act as a CA. That would bring up a can of worm of issues, > both politically and legally, I wouldn't want to see the first case > where a keyserver operator was sued for permitting a "fake key" > (the term itself is very misleading, the key itself isn't fake at > all, but a fully valid key where the UID has not been mated to its > holder through proper validation). But that's the main primary reason of the article at all. The fact that anyone can upload _every_ key to a keyserver is an issue. If keyservers would do some sort of verification (e.g. confirmation of the email addresses) then this would lead to much more reliable data. Furthermore, we need a feature to allow keys to be removed in case the true owner of an email address requests it. I know that this collides with today's keyservers and it also collides with keyservers exchanging keys between each other, but I strongly believe that this would make keyservers more trustworthy than today. -Patrick From dsaklad at gnu.org Fri Feb 27 16:37:20 2015 From: dsaklad at gnu.org (Don Warer Saklad) Date: Fri, 27 Feb 2015 10:37:20 -0500 Subject: How would Massachusetts College of Pharmacy and Health Sciences Ask The Pharmacist program setup things?... Message-ID: <5ibnkfe573.fsf@fencepost.gnu.org> -Enquiry Massachusetts College of Pharmacy indicated an interest for the Ask The Pharmacist program at http://www.mcphs.edu/impact/community%20service%20programs/pharmacy%20outreach%20program How would you inform the MCPHS Ask The Pharmacist program in a way that they can understand clearly the steps for setting up things?... all in all it appears really complicated for most folks ! From kristian.fiskerstrand at sumptuouscapital.com Fri Feb 27 17:31:29 2015 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Fri, 27 Feb 2015 17:31:29 +0100 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: <54F09ACB.6020108@enigmail.net> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <1890860.SDiBssEjyI@inno> <000e01d05280$656fed70$304fc850$@on.yourweb.de> <7920271.MAWFr6xyvP@inno> <54F05EF5.6050105__7398.9701144912$1425039188$gmane$org@sumptuouscapital.com> <54F09ACB.6020108@enigmail.net> Message-ID: <54F09BE1.4030103@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 02/27/2015 05:26 PM, Patrick Brunschwig wrote: > On 27.02.15 13:11, Kristian Fiskerstrand wrote: >> On 02/27/2015 12:43 PM, Hauke Laging wrote: >>> Am Fr 27.02.2015, 12:27:40 schrieb gnupgpacker: >> >>>> Maybe implementation with an opt-in could preserve >>>> publishing of faked keys on public keyservers? >> >>> We need keyservers which are a lot better that today's. IMHO >>> that also means that a keyserver should tell a client for each >>> offered certificate whether it (or a trusted keyserver) has >>> made such an email verification. >> >> The keyservers have no role in this, they are pure data store >> and can never act as a CA. That would bring up a can of worm of >> issues, both politically and legally, I wouldn't want to see the >> first case where a keyserver operator was sued for permitting a >> "fake key" (the term itself is very misleading, the key itself >> isn't fake at all, but a fully valid key where the UID has not >> been mated to its holder through proper validation). > > But that's the main primary reason of the article at all. The fact > that anyone can upload _every_ key to a keyserver is an issue. If No, it is not, it has always been very clear no to rely on the existence of a key on either a keyserver or on a local keyring without proper verification and certification > keyservers would do some sort of verification (e.g. confirmation > of the email addresses) then this would lead to much more reliable > data. Furthermore, we need a feature to allow keys to be removed in > case the true owner of an email address requests it. Again, no it wont, a key could still be valid even though a second user adopts a domain name, what should happen to the first key on the keyserver in such an event, in particular if this is revoked, any activity from the keyservers on this could lead to misappropriation. This would be bad for the overall security of the network, it is a reason the keyservers are add only and should continue to remain so. > > I know that this collides with today's keyservers and it also > collides with keyservers exchanging keys between each other, but I > strongly believe that this would make keyservers more trustworthy > than today. It collides with security and is a bad idea. - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- Nomina stultorum scribuntur ubique locorum Fools have the habit of writing their names everywhere -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJU8JvcAAoJEP7VAChXwav6qyEH/RtQlf3Y/hS02TByKbC/fYxt LunKjBEucWb06V3H+rU2og0SWwsnXhNq+LxHZsm8X6YaCKDT/zXjtUYyQzuqTbfH e6lBlXWJK/XyauXWi4RPNX2LhZkx8z+bRpMA6EcFvlZu/+jmWUDLXTCsypzpr77O Ex+G4Y6yJG4d/atJEMtjqeKPBwhvWCpDBA1Ar4SR5xiXDa3FtNQ/dYxCxDsGuwad Yk82YHSjeH1CMwmk1rLB1q/btaFwr7ZKeAR1ox8M9xBukfiCeYF09A3RtDPP/yHQ KTsFg5aaU0IksqJnsiVXOTbX1VRi4e6rho9O762nwbZSw7hfRHoDKOjWIyHsSQU= =vv+O -----END PGP SIGNATURE----- From marcozehe-ml at mailbox.org Fri Feb 27 19:37:49 2015 From: marcozehe-ml at mailbox.org (Marco Zehe) Date: Fri, 27 Feb 2015 19:37:49 +0100 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: <54F09BE1.4030103@sumptuouscapital.com> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <1890860.SDiBssEjyI@inno> <000e01d05280$656fed70$304fc850$@on.yourweb.de> <7920271.MAWFr6xyvP@inno> <54F05EF5.6050105__7398.9701144912$1425039188$gmane$org@sumptuouscapital.com> <54F09ACB.6020108@enigmail.net> <54F09BE1.4030103@sumptuouscapital.com> Message-ID: <6F29DDC0-9A47-4536-A0FA-17A8EE061129@mailbox.org> Hi Kristian, > Am 27.02.2015 um 17:31 schrieb Kristian Fiskerstrand : > > On 02/27/2015 05:26 PM, Patrick Brunschwig wrote: > > On 27.02.15 13:11, Kristian Fiskerstrand wrote: > >> On 02/27/2015 12:43 PM, Hauke Laging wrote: > >>> Am Fr 27.02.2015, 12:27:40 schrieb gnupgpacker: > >> > >>>> Maybe implementation with an opt-in could preserve > >>>> publishing of faked keys on public keyservers? > >> > >>> We need keyservers which are a lot better that today's. IMHO > >>> that also means that a keyserver should tell a client for each > >>> offered certificate whether it (or a trusted keyserver) has > >>> made such an email verification. > >> > >> The keyservers have no role in this, they are pure data store > >> and can never act as a CA. That would bring up a can of worm of > >> issues, both politically and legally, I wouldn't want to see the > >> first case where a keyserver operator was sued for permitting a > >> "fake key" (the term itself is very misleading, the key itself > >> isn't fake at all, but a fully valid key where the UID has not > >> been mated to its holder through proper validation). > > > > But that's the main primary reason of the article at all. The fact > > that anyone can upload _every_ key to a keyserver is an issue. If > > No, it is not, it has always been very clear no to rely on the > existence of a key on either a keyserver or on a local keyring without > proper verification and certification And here?s the other problem the main article in c?t mentions: Those keys, although faked, were certified. They were certified by equally faked keys which resemble keys that are quite well-known. So unless someone had the *real* certifying keys installed and could see that those weren?t the same certifications as on the forged keys, there was no first and even second glance way of recognising these as being faked. I agree with Patrick?s point that the problem, indeed, lies in the way keys can be uploaded to key servers without at least some basic verification of key ownership. Something needs to change, and there *must* be put a mechanism into place that allows at least some assurance that the person I think the key belongs to, is actually the owner. It is not always feasible to verify a whole key finger print with the recipient first-hand, except for insecure plain text e-mail. For example, if I wanted to have sent that journalist encrypted e-mail with some important information, according to the current model, I would have had to find out a phone number to reach him, have a business card with his key?s finger print on, or met him in person to verify each other?s keys first. That?s a damn high entry level, and I think it?s time to re-think some aspects of that and integrate some means of ownership verification that avoids at least some of the above mentioned problems. Marco -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From peter at digitalbrains.com Fri Feb 27 19:43:12 2015 From: peter at digitalbrains.com (Peter Lebbing) Date: Fri, 27 Feb 2015 19:43:12 +0100 Subject: Whishlist for next-gen card In-Reply-To: <54E8D46E.1080408@gmail.com> References: <54E6F12D.40504@gmail.com> <54E87133.2040202@digitalbrains.com> <54E8D46E.1080408@gmail.com> Message-ID: <54F0BAC0.7060503@digitalbrains.com> On 21/02/15 19:54, NdK wrote: >>> 4 - HOTP PINs for signature/certification keys >> What generates the HOTP then? Do you type a PIN on the HOTP device to get the HOTP? > No need. Just an applet on the phone could do. At least if you aren't > using the same phone to do the crypto. I don't understand the practical difference between HOTP and the button to confirm an action. As it is now, it is the case that malware can sniff your PIN and use that to use the card. When you add a button, it knows the PIN, but can't push the button, so you're back in the loop. The malware needs an action by you, the user. If you use HOTP, the malware doesn't know the next HOTP to do an action, which means it once again relies on you to enter the HOTP. In the former, the user pushes the button. In the latter, the user enters the HOTP. What does the HOTP prevent that the button doesn't? And then I don't mean "learning the PIN", but something that is a goal of an attacker. Getting the PIN is only the means, their goal is, for instance, to decrypt or sign. What goal can an attacker achieve when only the button is there, not the HOTP? > Maybe its addition to the security is marginal, but can be *way* more > practical than having to reenter a complex PIN every time. I think the security benefit from having to enter your PIN on every access is already very marginal, and outweighed by the burden of entering the PIN. In other words, have the card remain unlocked and ready for use with a single PIN entry. If you're working on a compromised PC, you're already so screwed that your forced entry of the PIN each and every time isn't going to help. To me, the benefit of the button is that it is out-of-band. Re-entering your PIN every time is in-band, and in my eyes, not worth it. > If that info is embedded in the signature packet, it could add something > to the signature value (if the receiving party sees that signature is > about a txt file and the presented object is a doc, there's something > wrong and suspect). Are you proposing that the internal hash state after the hashing of the document is handed over to the smartcard, after which the smartcard computes the hash over the signature subpackets that you want protected this way? It's unclear to me how you see such a thing be implemented without passing all data to the smartcard. > That's the fingerprint ssh shows you. It should be computed from the > complete public key. I wasn't talking about what it shows me, I was talking about what is in the challenge that is signed. I've had a quick look in RFC 4252, with public key user authentication for SSH2. I don't think there's anything that you can show on a display that would help the user decide if it were what they wanted to see. After a really quick glance in the RFC, I see just the username and the session identifier. The username is hardly unique (I usually use peter), and the session identifier is a unique number computed for the SSH session. It's the bit that prevents signature replay attacks but is not useful to show on a display, since the user can't tell whether it's good or not: it's just the output of a hash function. All this is based on a really quick read of documentation I hadn't consulted before. It could be glaringly wrong. But when you said "it is the fingerprint", I wondered if you misunderstood or that the fingerprint is actually part of the challenge. I don't think it is. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.You can send me encrypted mail if you want some privacy. My key is available at From kristian.fiskerstrand at sumptuouscapital.com Fri Feb 27 20:28:39 2015 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Fri, 27 Feb 2015 20:28:39 +0100 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: <6F29DDC0-9A47-4536-A0FA-17A8EE061129@mailbox.org> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <1890860.SDiBssEjyI@inno> <000e01d05280$656fed70$304fc850$@on.yourweb.de> <7920271.MAWFr6xyvP@inno> <54F05EF5.6050105__7398.9701144912$1425039188$gmane$org@sumptuouscapital.com> <54F09ACB.6020108@enigmail.net> <54F09BE1.4030103@sumptuouscapital.com> <6F29DDC0-9A47-4536-A0FA-17A8EE061129@mailbox.org> Message-ID: <54F0C567.3040707@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 02/27/2015 07:37 PM, Marco Zehe wrote: > Hi Kristian, > >> Am 27.02.2015 um 17:31 schrieb Kristian Fiskerstrand >> : >> >> On 02/27/2015 05:26 PM, Patrick Brunschwig wrote: >>> On 27.02.15 13:11, Kristian Fiskerstrand wrote: >>>> On 02/27/2015 12:43 PM, Hauke Laging wrote: >>>>> Am Fr 27.02.2015, 12:27:40 schrieb gnupgpacker: ... >>> >>> But that's the main primary reason of the article at all. The >>> fact that anyone can upload _every_ key to a keyserver is an >>> issue. If >> >> No, it is not, it has always been very clear no to rely on the >> existence of a key on either a keyserver or on a local keyring >> without proper verification and certification > > And here?s the other problem the main article in c?t mentions: > Those keys, although faked, were certified. They were certified by > equally faked keys which resemble keys that are quite well-known. > So unless someone had the *real* certifying keys installed and > could see that those weren?t the same certifications as on the > forged keys, there was no first and even second glance way of > recognising these as being faked. This doesn't make much sense, if you don't have a trust path to any of those other keys their existence is irrelevant, and that is before taking ownertrust into considerations in the first place (only a dozen of the keys I've certified have ever been assigned an ownertrust of marginal and much fewer as full) What is needed is better education and an increased consciousness in society at large in considering security and privacy. I will concede that we have a way to go on making the concepts better understood, which is increasingly getting difficult due to diffusion from things like discussions on algorithms and key preferences, that plays a marginal role in the overall consideration of security (including opsec). - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- "I never worry about action, but only inaction." (Winston Churchill) -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJU8MVjAAoJEP7VAChXwav6u+cH/2N+9jRongWuNnRVuoAtWv8l 942GmWX9bTiLrX7BMHLyVyQ3MwEA/nqvHA5g4wGCL2TbJ5IiUvMwEr772YlSbsXH nMpEV4OVtdaZpCjvoCNtnNxHVG0IHI5PaPoCcAHMxOq3Ed2GIJjCvS/CQjP0XpSy X96eyqg+IamEQzXF+ON90xstqLG704lFgkE7PI6hkRAzs+wi5mz54sN6YgmSKAUj A4KS3/1ZORWLG/P0bGYChrtipoXAlW74K3gjG2eLLtFuiqlqG38HEBDYLYPISkyC iwecqXSbKoq1R8e9c1Xox9bwVyqEDXz+lLahmwMgGtshQEhXkjylVPQ9uHkw8/w= =gwGH -----END PGP SIGNATURE----- From calestyo at scientia.net Fri Feb 27 19:16:17 2015 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Fri, 27 Feb 2015 19:16:17 +0100 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> Message-ID: <1425060977.5204.10.camel@scientia.net> Hey. I really cannot understand why ct/heise and some others run these Anti-OpenPGP campaigns recently, while at the same time hypocritically claiming they'd be in favour of cryptography for people. - Per se, users will need to have at least some basic understanding of cryptography - otherwise anyone could trick them into doing anything. I'm talking about things like "don't blindly sign others keys", or that one cannot securely communicated with a peer unless one has more or less directly exchanged some credentials (e.g. fingerprints) with that. - Apart from that, OpenPGP isn't that complicated, there are many front-ends which allow the end user to use gnupg in an easy manner. - If one wants real security, one will never get around that mutual authentication / credential-exchange ... and THIS is the actual thing that makes OpenPGP (in contrast to X.509 and friends) "complicated". And this is also why I'd call ct/heise anti-cryptographers: For some months now they demand "cryptography made easy" and to kick everything else into the can. They basically demand stuff like "TextSecure" which they advertise as the best secure messenger out there - while it actually doesn't even demand users to mutually verify any credentials at all. And even if they do one hasn't even a way to mark a contact as validated or not (bug open for ages now). This is basically what they want: Anonymous cryptography, whose complete security is based on some good luck whether you've communicated with the right peer the first time. But instead of just advertising that crap, they seem to also have went on some stupid anti-OpenPGP campaign... o.O Cheers, Chris. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5313 bytes Desc: not available URL: From wk at gnupg.org Fri Feb 27 20:42:30 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 27 Feb 2015 20:42:30 +0100 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: <6F29DDC0-9A47-4536-A0FA-17A8EE061129@mailbox.org> (Marco Zehe's message of "Fri, 27 Feb 2015 19:37:49 +0100") References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <1890860.SDiBssEjyI@inno> <000e01d05280$656fed70$304fc850$@on.yourweb.de> <7920271.MAWFr6xyvP@inno> <54F05EF5.6050105__7398.9701144912$1425039188$gmane$org@sumptuouscapital.com> <54F09ACB.6020108@enigmail.net> <54F09BE1.4030103@sumptuouscapital.com> <6F29DDC0-9A47-4536-A0FA-17A8EE061129@mailbox.org> Message-ID: <87pp8vm995.fsf@vigenere.g10code.de> On Fri, 27 Feb 2015 19:37, marcozehe-ml at mailbox.org said: > And here?s the other problem the main article in c?t mentions: Those > keys, although faked, were certified. They were certified by equally > faked keys which resemble keys that are quite well-known. So unless Nope. According to the questions the author sent me prior to publishing this article, he only looked at listing presented by the keyserver and concluded that if the web pages tells self-signature the user id must be valid (e.g. that second user id on the c't PGP CA). Now we all know that keyservers don't do crypto. As soon as you import that key the user ids with the faked self-signature are simply ignored and a listing by gpg won't show them. To avoid that in the future, the signature listing from the keyservers may add a note about this. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Feb 27 20:56:00 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 27 Feb 2015 20:56:00 +0100 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: <54F09ACB.6020108@enigmail.net> (Patrick Brunschwig's message of "Fri, 27 Feb 2015 17:26:51 +0100") References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <1890860.SDiBssEjyI@inno> <000e01d05280$656fed70$304fc850$@on.yourweb.de> <7920271.MAWFr6xyvP@inno> <54F05EF5.6050105__7398.9701144912$1425039188$gmane$org@sumptuouscapital.com> <54F09ACB.6020108@enigmail.net> Message-ID: <87lhjjm8mn.fsf@vigenere.g10code.de> On Fri, 27 Feb 2015 17:26, patrick at enigmail.net said: > that anyone can upload _every_ key to a keyserver is an issue. If > keyservers would do some sort of verification (e.g. confirmation of > the email addresses) then this would lead to much more reliable data. We have such a system. It is called S/MIME. Ever tried to find an S/MIME (X.509) key (aka certificate) for an arbitrary mail address? The only working solution to get such a key is by sending a mail and asking for the key. You can do the very same with PGP of course. Keyservers along with visting cards are much nicer. So, why is there no public service to distribute X.509 keys? Because nobody want to be legally responsible for such a key unless you push a stack of money over the table for a qualified signature certificate. BTW, even the DFN PGP keyserver (blackhole.pca.dfn.de) had to be shut down for similar legal reasons. However, it is not a problem, we can use other keyservers. > believe that this would make keyservers more trustworthy than today. There is no trust in keyservers by design. As soon as you start changing this you are turning PGP into a centralized system. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From kristian.fiskerstrand at sumptuouscapital.com Fri Feb 27 21:07:02 2015 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Fri, 27 Feb 2015 21:07:02 +0100 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: <87pp8vm995.fsf@vigenere.g10code.de> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <1890860.SDiBssEjyI@inno> <000e01d05280$656fed70$304fc850$@on.yourweb.de> <7920271.MAWFr6xyvP@inno> <54F05EF5.6050105__7398.9701144912$1425039188$gmane$org@sumptuouscapital.com> <54F09ACB.6020108@enigmail.net> <54F09BE1.4030103@sumptuouscapital.com> <6F29DDC0-9A47-4536-A0FA-17A8EE061129@mailbox.org> <87pp8vm995.fsf@vigenere.g10code.de> Message-ID: <54F0CE66.1080208@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 02/27/2015 08:42 PM, Werner Koch wrote: > On Fri, 27 Feb 2015 19:37, marcozehe-ml at mailbox.org said: > >> And here?s the other problem the main article in c?t mentions: >> Those keys, although faked, were certified. They were certified >> by equally faked keys which resemble keys that are quite >> well-known. So unless > > Nope. According to the questions the author sent me prior to > publishing this article, he only looked at listing presented by the > keyserver and concluded that if the web pages tells self-signature > the user id must be valid (e.g. that second user id on the c't PGP > CA). Now we all know that keyservers don't do crypto. As soon as > you import that key the user ids with the faked self-signature are > simply ignored and a listing by gpg won't show them. the author was fully aware of this, he contacted me back in May 2014 already regarding these keys and asked me to provide a list of keys that had been signed by some specific keys (the fake CA keys). That list was provided after a quick lookup - there were 7 keys in total that had been signed with them. > > To avoid that in the future, the signature listing from the > keyservers may add a note about this. Increasing the information on keyservers like this, in particular in the descriptive parts can be considered, would it suffice to be part of the standard web interface for keyserver intro, or would it have to be added on each individual index page? - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- Veni vidi velcro I came, I saw, I got stuck -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJU8M5dAAoJEP7VAChXwav6okgIAKEMDKEh4mcd++SWPpCdhlr/ 3Uyrz2E3Ifer3QuSBp4nav8XRx43HcvNkCja+RqdGue3RmRYadMUW2FwjLe/lX04 BKZ48/NOXBOC3/JJUQUr5/HkWXLII+rSf13jDu1GixnPUUI7gtECTPJQDevBrQLF cA5L/hgrNH1Te1y4iZLrzmlEtr95Az8MlwkBmSf+sLCnmG7gW7suKHXsC7JrcRA7 siApTYVqk7PLBq8iMcs40A33+BbYZ1eXUwe3NuNGaPJV/4UjnGaKO4zjvcsk/uY5 YdtW63jtNYtN51lpL67mEMsIzTGfN3FM0L/RC0ud83TeoBbWaaloAufJQJARem0= =nGok -----END PGP SIGNATURE----- From andreas.schwier.ml at cardcontact.de Fri Feb 27 21:12:25 2015 From: andreas.schwier.ml at cardcontact.de (Andreas Schwier) Date: Fri, 27 Feb 2015 21:12:25 +0100 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: <54F09BE1.4030103@sumptuouscapital.com> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <1890860.SDiBssEjyI@inno> <000e01d05280$656fed70$304fc850$@on.yourweb.de> <7920271.MAWFr6xyvP@inno> <54F05EF5.6050105__7398.9701144912$1425039188$gmane$org@sumptuouscapital.com> <54F09ACB.6020108@enigmail.net> <54F09BE1.4030103@sumptuouscapital.com> Message-ID: <54F0CFA9.7070601@cardcontact.de> >> But that's the main primary reason of the article at all. The fact >> that anyone can upload _every_ key to a keyserver is an issue. If > > No, it is not, it has always been very clear no to rely on the > existence of a key on either a keyserver or on a local keyring without > proper verification and certification So what exactly is the purpose of the keyserver then ? If you expect me to still verify fingerprints out of band, why would I grab a - probably bogus key - from a keyserver first place ? I could immediately ask my peer to send it by mail. The keyserver would make sense, if my mail client would automatically fetch the public key from a server, based on the e-mail address of the sender and some identity data (e.g. fingerprint) in the mail signature. It would them prompt me, if I want to add that key to my keyring and optionally perform some additional out-of-band checks. Because normally I exchange keys in the context of establishing a relationship with the sender of the e-mail. The context (mail arrived expectedly, had a phone call just before, answers my request) allows to me to make a cautious decision about the level of trust I have in the key. I have been using GNUPG for ages now, but I verified fingerprints only a hand-full of time. Most of the time, I ask my peer for his public key and wait for the mail to arrive. For me web-of-trust and key signing parties don't make any sense, because I'd rather start a communication with a bogus key and establish trust in my genuine peer from the conversation we are having. I like the way Threema does it: I can immediately start a secure communication and if I need I can elevate the trust I have in the key. But most of the time I'm communicating with people I know anyway. -- --------- CardContact Software & System Consulting |.##> <##.| Andreas Schwier |# #| Sch?lerweg 38 |# #| 32429 Minden, Germany |'##> <##'| Phone +49 571 56149 --------- http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org http://www.smartcard-hsm.com From calestyo at scientia.net Fri Feb 27 21:24:11 2015 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Fri, 27 Feb 2015 21:24:11 +0100 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: <87lhjjm8mn.fsf@vigenere.g10code.de> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <1890860.SDiBssEjyI@inno> <000e01d05280$656fed70$304fc850$@on.yourweb.de> <7920271.MAWFr6xyvP@inno> <54F05EF5.6050105__7398.9701144912$1425039188$gmane$org@sumptuouscapital.com> <54F09ACB.6020108@enigmail.net> <87lhjjm8mn.fsf@vigenere.g10code.de> Message-ID: <1425068651.5204.80.camel@scientia.net> On Fri, 2015-02-27 at 20:56 +0100, Werner Koch wrote: > There is no trust in keyservers by design. As soon as you start > changing this you are turning PGP into a centralized system. Well not necessarily - at least not in the sense of exactly one power having control over the whole key network (as it would be the case in X.509). IMHO the current situation with keyservers isn't perfect: - Usually (AFAIK), only one of them is used for queries/submissions... if that one is evil, that you have a problem (at least until the next submission/query). - Nothing is authenticated (well there is hkps, but the problem here is, that one single person holds the control over the effectively only used CA... and while I don't think that Kristian is evil ;-) ... it's a conceptual problem). => thus an attacker can easily do downgrade/blocking attacks... like filtering out any revocation certs. - Nothing is encrypted (so everyone eavesdropping will know that I just downloaded the key for nsa-whistleblowers at wikileaks.org... and five minutes later I'd be beaten to death). Ideally, every keyserver would sign his responses (with OpenPGP of course ;) )... and GnuPG/etc. would ship the keys of (at least some of) these servers. This is of course some effort to collect/verify and even then Werner&Co wouldn't know whether can for example trust me as a keyserver operator or whether I'm secretly paid by the BND. But(!) when each request (queries / submissions) would be made to a handful of randomly chosen keyservers (say 20?), there are good chances that at least some of them are not evil and any forgery would be at least noted. Ideally, gnupg.org would then also run a keyserver, which is always included in the list. Why? Well most people don't audit the code of GnuPG, so when they trust them already with respect to that, they can also trust them with respect to a keyserver. And people should be able to specify additional always-in-the-list keyservers,.. like I would specify my own or ubuntu employees would specify the one from canonical - if it's running ;) ). As for the privacy component: The above schema obviously makes encryption for privacy useless... (an other issues, like keyservers doing caching, could also make it defeatable). So I think the way to go here would be Tor. Cheers, Chris. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5313 bytes Desc: not available URL: From calestyo at scientia.net Fri Feb 27 21:25:40 2015 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Fri, 27 Feb 2015 21:25:40 +0100 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: <54F0CFA9.7070601@cardcontact.de> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <1890860.SDiBssEjyI@inno> <000e01d05280$656fed70$304fc850$@on.yourweb.de> <7920271.MAWFr6xyvP@inno> <54F05EF5.6050105__7398.9701144912$1425039188$gmane$org@sumptuouscapital.com> <54F09ACB.6020108@enigmail.net> <54F09BE1.4030103@sumptuouscapital.com> <54F0CFA9.7070601@cardcontact.de> Message-ID: <1425068740.5204.81.camel@scientia.net> On Fri, 2015-02-27 at 21:12 +0100, Andreas Schwier wrote: > So what exactly is the purpose of the keyserver then ? Find trust paths, signature updates, self signature updates, key revocation certs (but beware of the issues I've described in my mail a few seconds before)... Cheers, Chris. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5313 bytes Desc: not available URL: From wk at gnupg.org Fri Feb 27 21:20:54 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 27 Feb 2015 21:20:54 +0100 Subject: [Announce] GnuPG 1.4.19 released (with SCA fix) Message-ID: <87d24vm7h5.fsf@vigenere.g10code.de> Hello! We are pleased to announce the availability of a new GnuPG classic release: Version 1.4.19. This release mitigates two new side channel attacks. Updating any GnuPG 1.4 version to 1.4.19 is suggested! To update a GnuPG 2.0 or 2.1 version you need to update the shared library Libgcrypt to version 1.6.3. What is GnuPG ============= The GNU Privacy Guard (GnuPG) is a complete and free implementation of the OpenPGP standard as defined by RFC-4880 and better known as PGP. GnuPG, also known as GPG, allows to encrypt and sign data and communication, features a versatile key management system as well as access modules for public key directories. GnuPG itself is a command line tool with features for easy integration with other applications. A wealth of frontend applications and libraries making use of GnuPG are available. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License. Three different versions of GnuPG are actively maintained: - GnuPG "modern" (2.1) is the latest development with a lot of new features. - GnuPG "stable" (2.0) is the current stable version for general use. This is what most users are currently using. - GnuPG "classic" (1.4) is the old standalone version which is most suitable for older or embedded platforms. This announcement is about a release of this version. You may not install "modern" (2.1) and "stable" (2.0) at the same time. However, it is possible to install "classic" (1.4) along with any of the other versions. What's New in GnuPG 1.4.19 ========================== * Use ciphertext blinding for Elgamal decryption [CVE-2014-3591]. See http://www.cs.tau.ac.il/~tromer/radioexp/ for details. * Fixed data-dependent timing variations in modular exponentiation [related to CVE-2015-0837, Last-Level Cache Side-Channel Attacks are Practical]. * Detect faulty use of --verify on detached signatures. * Changed the PKA method to use CERT records and hashed names. * New import option "keep-ownertrust". * Support algorithm names when generating keys using the --command-fd method. * Updated many translations. * Updated build system. * Fixed a regression in keyserver import * Fixed argument parsing for option --debug-level. * Fixed DoS based on bogus and overlong key packets. * Fixed bugs related to bogus keyrings. * The usual minor minor bug fixes. Getting the Software ==================== Please follow the instructions found at https://gnupg.org/download/ or read on: GnuPG 1.4.19 may be downloaded from one of the GnuPG mirror sites or direct from its primary FTP server. The list of mirrors can be found at https://gnupg.org/mirrors.html . Note that GnuPG is not available at ftp.gnu.org. On ftp.gnupg.org you find these files: ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-1.4.19.tar.bz2 (3627k) ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-1.4.19.tar.bz2.sig This is the GnuPG 1.4.19 source code compressed using BZIP2 and its OpenPGP signature. ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-1.4.19.tar.gz (5020k) ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-1.4.19.tar.gz.sig This is the same GnuPG 1.4.19 source code compressed using GZIP and its OpenPGP signature. ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32cli-1.4.19.exe (1586k) ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32cli-1.4.19.exe.sig This is GnuPG 1.4.19 compiled for Microsoft Windows and its OpenPGP signature. This is a command line only version; the source files are the same as above. Note, that this is a minimal installer and unless you are only in need for the simple the gpg binary, you are better off using the full featured installer at https://www.gpg4win.org . Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a version of GnuPG installed, you can simply verify the supplied signature. For example to verify the signature of the file gnupg-1.4.19.tar.bz2 you would use this command: gpg --verify gnupg-1.4.19.tar.bz2.sig gnupg-1.4.19.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See below for information on the signing keys. * If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either "sha1sum" or "shasum". Assuming you downloaded the file gnupg-1.4.19.tar.bz2, you would run the command like this: sha1sum gnupg-1.4.19.tar.bz2 and check that the output matches the first line from the following list: 5503f7faa0a0e84450838706a67621546241ca50 gnupg-1.4.19.tar.bz2 d0cf40cc42ce057d7d747908ec21a973a423a508 gnupg-1.4.19.tar.gz dc03ae4e4c3e8fe0583b37dd6c3124f94246d2f8 gnupg-w32cli-1.4.19.exe Release Signing Keys ==================== To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: 2048R/4F25E3B6 2011-01-12 [expires: 2019-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048/E0856959 2014-10-29 [expires: 2019-12-31] Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 David Shaw (GnuPG Release Signing Key) rsa2048/33BD3F06 2014-10-29 [expires: 2016-10-28] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa2048/7EFD60D9 2014-10-19 [expires: 2020-12-31] Key fingerprint = D238 EA65 D64C 67ED 4C30 73F2 8A86 1B1C 7EFD 60D9 Werner Koch (Release Signing Key) You may retrieve these files from the keyservers using this command gpg --recv-keys 249B39D24F25E3B6 04376F3EE0856959 \ 2071B08A33BD3F06 8A861B1C7EFD60D9 The keys are also available at https://gnupg.org/signature_key.html . Note that this mail has been signed using my standard PGP key. Support ======== Please consult the archive of the gnupg-users mailing list before reporting a bug . We suggest to send bug reports for a new release to this list in favor of filing a bug at . For commercial support requests we keep a list of known service companies at: https://gnupg.org/service.html If you are a developer and you may need a certain feature for your project, please do not hesitate to bring it to the gnupg-devel mailing list for discussion. Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, and answering questions on the mailing lists. Since the start of the funding campaign in December several thousand people have been kind enough to donate a total of 250000 Euro to support this project. In addition the Linux Foundation gave a grant of $ 60000 for 2015, Stripe.com and Facebook.com each pledged $ 50000 per year. I am amazed by this superb and unexpected support for the GnuPG project. This does not only allow us to continue the project and allowed to hire second full time developer, but also gives the resources to improve things which have been delayed for too long. *Thank you all !* Salam-Shalom, Werner p.s. This is a announcement only mailing list. Please send replies only to the gnupg-users at gnupg.org mailing list. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 180 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From wk at gnupg.org Fri Feb 27 21:39:05 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 27 Feb 2015 21:39:05 +0100 Subject: [Announce] Libgcrypt 1.6.3 released (with SCA fix) Message-ID: <874mq7m6mu.fsf@vigenere.g10code.de> Hello! The GNU project is pleased to announce the availability of Libgcrypt version 1.6.3. This is a security fix release to mitigate two new side channel attacks. Libgcrypt is a general purpose library of cryptographic building blocks. It does not provide any implementation of OpenPGP or other protocols. Thorough understanding of applied cryptography is required for proper use Libgcrypt. Noteworthy changes in version 1.6.3 =================================== * Use ciphertext blinding for Elgamal decryption [CVE-2014-3591]. See http://www.cs.tau.ac.il/~tromer/radioexp/ for details. * Fixed data-dependent timing variations in modular exponentiation [related to CVE-2015-0837, Last-Level Cache Side-Channel Attacks are Practical]. * Improved asm support for older toolchains. Download ======== Source code is hosted at the GnuPG FTP server and its mirrors as listed at http://www.gnupg.org/download/mirrors.html . On the primary server the source tarball and its digital signature are: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.3.tar.bz2 (2436k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.3.tar.bz2.sig That file is bzip2 compressed. A gzip compressed version is here: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.3.tar.gz (2893k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.3.tar.gz.sig In order to check that the version of Libgcrypt you are going to build is an original and unmodified one, you can do it in one of the following ways: * Check the supplied OpenPGP signature. For example to check the signature of the file libgcrypt-1.6.3.tar.bz2 you would use this command: gpg --verify libgcrypt-1.6.3.tar.bz2.sig libgcrypt-1.6.3.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one of the release signing keys. See https://gnupg.org/signature_key.html . * If you are not able to use GnuPG, you have to verify the SHA-1 checksum: sha1sum libgcrypt-1.6.3.tar.bz2 and check that the output matches the first line from the following list: 9456e7b64db9df8360a1407a38c8c958da80bbf1 libgcrypt-1.6.3.tar.bz2 4d56b5d754d39acae239f876537672e1dc8298e3 libgcrypt-1.6.3.tar.gz Copying ======= Libgcrypt is distributed under the terms of the GNU Lesser General Public License (LGPLv2.1+). The helper programs as well as the documentation are distributed under the terms of the GNU General Public License (GPLv2+). The file LICENSES has notices about contributions that require these additional notices are distributed. Support ======= For help on developing with Libgcrypt you should read the included manual and optional ask on the gcrypt-devel mailing list [1]. A listing with commercial support offers for Libgcrypt and related software is available at the GnuPG web site [2]. If you are a developer and you may need a certain feature for your project, please do not hesitate to bring it to the gcrypt-devel mailing list for discussion. Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, and answering questions on the mailing lists. Niibe Yutaka did most of the work on fixing the side channel attacks. Special thanks to a) Daniel Genkin and his team for working with us on the fix for the "radioexp" attack, b) Yuval Yarum and its team for advance information on their new cache attack and sample code on how to fix it. Since the start of the GnuPG funding campaign in December several thousand people have been kind enough to donate a total of 250000 Euro to support this project. In addition the Linux Foundation gave a grant of $ 60000 for 2015, Stripe.com and Facebook.com each pledged $ 50000 per year. I am amazed by this superb and unexpected support for the GnuPG project. This will not only allow us to continue the project and hire a second full time developer but gives us also the resources to improve things which have been delayed for too long. *Thank you all !* Happy hacking, Werner [1] http://lists.gnupg.org/mailman/listinfo/gcrypt-devel [2] https://www.gnupg.org/service.html p.s. This is a announcement only mailing list. Please send replies only to the gcrypt-devel at gnupg.org mailing lists. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 180 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From ndk.clanbo at gmail.com Fri Feb 27 21:59:15 2015 From: ndk.clanbo at gmail.com (NdK) Date: Fri, 27 Feb 2015 21:59:15 +0100 Subject: Whishlist for next-gen card In-Reply-To: <54F0BAC0.7060503@digitalbrains.com> References: <54E6F12D.40504@gmail.com> <54E87133.2040202@digitalbrains.com> <54E8D46E.1080408@gmail.com> <54F0BAC0.7060503@digitalbrains.com> Message-ID: <54F0DAA3.9020208@gmail.com> Il 27/02/2015 19:43, Peter Lebbing ha scritto: > I don't understand the practical difference between HOTP and the button > to confirm an action. That the HOTP doesn't need HW support so it can be implemented in standard smartcards. >> If that info is embedded in the signature packet, it could add something >> to the signature value (if the receiving party sees that signature is >> about a txt file and the presented object is a doc, there's something >> wrong and suspect). > Are you proposing that the internal hash state after the hashing of the > document is handed over to the smartcard, after which the smartcard > computes the hash over the signature subpackets that you want protected > this way? It's unclear to me how you see such a thing be implemented > without passing all data to the smartcard. Well, IIRC there are cards that require you to compute all but the last round of the hash, then pass the last block of data and the current state to let them compute the result (and maybe do the padding before signing). Something similar could be used for this: the last block will include the shown data just before the file len. > I've had a quick look in RFC 4252, with public key user authentication > for SSH2. I don't think there's anything that you can show on a display > that would help the user decide if it were what they wanted to see. > After a really quick glance in the RFC, I see just the username and the > session identifier. The username is hardly unique (I usually use peter), > and the session identifier is a unique number computed for the SSH > session. It's the bit that prevents signature replay attacks but is not > useful to show on a display, since the user can't tell whether it's good > or not: it's just the output of a hash function. For auth it should be the hash of the host's pub key, the same SSH shows you the first time you connect to that host. > All this is based on a really quick read of documentation I hadn't > consulted before. It could be glaringly wrong. But when you said "it is > the fingerprint", I wondered if you misunderstood or that the > fingerprint is actually part of the challenge. I don't think it is. Since the challenge have to be encrypted to the host's pub key, you can display its hash. I'll have another look at the RFC tomorrow morning... BYtE, Diego. From wk at gnupg.org Fri Feb 27 21:56:52 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 27 Feb 2015 21:56:52 +0100 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: <54F0CE66.1080208@sumptuouscapital.com> (Kristian Fiskerstrand's message of "Fri, 27 Feb 2015 21:07:02 +0100") References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <1890860.SDiBssEjyI@inno> <000e01d05280$656fed70$304fc850$@on.yourweb.de> <7920271.MAWFr6xyvP@inno> <54F05EF5.6050105__7398.9701144912$1425039188$gmane$org@sumptuouscapital.com> <54F09ACB.6020108@enigmail.net> <54F09BE1.4030103@sumptuouscapital.com> <6F29DDC0-9A47-4536-A0FA-17A8EE061129@mailbox.org> <87pp8vm995.fsf@vigenere.g10code.de> <54F0CE66.1080208@sumptuouscapital.com> Message-ID: <87y4njkr8r.fsf@vigenere.g10code.de> On Fri, 27 Feb 2015 21:07, kristian.fiskerstrand at sumptuouscapital.com said: > Increasing the information on keyservers like this, in particular in > the descriptive parts can be considered, would it suffice to be part > of the standard web interface for keyserver intro, or would it have to > be added on each individual index page? I would put it on each index page - at least a link. "this key listing may harm you - we reject all resonsibility for improper use of this device" ;-) Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Feb 27 22:15:17 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 27 Feb 2015 22:15:17 +0100 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: <1425068651.5204.80.camel@scientia.net> (Christoph Anton Mitterer's message of "Fri, 27 Feb 2015 21:24:11 +0100") References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <1890860.SDiBssEjyI@inno> <000e01d05280$656fed70$304fc850$@on.yourweb.de> <7920271.MAWFr6xyvP@inno> <54F05EF5.6050105__7398.9701144912$1425039188$gmane$org@sumptuouscapital.com> <54F09ACB.6020108@enigmail.net> <87lhjjm8mn.fsf@vigenere.g10code.de> <1425068651.5204.80.camel@scientia.net> Message-ID: <87r3tbkqe2.fsf@vigenere.g10code.de> On Fri, 27 Feb 2015 21:24, calestyo at scientia.net said: > - Nothing is encrypted (so everyone eavesdropping will know that I just > downloaded the key for nsa-whistleblowers at wikileaks.org... and five Which he will anyway see as soon as you send the mail. Iff we have an anonymous network both problems will vanish. > Why? Well most people don't audit the code of GnuPG, so when they trust > them already with respect to that, they can also trust them with respect Most people run Windows or Android (or use Lenovo stuff) and thus have anyway no control over their boxes. > So I think the way to go here would be Tor. Or a real anonymous overlay network. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From mailinglisten at hauke-laging.de Fri Feb 27 22:25:16 2015 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Fri, 27 Feb 2015 22:25:16 +0100 Subject: trust paths (was: German ct magazine postulates death of pgp encryption) In-Reply-To: <1425068740.5204.81.camel@scientia.net> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <54F0CFA9.7070601@cardcontact.de> <1425068740.5204.81.camel@scientia.net> Message-ID: <1756253.oFcBDuDOmV@inno> Am Fr 27.02.2015, 21:25:40 schrieb Christoph Anton Mitterer: > On Fri, 2015-02-27 at 21:12 +0100, Andreas Schwier wrote: > > So what exactly is the purpose of the keyserver then ? > > Find trust paths What could that be good for? If you do not make very strange assumptions that could be of any use only if you assign certification trust to unknown keys which would be completely crazy. Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 603 bytes Desc: This is a digitally signed message part. URL: From calestyo at scientia.net Fri Feb 27 22:28:12 2015 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Fri, 27 Feb 2015 22:28:12 +0100 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: <87r3tbkqe2.fsf@vigenere.g10code.de> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <1890860.SDiBssEjyI@inno> <000e01d05280$656fed70$304fc850$@on.yourweb.de> <7920271.MAWFr6xyvP@inno> <54F05EF5.6050105__7398.9701144912$1425039188$gmane$org@sumptuouscapital.com> <54F09ACB.6020108@enigmail.net> <87lhjjm8mn.fsf@vigenere.g10code.de> <1425068651.5204.80.camel@scientia.net> <87r3tbkqe2.fsf@vigenere.g10code.de> Message-ID: <1425072492.5204.91.camel@scientia.net> On Fri, 2015-02-27 at 22:15 +0100, Werner Koch wrote: > Most people run Windows or Android (or use Lenovo stuff) and thus have > anyway no control over their boxes. To be honest, I don't think that anyone using Windows, Android, MacOS or any other [semi-]proprietary system actually wants to be secure - neither do I think that we should waste our resource on securing them which is per se not possible. Cheers, Chris. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5313 bytes Desc: not available URL: From calestyo at scientia.net Fri Feb 27 22:30:41 2015 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Fri, 27 Feb 2015 22:30:41 +0100 Subject: trust paths (was: German ct magazine postulates death of pgp encryption) In-Reply-To: <1756253.oFcBDuDOmV@inno> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <54F0CFA9.7070601@cardcontact.de> <1425068740.5204.81.camel@scientia.net> <1756253.oFcBDuDOmV@inno> Message-ID: <1425072641.5204.95.camel@scientia.net> On Fri, 2015-02-27 at 22:25 +0100, Hauke Laging wrote: > > Find trust paths > What could that be good for? If you do not make very strange assumptions > that could be of any use only if you assign certification trust to > unknown keys which would be completely crazy. I meant in the sense that I want to trust e.g. Werner's key but haven't met him in person yet,... but I might have an indirect trustpath to him via some other persons (which I do trust). Obviously I'll need any intermediate keys (and enough of them that I personally decide it's trustworthy). Cheers, Chris. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5313 bytes Desc: not available URL: From mailinglisten at hauke-laging.de Fri Feb 27 22:45:36 2015 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Fri, 27 Feb 2015 22:45:36 +0100 Subject: trust paths In-Reply-To: <1425072641.5204.95.camel@scientia.net> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <1756253.oFcBDuDOmV@inno> <1425072641.5204.95.camel@scientia.net> Message-ID: <6757300.eiPh0LXev4@inno> Am Fr 27.02.2015, 22:30:41 schrieb Christoph Anton Mitterer: > Obviously I'll need any intermediate keys (and enough of them that I > personally decide it's trustworthy). Once more we see the term that confuses nearly everyone: You personally decide to trust a key ? for it's certifications. That is not in any way related to the intermediate certifications for this key. The WoT makes a key *valid*. What is needed for that is your personal decision, too, but on another level: That is configured in GnuPG (with --completes-needed and --marginals-needed). Unless you decide not to use the WoT and make your own signature based on the ones you see. Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 603 bytes Desc: This is a digitally signed message part. URL: From peter at digitalbrains.com Fri Feb 27 22:49:28 2015 From: peter at digitalbrains.com (Peter Lebbing) Date: Fri, 27 Feb 2015 22:49:28 +0100 Subject: Whishlist for next-gen card In-Reply-To: <54F0DAA3.9020208@gmail.com> References: <54E6F12D.40504@gmail.com> <54E87133.2040202@digitalbrains.com> <54E8D46E.1080408@gmail.com> <54F0BAC0.7060503@digitalbrains.com> <54F0DAA3.9020208@gmail.com> Message-ID: <54F0E668.7020906@digitalbrains.com> On 27/02/15 21:59, NdK wrote: > For auth it should be the hash of the host's pub key, the same SSH shows > you the first time you connect to that host. I think you're confusing /host/ authentication and /user/ authentication. I was talking about using the auth key on your OpenPGP card to do user authentication. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From peter at digitalbrains.com Fri Feb 27 23:05:07 2015 From: peter at digitalbrains.com (Peter Lebbing) Date: Fri, 27 Feb 2015 23:05:07 +0100 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: <54F0CFA9.7070601@cardcontact.de> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <1890860.SDiBssEjyI@inno> <000e01d05280$656fed70$304fc850$@on.yourweb.de> <7920271.MAWFr6xyvP@inno> <54F05EF5.6050105__7398.9701144912$1425039188$gmane$org@sumptuouscapital.com> <54F09ACB.6020108@enigmail.net> <54F09BE1.4030103@sumptuouscapital.com> <54F0CFA9.7070601@cardcontact.de> Message-ID: <54F0EA13.7020401@digitalbrains.com> On 27/02/15 21:12, Andreas Schwier wrote: > I'd rather start a communication > with a bogus key and establish trust in my genuine peer from the > conversation we are having. But what about that Man in the Middle who does nothing more than receive your message encrypted to their key and forward it to the real recipient you are building a trust relationship with? That MITM is following and logging your interesting conversation without either of you noticing... Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From kristian.fiskerstrand at sumptuouscapital.com Fri Feb 27 23:05:36 2015 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Fri, 27 Feb 2015 23:05:36 +0100 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: <87y4njkr8r.fsf@vigenere.g10code.de> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <1890860.SDiBssEjyI@inno> <000e01d05280$656fed70$304fc850$@on.yourweb.de> <7920271.MAWFr6xyvP@inno> <54F05EF5.6050105__7398.9701144912$1425039188$gmane$org@sumptuouscapital.com> <54F09ACB.6020108@enigmail.net> <54F09BE1.4030103@sumptuouscapital.com> <6F29DDC0-9A47-4536-A0FA-17A8EE061129@mailbox.org> <87pp8vm995.fsf@vigenere.g10code.de> <54F0CE66.1080208@sumptuouscapital.com> <87y4njkr8r.fsf@vigenere.g10code.de> Message-ID: <54F0EA30.5090209@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 02/27/2015 09:56 PM, Werner Koch wrote: > On Fri, 27 Feb 2015 21:07, > kristian.fiskerstrand at sumptuouscapital.com said: > >> Increasing the information on keyservers like this, in particular >> in the descriptive parts can be considered, would it suffice to >> be part of the standard web interface for keyserver intro, or >> would it have to be added on each individual index page? > > I would put it on each index page - at least a link. > > "this key listing may harm you - we reject all resonsibility for > improper use of this device" ;-) I might use a slightly different wording :) But adding something of the sort to my TODO list for SKS. - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- "Expect the best. Prepare for the worst. Capitalize on what comes." (Zig Ziglar) -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJU8OosAAoJEP7VAChXwav6MxgH/2NMrQwew4ISRGJcrWLiLWyH Xt/m9euxfkj7DeMRRgGvMVW9ilUZM4q6jZ3dbncBjaMy3mAZv5ct1hbEgqSqWNxg GlyTyrLXBAC8p+/wSpeNzJGl2j9a5shmV8nxv3SEl7sxoYkbLhWdVUn7Kgph14xE mJe7VCn7NlqPt9b9YgbfRnI0VsD7aQ8eTwwqSCef5xMi5wdEUHirjkf5BMCV/uLQ wE7RUGkrV6YkX7H69MjOfrhpdglv0oU4QxQx0qnOCFvY20AIVo3N9jJzt5h+CNvz YO56foiCQ5+uQcA/4uIpSUXJXUEQlKZunmE3CF6LjL6jStK5F/NF3sraYuL663I= =krnn -----END PGP SIGNATURE----- From mailinglisten at hauke-laging.de Fri Feb 27 23:13:38 2015 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Fri, 27 Feb 2015 23:13:38 +0100 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: <87lhjjm8mn.fsf@vigenere.g10code.de> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <54F09ACB.6020108@enigmail.net> <87lhjjm8mn.fsf@vigenere.g10code.de> Message-ID: <3170230.tGOFc8NgMF@inno> Am Fr 27.02.2015, 20:56:00 schrieb Werner Koch: > On Fri, 27 Feb 2015 17:26, patrick at enigmail.net said: > > that anyone can upload _every_ key to a keyserver is an issue. If > > keyservers would do some sort of verification (e.g. confirmation of > > the email addresses) then this would lead to much more reliable > > data. > > We have such a system. It is called S/MIME. > There is no trust in keyservers by design. As soon as you start > changing this you are turning PGP into a centralized system. That is not true. The main difference between the two is not that OpenPGP keyservers must be irrelevant for certificate assessment. The IMHO most important difference is that OpenPGP is well prepared for keys being certified by several keys. As a result you can configure how a certificate becomes valid. Taking information into account which is generated by keyservers would not change this paradigm. Of course, such a feature could be used in a wrong way. But what change would that be? From my observation the majority of OpenPGP users uses it wrongly. And even the current official version of the Windows world's "model implementation" Enigmail makes it a pain to use it correctly. (The development version finally got that right, incredible...) The GPGTools plugin doesn't even offer you (at least not via the normal configuration interface) to do it right. The right way to select a certificate is: 1) Have a look at one or (if necessary) more (non-synced) keyservers and try to find a signature which makes one of the found certificates valid. 2) What now? If there is only one certificate on the keyservers then people will use it. Even if it is a fake because the address owner either doesn't use OpenPGP at all or wants to avoid the keyservers (as spam or privacy protection) and offers his certificate on his web site. If there are two non-valid certificates left the only question (in reality!) is "Use one of them or send unencrypted?" There is no reason to ignore additional information like "this entity (which happens to be a keyserver) claims to have verified the email address". Of course, this information becomes useful only if there is reason to trust this particular keyserver (which does not look promising with a DNS round- robin pool). You could even do that today by manually checking the pool for a validated certificate first and in case of failure one ore more keyservers which you happen to know that they verify the email address (like the PGP company's one). I don't understand anyway why gpg cannot be configured to use several keyservers at once (especially if the first one has no match). Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 603 bytes Desc: This is a digitally signed message part. URL: From mailinglisten at hauke-laging.de Fri Feb 27 23:21:42 2015 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Fri, 27 Feb 2015 23:21:42 +0100 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: <54F0EA13.7020401@digitalbrains.com> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <54F0CFA9.7070601@cardcontact.de> <54F0EA13.7020401@digitalbrains.com> Message-ID: <10330032.xGXXIq3lh9@inno> Am Fr 27.02.2015, 23:05:07 schrieb Peter Lebbing: > But what about that Man in the Middle who does nothing more than > receive your message encrypted to their key and forward it to the > real recipient you are building a trust relationship with? He does have to do more: He has to intercept the messages or deceive you about the email address to use. Both is possible, both are non-triviasl tasks so that you also have to ask: If he can to that why assume that he doesn't just hack your system? > That MITM > is following and logging your interesting conversation without either > of you noticing... So would he with unencrypted messages. Certificate validation does not appear from nowhere. Either you have it or you don't. And in reality you usually have to send the message anyway. IMHO we especially need education for the masses that they become aware that different messages require different security levels (in all areas: key security, authentication security and system security). OpenPGP is not a model technology in that regard, too. As you can read German, at least slowly... ;-) http://www.crypto-fuer-alle.de/wishlist/securitylevel/ Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 603 bytes Desc: This is a digitally signed message part. URL: From kristian.fiskerstrand at sumptuouscapital.com Fri Feb 27 23:25:29 2015 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Fri, 27 Feb 2015 23:25:29 +0100 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: <10330032.xGXXIq3lh9@inno> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <54F0CFA9.7070601@cardcontact.de> <54F0EA13.7020401@digitalbrains.com> <10330032.xGXXIq3lh9@inno> Message-ID: <54F0EED9.4000309@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 02/27/2015 11:21 PM, Hauke Laging wrote: > Am Fr 27.02.2015, 23:05:07 schrieb Peter Lebbing: > >> But what about that Man in the Middle who does nothing more than >> receive your message encrypted to their key and forward it to >> the real recipient you are building a trust relationship with? > > He does have to do more: He has to intercept the messages or > deceive you about the email address to use. Both is possible, both > are non-triviasl tasks so that you also have to ask: If he can to > that why assume that he doesn't just hack your system? > > _cracking_ the system (I hack my system every day..) would leave traces, the same would not necessarily be true for DNS poisioning or BGP hijacking on the network layer. - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- "I have always wished that my computer would be as easy to use as my telephone. My wish has come true -- I no longer know how to use my telephone" (Bjarne Stroustrup, April 1999) -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJU8O7TAAoJEP7VAChXwav6hxkIAI6qRHP4D2aFp9y+BB25CXGD RU3q4+F4qe0UPjOQP5NRdywxQIzzOwGEjAKwQ8V3ruQo087+Ion+rI81QQ3RUHsn NFRSOmkxdvEWzyj5zF8exegfJFnGxm0p5kAywIfWKxaZMngMC7TgLSZo7b0HTvcC 1Tl7BcbkNXICFS7yJ0hlQvbnxIe4gzmrALG2EyG+TvGIHk9O6Ks6VqafayXSQw7H XzMXNQJpjULIpcT/EhfQIr4GrjDDrE6AqImovqKIi9TkdnNHfiI1WTszDjUEwH6c qhEYPCM29LFcX9mTIpQnONUqacjHieF0TLeJfgISD7j8QTmSOMwXsVOOoB/ijtc= =d2VX -----END PGP SIGNATURE----- From martin-gnupg-users at dkyb.de Fri Feb 27 22:40:00 2015 From: martin-gnupg-users at dkyb.de (Martin Behrendt) Date: Fri, 27 Feb 2015 22:40:00 +0100 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: <1425072492.5204.91.camel@scientia.net> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <1890860.SDiBssEjyI@inno> <000e01d05280$656fed70$304fc850$@on.yourweb.de> <7920271.MAWFr6xyvP@inno> <54F05EF5.6050105__7398.9701144912$1425039188$gmane$org@sumptuouscapital.com> <54F09ACB.6020108@enigmail.net> <87lhjjm8mn.fsf@vigenere.g10code.de> <1425068651.5204.80.camel@scientia.net> <87r3tbkqe2.fsf@vigenere.g10code.de> <1425072492.5204.91.camel@scientia.net> Message-ID: <54F0E430.7030006@dkyb.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 27.02.2015 um 22:28 schrieb Christoph Anton Mitterer: > On Fri, 2015-02-27 at 22:15 +0100, Werner Koch wrote: >> Most people run Windows or Android (or use Lenovo stuff) and thus >> have anyway no control over their boxes. > To be honest, I don't think that anyone using Windows, Android, > MacOS or any other [semi-]proprietary system actually wants to be > secure - neither do I think that we should waste our resource on > securing them which is per se not possible. At what point is a system a [semi-]proprietary system? How many computers are out there where not even a single part of the hardware (and firmware) is proprietary? Where do you draw the line? If I would have to guess, I would say, the device you wrote that sentence with, falls in the category semi-proprietary... greetings Martin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlTw5C4ACgkQ/6vdZgk46sggswCgyXjGYnul/yxgMoDb7Astu1e+ u4wAnR9JqtMXTAy6MGo3HvzQSBV08m/U =g1qf -----END PGP SIGNATURE----- From mailinglisten at hauke-laging.de Sat Feb 28 00:03:26 2015 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Sat, 28 Feb 2015 00:03:26 +0100 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: <54F05EF5.6050105@sumptuouscapital.com> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <7920271.MAWFr6xyvP@inno> <54F05EF5.6050105@sumptuouscapital.com> Message-ID: <2185752.y374kRer4d@inno> Am Fr 27.02.2015, 13:11:33 schrieb Kristian Fiskerstrand: > > We need keyservers which are a lot better that today's. IMHO that > > also means that a keyserver should tell a client for each offered > > certificate whether it (or a trusted keyserver) has made such an > > email verification. > > The keyservers have no role in this, they are pure data store and can > never act as a CA. That is not a higher truth which must not be breached. The other way round it is correct, though: It must be possible to run a keyserver without making any statements about the certificates. > That would bring up a can of worm of issues, both > politically and legally, I wouldn't want to see the first case where a > keyserver operator was sued for permitting a "fake key" (the term > itself is very misleading I would consider taking that to court ridiculous (for several reasons, one being the (also ridiculous) class 1 X.509 certifications) but it makes obviously little sense for us to make a mandatory assessment for the whole world. That is a decision which everyone who runs a keyserver (or intends to) should make himself. This need not be implemented by the keyserver making signatures. It would be enough if there were certificate attributes in the keyserver answer. That way these certificates could not easily become valid by some not so clever user giving full certification trust to the keyserver's own certificate. > People need to understand that operational security is critical for > any security of a system and validate the key through secondary > channel (fingerprint, algorithm type, key length etc verifiable > directly or through probabilistic measures e.g. based on historical > postings on mailing lists over a long time for a project etc). I could hardly agree more but it is easy to join the "People need to understand" game if you are on a mailing list. This becomes much harder if you have been working on spreading OpenPGP usage in the nasty real world for a while. Like I have. For more than two years I have been teaching people myself, seen what is done (and what isn't) at Cryptoparties, have tried to use universities and schools for gaining new users. So what do we talk about here if in good approximation nobody outside this mailing list gives a^W^W cares about that? We are going to lose this if we don't make usable offers. And in case it is not already well known here: I am at the security extremist end of the spectrum. I think both OpenPGP and GnuPG are not good enough yet in supporting high level security. I am just not willing to ignore the other 99.3%. Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 603 bytes Desc: This is a digitally signed message part. URL: From calestyo at scientia.net Sat Feb 28 00:20:12 2015 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Sat, 28 Feb 2015 00:20:12 +0100 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: <54F0E430.7030006@dkyb.de> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <1890860.SDiBssEjyI@inno> <000e01d05280$656fed70$304fc850$@on.yourweb.de> <7920271.MAWFr6xyvP@inno> <54F05EF5.6050105__7398.9701144912$1425039188$gmane$org@sumptuouscapital.com> <54F09ACB.6020108@enigmail.net> <87lhjjm8mn.fsf@vigenere.g10code.de> <1425068651.5204.80.camel@scientia.net> <87r3tbkqe2.fsf@vigenere.g10code.de> <1425072492.5204.91.camel@scientia.net> <54F0E430.7030006@dkyb.de> Message-ID: <1425079212.5204.105.camel@scientia.net> On Fri, 2015-02-27 at 22:40 +0100, Martin Behrendt wrote: > At what point is a system a [semi-]proprietary system? > How many computers are out there where not even a single part of the > hardware (and firmware) is proprietary? I rather meant Android here, which may have an open source core, but in fact most people use a binary only installation from a not trustworthy vendor. Cheers, Chris -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5313 bytes Desc: not available URL: From hugo at barrera.io Sat Feb 28 00:48:21 2015 From: hugo at barrera.io (Hugo Osvaldo Barrera) Date: Fri, 27 Feb 2015 20:48:21 -0300 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: <54F061B6.3070205@seichter.de> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <54F061B6.3070205@seichter.de> Message-ID: <20150227234821.GA15748@athena.barrera.io> On 2015-02-27 13:23, Ralph Seichter wrote: > > Your positions to this ct approach? > > The c't magazine is mostly well respected in Germany and the editors > have some valid points; the latest articles are by no means mindless > rants or PGP-bashing. The thought of letting PGP die as an e-mail > encryption mechanism for the "masses" (the non-tech-savvy average users) > and to have it replaced with something my mother could use is valid. The > c't editorial also clearly states that PGP works perfectly well and is > secure as long as keys are verified, but fake keys and people not > verifying fingerprints are a reality. Alice can't just send an e-mail to > Bob, she needs to acquire and verify Bob's public key first. Compare > this to transparent encryption like Apple's iMessage service uses and it > is not hard to answer which mechanism has better usability. I like and > use PGP like probably every subscriber on this mailing list, but the > number of people I can exchange PGP-encrypted data with is very low when > compared to the total number of my e-mail contacts. > > -Ralph iMessages model offers way less security than GPG, and a centrail authority that all of humanity needs to trust in charge of everything is incredibly naive. What if I work for Apple's competition and need to send an extremely confidential message to my coworkers? I can't possibly trust Apple with handling my keys transparently for me. Encryption is clumbersome because that's the price of security and privacy. I hate having to put the key on the lock every day to open it, but if I don't, anyone can get in. Sure, I've heard the arguments like: * Let's use a globally trusted authority instead: There's no such thing and never will be. Someone will always have a valid reason to distrust it. * Set up your own keyexchange server: Ok, so we're back to GPG and keyrings where users need to manually retrieve keys from different places and determine if they're the right one or not. Please, stop spreading the iMessage falacy, it's system offers privacy only from *some* parties, but not from everyone. -- Hugo Osvaldo Barrera A: Because we read from top to bottom, left to right. Q: Why should I start my reply below the quoted text? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From mirimir at riseup.net Sat Feb 28 02:19:52 2015 From: mirimir at riseup.net (Mirimir) Date: Fri, 27 Feb 2015 18:19:52 -0700 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: <54F0CFA9.7070601@cardcontact.de> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <1890860.SDiBssEjyI@inno> <000e01d05280$656fed70$304fc850$@on.yourweb.de> <7920271.MAWFr6xyvP@inno> <54F05EF5.6050105__7398.9701144912$1425039188$gmane$org@sumptuouscapital.com> <54F09ACB.6020108@enigmail.net> <54F09BE1.4030103@sumptuouscapital.com> <54F0CFA9.7070601@cardcontact.de> Message-ID: <54F117B8.2000103@riseup.net> On 02/27/2015 01:12 PM, Andreas Schwier wrote: > So what exactly is the purpose of the keyserver then ? If you expect me > to still verify fingerprints out of band, why would I grab a - probably > bogus key - from a keyserver first place ? I could immediately ask my > peer to send it by mail. I find keyservers most useful when I receive a signed (and typically encrypted) email from someone whose public key I don't have. Enigmail reports an untrusted signature. So I hit Details, and accept its offer to get the requisite key from (by default) . If I need the public key of someone new, I first look on . If it's not there, or on their website or blog, I typically just request it by email. From aef at raxys.net Sat Feb 28 03:02:37 2015 From: aef at raxys.net (Alexander E. Fischer) Date: Sat, 28 Feb 2015 03:02:37 +0100 Subject: A forgotten patch? Message-ID: <1425088957.14003.87.camel@neoprokrast.monkey.poo> Hello, I recently came to know that Felix von Leitner (Fefe) did a code audit of GnuPG in 2009. According to him, the patch fixes lots of problems that might be usable as in attack vectors on GnuPG. It seems however, as if this patch was never included into upstream GnuPG. Because of that, he keeps maintaining his patch and offers it freely on his personal website [1]. Although I don't know him personally, as far I know, Felix von Leitner is a professional code security auditor and a reputable member of the Chaos Computer Club. In earlier releases of GnuPG he was even mentioned for supporting the project [2]. What are the reasons which lead to the patch never being applied? Is there any archived discussion available about that topic? Have the problems addressed by the patch been fixed otherwise? [1]: https://www.fefe.de/ [2]: http://article.gmane.org/gmane.comp.encryption.gpg.devel/10425/match=felix+von+leitner Kind regards Alexander E. Fischer -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 931 bytes Desc: This is a digitally signed message part URL: From marcozehe-ml at mailbox.org Sat Feb 28 07:01:19 2015 From: marcozehe-ml at mailbox.org (Marco Zehe) Date: Sat, 28 Feb 2015 07:01:19 +0100 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: <1425060977.5204.10.camel@scientia.net> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <1425060977.5204.10.camel@scientia.net> Message-ID: Hi Chris, > Am 27.02.2015 um 19:16 schrieb Christoph Anton Mitterer : > > This is basically what they want: Anonymous cryptography, whose complete > security is based on some good luck whether you've communicated with the > right peer the first time. > > But instead of just advertising that crap, they seem to also have went > on some stupid anti-OpenPGP campaign? o.O I agree! I actually took them up on their offer to contact them for signing my public key with their C?t PGPCA key they advertise at the end of the actual article (not the editorial) in c?t 6/2015, page 160. But because I had a question, I wrote to them first. Took a couple of days before I got a reply, and I couldn?t help but ask if they?ve already ditched OpenPGP completely. I was sarcastic, and got a very honest reply from another c?t journalist saying that that very topic has been heatedly debated at Heise, and that by far not everyone agrees with Mr. Schmidt. Their crypto campaign is still in full force despite the editorial. So like everywhere, different opinions, and that one journalist?s opinion definitely doesn?t speak for all of the folks at c?t or Heise in General. Marco -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From marcozehe-ml at mailbox.org Sat Feb 28 07:10:24 2015 From: marcozehe-ml at mailbox.org (Marco Zehe) Date: Sat, 28 Feb 2015 07:10:24 +0100 Subject: Best practice to make one's key known, was Re: German ct magazine postulates death of pgp encryption In-Reply-To: <87lhjjm8mn.fsf@vigenere.g10code.de> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <1890860.SDiBssEjyI@inno> <000e01d05280$656fed70$304fc850$@on.yourweb.de> <7920271.MAWFr6xyvP@inno> <54F05EF5.6050105__7398.9701144912$1425039188$gmane$org@sumptuouscapital.com> <54F09ACB.6020108@enigmail.net> <87lhjjm8mn.fsf@vigenere.g10code.de> Message-ID: Hi Werner et al, > Am 27.02.2015 um 20:56 schrieb Werner Koch : > > There is no trust in keyservers by design. As soon as you start > changing this you are turning PGP into a centralized system. OK, then I have a very practical question: Even though this is my fourth or fifth attempt at establishing OpenPGP in my daily routine since the mid 1990s, I am still confused by what the best way is to make my public key known. So if, as you say, key servers are not trusted by design, if I want to spread word around my available public key, which source should I put in a signature? While reading this list, I have seen quite a number of different approaches. Some put their key ID along with the finger print and the URL of a key server. Others put a link to the key file on a web server, others just quote their key ID and finger print, or only either of those. I have my key uploaded (and kept current) on key servers as well as on my web site(s), and my Impressum links to the copy on my web site rather than the key server URL. So: What?s the best practice advice? (and yes, I looked in the FAQ, but that didn?t prove conclusive to me.) Marco -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From calestyo at scientia.net Sat Feb 28 07:11:01 2015 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Sat, 28 Feb 2015 07:11:01 +0100 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <1425060977.5204.10.camel@scientia.net> Message-ID: <1425103861.5204.138.camel@scientia.net> On Sat, 2015-02-28 at 07:01 +0100, Marco Zehe wrote: > So like everywhere, different opinions, and that one journalist?s > opinion definitely doesn?t speak for all of the folks at c?t or Heise > in General. Well, that might be... but with respect to this question, there is only one correct opinion - at least as long as we have no crypto system that can do without mutual authentication and still provide mutually authenticated identities ;-) And whether or not there are journalists at heise who don't agree, their current voice seem to be that of an ignorant... and people will read these articles and the seed of the though that crypto "must be easier" will be laid :-( -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5313 bytes Desc: not available URL: From marcozehe-ml at mailbox.org Sat Feb 28 07:21:57 2015 From: marcozehe-ml at mailbox.org (Marco Zehe) Date: Sat, 28 Feb 2015 07:21:57 +0100 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: <54F0CFA9.7070601@cardcontact.de> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <1890860.SDiBssEjyI@inno> <000e01d05280$656fed70$304fc850$@on.yourweb.de> <7920271.MAWFr6xyvP@inno> <54F05EF5.6050105__7398.9701144912$1425039188$gmane$org@sumptuouscapital.com> <54F09ACB.6020108@enigmail.net> <54F09BE1.4030103@sumptuouscapital.com> <54F0CFA9.7070601@cardcontact.de> Message-ID: Hi Andreas, > Am 27.02.2015 um 21:12 schrieb Andreas Schwier : > The keyserver would make sense, if my mail client would automatically > fetch the public key from a server, based on the e-mail address of the > sender and some identity data (e.g. fingerprint) in the mail signature. FWIW, that?s how GPGMail, the Apple Mail plug-in on OS X, does it, or *can* do it (the feature can be disabled). It will fetch keys based on the e-mail address and signature. So only if it finds a key on the key server that can verify the signature, will it add it to the local key ring. I believe you can also do that with Enigmail by editing something on the Key Servers page of the *advanced* Enigmail settings dialog. So the Mail plugin doesn?t just add keys based on the e-mail address, but needs additional clues that the sender is OpenPGP-capable. And so far, I think I?ve only seen it do that with signatures. > > I have been using GNUPG for ages now, but I verified fingerprints only a > hand-full of time. Most of the time, I ask my peer for his public key > and wait for the mail to arrive. For me web-of-trust and key signing > parties don't make any sense, because I'd rather start a communication > with a bogus key and establish trust in my genuine peer from the > conversation we are having. That?s how things have developed for me over the past year since I started using GnuPG again. > I like the way Threema does it: I can immediately start a secure > communication and if I need I can elevate the trust I have in the key. > But most of the time I'm communicating with people I know anyway. Yes, and Threema itself even offers a few levels of potential trust through verification of the phone number and/or e-mail address, indicating that the other party has established it has access to one or both of these means, without actually giving away the phone number or e-mail address. And if one has that Threema contact in one?s own address book and chose to look them up on the Threema servers, that is also indicated. This is a level of proof of ownership I was also referring to earlier, where one can do a bit more to tell others ?hey, this is really me!?. Marco -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From wk at gnupg.org Sat Feb 28 12:20:08 2015 From: wk at gnupg.org (Werner Koch) Date: Sat, 28 Feb 2015 12:20:08 +0100 Subject: A forgotten patch? In-Reply-To: <1425088957.14003.87.camel@neoprokrast.monkey.poo> (Alexander E. Fischer's message of "Sat, 28 Feb 2015 03:02:37 +0100") References: <1425088957.14003.87.camel@neoprokrast.monkey.poo> Message-ID: <87fv9ql1uf.fsf@vigenere.g10code.de> On Sat, 28 Feb 2015 03:02, aef at raxys.net said: > of GnuPG in 2009. According to him, the patch fixes lots of problems > that might be usable as in attack vectors on GnuPG. It seems however, as > if this patch was never included into upstream GnuPG. Because of that, This comes up every once in a while and I try not to spend time on that silly thing. At least by private mail I explained it to him years ago, but he seem not to understand. Let's look at two examples: We have this function: /* Return a string which is used as a kind of process ID */ const byte * get_session_marker( size_t *rlen ) { static byte marker[SIZEOF_UNSIGNED_LONG*2]; static int initialized; if ( !initialized ) { volatile ulong aa, bb; /* we really want the uninitialized value */ ulong a, b; initialized = 1; /* also this marker is guessable it is not easy to use this * for a faked control packet because an attacker does not * have enough control about the time the verification does * take place. Of course, we can add just more random but * than we need the random generator even for verification * tasks - which does not make sense. */ a = aa ^ (ulong)getpid(); b = bb ^ (ulong)time(NULL); memcpy( marker, &a, SIZEOF_UNSIGNED_LONG ); memcpy( marker+SIZEOF_UNSIGNED_LONG, &b, SIZEOF_UNSIGNED_LONG ); } *rlen = sizeof(marker); return marker; } Fefe changes it to use /dev/urandom by inserting this code before the above initialization test: int fd; if (!initialized) { fd=open("/dev/urandom",O_RDONLY); if (fd!=-1) { if (read(fd,marker,sizeof(marker))==sizeof(marker)) initialized=1; close(fd); } } Let's ignore the fact that a failed open falls back to the, in his book broken, existing scheme. The real trouble here is that he does not look for the use of this function. Now, for what is it used: If a clearsigned messages is received that message has an indication which hash algorithms are used (the "Hash: XXXX" line). We need to convey this information from the unarmor layer to the actual parsing code. This is done by inserting a faked packet with information on the hash algorithms as well as a plaintext packet. The final message the parser then sees resembles this valid OpenPGP message One-Pass Signed Message :- One-Pass Signature Packet, OpenPGP Message, Corresponding Signature Packet. Now an attacker might be able to insert a bogus control packet in an arbitrary non-armored messages and in such a way resembles cleartext message. However, the only thing he could do with this is to announce a different hash algorithm and switch the parsed to a different interpretation of white spaces at line ends. The first is entirely harmless because gpg checks that the used hash algorithms matches those in the actual Signature Packet which comes after the signed text. It is annoying if that happens but it merely leads to a BAD signature. The slightly changed interpretation of trailing line spaces (clearsigned versus text mode signatures) might be useful to insert extra trailing spaces into a text file. But that is something which happens to mails anyway and the whole reason for text mode messages. Why the session marker packet? That is simply to help gpg to stop earlier on bogus input data. No need for cryptographical strong random. Second example: struct private_membuf_s { size_t len; size_t size; char *buf; int out_of_core; }; typedef struct private_membuf_s membuf_t; void put_membuf (membuf_t *mb, const void *buf, size_t len) { if (mb->out_of_core) return; assert(mb->len + len > mb->len); if (mb->len + len >= mb->size) { char *p; assert(len + 1024 > len); assert(mb->size + len > mb->size); mb->size += len + 1024; p = xrealloc (mb->buf, mb->size); mb->buf = p; } memcpy (mb->buf + mb->len, buf, len); mb->len += len; } The assert calls are inserted by Fefe. Their intention is to detect integer overflows. Given that unsigned integers are used these checks do work. Are they required? Looking at the first one: MB->LEN tracks the used length of a malloced buffer. Thus it this value is bound at a reasonable value. LEN give the length of BUG which is either a static array or another malloced region. Thus this is also bound. To trigger this assertion it needs two buffers which together allocate more that 2^32 bytes (or 2^64 on systems with sizeof(size_t)==8). And before the process comes to put_membuf it has already allocated other buffers. Thus the answer from the engineering department is: No. The QA department would give an unfavorable statement about the use of assert calls for conditions which are supposed to happen (in Fefe's short sighted analysis). > is a professional code security auditor and a reputable member of the Right he lists Microsoft and a German "newspaper", to which many people would never talk, as his clients. I wonder a bit why a he did not caught obvious bugs which could indeed lead to a segv. Like the faulty shifting of MSBs fixed with commit 57af33d9e7c9b20b413b96882e670e75a67a5e65 lingering for many years in the code. And why pusblishing a patch and no bug reports? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From neal at walfield.org Sat Feb 28 12:27:05 2015 From: neal at walfield.org (Neal H. Walfield) Date: Sat, 28 Feb 2015 12:27:05 +0100 Subject: LDAP-based Keyserver Message-ID: <87y4ni9sza.wl%neal@walfield.org> Hi, Nearly a decade ago, Walter Haidinger posted a how to describing how to setup an OpenLDAP PGP keyserver. http://lists.gnupg.org/pipermail/gnupg-users/2006-February/028058.html In that time, OpenLDAP configuration has gotten a lot more complicated. I've modernized and significantly expanded his tutorial. You can find it here: http://wiki.gnupg.org/LDAPKeyserver I did my best to provide a recipe that requires little prior knowledge about OpenLDAP while also explaining the reasoning behind the actions and high-level concepts. I'd appreciate it if someone could try to reproduce the steps and report any bugs. I used Debian. There are probably differences on other platforms that are worth noting. I'd also appreciate any improvements to the text. Thanks! Neal From gnupg-ml at seichter.de Sat Feb 28 12:37:17 2015 From: gnupg-ml at seichter.de (Ralph Seichter) Date: Sat, 28 Feb 2015 12:37:17 +0100 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: <20150227234821.GA15748@athena.barrera.io> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <54F061B6.3070205@seichter.de> <20150227234821.GA15748@athena.barrera.io> Message-ID: <54F1A86D.1050907@seichter.de> On 28.02.2015 00:48, Hugo Osvaldo Barrera wrote: > Please, stop spreading the iMessage falacy, it's system offers privacy > only from *some* parties, but not from everyone. I invite you to read my message again. I used iMessage as an example for usability (as did c't editor J?rgen Schmidt), not for impregnable security. There is a reason why I use PGP, but there are also reasons why my family does not. Lately I have set up S/MIME when I helped friends with their smartphones, but while that takes care of transporting the public keys automatically, establishing trust is still an issue most people spend too little thought and effort on. Lower that bar, and more users will likely opt for end-to-end encryption. -Ralph From johanw at vulcan.xs4all.nl Sat Feb 28 13:22:19 2015 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Sat, 28 Feb 2015 13:22:19 +0100 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: <20150227155738.GB14628@IUPUI.Edu> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <20150227155738.GB14628@IUPUI.Edu> Message-ID: <54F1B2FB.10009@vulcan.xs4all.nl> On 27-02-2015 16:57, Mark H. Wood wrote: > It's always good to look for patterns that lead to useful > simplification. But there comes a point at which no further > simplfication can be done without making the system less useful. Well, in making it more beginner friendly, I imagine a system that does not bother the user with complexities about whan to sign someone's key to which degree, but after install: 1. The beginner friendly installer notices there is no secret key yet -> create one automatically and upload it to the keyservers. To make the experience as easy as possible perhaps even offer to use no password on the key so it does not need to ask for a password when opening mail (with a warning that this could give problems if losing or confiscating the computer is part of the threat model). 2. It notices 2 email programs -> offer to integrate a plugin in both and set the defaults to sign and encrypt when the receiver has a public key on the servers. I agree that for webmail solutions this might be difficult but plugins for browser automation do exist (usually aimed at unit testing of websites). This approach might lead to issues, like targeted attacks with false keys and stolen computers, but it would get the number of encrypted emails up. At least the mails would be safer in transit and at the mail provider. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From mailinglisten at hauke-laging.de Sat Feb 28 13:23:14 2015 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Sat, 28 Feb 2015 13:23:14 +0100 Subject: LDAP-based Keyserver In-Reply-To: <87y4ni9sza.wl%neal@walfield.org> References: <87y4ni9sza.wl%neal@walfield.org> Message-ID: <3951114.APtb54Cmoy@inno> Am Sa 28.02.2015, 12:27:05 schrieb Neal H. Walfield: > In that time, OpenLDAP configuration has gotten a lot more > complicated. I've modernized and significantly expanded his tutorial. > You can find it here: > > http://wiki.gnupg.org/LDAPKeyserver Doesn't refer to your work but is a general question as I have never used LDAP: Is there any advantage in using LDAP for this? Or is this a "We have the LDAP server anyway thus we add the keyserver stuff instead of using a separate keyserver" decision? Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 603 bytes Desc: This is a digitally signed message part. URL: From johanw at vulcan.xs4all.nl Sat Feb 28 13:28:06 2015 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Sat, 28 Feb 2015 13:28:06 +0100 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: <1425060977.5204.10.camel@scientia.net> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <1425060977.5204.10.camel@scientia.net> Message-ID: <54F1B456.2080900@vulcan.xs4all.nl> On 27-02-2015 19:16, Christoph Anton Mitterer wrote: > This is basically what they want: Anonymous cryptography, whose complete > security is based on some good luck whether you've communicated with the > right peer the first time. In practice the Textsecure protocol works well of couyrse because it uses the phone number. One usually knows that number already from a contact. Most people I communicatw with often I even recognise by voice alone - taking over the phone number is not going to work. I don't see even the NSA breaking that. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From peter at digitalbrains.com Sat Feb 28 13:31:23 2015 From: peter at digitalbrains.com (Peter Lebbing) Date: Sat, 28 Feb 2015 13:31:23 +0100 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: <10330032.xGXXIq3lh9@inno> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <54F0CFA9.7070601@cardcontact.de> <54F0EA13.7020401@digitalbrains.com> <10330032.xGXXIq3lh9@inno> Message-ID: <54F1B51B.4060205@digitalbrains.com> I think a bit of opportunistic encryption without proper identity verification can be a very good thing. I was just pointing out that you need to know the limits of that way of working, and make a conscious decision whether you need proper verification or not. But I didn't indicate that clearly enough. HTH, Peter. PS: By the way, my ISP and some of it's employees are in a perfect position to do a man in the middle. I sure hope they can't "just hack my system" because of that position. The one capability certainly does not imply the other. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From hugo at barrera.io Sat Feb 28 13:36:19 2015 From: hugo at barrera.io (Hugo Osvaldo Barrera) Date: Sat, 28 Feb 2015 09:36:19 -0300 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: <54F1A86D.1050907@seichter.de> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <54F061B6.3070205@seichter.de> <20150227234821.GA15748@athena.barrera.io> <54F1A86D.1050907@seichter.de> Message-ID: <20150228123619.GA7370@athena.barrera.io> On 2015-02-28 12:37, Ralph Seichter wrote: > On 28.02.2015 00:48, Hugo Osvaldo Barrera wrote: > > > Please, stop spreading the iMessage falacy, it's system offers privacy > > only from *some* parties, but not from everyone. > > I invite you to read my message again. I used iMessage as an example for > usability (as did c't editor J?rgen Schmidt), not for impregnable > security. There is a reason why I use PGP, but there are also reasons > why my family does not. Lately I have set up S/MIME when I helped > friends with their smartphones, but while that takes care of transporting > the public keys automatically, establishing trust is still an issue most > people spend too little thought and effort on. Lower that bar, and more > users will likely opt for end-to-end encryption. > > -Ralph > Of course iMessage is a lot more usable: it's not a challenge to create very usable and friendly IM UIs. The challenge is about creating easily usable *secure* communication software. Sure, lower the bar *on how secure what you're using is*, and most it's easier to user. S/MIME isn't *really* safe. It requires trusting a bunch of CAs, and is can basically receive the same criticism as TLS applied to the web. -- Hugo Osvaldo Barrera A: Because we read from top to bottom, left to right. Q: Why should I start my reply below the quoted text? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From peter at digitalbrains.com Sat Feb 28 13:40:05 2015 From: peter at digitalbrains.com (Peter Lebbing) Date: Sat, 28 Feb 2015 13:40:05 +0100 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: <54F1B456.2080900@vulcan.xs4all.nl> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <1425060977.5204.10.camel@scientia.net> <54F1B456.2080900@vulcan.xs4all.nl> Message-ID: <54F1B725.9090805@digitalbrains.com> On 28/02/15 13:28, Johan Wevers wrote: > I don't see even the NSA breaking that. Heh, famous last words ;). Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From dkg at fifthhorseman.net Sat Feb 28 03:05:04 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 27 Feb 2015 21:05:04 -0500 Subject: Thoughts on GnuPG and automation In-Reply-To: <20150227121834-25258-9117-mailpile@slinky> References: <54F04EC5.3000107@guardianproject.info> <20150227121834-25258-9117-mailpile@slinky> Message-ID: <87mw3y94fj.fsf@alice.fifthhorseman.net> On Fri 2015-02-27 07:19:41 -0500, Bjarni Runar Einarsson wrote: > I think you misunderstood my complaint. I don't mind if the agent is a > persistance daemon that provides GPG-related services, that's all well > and good. It's good process separation and I have no problem with that. > > My gripe with the agent, is the agent is controlling the UI of > authentication. This breaks Mailpile, and this is one of the key areas > where GnuPG crosses the imaginary line between library/utility and > "application". Fixing this was point 1. in my list of suggestions and > explaining why it was necessary was the bulk of the post. The only part of the UI that the agent controls is prompting the user for use of the key, and passphrase entry upon unlock. Why does this break mailpile? I prefer the agent to have separate UI from the tool that uses the agent, because i want don't want tools that use the agent to be able to mask the agent's UI. I'm quite happy that enigmail (for example) appears to be dropping plans for non-agent use of secret key material. this should be a simplifying change, and it should make it easier for systems to integrate OS-level prompting and feedback to the user independent of which application uses the secret key store. --dkg From gnupg-ml at seichter.de Sat Feb 28 14:06:08 2015 From: gnupg-ml at seichter.de (Ralph Seichter) Date: Sat, 28 Feb 2015 14:06:08 +0100 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: <20150228123619.GA7370@athena.barrera.io> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <54F061B6.3070205@seichter.de> <20150227234821.GA15748@athena.barrera.io> <54F1A86D.1050907@seichter.de> <20150228123619.GA7370@athena.barrera.io> Message-ID: <54F1BD40.4080504@seichter.de> It looks like we agree on most aspects, but to get back to the original question of this thread: From what I have seen since the nineties (I do remember donating money for Philip Zimmermann), PGP is great for users with a solid foundation in cryptography, but it is too complicated for avarage users -- no disrespect intended. For more than 20 years, PGP has not made critical mass, and in these years computers and related services have become ever more accessible to average users who don't know about cryptography. In its current form, PGP can be used to improve security in many areas and I am very grateful for the work Werner and others put into it, but PGP does not work for mass e-mail protection, as much as I would prefer matters to be different. -Ralph From peter at digitalbrains.com Sat Feb 28 14:12:24 2015 From: peter at digitalbrains.com (Peter Lebbing) Date: Sat, 28 Feb 2015 14:12:24 +0100 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: <54F1BD40.4080504@seichter.de> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <54F061B6.3070205@seichter.de> <20150227234821.GA15748@athena.barrera.io> <54F1A86D.1050907@seichter.de> <20150228123619.GA7370@athena.barrera.io> <54F1BD40.4080504@seichter.de> Message-ID: <54F1BEB8.5090603@digitalbrains.com> On 28/02/15 14:06, Ralph Seichter wrote: > but PGP does not work for mass e-mail protection Let me stress again that the proper course might be to replace SMTP (e-mail) and then work from that. If you have a sieve and wish for something to hold liquids, you could plug up all the holes or say "Blow this for a lark" and get a pan. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From dkg at fifthhorseman.net Sat Feb 28 15:09:39 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 28 Feb 2015 15:09:39 +0100 Subject: strength of voice authentication [was: Re: German ct magazine postulates death of pgp encryption] In-Reply-To: <54F1B456.2080900@vulcan.xs4all.nl> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <1425060977.5204.10.camel@scientia.net> <54F1B456.2080900@vulcan.xs4all.nl> Message-ID: <87a8zycel8.fsf@alice.fifthhorseman.net> On Sat 2015-02-28 13:28:06 +0100, Johan Wevers wrote: > In practice the Textsecure protocol works well of couyrse because it > uses the phone number. One usually knows that number already from a > contact. Most people I communicatw with often I even recognise by > voice alone - taking over the phone number is not going to work. I > don't see even the NSA breaking that. We had this discussion recently over on messaging at moderncrypto.org. It's far from "trivial", but breaking voice-based authentication (particularly in the already-noisy realm of mobile phone calls) with high probability doesn't seem to be beyond serious researchers. I recommend reading the thread and the referenced papers: http://moderncrypto.org/mail-archive/messaging/2015/001307.html --dkg From bre at pagekite.net Sat Feb 28 13:57:50 2015 From: bre at pagekite.net (=?UTF-8?Q?Bjarni_R=C3=BAnar_Einarsson?=) Date: Sat, 28 Feb 2015 12:57:50 +0000 Subject: Thoughts on GnuPG and automation In-Reply-To: <87mw3y94fj.fsf@alice.fifthhorseman.net> References: <54F04EC5.3000107@guardianproject.info> <20150227121834-25258-9117-mailpile@slinky> <87mw3y94fj.fsf@alice.fifthhorseman.net> Message-ID: Hi Dan, I dedicated an most of the blog post to answering that question (why it breaks Mailpile), did you not read it or did I fail to communicate? - Bjarni On 28 Feb 2015 12:44, "Daniel Kahn Gillmor" wrote: > On Fri 2015-02-27 07:19:41 -0500, Bjarni Runar Einarsson > wrote: > > I think you misunderstood my complaint. I don't mind if the agent is a > > persistance daemon that provides GPG-related services, that's all well > > and good. It's good process separation and I have no problem with that. > > > > My gripe with the agent, is the agent is controlling the UI of > > authentication. This breaks Mailpile, and this is one of the key areas > > where GnuPG crosses the imaginary line between library/utility and > > "application". Fixing this was point 1. in my list of suggestions and > > explaining why it was necessary was the bulk of the post. > > The only part of the UI that the agent controls is prompting the user > for use of the key, and passphrase entry upon unlock. > > Why does this break mailpile? I prefer the agent to have separate UI > from the tool that uses the agent, because i want don't want tools that > use the agent to be able to mask the agent's UI. > > I'm quite happy that enigmail (for example) appears to be dropping plans > for non-agent use of secret key material. this should be a simplifying > change, and it should make it easier for systems to integrate OS-level > prompting and feedback to the user independent of which application uses > the secret key store. > > --dkg > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kristian.fiskerstrand at sumptuouscapital.com Sat Feb 28 15:42:04 2015 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Sat, 28 Feb 2015 15:42:04 +0100 Subject: LDAP-based Keyserver In-Reply-To: <3951114.APtb54Cmoy@inno> References: <87y4ni9sza.wl%neal@walfield.org> <3951114.APtb54Cmoy@inno> Message-ID: <54F1D3BC.7090009@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 02/28/2015 01:23 PM, Hauke Laging wrote: > Am Sa 28.02.2015, 12:27:05 schrieb Neal H. Walfield: > >> In that time, OpenLDAP configuration has gotten a lot more >> complicated. I've modernized and significantly expanded his >> tutorial. You can find it here: >> >> http://wiki.gnupg.org/LDAPKeyserver > > Doesn't refer to your work but is a general question as I have > never used LDAP: > > Is there any advantage in using LDAP for this? Or is this a "We > have the LDAP server anyway thus we add the keyserver stuff instead > of using a separate keyserver" decision? Can't speak as to the motives of the OP, but at least Symantec Encryption Server can be configured to look for keys on LDAP server on keys.[domain] of the recipient to try to establish an OpenPGP channel. This product does not support the HKP protocol, so I'm actually experimenting with a HKP<->LDAP gateway using OpenLDAP myself. - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- Nihil lacrima citius arescit Nothing dries more quickly than a tear -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJU8dO3AAoJEP7VAChXwav6Bh8IALdNFfEl8rU9byZYLyStpnrP mwDzVc+kWqhXDtWyd5oG9YaVzVDMGUK01MEpqWW1/UqwF8QorztMpkn2SUe1Fvns 941Ga2ADFpRDMuCj/mythm5YmIWrtqkmBPm113szQDXYmsO3sDIywt/uirTqb8tZ mU65e6niRAE5/E9Fgk9Go5MYsU+D1gGYcc33FFg4D7vK4bc9D1xdr+RmvhhpogfE 3VJNDrd+Yi2SOykfRHCnCsjuDkYqRMkeYS3h4QacnYKSEX8xoNo+vLGpdoxh4x1U vmd8lFv9jjXTI7Dtcq9WuanyUDiJcGbiHRdiDUWFeNpHUpiaU90SoA6ZxyliJ7k= =GML0 -----END PGP SIGNATURE----- From bre at pagekite.net Sat Feb 28 16:25:11 2015 From: bre at pagekite.net (Bjarni Runar Einarsson) Date: Sat, 28 Feb 2015 15:25:11 -0000 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: <54F1BEB8.5090603@digitalbrains.com> References: <54F1BEB8.5090603@digitalbrains.com> Message-ID: <20150228152510-2617-69195-mailpile@slinky> Peter Lebbing wrote: > On 28/02/15 14:06, Ralph Seichter wrote: > > but PGP does not work for mass e-mail protection > > Let me stress again that the proper course might be to replace SMTP (e-mail) and > then work from that. If you have a sieve and wish for something to hold liquids, > you could plug up all the holes or say "Blow this for a lark" and get a pan. People keep saying this. I see this as both less realistic and more harmful than the voices that are now claiming that OpenPGP should die. E-mail is the *only* surviving decentralized free and open messaging system with any clout today. Literally everything else in common use is proprietary and centralized. We should all be deeply worried about this. Either way, even if this were a reasonable attitude, it doesn't in any way diminish or excuse the fact that OpenPGP in all its glory is too complicated for all but a handful of humans on the planet, most of whom are probably on this mailing list. :-) OpenPGP may be hard to use over SMTP, but it isn't any easier over XMPP or Facebook messages or carrier pigeons either. That said, the DIME proposal is one attempt at "next gen SMTP". From what I've read it's pretty well thought out. It's really, really complicated though, so I'm not particularly optimistic about its chances of success. Cheers! - Bjarni -- Sent using Mailpile, Free Software from www.mailpile.is From peter at digitalbrains.com Sat Feb 28 17:10:28 2015 From: peter at digitalbrains.com (Peter Lebbing) Date: Sat, 28 Feb 2015 17:10:28 +0100 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: <20150228152510-2617-69195-mailpile@slinky> References: <54F1BEB8.5090603@digitalbrains.com> <20150228152510-2617-69195-mailpile@slinky> Message-ID: <54F1E874.80102@digitalbrains.com> On 28/02/15 16:25, Bjarni Runar Einarsson wrote: > E-mail is the *only* surviving decentralized free and open messaging > system with any clout today. Literally everything else in common use is > proprietary and centralized. We should all be deeply worried about this. Well, I think it's a bit grim to think that therefore a successor to replace SMTP must surely be proprietary and centralized, and we should desperately clutch to our last straw, SMTP. Plus, half the e-mail is @google.com anyway. Proprietary, and centralized. It can still communicate with the rest of the world, but for most contacts, it doesn't need to. > Either way, even if this were a reasonable attitude, it doesn't in any > way diminish or excuse the fact that OpenPGP in all its glory is too > complicated for all but a handful of humans on the planet, most of whom > are probably on this mailing list. But a large part of that is due to the fact that SMTP was never built to accomodate any form of privacy or security.[1] Hence my comparison of SMTP being a sieve and privacy being a liquid to transport in that sieve. I for my part think it's unrealistic to keep using SMTP. As I said, you can keep the endpoint communication the same, but the core network needs to be designed with a different goal than SMTP was designed for, to wit, privacy and security. Peter. [1] At least where it concerns using OpenPGP for e-mail communication, which is what we are discussing. I think most users of Debian properly use GnuPG for the authentication of the package management, as an example. PS: By the way, I think you don't mean "literally" in the first quoted paragraph. Because then I need to read your words in a literal fashion, and verbal communication qualifies, in a literal sense, as a messaging system and is not proprietary or centralized. PPS: I like the word "literal". It's the one word in the dictionary that can by definition not be used in any other than its true sense :). It's comfortingly solid in that respect. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From calestyo at scientia.net Sat Feb 28 18:21:04 2015 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Sat, 28 Feb 2015 18:21:04 +0100 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: <54F1B456.2080900@vulcan.xs4all.nl> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <1425060977.5204.10.camel@scientia.net> <54F1B456.2080900@vulcan.xs4all.nl> Message-ID: <1425144064.4857.6.camel@scientia.net> On Sat, 2015-02-28 at 13:28 +0100, Johan Wevers wrote: > In practice the Textsecure protocol works well of couyrse because it > uses the phone number. "In practise"... I guess that's also what most "normal" people believed about their security before Snowden. And a phone number is really no secure credential at all to prove one's identity. o.O > Most people I communicatw with often I even recognise by voice > alone Not sure what you refer to,... but if it's authentication schemes like ZRTP (which TextSecure wouldn't use)... I'm quite sceptical about these. The idea behind them (authentication via voice and some random string which the peers say to each other and compare) may sound nice at a first glance,... but little is known how good (or not) powerful organisations can real-time fake voices. And even if not, how difficult can it be for an organisation like the NSA to spy on you for a while and record enough of your voice and then do a MitM? > taking over the phone number is not going to work. I don't see > even the NSA breaking that. You seem to have missed all the years long discussion about how easy it is to hack mobile systems? Even for novice criminals, etc.? And this even assumes that everything in between (network operator, phone manufacturer, OS manufacturer) is actually not evil, which is unlikely as well. Cheers, Chris. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5313 bytes Desc: not available URL: From johanw at vulcan.xs4all.nl Sat Feb 28 18:39:33 2015 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Sat, 28 Feb 2015 18:39:33 +0100 Subject: trust paths In-Reply-To: <1425072641.5204.95.camel@scientia.net> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <54F0CFA9.7070601@cardcontact.de> <1425068740.5204.81.camel@scientia.net> <1756253.oFcBDuDOmV@inno> <1425072641.5204.95.camel@scientia.net> Message-ID: <54F1FD55.8080308@vulcan.xs4all.nl> On 27-02-2015 22:30, Christoph Anton Mitterer wrote: > I meant in the sense that I want to trust e.g. Werner's key but haven't > met him in person yet,... but I might have an indirect trustpath to him > via some other persons (which I do trust). > Obviously I'll need any intermediate keys (and enough of them that I > personally decide it's trustworthy). OR, in case a key belongs to a well-known person, you've seen it mentioned in enough places and seen it used to sign gpg packages to be rather certain that if it were a forgery someone would have noticed by now and made noise about it. After all, if I want to securely communicate witgh the author of GnuPG I want to know if this key belongs to someone calling himself "Werner Koch". If the government knows this person by the same name (that what is known by an ID check) is less of a concern for me, maybe "Werner Koch" is only an artist name. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From johanw at vulcan.xs4all.nl Sat Feb 28 18:45:35 2015 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Sat, 28 Feb 2015 18:45:35 +0100 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: <54F1B725.9090805@digitalbrains.com> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <1425060977.5204.10.camel@scientia.net> <54F1B456.2080900@vulcan.xs4all.nl> <54F1B725.9090805@digitalbrains.com> Message-ID: <54F1FEBF.1000200@vulcan.xs4all.nl> On 28-02-2015 13:40, Peter Lebbing wrote: > On 28/02/15 13:28, Johan Wevers wrote: >> I don't see even the NSA breaking that. > > Heh, famous last words ;). OK, not cryptographically. They could always try to bribe/threat/torture someone to cooperate. But that model fails if you want to perform unnoticed mass surveillance. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From johanw at vulcan.xs4all.nl Sat Feb 28 18:54:21 2015 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Sat, 28 Feb 2015 18:54:21 +0100 Subject: strength of voice authentication [was: Re: German ct magazine postulates death of pgp encryption] In-Reply-To: <87a8zycel8.fsf@alice.fifthhorseman.net> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <1425060977.5204.10.camel@scientia.net> <54F1B456.2080900@vulcan.xs4all.nl> <87a8zycel8.fsf@alice.fifthhorseman.net> Message-ID: <54F200CD.6060108@vulcan.xs4all.nl> On 28-02-2015 15:09, Daniel Kahn Gillmor wrote: > We had this discussion recently over on messaging at moderncrypto.org. What is described there is a much more confined problem. > It's far from "trivial", but breaking voice-based authentication > (particularly in the already-noisy realm of mobile phone calls) with > high probability doesn't seem to be beyond serious researchers. Fooling a computer that a certain voice belongs to someone else, sure, I'm sure that is or will be possible. Fooling me that a short, fixed string is spoken by someone I know when in fact it is not, sure, that too. But fooling me that the person on the other end of the line is someone I know well by only technically impersonating his voice while having an actual conversation... I don't believe it very likely to happen in the near future. Perhaps it could work on someone I barely know, but pick only once the wrong person and I might become very suspicious. It requires not only changing the voice but also solving a problem much harder than the classic Turing test. For once, it requires much contextual knowledge about what both persons know of each other. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From calestyo at scientia.net Sat Feb 28 18:56:13 2015 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Sat, 28 Feb 2015 18:56:13 +0100 Subject: trust paths In-Reply-To: <54F1FD55.8080308@vulcan.xs4all.nl> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <54F0CFA9.7070601@cardcontact.de> <1425068740.5204.81.camel@scientia.net> <1756253.oFcBDuDOmV@inno> <1425072641.5204.95.camel@scientia.net> <54F1FD55.8080308@vulcan.xs4all.nl> Message-ID: <1425146173.4857.17.camel@scientia.net> On Sat, 2015-02-28 at 18:39 +0100, Johan Wevers wrote: > OR, in case a key belongs to a well-known person, you've seen it > mentioned in enough places and seen it used to sign gpg packages to be > rather certain that if it were a forgery someone would have noticed by > now and made noise about it. I'm not sure but I fear you have some deep misunderstanding of cryptography... or at least that's how I understand your message (but maybe I confuse something). "Well-known", "often seen enough" or "not having heard any noise about it" are absolutely no ways to prove the validity of a key's named identity. If there was only one "Werner Koch" on the keyservers, and that key was signed by thousands of other famous names (Linus Torvalds, and that like) you still couldn't be sure of anything. An attacker that MitMs you could just set up a fake web-of-trust in very little time and when you ask your favourite keyserver, block any of the "real answers" and instead deliver you his faked key space with all the mutual signatures and so on. And you'd think "Only one Werner Koch, with an @gnupg.org email, even signed by all these other people - that can't be coincidence, some of the must have checked his ID, and if it was an impostor, I'd surely have read on heise.de about it" - while in fact no one else than you ever saw these faked keys. If the attacker is powerful enough (and this is still way below of what intelligence agencies can do - rather the level of what your network provider can do), they can also intercept anything you'd send back to the web with these forged keys, so they'd truly be never discovered. Cheers, Chris. btw: These kinds of things are just what one can heise accuse of: they give people an all to easy sight of crypto security, so that they'll believe things are secure by using one's phone number, or by using pinning techniques like HPKP. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5313 bytes Desc: not available URL: From johanw at vulcan.xs4all.nl Sat Feb 28 19:01:02 2015 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Sat, 28 Feb 2015 19:01:02 +0100 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: <1425144064.4857.6.camel@scientia.net> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <1425060977.5204.10.camel@scientia.net> <54F1B456.2080900@vulcan.xs4all.nl> <1425144064.4857.6.camel@scientia.net> Message-ID: <54F2025E.1050308@vulcan.xs4all.nl> On 28-02-2015 18:21, Christoph Anton Mitterer wrote: > Not sure what you refer to,... but if it's authentication schemes like > ZRTP (which TextSecure wouldn't use)... No it's not, it is much simpler. When I call my wife and are in fact connected with a computer or agent impersonating her, they are unlikely being able to copy her voice so good that I don't hear it. And even if they are, I think it's very unprobable they would be able to fool me due to them missing context. Try it out: have 2 people who know each other well speak via a computer synthesised voice so voice reconnition would not work. Then have a third person who doesn't have intimate knpowledge about both others try to fool one of the other two he is the other person. Unluikely to work. And even if it would be possible, it would require so much manpower to make it unusable for mass surveilance. It would probably only be used against very high-priority targets of the caliber Bin Laden. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From calestyo at scientia.net Sat Feb 28 19:07:59 2015 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Sat, 28 Feb 2015 19:07:59 +0100 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: <54F1FEBF.1000200@vulcan.xs4all.nl> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <1425060977.5204.10.camel@scientia.net> <54F1B456.2080900@vulcan.xs4all.nl> <54F1B725.9090805@digitalbrains.com> <54F1FEBF.1000200@vulcan.xs4all.nl> Message-ID: <1425146879.4857.27.camel@scientia.net> On Sat, 2015-02-28 at 18:45 +0100, Johan Wevers wrote: > OK, not cryptographically. They could always try to bribe/threat/torture > someone to cooperate. But that model fails if you want to perform > unnoticed mass surveillance. Admittedly, when it comes to "unnoticed mass surveillance" anonymous cryptography (like TextSecure does for most users, since they aren't pushed to validate - and even if, one cannot mark who was validated and who not)... *might* help somewhat against unnoticed mass surveillance, that is when something like DH is used. But this assumption is largely based on two things: - That's resource-wise too costly for them to MitM everyone => and given what we've learned from Snowden (and what "paranoid" people already assumed/knew before)... I really doubt that this would be any bigger problem for them. Apparently they sit at all the bigger internet exchanges, transatlantic cables, etc. and all the big US players (FB, Google, and Tier-1 content providers are anyway forced to cooperate with them) - That people actually eventually check their keys, so that they'd find out whether their anonymous DH was attacked by some MitM. This might be done by some "more advanced" people who even know about what a fingerprint is, and when their client actually exports it to them (which may not be the case when you do something like whotsapp? or any other system used by the masses, which just promises you to be "secure". Cheers, Chris. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5313 bytes Desc: not available URL: From johanw at vulcan.xs4all.nl Sat Feb 28 19:15:10 2015 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Sat, 28 Feb 2015 19:15:10 +0100 Subject: trust paths In-Reply-To: <1425146173.4857.17.camel@scientia.net> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <54F0CFA9.7070601@cardcontact.de> <1425068740.5204.81.camel@scientia.net> <1756253.oFcBDuDOmV@inno> <1425072641.5204.95.camel@scientia.net> <54F1FD55.8080308@vulcan.xs4all.nl> <1425146173.4857.17.camel@scientia.net> Message-ID: <54F205AE.5010307@vulcan.xs4all.nl> On 28-02-2015 18:56, Christoph Anton Mitterer wrote: > I'm not sure but I fear you have some deep misunderstanding of > cryptography... I'm not talking about mathematically proving something. After all, a government agency could make a false key with Werner Koch's name on it and send someone who looks like him with real ID documents to a keysigning party. Government-issued ID's are no mathematical proof either. > "Well-known", "often seen enough" or "not having heard any noise about > it" are absolutely no ways to prove the validity of a key's named > identity. No proof no - but nathematical proof does not exist in this matter. > If there was only one "Werner Koch" on the keyservers, and that key was > signed by thousands of other famous names (Linus Torvalds, and that > like) you still couldn't be sure of anything. Of course not, anyone can upload a key with any name to the keyservers. But I doubt anyone can publish a fake key on www.gnupg.org without anyone noticing for long. > An attacker that MitMs you could just set up a fake web-of-trust in very > little time and when you ask your favourite keyserver, block any of the > "real answers" and instead deliver you his faked key space with all the > mutual signatures and so on. I am not talking about keyservers at all, except maybe for obtaining a key with a given keyID. Nothing more, and no WoT issues. While I understand the concept I consider the WoT way to complicated and I use it only as additional evidence a key belongs to someone. > And you'd think "Only one Werner Koch, with an @gnupg.org email, even > signed by all these other people - that can't be coincidence, some of > the must have checked his ID, and if it was an impostor, I'd surely have > read on heise.de about it" - while in fact no one else than you ever saw > these faked keys. If the key was only on the keyservers, sure, then even I could do that myself easily. But I'm talking about keys on places where it is unlikely anyone has write access to, like the gnupg website or as a signature in mailinglist messages. Sure, it could be spoofed - but only a short time before it get noticed. It would not be the first time I read about a spoofed gpg key on a Linux distro server when the server was hacked. The attack works - but not for long. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From calestyo at scientia.net Sat Feb 28 19:17:56 2015 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Sat, 28 Feb 2015 19:17:56 +0100 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: <54F2025E.1050308@vulcan.xs4all.nl> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <1425060977.5204.10.camel@scientia.net> <54F1B456.2080900@vulcan.xs4all.nl> <1425144064.4857.6.camel@scientia.net> <54F2025E.1050308@vulcan.xs4all.nl> Message-ID: <1425147476.4857.36.camel@scientia.net> On Sat, 2015-02-28 at 19:01 +0100, Johan Wevers wrote: > No it's not, it is much simpler. When I call my wife and are in fact > connected with a computer or agent impersonating her, they are unlikely > being able to copy her voice so good that I don't hear it. I guess you've missed some developments in research here (see Daniel's post) - and this is just the publicly known research. > And even if > they are, I think it's very unprobable they would be able to fool me due > to them missing context. They don't need to know any content. And they don't need to fake her all the time. When "they" MitM you, they just need to wait for the time when you'd actually to mutual authentication via saying some "code" or whatever the ZRTP implementation gives you. Only then they need to mute the real "her" and let the faked "her" say the code for their (evil) DH connection with you - and vice versa. I'm not sure what the most recent ZRTP implementations do... but is it more than numbers, letters or simple words? Nothing one couldn't fake or perhaps pre-record somewhere in the real world. Of course they might still not be able to imposture her completely - in the sense that "she" tells you to send all your savings via PayPal to calestyo at scientia.net (which would be surely a good idea ;-) ) - But it's enough for them to eavesdrop. > And even if it would be possible, it would require so much manpower to > make it unusable for mass surveilance. It would probably only be used > against very high-priority targets of the caliber Bin Laden. btw: I don't think that GnuPG's only intent is to fight against mass surveillance. I mean mass surveillance *is* of course a problem - but at least none that will usually have any directly measurable negative effect on the victim (again I'm not talking about the negative effect on his liberties here). The NSA has definitely read most of my mails (as they go to public lists ^^) but since I'm no criminal, neither someone like Snowden, Greenwald or Assange - they simply don't care about me. But such people or Iranian dissidents and that like ... probably want some system which not only protects them against mass surveillance but also gives them at least the best possible safety against dedicated surveillance of single targets. Cheers, Chris. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5313 bytes Desc: not available URL: From dougb at dougbarton.email Sat Feb 28 21:36:44 2015 From: dougb at dougbarton.email (Doug Barton) Date: Sat, 28 Feb 2015 12:36:44 -0800 Subject: Best practice to make one's key known, was Re: German ct magazine postulates death of pgp encryption In-Reply-To: References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <1890860.SDiBssEjyI@inno> <000e01d05280$656fed70$304fc850$@on.yourweb.de> <7920271.MAWFr6xyvP@inno> <54F05EF5.6050105__7398.9701144912$1425039188$gmane$org@sumptuouscapital.com> <54F09ACB.6020108@enigmail.net> <87lhjjm8mn.fsf@vigenere.g10code.de> Message-ID: <54F226DC.9010506@dougbarton.email> On 2/27/15 10:10 PM, Marco Zehe wrote: > Hi Werner et al, > >> Am 27.02.2015 um 20:56 schrieb Werner Koch : >> >> There is no trust in keyservers by design. As soon as you start >> changing this you are turning PGP into a centralized system. > > OK, then I have a very practical question: Even though this is my > fourth or fifth attempt at establishing OpenPGP in my daily routine > since the mid 1990s, I am still confused by what the best way is to > make my public key known. So if, as you say, key servers are not > trusted by design, if I want to spread word around my available > public key, which source should I put in a signature? While reading > this list, I have seen quite a number of different approaches. Some > put their key ID along with the finger print and the URL of a key > server. Others put a link to the key file on a web server, others > just quote their key ID and finger print, or only either of those. > > I have my key uploaded (and kept current) on key servers as well as > on my web site(s), and my Impressum links to the copy on my web > site rather than the key server URL. > > So: What?s the best practice advice? (and yes, I looked in the FAQ, > but that didn?t prove conclusive to me.) It's overwhelmingly likely that you are overthinking this. :) If someone wants to correspond with you using PGP, they will ask. If you sign a message, they will know that you are using PGP, and what your key Id is. And you've posted it enough places that even a moderately motivated person will be able to find it. Relax, and enjoy the ride. Doug From dougb at dougbarton.email Sat Feb 28 21:37:52 2015 From: dougb at dougbarton.email (Doug Barton) Date: Sat, 28 Feb 2015 12:37:52 -0800 Subject: German ct magazine postulates death of pgp encryption In-Reply-To: <54F051D8.8080104@digitalbrains.com> References: <000d01d05269$c1726dd0$44574970$@on.yourweb.de> <54F051D8.8080104@digitalbrains.com> Message-ID: <54F22720.9030608@dougbarton.email> On 2/27/15 3:15 AM, Peter Lebbing wrote: > So what did this key attract, being on the keyserver for four years now? > > 22 Nigerian 419 scams. That's it. Twenty-two! They came in batches; I haven't > seen anything since March last year. I've had a similar key out there for longer than four years, and my experience is the same. This is simply not an issue. Doug