From rjh at sixdemonbag.org Tue Dec 1 01:25:45 2020 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 30 Nov 2020 19:25:45 -0500 Subject: Christmas giving Message-ID: In years past I'd run a Christmas fundraiser for GnuPG. I haven't done that recently after GnuPG received some large contributions from corporate sponsors: but 2020 being what it is, I kind of suspect GnuPG can use a fundraiser, so... let's go back to the classics. WHAT: For every euro you donate to GnuPG, I donate one euro, up to five hundred euros. WHEN: From December 10 to January 6. This should cover the vast majority of seasonal religious holidays. HOW: All you have to do is donate. At the end of it I'll ask Werner how big of a donation I'm making, and once it arrives he'll confirm to the list I've upheld my end of the deal. WHY: Because a great way to say "thank you for all your work, guys!" is to donate to the GnuPG project. LINK: https://www.gnupg.org/cgi-bin/procdonate.cgi?mode=preset Merry Christmas, Happy Hanukkah, Blessed Yule and/or Solstice, Season's Greetings, and just have yourself a nice day. :) From karmanyaahm at gmail.com Tue Dec 1 01:39:10 2020 From: karmanyaahm at gmail.com (Karmanyaah Malhotra) Date: Mon, 30 Nov 2020 19:39:10 -0500 Subject: Changing compression configuration In-Reply-To: <87pn3wfknh.fsf@wheatstone.g10code.de> References: <87pn3wfknh.fsf@wheatstone.g10code.de> Message-ID: > Adding this to GnuPG would be too hard. You better use an external > program for compressing the data > cat foo | bzip2 | gpg -z0 -e >foo.bz2.gpg > gpg -d foo Got it, thanks. -- Karmanyaah Malhotra https://karmanyaah.malhotra.cc/contact/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 554 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Tue Dec 1 09:36:25 2020 From: wk at gnupg.org (Werner Koch) Date: Tue, 01 Dec 2020 09:36:25 +0100 Subject: Odd error In-Reply-To: <878saiee2t.fsf@wheatstone.g10code.de> (Werner Koch via Gnupg-users's message of "Mon, 30 Nov 2020 22:20:58 +0100") References: <31679534-a4ff-5222-f02c-b5de32e53de1@sixdemonbag.org> <87pn3vdj63.fsf@wheatstone.g10code.de> <87ft4qeg8m.fsf@wheatstone.g10code.de> <878saiee2t.fsf@wheatstone.g10code.de> Message-ID: <87v9dldit2.fsf@wheatstone.g10code.de> On Mon, 30 Nov 2020 22:20, Werner Koch said: > I'll build with the Fedora patches in the next days. If the missing > curves are really the reason, we can fix that. Yes, the disabled Brainpool curves lead to the import problem. I'll see what we can do. See https://dev.gnupg.org/T5162 Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From tmz at pobox.com Tue Dec 1 22:08:52 2020 From: tmz at pobox.com (Todd Zullinger) Date: Tue, 1 Dec 2020 16:08:52 -0500 Subject: Odd error In-Reply-To: <878saiee2t.fsf@wheatstone.g10code.de> References: <31679534-a4ff-5222-f02c-b5de32e53de1@sixdemonbag.org> <87pn3vdj63.fsf@wheatstone.g10code.de> <87ft4qeg8m.fsf@wheatstone.g10code.de> <878saiee2t.fsf@wheatstone.g10code.de> Message-ID: <20201201210852.GS748@pobox.com> Hi, Werner Koch wrote: > I looked at the Fedora Libgcrypt source and noticed that they ship > libgcrypt with the nistp192 and all brainpool curves removed. I have > not yet build this version but given that one of your keys has brainpool > curves this might be the culprit. > > I can understand that they remove nistp192 for security policy reasons. > But I do not understand why the brainpool curves are removed. The > general statement in the spec file is that curves need to be removed due > to patent rasons. However, Brainpool curves are less prone to patent > claims for fast multiplication than the NIST curves and we actually use > the very same code for all those Weierstrass curves. FWIW, I noticed that someone recently asked about the status of the ECC Brainpool curves on the Fedora Legal list: https://lists.fedoraproject.org/archives/list/legal at lists.fedoraproject.org/thread/WUQNAB4EPWSJMMVECL2TZGKB5KIDESII/ With luck, a fresh review by the Red Hat legal folks will result in those curves becoming accessible in the Fedora libgcrypt packages. Cheers, -- Todd From johndoe65534 at mail.com Thu Dec 3 07:50:47 2020 From: johndoe65534 at mail.com (john doe) Date: Thu, 3 Dec 2020 07:50:47 +0100 Subject: Verifying and checksumming new release is somewhat cumbersom In-Reply-To: <87lfekfkfi.fsf@wheatstone.g10code.de> References: <5fe4d4c3-8ab2-6555-792d-00b59997b9b8@mail.com> <87ft4vhoad.fsf@wheatstone.g10code.de> <469842e0-86fa-cd41-f80f-be7efec7d754@mail.com> <87lfekfkfi.fsf@wheatstone.g10code.de> Message-ID: <563bee81-4bd2-41f9-7a82-446b627d473a@mail.com> On 11/29/2020 12:53 PM, Werner Koch wrote: > On Sat, 28 Nov 2020 07:57, john doe said: > >> If I look at Debian (1) for example, the checksum file is gpg signed. >> Assuming that I understand correctly, the Debian approach is not a safe >> way to make the checksums available?propagate? > > No, that is a safe way. > > Having a separate file with checksums is sometimes better for the > signing workflow. It also allows to sign/verify a bunch of files with > just one operation. It also avoids the need to download and upload all > files to a dedicated signing box. Only since GnuPG 2.2 the latter could > be handled using gpg-agent's remote feature. > Interesting, just to be sure you are refering to the below option from (1)?: "--extra-socket name" Is the release workflow documented somewhere so a non-dev could look to implement this ? In other words, is it worth considering such a move. 1) https://www.gnupg.org/documentation/manuals/gnupg/Agent-Options.html#Agent-Options -- John Doe From wk at gnupg.org Fri Dec 4 08:23:11 2020 From: wk at gnupg.org (Werner Koch) Date: Fri, 04 Dec 2020 08:23:11 +0100 Subject: Verifying and checksumming new release is somewhat cumbersom In-Reply-To: <563bee81-4bd2-41f9-7a82-446b627d473a@mail.com> (john doe via Gnupg-users's message of "Thu, 3 Dec 2020 07:50:47 +0100") References: <5fe4d4c3-8ab2-6555-792d-00b59997b9b8@mail.com> <87ft4vhoad.fsf@wheatstone.g10code.de> <469842e0-86fa-cd41-f80f-be7efec7d754@mail.com> <87lfekfkfi.fsf@wheatstone.g10code.de> <563bee81-4bd2-41f9-7a82-446b627d473a@mail.com> Message-ID: <87v9di8274.fsf@wheatstone.g10code.de> On Thu, 3 Dec 2020 07:50, john doe said: > Is the release workflow documented somewhere so a non-dev could look to > implement this ? https://wiki.gnupg.org/AgentForwarding feel free to extend this page if you have remarks. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From spam.trap.mailing.lists at gmail.com Fri Dec 4 18:41:32 2020 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Fri, 4 Dec 2020 18:41:32 +0100 Subject: Mobile mini computers for GnuPG/OpenPGP usage instead of smartphone usage In-Reply-To: References: <970cb566-619d-02fb-b70f-5a83381f2968@bruckner.email> Message-ID: On Sat, Nov 28, 2020 at 4:49 PM Stefan Claas wrote: > > On Sat, Nov 28, 2020 at 3:38 PM Juergen Bruckner via Gnupg-users > wrote: > > > > Hello Stefan, > > [...] > > > Could you please tell me more when you get this device? > > Hi Juergen, > > sure, I will tell you more once I have the device. It may take > a couple of days due to delivery schedules at DHL, because > of COVID-19. Hi Juergen, So, yesterday the device arrived and today it was picked up at the DHL bus. I am really excited about this little MicroPC! It has the highest quality finishing and looks and feels better than one might expect from the photos. So 1A quality! The MicroPC is also quite fast, because Ubuntu Mate starts quickly and you can work smoothly, even in the dark, because the keyboard is illuminated. Once time permits, I will install some packages and do further testing. Best regards Stefan From pete at heypete.com Fri Dec 4 19:26:57 2020 From: pete at heypete.com (Pete Stephenson) Date: Fri, 04 Dec 2020 10:26:57 -0800 Subject: Add key to card without substituting stubs for actual private key? Message-ID: Hi all, Background: I have an offline system I use for holding my private keys on-disk. I use smartcards for my day-to-day use on ordinary systems. I use the offline system to generate new primary keys when needed, as well as encryption subkeys (so I can always go back and decrypt things even if the smartcards are lost), and then transfer keys to smartcards using the "keytocard" command under gpg --edit-key . Signing subkeys are generated directly on the smartcards. Issue: Whenever I use keytocard, the selected private key is transferred to the smartcard as expected. The selected private key on the offline system is replaced with a stub pointing to that card (also as expected). In my use case, this is undesirable since I wish for the offline system to retain the actual private key after copying the private key to the card. As a workaround, I've taken to making a backup of the .gnupg directory, performing the keytocard operation, then deleting the .gnupg directory that now contains the stubs and restoring the backup from before the operation. While functional, this is potentially error-prone. Question: Is it possible to transfer an existing private key from a computer to a smartcard without replacing the private key on the computer with a stub pointing to the card? Request: If it is not currently possible to do this, I request that such a feature (e.g. "copykeytocard" rather than "keytocard") be added when convenient. Thanks! Cheers! -Pete -- Pete Stephenson From andrewg at andrewg.com Fri Dec 4 20:55:04 2020 From: andrewg at andrewg.com (Andrew Gallagher) Date: Fri, 4 Dec 2020 19:55:04 +0000 Subject: Add key to card without substituting stubs for actual private key? In-Reply-To: References: Message-ID: <490ED1B7-0E31-456D-BE4D-FDC279D2C42E@andrewg.com> > On 4 Dec 2020, at 19:27, Pete Stephenson via Gnupg-users wrote: > > Question: > Is it possible to transfer an existing private key from a computer to a smartcard without replacing the private key on the computer with a stub pointing to the card? Yes, after you invoke the keytocard command(s) you have a choice to quit or save. If you save, you write the stubs to disk and overwrite the real key material. If you quit without saving, no disk write is performed, but your keys are already on the card so now you have both a card and a disk copy. Andrew. From nicolas.boullis at ecp.fr Sat Dec 5 15:20:33 2020 From: nicolas.boullis at ecp.fr (Nicolas Boullis) Date: Sat, 5 Dec 2020 15:20:33 +0100 Subject: =?utf-8?Q?=E2=80=9CHardware_problem?= =?utf-8?B?4oCd?= with OpenPGP smart card Message-ID: <20201205142033.GB2368@debian> Hi, I?ve been using GnuPG with my private keys stored in an OpenPGP smartcard since year 2014. Suddenly, it stopped working yesterday. The smartcard is an ID000-cut version 2 OpenPGP smartcard, that I put in a Gemalto Shell Token v2 card reader. Whenever I try to decrypt a file with gnupg, it asks me for the pin code, and then fails with: gpg: public key decryption failed: Hardware problem gpg: decryption failed: No secret key But gpg2 --card-status looks fine: Reader ...........: 08E6:3438:EB846942:0 Application ID ...: D2760001240102000005000028AC0000 Version ..........: 2.0 Manufacturer .....: ZeitControl Serial number ....: 000028AC Name of cardholder: Nicolas Boullis Language prefs ...: fren Sex ..............: male URL of public key : https://people.debian.org/~nboullis/882D4468.asc Login data .......: nboullis Signature PIN ....: not forced Key attributes ...: rsa4096 rsa4096 rsa4096 Max. PIN lengths .: 32 32 32 PIN retry counter : 2 0 3 Signature counter : 89 Signature key ....: E255 CB42 FC16 B17E 20CD 18D9 79F1 8F90 CC2B 8435 created ....: 2014-12-14 00:17:04 Encryption key....: 7D9E A605 E167 A29C 4C0F 8AEA 5BEC 68E0 0D97 34FB created ....: 2014-12-14 00:12:11 Authentication key: F2DF B54A 3623 7414 53DD 9461 F203 2B12 D9E8 23FD created ....: 2014-12-14 00:19:47 General key info..: sub rsa4096/79F18F90CC2B8435 2014-12-14 Nicolas Boullis sec# rsa4096/D0E94F8D882D4468 created: 2014-12-13 expires: 2021-01-01 ssb> rsa4096/5BEC68E00D9734FB created: 2014-12-14 expires: never card-no: 0005 000028AC ssb> rsa4096/79F18F90CC2B8435 created: 2014-12-14 expires: never card-no: 0005 000028AC ssb> rsa4096/F2032B12D9E823FD created: 2014-12-14 expires: never card-no: 0005 000028AC Has anyone experienced such a problem? Any suggestion how I can sort this out? Cheers, -- Nicolas From gnupgpacker at on.yourweb.de Sun Dec 6 12:12:11 2020 From: gnupgpacker at on.yourweb.de (gnupgpacker) Date: Sun, 6 Dec 2020 12:12:11 +0100 Subject: Question about key verification with GnuPG 2.2.25 Message-ID: <000001d6cbc0$a50d7410$ef285c30$@on.yourweb.de> Hello, my attempt to verify all keys with GnuPG-2.2.25 shows this response: $ gpg --refresh-keys gpg: 59 Schl?ssel werden per hkps://hkps.pool.sks-keyservers.net aktualisiert gpg: ... gpg: signature packet: hashed data too long gpg: read_block: read error: Ung?ltiges Paket gpg: Anzahl insgesamt bearbeiteter Schl?ssel: 27 gpg: unver?ndert: 27 In gpg.conf option charset utf-8 is set only. GnuPG-2.2.25 has been installed as part of Gpg4win-3.1.14. How to further explore the shown errors: gpg: signature packet: hashed data too long gpg: read_block: read error: Ung?ltiges Paket How to identify / correct affected keys? Thanks and best regards, Chris From wk at gnupg.org Sun Dec 6 12:39:01 2020 From: wk at gnupg.org (Werner Koch) Date: Sun, 06 Dec 2020 12:39:01 +0100 Subject: Question about key verification with GnuPG 2.2.25 In-Reply-To: <000001d6cbc0$a50d7410$ef285c30$@on.yourweb.de> (gnupgpacker's message of "Sun, 6 Dec 2020 12:12:11 +0100") References: <000001d6cbc0$a50d7410$ef285c30$@on.yourweb.de> Message-ID: <87czzn88q2.fsf@wheatstone.g10code.de> On Sun, 6 Dec 2020 12:12, gnupgpacker said: > How to identify / correct affected keys? As usual add --verose to the gpg invocation. This might give some more information. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Sun Dec 6 12:37:19 2020 From: wk at gnupg.org (Werner Koch) Date: Sun, 06 Dec 2020 12:37:19 +0100 Subject: =?utf-8?Q?=E2=80=9CHardware_problem=E2=80=9D?= with OpenPGP smart card In-Reply-To: <20201205142033.GB2368@debian> (Nicolas Boullis's message of "Sat, 5 Dec 2020 15:20:33 +0100") References: <20201205142033.GB2368@debian> Message-ID: <87h7oz88sw.fsf@wheatstone.g10code.de> On Sat, 5 Dec 2020 15:20, Nicolas Boullis said: > gpg: public key decryption failed: Hardware problem > gpg: decryption failed: No secret key To make sure that this is really the card (or reader), I'd like to ask you to put --8<---------------cut here---------------start------------->8--- log-file /some/path/scd.log verbose debug cardio --8<---------------cut here---------------end--------------->8--- into scdaemon.conf. Kill scdaemon.conf and retry. You should see a line with status code 0x6581 (EEPROM FAILURE) in response to a VERIFY (00 20 ... PIN) APDU or a PSO (00 2A ....) APDU. If that is the case you are probably out of luck. It is a rare thing; iirc, I recall one other report about a hardware failure. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From nicolas.boullis at ecp.fr Sun Dec 6 16:34:40 2020 From: nicolas.boullis at ecp.fr (Nicolas Boullis) Date: Sun, 6 Dec 2020 16:34:40 +0100 Subject: =?utf-8?Q?=E2=80=9CHardware_problem?= =?utf-8?B?4oCd?= with OpenPGP smart card In-Reply-To: <87h7oz88sw.fsf@wheatstone.g10code.de> References: <20201205142033.GB2368@debian> <87h7oz88sw.fsf@wheatstone.g10code.de> Message-ID: <20201206153440.GA4764@debian> Hi, On Sun, Dec 06, 2020 at 12:37:19PM +0100, Werner Koch wrote: > > To make sure that this is really the card (or reader), I'd like to ask > you to put > > --8<---------------cut here---------------start------------->8--- > log-file /some/path/scd.log > verbose > debug cardio > --8<---------------cut here---------------end--------------->8--- > > into scdaemon.conf. Kill scdaemon.conf and retry. You should see a line > with status code 0x6581 (EEPROM FAILURE) in response to a VERIFY (00 20 > ... PIN) APDU or a PSO (00 2A ....) APDU. If that is the case you are > probably out of luck. It is a rare thing; iirc, I recall one other > report about a hardware failure. Thanks for your suggestion. I just tried it, and found, in the scd.log file: 2020-12-06 16:26:24 scdaemon[4732] DBG: send apdu: c=00 i=20 p1=00 p2=82 lc=8 le=-1 em=0 2020-12-06 16:26:24 scdaemon[4732] DBG: raw apdu: 00 20 00 82 08 ***PIN*** 2020-12-06 16:26:24 scdaemon[4732] DBG: response: sw=6581 datalen=0 2020-12-06 16:26:24 scdaemon[4732] verify CHV2 failed: Hardware problem 2020-12-06 16:26:24 scdaemon[4732] operation decipher result: Hardware problem 2020-12-06 16:26:24 scdaemon[4732] app_decipher failed: Hardware problem Do you think there is still a chance that the reader is at fault rather than the smartcard? Any hope besides replacing the smartcard *and the subkeys*? Thanks for your help, -- Nicolas From gnupgpacker at on.yourweb.de Sun Dec 6 17:41:04 2020 From: gnupgpacker at on.yourweb.de (gnupgpacker) Date: Sun, 6 Dec 2020 17:41:04 +0100 Subject: Question about key verification with GnuPG 2.2.25 In-Reply-To: <87czzn88q2.fsf@wheatstone.g10code.de> References: <000001d6cbc0$a50d7410$ef285c30$@on.yourweb.de> <87czzn88q2.fsf@wheatstone.g10code.de> Message-ID: <000001d6cbee$96b9c3e0$c42d4ba0$@on.yourweb.de> Hello, the --verbose options gave me some more unusual information: gpg: Schl?ssel 22EEE0488086...F: Ung?ltige Eigenbeglaubigung f?r User-ID "[jpeg image of size 7915]" gpg: Schl?ssel 22EEE0488086...F/CE7911B7FC04...F: Ung?ltige Unterschl?ssel-Anbindung gpg: key 41E7044E1DBA...9: number of dropped non-self-signatures: 60 gpg: Schl?ssel 4E2C6E879329...0/7017ADCEF65C...6: Mehrfache Unterschl?ssel-Anbindung entfernt gpg: Im Unterpaket des Typs 28 ist das "critical bit" gesetzt gpg: compacting user ID "" on key 2BAE3CF6DAFF...0: ung?ltig Which error causes following warnings: gpg: signature packet: hashed data too long gpg: read_block: read error: Ung?ltiges Paket Thanks once more, best regards, Chris > As usual add --verose to the gpg invocation. This might give some more > information. From guru at unixarea.de Sun Dec 6 17:41:06 2020 From: guru at unixarea.de (Matthias Apitz) Date: Sun, 6 Dec 2020 16:41:06 +0000 Subject: =?UTF-8?B?4oCcSGFyZHdhcmU=?= =?UTF-8?B?IHByb2JsZW3igJ0=?= with OpenPGP smart card In-Reply-To: <20201206153440.GA4764@debian> References: <20201205142033.GB2368@debian> <87h7oz88sw.fsf@wheatstone.g10code.de> <20201206153440.GA4764@debian> Message-ID: On Sun, 6 Dec 2020 16:34:40 +0100, Nicolas Boullis wrote: > Hi, > > On Sun, Dec 06, 2020 at 12:37:19PM +0100, Werner Koch wrote: >> >> To make sure that this is really the card (or reader), I'd like to ask >> you to put >> >> --8<---------------cut here---------------start------------->8--- >> log-file /some/path/scd.log >> verbose >> debug cardio >> --8<---------------cut here---------------end--------------->8--- >> >> into scdaemon.conf. Kill scdaemon.conf and retry. You should see a line >> with status code 0x6581 (EEPROM FAILURE) in response to a VERIFY (00 20 >> ... PIN) APDU or a PSO (00 2A ....) APDU. If that is the case you are >> probably out of luck. It is a rare thing; iirc, I recall one other >> report about a hardware failure. > > Thanks for your suggestion. > I just tried it, and found, in the scd.log file: > > 2020-12-06 16:26:24 scdaemon[4732] DBG: send apdu: c=00 i=20 > p1=00 p2=82 lc=8 le=-1 em=0 > 2020-12-06 16:26:24 scdaemon[4732] DBG: raw apdu: 00 20 00 82 08 ***PIN*** > 2020-12-06 16:26:24 scdaemon[4732] DBG: response: sw=6581 datalen=0 > 2020-12-06 16:26:24 scdaemon[4732] verify CHV2 failed: Hardware problem > 2020-12-06 16:26:24 scdaemon[4732] operation decipher result: > Hardware problem > 2020-12-06 16:26:24 scdaemon[4732] app_decipher failed: Hardware problem > > Do you think there is still a chance that the reader is at fault rather > than the smartcard? > Any hope besides replacing the smartcard *and the subkeys*? > > Testing a new reader dongle is the best option. matthias -- Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub ??? ????? ??? ??????, ??? ?????? ??? ?????????? (??a????? ????? ?????) Without books no knowledge - without knowledge no communism (Vladimir Ilyich Lenin) Sin libros no hay saber - sin saber no hay comunismo. (Vladimir Ilich Lenin) From jscott at posteo.net Sun Dec 6 19:43:45 2020 From: jscott at posteo.net (John Scott) Date: Sun, 06 Dec 2020 13:43:45 -0500 Subject: =?UTF-8?B?4oCcSGFyZHdhcmUgcHJvYmxlbeKAnQ==?= with OpenPGP smart card In-Reply-To: <20201205142033.GB2368@debian> References: <20201205142033.GB2368@debian> Message-ID: <1902076.7aRn1RRit1@t450> On Saturday, December 5, 2020 9:20:33 AM EST Nicolas Boullis wrote: > PIN retry counter : 2 0 3 It looks like you're trying to decrypt a file and your encryption PIN counter is zero. I wonder why it was giving you the strange error message. Does signing work? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Mon Dec 7 12:08:23 2020 From: wk at gnupg.org (Werner Koch) Date: Mon, 07 Dec 2020 12:08:23 +0100 Subject: =?utf-8?Q?=E2=80=9CHardware_problem=E2=80=9D?= with OpenPGP smart card In-Reply-To: <1902076.7aRn1RRit1@t450> (John Scott via Gnupg-users's message of "Sun, 06 Dec 2020 13:43:45 -0500") References: <20201205142033.GB2368@debian> <1902076.7aRn1RRit1@t450> Message-ID: <87o8j57u1k.fsf@wheatstone.g10code.de> On Sun, 6 Dec 2020 13:43, John Scott said: >> PIN retry counter : 2 0 3 > It looks like you're trying to decrypt a file and your encryption PIN counter > is zero. I wonder why it was giving you the strange error message. No, it is not at zero. Since OpenPGP card specification version 2 we only have two PINs and not a separate one for the encryption key. Thus the the secund number is always zero. Well, not always: If you set a reset code the second retry counter is set to 3. Such a reset code is an alternative to the Admin PIN. If an organization does not want to hand out the Admin PIN a reset code is instead set and the user can use that reset code to unblock they PIN. The show error code is indeed either a hardware error (EEPROM failure) or due to a card reader which filters certyain commands send to the card and return a bogus error code. However, I doubt that the latter is the case. In any case, it is best to try a different reader and if possible a different machine. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From nicolas.boullis at ecp.fr Mon Dec 7 23:37:32 2020 From: nicolas.boullis at ecp.fr (Nicolas Boullis) Date: Mon, 7 Dec 2020 23:37:32 +0100 Subject: =?utf-8?Q?=E2=80=9CHardware_problem?= =?utf-8?B?4oCd?= with OpenPGP smart card In-Reply-To: <87o8j57u1k.fsf@wheatstone.g10code.de> References: <20201205142033.GB2368@debian> <1902076.7aRn1RRit1@t450> <87o8j57u1k.fsf@wheatstone.g10code.de> Message-ID: <20201207223732.GA1783@debian> Hi, On Mon, Dec 07, 2020 at 12:08:23PM +0100, Werner Koch via Gnupg-users wrote: > > The show error code is indeed either a hardware error (EEPROM failure) > or due to a card reader which filters certyain commands send to the card > and return a bogus error code. However, I doubt that the latter is the > case. > > In any case, it is best to try a different reader and if possible a > different machine. Thanks to all for your answers. I had already tried on a different computer, with no success. I have a second OpenPGP card (with different keys) installed in a second reader, which still works fine on both computers. I tried the first card in the second reader; it still fails. I tried the second card in the firest reader; it works. Hence, I think my card is really dead. Anyhow, even if it?s dead, I?d love to understand how/why it happened. I see that the card includes a signature counter (which reads 89), hence I understand the card has to write the EEPROM (to update the counter) each time I perform a signature. But I think 89 is a much too low a number to wear en EEPROM. I have used my card much more for file decryption and for SSH authentication. Does the card write the EEPROM each time such an operation is performed? A rough guess is that I might have performed between 1,000 and 10,000 authentications with that card. I think it might be sufficient to wear an EEPROM. Also, the card reports 2 tries left for the PIN code, which means that my last try to unlock the unlock the pin was a failure. Did the card somehow fail updating the retry counter? (Either when I typed the wrong pin, or now when I type the right one and it tries to reset the counter to 3?) If there?s anything I can do to investigate that failure, please tell me. Cheers, -- Nicolas Boullis From p at sys4.de Tue Dec 8 10:03:50 2020 From: p at sys4.de (Patrick Ben Koetter) Date: Tue, 8 Dec 2020 10:03:50 +0100 Subject: Security-Token: "No secret key" unless "gpg --card-status" first Message-ID: <20201208090350.kopj6g746vg3jgpn@sys4.de> Greetings, my PGP secret key is stored on a Yubikey security token and until recently I would simply plug it into my computer and use it to encrypt/decrypt data. This stopped working and now all I get is this unless I command gpg first to list the card status using "gpg --card-status": $ gpg: Entschl?sselung fehlgeschlagen: Kein geheimer Schl?ssel I'm not familiar with all the components that need to play together for this to work "plug & play", so I figured I'd start here first and find out if gpg requires some change in config to let it use the security token immediately. I'm on ARCH Linux and the software installed and hardware used is: $ gpg --version gpg (GnuPG) 2.2.24 libgcrypt 1.8.7 $ ykinfo -v version: 5.1.2 $ ykman --version YubiKey Manager (ykman) version: 3.1.1 Libraries: libykpers 1.20.0 libusb 1.0.23 $ gpg --card-status Reader ...........: 1050:0407:X:0 Application ID ...: D2760001240102010006095075160000 Application type .: OpenPGP Version ..........: 2.1 Manufacturer .....: Yubico Serial number ....: 09507516 Name of cardholder: Patrick Ben Koetter Language prefs ...: [nicht gesetzt] Salutation .......: Hr. URL of public key : [nicht gesetzt] Login data .......: p at sys4.de Signature PIN ....: nicht zwingend Key attributes ...: rsa2048 rsa4096 rsa2048 Max. PIN lengths .: 127 127 127 PIN retry counter : 3 0 3 Signature counter : 0 Signature key ....: [none] Encryption key....: 74B5 --redacted-- created ....: 2014-03-28 16:28:13 Authentication key: [none] General key info..: sub rsa4096/3AB431AF62D277F5 2014-03-28 Patrick Ben Koetter

sec rsa4096/5677226BCD1FD704 erzeugt: 2014-03-28 verf?llt: niemals ssb> rsa4096/3AB431AF62D277F5 erzeugt: 2014-03-28 verf?llt: niemals Kartennummer:0006 09507516 TIA, p at rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schlei?heimer Stra?e 26/MG,80333 M?nchen Sitz der Gesellschaft: M?nchen, Amtsgericht M?nchen: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein From wk at gnupg.org Tue Dec 8 12:11:05 2020 From: wk at gnupg.org (Werner Koch) Date: Tue, 08 Dec 2020 12:11:05 +0100 Subject: Security-Token: "No secret key" unless "gpg --card-status" first In-Reply-To: <20201208090350.kopj6g746vg3jgpn@sys4.de> (Patrick Ben Koetter via Gnupg-users's message of "Tue, 8 Dec 2020 10:03:50 +0100") References: <20201208090350.kopj6g746vg3jgpn@sys4.de> Message-ID: <87wnxs5z92.fsf@wheatstone.g10code.de> On Tue, 8 Dec 2020 10:03, Patrick Ben Koetter said: > $ gpg: Entschl?sselung fehlgeschlagen: Kein geheimer Schl?ssel (gpg: decryption failed: No secret key) > $ gpg --version > gpg (GnuPG) 2.2.24 Please update to 2.2.25 because of * scd: Fix regression in 2.2.24 requiring gpg --card-status before signing or decrypting. [#5065] Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Tue Dec 8 12:21:08 2020 From: wk at gnupg.org (Werner Koch) Date: Tue, 08 Dec 2020 12:21:08 +0100 Subject: =?utf-8?Q?=E2=80=9CHardware_problem=E2=80=9D?= with OpenPGP smart card In-Reply-To: <20201207223732.GA1783@debian> (Nicolas Boullis's message of "Mon, 7 Dec 2020 23:37:32 +0100") References: <20201205142033.GB2368@debian> <1902076.7aRn1RRit1@t450> <87o8j57u1k.fsf@wheatstone.g10code.de> <20201207223732.GA1783@debian> Message-ID: <87sg8g5ysb.fsf@wheatstone.g10code.de> On Mon, 7 Dec 2020 23:37, Nicolas Boullis said: > Hence, I think my card is really dead. yeah :-( > I see that the card includes a signature counter (which reads 89), hence > I understand the card has to write the EEPROM (to update the counter) Yes, this one reason to write to the EEPROM. However, this is a way too low number for a failure. A few years ago we had a similar report and the Zeitcontrol folks did some testing. A 100000 operations were not a problem at all. From my understanding the EEPROM of the chip used by Zeitcontrol allows for much more r/w cycles than what you usually get from an average Atmel or so microcontroller. Anyway, my STM32 based Gnuk token did about 8000 signing operaion with the first key. > between 1,000 and 10,000 authentications with that card. I think it > might be sufficient to wear an EEPROM. Nope. > Also, the card reports 2 tries left for the PIN code, which means that > my last try to unlock the unlock the pin was a failure. Did the card > somehow fail updating the retry counter? (Either when I typed the wrong It failed. Smartcards handle verification by first decrementing the retry counter, running the verify, and on success incrementing the retry counter. This is so that a power glitch can't be used to trick out the retry counter. This method explains why you see 2. > If there?s anything I can do to investigate that failure, please tell > me. The card should not allow you to investigate things even after a failure. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From spam.trap.mailing.lists at gmail.com Thu Dec 10 16:11:02 2020 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Thu, 10 Dec 2020 16:11:02 +0100 Subject: Protecting your private key - passphrase Message-ID: Hi all, while playing with hashcat, diceware passphrases and entropy checkers I thought why not try to create a little program that you can input your passphrase and it gets converted to a random chars string (40 chars), based either on sha256+base91 or ripemd-160 output. The idea here is to use phrases which makes no sense but can easily been remembered and then get converted so that you always have IMHO good random input for GnuPG. For that task I created two little Golang programs which asks the user to input a phrase that makes no sense and while the user is typing in his passphrase bullets are displayed, like in pinentry, and then the random 40 chars get copied to the clipboard, so that users can paste the passphrase into GnuPG. In order that this works under Linux/Unix too you need to install xclip or xsel and don't forget to clear the clipboard after usage. Example #1 Input: Alice+eats&red+stones Output program #1: 8rW3 -------------- next part -------------- A non-text attachment was scrubbed... Name: ep_ripemd160.go Type: application/octet-stream Size: 453 bytes Desc: not available URL: From spam.trap.mailing.lists at gmail.com Thu Dec 10 17:26:50 2020 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Thu, 10 Dec 2020 17:26:50 +0100 Subject: Christmas giving In-Reply-To: References: Message-ID: Hi Robert, not sure if you have direkt contact to the GnuPG Verein, but I like to mention that Elon Musk is currently giving away again Bitcoins etc. This was posted also from his Twitter account. If the Verein would send his Bitcoin donations to him the Verein would receive back the double ammount. https://muskx.eu And another thing regarding Bitcoin donations, maybe the Verein could set up also a newer bech32 Bitcoin address, so that people having large ammounts, can anonymously send funds via Bitcoin Mixers, from within Wasabi Wallets via Tor, in case they do not want to reveil that they send funds to the Verein. Regards Stefan On Tue, Dec 1, 2020 at 1:29 AM Robert J. Hansen via Gnupg-users wrote: > > In years past I'd run a Christmas fundraiser for GnuPG. I haven't done > that recently after GnuPG received some large contributions from > corporate sponsors: but 2020 being what it is, I kind of suspect GnuPG > can use a fundraiser, so... let's go back to the classics. > > WHAT: For every euro you donate to GnuPG, I donate one euro, up to five > hundred euros. > > WHEN: From December 10 to January 6. This should cover the vast > majority of seasonal religious holidays. > > HOW: All you have to do is donate. At the end of it I'll ask Werner how > big of a donation I'm making, and once it arrives he'll confirm to the > list I've upheld my end of the deal. > > WHY: Because a great way to say "thank you for all your work, guys!" is > to donate to the GnuPG project. > > LINK: https://www.gnupg.org/cgi-bin/procdonate.cgi?mode=preset > > Merry Christmas, Happy Hanukkah, Blessed Yule and/or Solstice, Season's > Greetings, and just have yourself a nice day. :) From rjh at sixdemonbag.org Thu Dec 10 17:58:50 2020 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 10 Dec 2020 11:58:50 -0500 Subject: Christmas giving In-Reply-To: References: Message-ID: <07de5875-55ae-28cf-1524-d24f78d7e48a@sixdemonbag.org> > not sure if you have direkt contact to the GnuPG Verein, > but I like to mention that Elon Musk is currently giving away > again Bitcoins etc. This was posted also from his Twitter account. It very likely was not. https://news.bitcoin.com/spacex-bitcoin-scam-btc-giveaway-elon-musk-nasa-launch/ https://www.usatoday.com/story/tech/2020/02/03/tesla-ceo-elon-musk-bitcoin-scammers-twitter-not-cool/4650272002/ https://www.cnbc.com/2020/07/16/twitter-hackers-made-121000-in-bitcoin-analysis-shows.html These "Elon Musk is giving away bitcoin!" scams have been going on for years. Stefan, think about it for a second. Start with one bitcoin, trade it, get two back... transfer those two BTC to another account... have that account send two BTC to Musk, get four back... transfer those four to another account... send four BTC to Musk, get eight back... transfer those eight to another account, get sixteen back... cash out six BTC ( ** $111,000 USD ** ) and send ten to Musk, get twenty back... cash out ten BTC ( ** 180,000 USD **), send ten to another account, send them to Musk, get twenty back ... But wait! Once you have 10 BTC, it parallelizes. So instead of cashing out 10 BTC, you start an *entirely new* set of BTC trades. Your first 10 BTC transfer yields 20 BTC, which you then split into two 10 BTC transfers each yielding 20 BTC giving you 40. You split those into four 10-BTC transfers and... Musk, with all his billions, would literally be bankrupted in single-digit hours. Think about this stuff, Stefan. Type in "Elon Musk bitcoin" into Google before you share things like this. Don't spread scams on this mailing list. From cqcallaw at brainvitamins.net Thu Dec 10 18:21:31 2020 From: cqcallaw at brainvitamins.net (cqcallaw) Date: Thu, 10 Dec 2020 17:21:31 +0000 Subject: Christmas giving In-Reply-To: References: Message-ID: Ah, the Elon Musk crypto scams. We really ought to preserve these as part of Internet history :) ??????? Original Message ??????? On Thursday, December 10, 2020 8:26 AM, Stefan Claas via Gnupg-users wrote: > Hi Robert, > > not sure if you have direkt contact to the GnuPG Verein, > but I like to mention that Elon Musk is currently giving away > again Bitcoins etc. This was posted also from his Twitter account. > > If the Verein would send his Bitcoin donations to him the Verein > would receive back the double ammount. > > https://muskx.eu > > And another thing regarding Bitcoin donations, maybe the Verein > could set up also a newer bech32 Bitcoin address, so that people > having large ammounts, can anonymously send funds via Bitcoin > Mixers, from within Wasabi Wallets via Tor, in case they do not > want to reveil that they send funds to the Verein. > > Regards > Stefan > > On Tue, Dec 1, 2020 at 1:29 AM Robert J. Hansen via Gnupg-users > gnupg-users at gnupg.org wrote: > > > In years past I'd run a Christmas fundraiser for GnuPG. I haven't done > > that recently after GnuPG received some large contributions from > > corporate sponsors: but 2020 being what it is, I kind of suspect GnuPG > > can use a fundraiser, so... let's go back to the classics. > > WHAT: For every euro you donate to GnuPG, I donate one euro, up to five > > hundred euros. > > WHEN: From December 10 to January 6. This should cover the vast > > majority of seasonal religious holidays. > > HOW: All you have to do is donate. At the end of it I'll ask Werner how > > big of a donation I'm making, and once it arrives he'll confirm to the > > list I've upheld my end of the deal. > > WHY: Because a great way to say "thank you for all your work, guys!" is > > to donate to the GnuPG project. > > LINK: https://www.gnupg.org/cgi-bin/procdonate.cgi?mode=preset > > Merry Christmas, Happy Hanukkah, Blessed Yule and/or Solstice, Season's > > Greetings, and just have yourself a nice day. :) > > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From rjh at sixdemonbag.org Thu Dec 10 18:33:03 2020 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 10 Dec 2020 12:33:03 -0500 Subject: Christmas giving In-Reply-To: References: Message-ID: <8e8e1a4d-d3db-14ee-b223-cf34361b785e@sixdemonbag.org> > Ah, the Elon Musk crypto scams. We really ought to preserve these as part of Internet history :) I have great sympathy and compassion for people snookered in by such scams, but not when they claim to be part of the information security community. These BTC scams are obvious nonsense to anyone with a glimmer of security awareness. "If it were true he would already be bankrupt, he is not bankrupt, therefore it is not true" ain't hard logic to work through. From casey.marshall at gmail.com Thu Dec 10 18:07:00 2020 From: casey.marshall at gmail.com (Casey Marshall) Date: Thu, 10 Dec 2020 11:07:00 -0600 Subject: [Keyserver] Hockeypuck 2.1.0 released Message-ID: I've released Hockeypuck 2.1.0 [0], which contains several new features that may be useful to mitigate spamming/flooding/DoS [1] attacks on GnuPG and keyservers. See the release link for details, but here's the highlights: - Configurable key length and packet size limits, with sensible defaults to limit keyserver resource consumption (1MB and 8K respectively). - Configurable blacklist of primary key fingerprints. - Authenticated key management. This adds a couple of extra endpoints which allow a key owner to replace and delete their key, authenticated by signing the armored key in the request. This allows a key owner to still update their own key once it has been inflated beyond the key length limit. Blacklists and auth key management may also be of interest to keyserver operators subject to GDPR-related requests. -Casey [0] https://github.com/hockeypuck/hockeypuck/releases/tag/2.1.0 [1] https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f -------------- next part -------------- An HTML attachment was scrubbed... URL: From spam.trap.mailing.lists at gmail.com Thu Dec 10 20:32:18 2020 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Thu, 10 Dec 2020 20:32:18 +0100 Subject: Christmas giving In-Reply-To: <07de5875-55ae-28cf-1524-d24f78d7e48a@sixdemonbag.org> References: <07de5875-55ae-28cf-1524-d24f78d7e48a@sixdemonbag.org> Message-ID: Ouch, STUPID ME! I had better checked Twitter, after seen the fake tweet image, which linked to this site ... :-( Appologies! Regards Stefan [...] > Think about this stuff, Stefan. Type in "Elon Musk bitcoin" into Google > before you share things like this. Don't spread scams on this mailing list. From andrewg at andrewg.com Thu Dec 10 20:59:46 2020 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 10 Dec 2020 19:59:46 +0000 Subject: [Keyserver] Hockeypuck 2.1.0 released In-Reply-To: References: Message-ID: How do you handle the gradual degradation of sync as different operators implement divergent blacklists? A On 10/12/2020 17:07, Casey Marshall wrote: > I've released Hockeypuck 2.1.0 > ?[0], which > contains several new features that may be useful to mitigate > spamming/flooding/DoS [1] attacks on GnuPG and keyservers. See the > release link for details, but here's the highlights: > > * Configurable key length and packet size limits, with sensible > defaults to limit keyserver resource consumption (1MB and 8K > respectively). > * Configurable blacklist of primary key fingerprints. > * Authenticated key management. This adds a couple of extra endpoints > which allow a key owner to replace and delete their key, > authenticated by signing the armored key in the request. This allows > a key owner to still update their own key once it has been inflated > beyond the key length limit. > > Blacklists and auth key management may also be of interest to keyserver > operators subject to GDPR-related requests. > > > -Casey > > > [0] https://github.com/hockeypuck/hockeypuck/releases/tag/2.1.0 > > > [1] https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f > > -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From heiko.carrasco at yahoo.com Thu Dec 10 11:57:53 2020 From: heiko.carrasco at yahoo.com (Heiko Carrasco) Date: Thu, 10 Dec 2020 11:57:53 +0100 Subject: Smartcard not initialized automatically on GnuPG 2.2.24 References: <20201210105753.yfqkvs6z5aeim7w7.ref@meltdown> Message-ID: <20201210105753.yfqkvs6z5aeim7w7@meltdown> Hello, I recently got the "new" version of GnuPG 2.2.24 through my distribution and noticed some form of bug together with my smartcard. When I attempt to use gpg to decrypt something I get the following error: $ gpg -d test.gpg gpg: encrypted with 4096-bit RSA key, ID 1632F70C0F463100, created 2015-08-24 "Heiko Carrasco gpg: public key decryption failed: Invalid ID gpg: decryption failed: No secret key I have to manually run some command which interacts with the smartcard such as gpg --card-status for it to show a pinentry to enter my smartcard pin. This was not the case with 2.2.23, which automatically asks me for my pin when executing the above command. There wasn't anything regarding this in the changelog as far as I can see, so this might be a bug? Cheers, Heiko -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From kloecker at kde.org Thu Dec 10 22:51:46 2020 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Thu, 10 Dec 2020 22:51:46 +0100 Subject: Smartcard not initialized automatically on GnuPG 2.2.24 In-Reply-To: <20201210105753.yfqkvs6z5aeim7w7@meltdown> References: <20201210105753.yfqkvs6z5aeim7w7.ref@meltdown> <20201210105753.yfqkvs6z5aeim7w7@meltdown> Message-ID: <2685600.N1zbqk4GF1@breq> On Donnerstag, 10. Dezember 2020 11:57:53 CET Heiko Carrasco via Gnupg-users wrote: > I recently got the "new" version of GnuPG 2.2.24 through my distribution > and noticed some form of bug together with my smartcard. It's a regression. It has already been fixed. See below. You could ask your distribution to quickly update to GnuPG 2.2.25. > When I attempt to use gpg to decrypt something I get the following > error: > $ gpg -d test.gpg > gpg: encrypted with 4096-bit RSA key, ID 1632F70C0F463100, created > 2015-08-24 "Heiko Carrasco > gpg: public key decryption failed: Invalid ID > gpg: decryption failed: No secret key >From the release notes for GnuPG 2.2.25 ([1]): ===== Noteworthy changes in version 2.2.25 ==================================== * scd: Fix regression in 2.2.24 requiring gpg --card-status before signing or decrypting. [#5065] ===== Regards, Ingo [1] https://lists.gnupg.org/pipermail/gnupg-announce/2020q4/000450.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: From casey.marshall at gmail.com Fri Dec 11 06:11:10 2020 From: casey.marshall at gmail.com (Casey Marshall) Date: Thu, 10 Dec 2020 23:11:10 -0600 Subject: [Keyserver] Hockeypuck 2.1.0 released (Andrew Gallagher) Message-ID: > > Date: Thu, 10 Dec 2020 19:59:46 +0000 > From: Andrew Gallagher > To: SKS Development and Deployment discussion , > GnuPG Users > Subject: Re: [Keyserver] Hockeypuck 2.1.0 released > Message-ID: > Content-Type: text/plain; charset="utf-8"; Format="flowed" > How do you handle the gradual degradation of sync as different operators > implement divergent blacklists? > This might be a controversial opinion, but I would allow it to happen. Even if reconciliation cannot provide perfect consistency in such a world, it is still useful as a gossip protocol to distribute new keys and signatures. My prediction (given keyserver operator buy-in) is, some cohorts of like-minded keyserver operators will coordinate on their settings. Peers in these cohorts will keep relatively more closely in sync and propagate key material faster amongst themselves, than with those that have different policies that cause them to diverge more widely. Peers across these more divergent cohorts may still peer at a lower frequency, so key material accepted by both may still propagate. -Casey A > On 10/12/2020 17:07, Casey Marshall wrote: > > I've released Hockeypuck 2.1.0 > > [0], which -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrewg at andrewg.com Fri Dec 11 08:52:12 2020 From: andrewg at andrewg.com (Andrew Gallagher) Date: Fri, 11 Dec 2020 07:52:12 +0000 Subject: [Keyserver] Hockeypuck 2.1.0 released (Andrew Gallagher) In-Reply-To: References: Message-ID: <3DC31234-288D-4F63-AB36-239C4A816A1B@andrewg.com> > On 11 Dec 2020, at 05:11, Casey Marshall via Gnupg-users wrote: > > Peers across these more divergent cohorts may still peer at a lower frequency, so key material accepted by both may still propagate. But the problem with divergence isn?t loss of efficiency - divergent servers don?t gracefully degrade. They work perfectly fine until they hit the polynomial limit, and then they just break. And they break in a way that requires reloading the entire database from scratch. A From wk at gnupg.org Fri Dec 11 11:23:19 2020 From: wk at gnupg.org (Werner Koch) Date: Fri, 11 Dec 2020 11:23:19 +0100 Subject: [Keyserver] Hockeypuck 2.1.0 released In-Reply-To: (Casey Marshall via Gnupg-users's message of "Thu, 10 Dec 2020 11:07:00 -0600") References: Message-ID: <87sg8c4p60.fsf@wheatstone.g10code.de> On Thu, 10 Dec 2020 11:07, Casey Marshall said: > - Authenticated key management. This adds a couple of extra endpoints > which allow a key owner to replace and delete their key, authenticated by > signing the armored key in the request. This allows a key owner to still > update their own key once it has been inflated beyond the key Finally after more than 20 years waiting for someone to implement such a feature. Yeah. Where can I find the specs? Did you consider that an authenticated request to delete a key may not actually remove the key from the keyserver? Instead the the primary key should be kept and the server prepared to receive and merge even unauthenticated revocation certificates. This is important in case of a lost key (or passphrase forgotten) so that a pre-created revocation certificate can be uploaded. Also avoids DoS after a key compromise. > Blacklists and auth key management may also be of interest to keyserver Still revocation certificates should get through. At least the first valid revocation certificate needs to be handles before the key can be set into an eternal non-modifiable state. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From informatik at semy.ch Fri Dec 11 12:06:40 2020 From: informatik at semy.ch (Daniel Bossert) Date: Fri, 11 Dec 2020 12:06:40 +0100 Subject: No v3 keys allowed Message-ID: <20201211120640.d2786d72e5e3ec00f0eda293@semy.ch> Hello all When uploading a key to keyserver.pgp.com I get the message that no V3 keys are allowed. How that? I took gpg2 with expert option and 22519 algorithm. How can I create a v4 key? Kind regards Daniel -- PGP: 81A8 1EC7 179C BE5F 02A8 2C01 3FF1 07B6 FC68 F10A -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From rjh at sixdemonbag.org Fri Dec 11 12:57:03 2020 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 11 Dec 2020 06:57:03 -0500 Subject: No v3 keys allowed In-Reply-To: <20201211120640.d2786d72e5e3ec00f0eda293@semy.ch> References: <20201211120640.d2786d72e5e3ec00f0eda293@semy.ch> Message-ID: > How can I create a v4 key? v3 keys are the kind generated by PGP 2.6.2, dating from the early 1990s. You certainly created a v4 key. Another strong hint comes from your key fingerprint, which is a v4-style 160-bit hash. v3 keys overwhelmingly used 128-bit hashes. My suspicion is that keyserver.pgp.com doesn't support elliptical curve keys, and when it throws an error it has half-assed error handling that assumes "if I couldn't import the key it must've been a v3 key." From spam.trap.mailing.lists at gmail.com Fri Dec 11 18:56:24 2020 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Fri, 11 Dec 2020 17:56:24 +0000 Subject: [Keyserver] Hockeypuck 2.1.0 released In-Reply-To: <87sg8c4p60.fsf@wheatstone.g10code.de> References: <87sg8c4p60.fsf@wheatstone.g10code.de> Message-ID: On Fri, Dec 11, 2020 at 10:25 AM Werner Koch wrote: > > On Thu, 10 Dec 2020 11:07, Casey Marshall said: > > > - Authenticated key management. This adds a couple of extra endpoints > > which allow a key owner to replace and delete their key, authenticated by > > signing the armored key in the request. This allows a key owner to still > > update their own key once it has been inflated beyond the key > > Finally after more than 20 years waiting for someone to implement such a > feature. Yeah. Where can I find the specs? > > Did you consider that an authenticated request to delete a key may not > actually remove the key from the keyserver? Instead the the primary key > should be kept and the server prepared to receive and merge even > unauthenticated revocation certificates. This is important in case of a > lost key (or passphrase forgotten) so that a pre-created revocation > certificate can be uploaded. Also avoids DoS after a key compromise. Hi Werner and Casey, I have a question for both of you. When I reported a while ago on GitHub about a fake uat packet on Werner's key you quickly fixed the issue and the added image of 'Donnie' no longer showed up at the Ubuntu keyserver. Interestingly now GitHub shows zero issues as of today, while yesterday still some issues where open and a lot of them closed. Now my second question how is/was this done with Werner's key? SKS still shows Werner's key with signatures, while the Ubuntu keyserver shows only a very small key now. Before that the Ubuntu key server showed the sigs too and additionally the fake uat packet (Donnie image). Does this mean that a GnuPG user can modify his key in such a way and re-submit it, so that the result is now like Werner's key or can a Hockerpuck operator do this (on behalf) of the key owner? The key in question, on the Ubuntu keyserver has also no longer a UID, which I thought only sequoia-pgp can handle and not GnuPG. https://keyserver.ubuntu.com/pks/lookup?search=0x7b96d396e6471601754be4db53b620d01ce0c630&fingerprint=on&op=vindex http://keys2.andreas-puls.de:11371/pks/lookup?search=0x7b96d396e6471601754be4db53b620d01ce0c630&fingerprint=on&op=vindex Regards Stefan From nicolas.boullis at ecp.fr Sat Dec 12 16:29:55 2020 From: nicolas.boullis at ecp.fr (Nicolas Boullis) Date: Sat, 12 Dec 2020 16:29:55 +0100 Subject: Best practice to use several smartcards for a single key? Message-ID: <20201212152955.GE10813@debian> Hi, Since the smartcard that held all my subkeys died, I have to replace my subkeys, and I?m willing to store them on several smartcards, just in case I am unlucky again? I wonder whether I should the same subkey or different subkeys on different smartcards. As far as I understand it, for encryption, if I have several encryption subkeys, people who send me encrypted messages will encrypt for single subkey. Hence, if I want to be able to decrypt the message with any smartcard, then I have to use a single subkey that is held by all smartcards. As for signature subkeys, as I understand it, there is no problem with using several distinct subkeys, so I can sign with the one that is available, and people who verify the signature will accept any subkey. Moreover, if a smartcard is lost/stolen, I can revoke its signature subkey. As for the authentication subkeys (that I use for SSH connection), it behaves like the signature subkeys, except that I have to explicitly allow each subkey on all machine that I want to connect to. Any opinion on this? As a bonus question: given that my ?master? private key is also stored on a smartcard, is there a way to ask GnuPG to generate a signature subkey on a second smartcard, while signing it with the first smartcard? Or do I have to first generate it in software and sign it with the first smartcard, and then export it to the second smartcard? Best regards, -- Nicolas From gnupg at eckner.net Sat Dec 12 17:03:56 2020 From: gnupg at eckner.net (Erich Eckner) Date: Sat, 12 Dec 2020 17:03:56 +0100 (CET) Subject: Best practice to use several smartcards for a single key? In-Reply-To: <20201212152955.GE10813@debian> References: <20201212152955.GE10813@debian> Message-ID: <4cbf2f-843d-17b8-a821-7990a3b4ed9@eckner.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Sat, 12 Dec 2020, Nicolas Boullis wrote: > Hi, Hi Nicolas, > > Since the smartcard that held all my subkeys died, I have to replace my > subkeys, and I?m willing to store them on several smartcards, just in > case I am unlucky again? [ ... snip ... ] > Any opinion on this? Sry to not answer your question(s), but: I believe, the common way is to use *one* smart card and backup the keys on paper (or any other offline storage, like a usb thumb drive lying in some shoe box). [ ... snip ... ] > Best regards, > > -- > Nicolas regards, Erich -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAl/U6e4ACgkQCu7JB1Xa e1r4qQ//Ykkk7x83Hkq+AJuxtTVkh1HWtSR9DrgDboKSz693uJvkpL4ISIG/xnsn oSqePGtQ0ZcspnF0+vLTjCku8RyJUKf1XCUcq+n/iMqfJBp3hpzMhQm77/IRe/rj O5AtINfq2cYPcVHjTh3/MvUJoW6nkwW4LCCjg/7rxvQhKtqOX+SkD/x9XvCm4cMP PPU/Awb6Kpj8rwaXQJCFyLTYHdWGjIBIZFrevi9yhjCoFDHxMVwtlRHEX0r/GK5A b8CdV1wQE1mMX0tLYrEjPhwwIjQ/EEYQytaNEkIZ5I8Sbt+RgwSfHrjRealHQpwr aedwHyklpRpX4glQqzEiV5AYmadLQ+1V+KDUUO7texKoVmRyn8xOqAMbC659mYiw p5v8uE+mCu7V8WRBiDF0c0yk88Tplrkz3tRxRRToXAByqqQf7wAYBhTdP9wnMW++ nnzmpnhY7TZ0Vh43/fc1CjULYb0tOrMSxuCq9jHKwrGI0fg3ED9zpq+ZZR/ZzkF2 24phqnA8PuSLEQ0yK11ZRjpQcH64a9Fb5KTm7dwgVQFU3dnsacYdHGw4qVVYD+CI GYsaLCuioUar9jTgBp+4sfDPb79rBbnMJFDPUKeXZT+r/M8cmM+HP3nYPNi54Viv KPQXTeHpihWFRLjlIpPLLdIj0Cto2l+ZwkoXDja7uKQhyxQZtxk= =kZaw -----END PGP SIGNATURE----- From kloecker at kde.org Sat Dec 12 18:45:46 2020 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Sat, 12 Dec 2020 18:45:46 +0100 Subject: Best practice to use several smartcards for a single key? In-Reply-To: <20201212152955.GE10813@debian> References: <20201212152955.GE10813@debian> Message-ID: <4339715.UpiRXEjXS1@breq> On Samstag, 12. Dezember 2020 16:29:55 CET Nicolas Boullis wrote: > Since the smartcard that held all my subkeys died, I have to replace my > subkeys, and I?m willing to store them on several smartcards, just in > case I am unlucky again? > > I wonder whether I should the same subkey or different subkeys on > different smartcards. I see little reason for setting up a second smartcard for subkeys as disaster recovery backup for the first smartcard. Reasoning below: > As far as I understand it, for encryption, if I have several encryption > subkeys, people who send me encrypted messages will encrypt for single > subkey. Yes, unless they explicitly specify multiple subkeys gpg will use the most recently created valid encryption subkey. > Hence, if I want to be able to decrypt the message with any > smartcard, then I have to use a single subkey that is held by all > smartcards. Yes, but why a second smartcard? The reason for making a backup of the encryption (sub)key is that this will allow you to decrypt messages even if the smartcard dies. But if your second smartcard also dies, then all is lost ... unless you have an off-card backup of the private encryption key. But this off-card backup would allow you to create a new smartcard _after_ the first smartcard dies. So, instead of setting up two smartcards with identical encryption keys I suggest to save the money for the second smartcard and instead create an off-card backup of the private encryption key that you store somewhere safe (see Erich's mail). > As for signature subkeys, as I understand it, there is no problem with > using several distinct subkeys, so I can sign with the one that is > available, and people who verify the signature will accept any subkey. > Moreover, if a smartcard is lost/stolen, I can revoke its signature > subkey. Yes, but what purpose serves the second smartcard? Again, you can easily setup a replacement smartcard _after_ the first smartcard dies. Typically, you would create the signature (sub)key on-card to avoid any risk of compromise of the private key. > As for the authentication subkeys (that I use for SSH connection), it > behaves like the signature subkeys, except that I have to explicitly > allow each subkey on all machine that I want to connect to. Yes, for the authentication use case setting up a second smartcard does make sense because otherwise you'd lose access to the machines if the first smartcard dies. But you could as well keep an off-card backup of the authentication key. Or you could create a second "master" authentication key off-card and store it somewhere safe. One argument for using a second smartcard instead is to avoid any risk of compromise of the private authentication keys. > As a bonus question: given that my ?master? private key is also stored > on a smartcard, is there a way to ask GnuPG to generate a signature > subkey on a second smartcard, while signing it with the first smartcard? Yes, but only with the unreleased development version of GnuPG. With 2.2.25 trying to add a subkey from an existing key from card failed here. There have been quite some fixes with regard to smartcard support in the development version in the last few weeks. What I did: Remove the first smartcard. Insert the second smartcard. Then $ gpg --edit-key master at example.net gpg (GnuPG) 2.3.0-beta1490; Copyright (C) 2020 Free Software Foundation, Inc. [...] sec ed25519/B16F599516474ABA created: 2020-08-03 expires: 2022-08-03 usage: SC card-no: [s/n of first card] trust: ultimate validity: ultimate sub cv25519/2BBE9540CAF56DC9 created: 2020-08-03 expires: never usage: E [ultimate] (1). master at example.net gpg> addkey Secret parts of primary key are stored on-card. Please select what kind of key you want: (3) DSA (sign only) (4) RSA (sign only) (5) Elgamal (encrypt only) (6) RSA (encrypt only) (10) ECC (sign only) (12) ECC (encrypt only) (14) Existing key from card Your selection? 14 Serial number of the card: D2760001240100000006090745820000 Available keys: (1) 930509C5F5BD42B2ABCB4C7BDC2FD64BE59086CE OPENPGP.1 rsa2048 (cert,sign*) (2) AEA62514505EBDDB4C2FF8AF27B02F221ECAFBCE OPENPGP.2 rsa2048 (encr*) (3) 56EBCBEEA72DBF1BFAFE583F7FF36CBCB895C265 OPENPGP.3 rsa2048 (sign,auth*) Your selection? 1 Please specify how long the key should be valid. 0 = key does not expire = key expires in n days w = key expires in n weeks m = key expires in n months y = key expires in n years Key is valid for? (0) Key does not expire at all Is this correct? (y/N) y Really create? (y/N) y -> "Please insert the card with serial number: [s/n of first card]" -> "Please unlock the card" [s/n of first card] -> "Please unlock the card" [s/n of second card] sec ed25519/B16F599516474ABA created: 2020-08-03 expires: 2022-08-03 usage: SC card-no: [s/n of first card] trust: ultimate validity: ultimate sub cv25519/2BBE9540CAF56DC9 created: 2020-08-03 expires: never usage: E ssb rsa2048/06B697821DAABF4B created: 2020-12-04 expires: never usage: S card-no: [s/n of first [sic] card] <-- This is a bug. [ultimate] (1). master at example.net gpg> save Now let's try to sign (and immediately verify) something. $ gpg --clearsign | gpg --verify bla ^D -> "Please insert the card with serial number: [s/n of first [sic] card]" -> I insert the second (!) card -> "Please unlock the card" [s/n of second card] gpg: Signature made Sa 12 Dez 2020 18:35:47 CET gpg: using RSA key AF440A8368A6C258DB22AC2C06B697821DAABF4B gpg: Good signature from "master at example.net" [ultimate] -> Success! Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: From nicolas.boullis at ecp.fr Sun Dec 13 12:06:21 2020 From: nicolas.boullis at ecp.fr (Nicolas Boullis) Date: Sun, 13 Dec 2020 12:06:21 +0100 Subject: Best practice to use several smartcards for a single key? In-Reply-To: <4339715.UpiRXEjXS1@breq> References: <20201212152955.GE10813@debian> <4339715.UpiRXEjXS1@breq> Message-ID: <20201213110621.GA1662@debian> Hi, Thanks to you and Erich for your answers. On Sat, Dec 12, 2020 at 06:45:46PM +0100, Ingo Kl?cker wrote: > > > As far as I understand it, for encryption, if I have several encryption > > subkeys, people who send me encrypted messages will encrypt for single > > subkey. > > Yes, unless they explicitly specify multiple subkeys gpg will use the most > recently created valid encryption subkey. I guess I hould better not expect others to do so. ;-) > Yes, but why a second smartcard? The reason for making a backup of the > encryption (sub)key is that this will allow you to decrypt messages even if > the smartcard dies. But if your second smartcard also dies, then all is lost > ... unless you have an off-card backup of the private encryption key. But this > off-card backup would allow you to create a new smartcard _after_ the first > smartcard dies. So, instead of setting up two smartcards with identical > encryption keys I suggest to save the money for the second smartcard and > instead create an off-card backup of the private encryption key that you store > somewhere safe (see Erich's mail). To be honnest, I don?t feel comfortable with storing an off-card backup of my private encryption card. My inner feeling is that it defeats the point of using a smartcard: if someone finds it, it can easily be copied (without me knowing it was copied) and it is protected with a passphrase with limited entropy (because I can?t remember a random 128-bit number). My idea was that there was little chance that a smartcard fails (Werner Koch told me that the failure I experienced was exceptionnal) and if it does I can set up a new encryption key and, using the second smartcard, decrypt all the files that were encrypted for the old key and re-encrypt them for the new key. Another idea would be to encrypt the off-card backup of the encryption key with the encryption key. I think it would be safer than having it protected with a passphrase. Then, if a smartcard fails, I get a new one, and then use the second smartcard to decrypt the off-card backup and then send it to the new card. > Yes, but what purpose serves the second smartcard? Again, you can easily setup > a replacement smartcard _after_ the first smartcard dies. Typically, you would > create the signature (sub)key on-card to avoid any risk of compromise of the > private key. I agree that there is no problem with creating a replacement signature subkey after the previous one failed. But if I use two smartcards to store the encryption subkey, I think I should better use both (so I can detect if one fails), and then it seems to me it would be more comfortable to also have a sigature subkey on each. > > As a bonus question: given that my ?master? private key is also stored > > on a smartcard, is there a way to ask GnuPG to generate a signature > > subkey on a second smartcard, while signing it with the first smartcard? > > Yes, but only with the unreleased development version of GnuPG. With 2.2.25 > trying to add a subkey from an existing key from card failed here. There have > been quite some fixes with regard to smartcard support in the development > version in the last few weeks. > > What I did: > Remove the first smartcard. Insert the second smartcard. Then > $ gpg --edit-key master at example.net > gpg (GnuPG) 2.3.0-beta1490; Copyright (C) 2020 Free Software Foundation, Inc. > [...] > sec ed25519/B16F599516474ABA > created: 2020-08-03 expires: 2022-08-03 usage: SC > card-no: [s/n of first card] > trust: ultimate validity: ultimate > sub cv25519/2BBE9540CAF56DC9 > created: 2020-08-03 expires: never usage: E > [ultimate] (1). master at example.net > > gpg> addkey > Secret parts of primary key are stored on-card. > Please select what kind of key you want: > (3) DSA (sign only) > (4) RSA (sign only) > (5) Elgamal (encrypt only) > (6) RSA (encrypt only) > (10) ECC (sign only) > (12) ECC (encrypt only) > (14) Existing key from card > Your selection? 14 > Serial number of the card: D2760001240100000006090745820000 > Available keys: > (1) 930509C5F5BD42B2ABCB4C7BDC2FD64BE59086CE OPENPGP.1 rsa2048 (cert,sign*) > (2) AEA62514505EBDDB4C2FF8AF27B02F221ECAFBCE OPENPGP.2 rsa2048 (encr*) > (3) 56EBCBEEA72DBF1BFAFE583F7FF36CBCB895C265 OPENPGP.3 rsa2048 (sign,auth*) > Your selection? 1 > Please specify how long the key should be valid. > 0 = key does not expire > = key expires in n days > w = key expires in n weeks > m = key expires in n months > y = key expires in n years > Key is valid for? (0) > Key does not expire at all > Is this correct? (y/N) y > Really create? (y/N) y > -> "Please insert the card with serial number: [s/n of first card]" > -> "Please unlock the card" [s/n of first card] > -> "Please unlock the card" [s/n of second card] Do these step work if I have both cards inserted (in 2 readers) or would I have to remove one card to insert the other one? > sec ed25519/B16F599516474ABA > created: 2020-08-03 expires: 2022-08-03 usage: SC > card-no: [s/n of first card] > trust: ultimate validity: ultimate > sub cv25519/2BBE9540CAF56DC9 > created: 2020-08-03 expires: never usage: E > ssb rsa2048/06B697821DAABF4B > created: 2020-12-04 expires: never usage: S > card-no: [s/n of first [sic] card] <-- This is a bug. > [ultimate] (1). master at example.net > > gpg> save > > Now let's try to sign (and immediately verify) something. > $ gpg --clearsign | gpg --verify > bla > ^D > -> "Please insert the card with serial number: [s/n of first [sic] card]" > -> I insert the second (!) card Hmmm? That?s a funny bug? You mean gnupg asks for the first card, but it needs and accepts the second one? Just curious, do you know how this is possible? I might understand that it could store the wrong s/n is the subkey stub, but why does it accept the card whose s/n does not match? Can?t you then fix this by deleting the stub and then learning the second card? > -> "Please unlock the card" [s/n of second card] > gpg: Signature made Sa 12 Dez 2020 18:35:47 CET > gpg: using RSA key AF440A8368A6C258DB22AC2C06B697821DAABF4B > gpg: Good signature from "master at example.net" [ultimate] > > -> Success! Thanks for the explanation about that incoming feature. It looks great! :-) Cheers, -- Nicolas From kloecker at kde.org Sun Dec 13 22:10:34 2020 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Sun, 13 Dec 2020 22:10:34 +0100 Subject: Best practice to use several smartcards for a single key? In-Reply-To: <20201213110621.GA1662@debian> References: <20201212152955.GE10813@debian> <4339715.UpiRXEjXS1@breq> <20201213110621.GA1662@debian> Message-ID: <5093798.UbVZ3xmZVd@breq> On Sonntag, 13. Dezember 2020 12:06:21 CET Nicolas Boullis wrote: > > > As a bonus question: given that my ?master? private key is also stored > > > on a smartcard, is there a way to ask GnuPG to generate a signature > > > subkey on a second smartcard, while signing it with the first smartcard? > > > > Yes, but only with the unreleased development version of GnuPG. With > > 2.2.25 > > trying to add a subkey from an existing key from card failed here. There > > have been quite some fixes with regard to smartcard support in the > > development version in the last few weeks. > > > > What I did: > > Remove the first smartcard. Insert the second smartcard. Then > > $ gpg --edit-key master at example.net [...] > > -> "Please insert the card with serial number: [s/n of first card]" > > -> "Please unlock the card" [s/n of first card] > > -> "Please unlock the card" [s/n of second card] > > Do these step work if I have both cards inserted (in 2 readers) or would > I have to remove one card to insert the other one? Both cards were inserted after I was asked to insert the first card. I have not tried the above with both cards inserted from the start. Even if it works, I think it's easier if at first you only insert the second card (i.e. the card with the key you want to add as signing subkey) because it will make the selection of the key from the list of available keys easier. > > -> "Please insert the card with serial number: [s/n of first [sic] card]" > > -> I insert the second (!) card > > Hmmm? That?s a funny bug? > You mean gnupg asks for the first card, but it needs and accepts the > second one? > Just curious, do you know how this is possible? > I might understand that it could store the wrong s/n is the subkey stub, > but why does it accept the card whose s/n does not match? The request to enter a certain card is merely a hint (in this case a bogus hint) for the user. gpg will look for the key on any inserted card regardless of what card it asked for. The key is uniquely identified by its keygrip (use --with-keygrip to see it on --list[-secret]-keys), the s/n of the card doesn't matter. > Can?t you then fix this by deleting the stub and then learning the > second card? Maybe, but I'd rather make sure that the bug is fixed. ;-) Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: From spam.trap.mailing.lists at gmail.com Sun Dec 13 22:20:04 2020 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Sun, 13 Dec 2020 22:20:04 +0100 Subject: Protecting your private key - passphrase In-Reply-To: References: Message-ID: I will release tomorrow, if time permits, the GUI based versions, on GitHUb, created with the help of the fyne toolkit. https://ibb.co/rxYcXvq Regards Stefan On Thu, Dec 10, 2020 at 4:11 PM Stefan Claas wrote: > > Hi all, > > while playing with hashcat, diceware passphrases and entropy > checkers I thought why not try to create a little program that > you can input your passphrase and it gets converted to a random > chars string (40 chars), based either on sha256+base91 or > ripemd-160 output. > > The idea here is to use phrases which makes no sense but > can easily been remembered and then get converted so that > you always have IMHO good random input for GnuPG. > > For that task I created two little Golang programs which > asks the user to input a phrase that makes no sense and > while the user is typing in his passphrase bullets are > displayed, like in pinentry, and then the random 40 chars > get copied to the clipboard, so that users can paste > the passphrase into GnuPG. > > In order that this works under Linux/Unix too you need > to install xclip or xsel and don't forget to clear the > clipboard after usage. > > Example #1 > > Input: Alice+eats&red+stones > > Output program #1: 8rW3 Output program #2 a6a549d45f1e5c3fabfba37003541c3fa7f26d13 > > Exampl #2 > > Input: gr?ne-F?chse-fliegen#weich (= green-foxes-flying#soft) > > Output program #1: $j{hDH!5m4O[9JcPVBbHLlM^]R]RJ%yJoPr:IxAD > Output program #2: 89216958ceed145dd03a6d23afa7ae93b27457e9 > > Example #3 > > Input mixed languages question: has*Bob*deutsche*???s? > > Output program #1 fq7Mr469cU#d%uOIX?zG?:^@^y[n152_OUvp8|gB > Output program #2 9f770781c96d72b9974421ea72b523c019714a1f > > Hope you like the idea and maybe others come up with better > solutions. > > Attached are the two programs as Golang source code. > > Please note I am only noodling around with Golang and I am > not a programmer! > > Regards > Stefan > > Resources: > > https://www.gnupg.org/gph/en/manual/c481.html > https://www.armourinfosec.com/password-cracking-with-hashcat/ > http://passwordstrengthcalculator.com/index.php > http://rumkin.com/tools/password/passchk.php From andrewg at andrewg.com Sun Dec 13 22:22:44 2020 From: andrewg at andrewg.com (Andrew Gallagher) Date: Sun, 13 Dec 2020 21:22:44 +0000 Subject: Best practice to use several smartcards for a single key? In-Reply-To: <20201213110621.GA1662@debian> References: <20201213110621.GA1662@debian> Message-ID: <9AE37DA2-0E50-46CD-8F16-05C4D55B3BDF@andrewg.com> > On 13 Dec 2020, at 11:08, Nicolas Boullis wrote: > > My idea was that there was little chance that a smartcard fails (Werner > Koch told me that the failure I experienced was exceptionnal) and if it > does I can set up a new encryption key and, using the second smartcard, > decrypt all the files that were encrypted for the old key and re-encrypt > them for the new key. How are you going to decrypt the old files if your old smartcard is already dead? If you don?t want to lose all access to your encrypted files, you *must* keep a backup of your encryption key material at the very least. There is no recovering from a deleted encryption private key. I keep my key material on a Tails encrypted partition in a safe place. Alternatively you could keep a paper backup in a safe place. But there?s no getting around having some form of backup. What amounts to a ?safe place? depends on your threat model of course... A From kloecker at kde.org Sun Dec 13 22:46:43 2020 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Sun, 13 Dec 2020 22:46:43 +0100 Subject: Protecting your private key - passphrase In-Reply-To: References: Message-ID: <1661444.SRP0WcWmkE@breq> On Sonntag, 13. Dezember 2020 22:20:04 CET Stefan Claas via Gnupg-users wrote: > I will release tomorrow, if time permits, the GUI based versions, > on GitHUb, created with the help of the fyne toolkit. I'm sorry, but in my opinion this is snake oil. If you think that you can increase entropy ("randomness") by hashing a passphrase a user came up with, then you should really take a basic course on information theory. If the user comes up with an easy-to-guess passphrase and runs it through your program, then s:he will get a hashed easy-to-guess passphrase with a little bit security-by-obscurity sugar on top. But this doesn't add any real security. It only adds complexity (which often means less security; I mean you are putting the passphrase on the clipboard from where it can be grabbed by any other application) because now one needs to use two programs to decrypt something. First your program to calculate the actual passphrase to feed into gpg and then gpg to perform the actual decryption. Why do you think you need "good random input for GnuPG"? GnuPG does have a state-of-the-art key derivation function. If people want to generate a secure random passphrase for gpg, then they should use a secure password generator. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: From spam.trap.mailing.lists at gmail.com Sun Dec 13 23:11:19 2020 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Sun, 13 Dec 2020 23:11:19 +0100 Subject: Protecting your private key - passphrase In-Reply-To: <1661444.SRP0WcWmkE@breq> References: <1661444.SRP0WcWmkE@breq> Message-ID: On Sun, Dec 13, 2020 at 10:49 PM Ingo Kl?cker wrote: > > On Sonntag, 13. Dezember 2020 22:20:04 CET Stefan Claas via Gnupg-users wrote: > > I will release tomorrow, if time permits, the GUI based versions, > > on GitHUb, created with the help of the fyne toolkit. > > I'm sorry, but in my opinion this is snake oil. > > If you think that you can increase entropy ("randomness") by hashing a > passphrase a user came up with, then you should really take a basic course on > information theory. I guess you have not read my initial posting ... otherwise you would think different and would not say so ... The program is not only for GnuPG usage and if you refer to bcrypt and the likes you are aware that due to salting you always get a different hash result, thus you would have problems to input your passphrase into web forms etc. with such standalone programs. Regarding entropy, like I said, I suggest you read my intitial posting, try out the programs from my initial posting and then check the entropy of the output. BTW. Nobody is forced to use my programs and real cryptographers, I have shown my humble approach, liked it also and they are aware that the software which receives such input from my programs are doing additional salting and/or stretching. Regards Stefan From rjh at sixdemonbag.org Mon Dec 14 05:15:33 2020 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 13 Dec 2020 23:15:33 -0500 Subject: Protecting your private key - passphrase In-Reply-To: References: Message-ID: On Sun, 2020-12-13 at 22:20 +0100, Stefan Claas via Gnupg-users wrote: > I will release tomorrow, if time permits, the GUI based versions, > on GitHUb, created with the help of the fyne toolkit. > > https://ibb.co/rxYcXvq This is snake oil. Please do not use it. Stefan's claims are not rooted in mathematics. Ingo's criticism is bang-on accurate. > > checkers I thought why not try to create a little program that > > you can input your passphrase and it gets converted to a random > > chars string (40 chars), based either on sha256+base91 or > > ripemd-160 output. Digest algorithms do not produce random output. They do not even produce cryptographically secure pseudorandom output. A digest algorithm is not a CSPRNG. The construction Stefan is using here is known to fail many important tests of a CSPRNG. > > The idea here is to use phrases which makes no sense but > > can easily been remembered and then get converted so that > > you always have IMHO good random input for GnuPG. Don't do this. The entire step is unnecessary and adds literally zero security to GnuPG. > > Please note I am only noodling around with Golang and I am > > not a programmer! Nor is he a cryptographic engineer. Please do not use this, or if you do, use it at your own risk. From rjh at sixdemonbag.org Mon Dec 14 05:35:15 2020 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 13 Dec 2020 23:35:15 -0500 Subject: Protecting your private key - passphrase In-Reply-To: References: <1661444.SRP0WcWmkE@breq> Message-ID: <2d249d1d3e729124f5f52b14ecf9759ba9abbc04.camel@sixdemonbag.org> > I guess you have not read my initial posting ... otherwise you would > think different and would not say so ... Stefan, I read your original posting and I completely concur with Ingo. > The program is not only for GnuPG usage Please explain to me who might benefit from this. Seriously. If people want CSPRNG output, this is not CSPRNG output. If people want a key derivation function, this is a *really bad* key derivation function: you should've used PBKDF2 or Argon2. What's your use case? Who might benefit? > try out > the programs from my initial posting and then check the entropy of > the output. No, Stefan, that's not how it works. It is flat impossible to, by any deterministic means, increase the entropy of a function's output over the function of the input. Deterministic functions only ever reduce entropy: there exist no deterministic functions that increase it. Imagine I have a 'Gender' field on a driver's license, and it can take three values: 'Male', 'Female', and 'Nonbinary'. There are three states there, meaning there are (log-2 of 3 = ) 1.58 shannons of entropy present. If I feed one of those three fields into SHA256 and get 'fceea935c627080824b44df8f222631d39e6f705b307be1fc80f36769ade230c' I'm not increasing the entropy, I'm only spreading 1.58 shannons out over a larger region of text. "But if I feed this into an entropy estimator it comes back high!" Yes, because entropy estimators are like any other tool: they need to be used with insight. If the entropy estimator knew the universe of possibilities was only 'Male', 'Female', and 'Nonbinary', and the algorithm used was SHA256, it could then say "oh yeah, 1.58 shannons of entropy, boss." But when you na?vely run an entropy estimator and *deny it information about the possibility set or algorithms used*, you're violating Kerckhoff's Principle and of course you're going to get wildly incorrect results. > BTW. Nobody is forced to use my programs and real cryptographers, I > have shown > my humble approach, liked it also... Then I invite them to come here and explain to me where I'm wrong. So far in the last week you've advocated Bitcoin scams on this list and hyped your own snake oil. In just the last week. Please stop. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 850 bytes Desc: This is a digitally signed message part URL: From spam.trap.mailing.lists at gmail.com Mon Dec 14 09:37:51 2020 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Mon, 14 Dec 2020 09:37:51 +0100 Subject: Protecting your private key - passphrase In-Reply-To: <2d249d1d3e729124f5f52b14ecf9759ba9abbc04.camel@sixdemonbag.org> References: <1661444.SRP0WcWmkE@breq> <2d249d1d3e729124f5f52b14ecf9759ba9abbc04.camel@sixdemonbag.org> Message-ID: On Mon, Dec 14, 2020 at 5:35 AM Robert J. Hansen wrote: > > > I guess you have not read my initial posting ... otherwise you would > > think different and would not say so ... > > Stefan, I read your original posting and I completely concur with Ingo. > > > The program is not only for GnuPG usage > > Please explain to me who might benefit from this. People who have difficulties to create a long passphrase and remembering those, when using differrent ones for different use cases. > > Seriously. If people want CSPRNG output, this is not CSPRNG output. > If people want a key derivation function, this is a *really bad* key > derivation function: you should've used PBKDF2 or Argon2. I recently posted here, in the Governikus thread, that I used PBKDF2 along with NIST guidelines to create a secure key for a GnuPG key of mine, for UID purposes ... Had I used PBKDF2 for my litle program people would have a key which they need to store somewhere, while my program does not store keys, instead one types in his no sense making passphrase, which then gets converted. > What's your use case? Who might benefit? We all have probably read that servers often gets hacked or otherwise compromised and crackers and law enforcement are using software like hashcat or John the Ripper etc. to crack peoples passwords. Lists of used passwords are available on the net. Lists of MD5 and SHA1 hashes etc. as well. We are also aware of brute-force or dictionary attacks etc. One would think that nowadays passwords with all online services are properly salted and hashed, in order to protect peoples passphrases, but why are then password crackers, used by crackers and law enforcemnet are often successful? We could probably agree that then a weak password was used and no salt, so that the stored hashes in databases from online services makes it easier to crack passwords. Or do we have NIST/BSI certified consumer online services, when it comes to security ... With that said would you say that when one inputs his password into an online form that it is equally secure than if one would use my program and use an easy to remember nonsense phrase which gets convert? Regards Stefan From spam.trap.mailing.lists at gmail.com Mon Dec 14 09:53:32 2020 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Mon, 14 Dec 2020 09:53:32 +0100 Subject: Protecting your private key - passphrase In-Reply-To: References: Message-ID: Robert, you are one hundred percent correct that the output of my programs are *not* random and that they do not generate random output like a CSPRNG does. So, once again, I appologize for my wrong wording and should had better used garbled looking output, compared to a regular users passphrase input. With all fairness you should also tell people that if they use a CSPRNG for password generation and the password is long or is a passphrase that then again they have to store the key because it is unlikely that they can remember such passwords/passphrases. My humble approach does *not* store keys and I also said that users need to clear their clipboard after usage. Regards Stefan On Mon, Dec 14, 2020 at 5:15 AM Robert J. Hansen wrote: > > On Sun, 2020-12-13 at 22:20 +0100, Stefan Claas via Gnupg-users wrote: > > I will release tomorrow, if time permits, the GUI based versions, > > on GitHUb, created with the help of the fyne toolkit. > > > > https://ibb.co/rxYcXvq > > This is snake oil. Please do not use it. Stefan's claims are not > rooted in mathematics. Ingo's criticism is bang-on accurate. > > > > checkers I thought why not try to create a little program that > > > you can input your passphrase and it gets converted to a random > > > chars string (40 chars), based either on sha256+base91 or > > > ripemd-160 output. > > Digest algorithms do not produce random output. > > They do not even produce cryptographically secure pseudorandom output. > > A digest algorithm is not a CSPRNG. The construction Stefan is using > here is known to fail many important tests of a CSPRNG. > > > > The idea here is to use phrases which makes no sense but > > > can easily been remembered and then get converted so that > > > you always have IMHO good random input for GnuPG. > > Don't do this. The entire step is unnecessary and adds literally zero > security to GnuPG. > > > > Please note I am only noodling around with Golang and I am > > > not a programmer! > > Nor is he a cryptographic engineer. > > Please do not use this, or if you do, use it at your own risk. > > From wk at gnupg.org Mon Dec 14 10:26:40 2020 From: wk at gnupg.org (Werner Koch) Date: Mon, 14 Dec 2020 10:26:40 +0100 Subject: Protecting your private key - passphrase In-Reply-To: <1661444.SRP0WcWmkE@breq> ("Ingo \=\?utf-8\?Q\?Kl\=C3\=B6cker\=22's\?\= message of "Sun, 13 Dec 2020 22:46:43 +0100") References: <1661444.SRP0WcWmkE@breq> Message-ID: <874kko4u27.fsf@wheatstone.g10code.de> Hi! Let me also add that the private key protection mechanism of OpenPGP does not work like we would do it these days. Thus my suggestion has always been: If you need to convey a private key over a public channel do not rely on the passphrase protection [1] but wrap the backuped key in a proper OpenPGP encryption message (public key or symmetric with a good and different passphrase) for transport. For backup purposes the passphrase protection system is okay. Shalom-Salam, Werner [1] Even if the passphrase is strong enough to be published in the NYT. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From rjh at sixdemonbag.org Mon Dec 14 12:26:42 2020 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 14 Dec 2020 06:26:42 -0500 Subject: Protecting your private key - passphrase In-Reply-To: References: <1661444.SRP0WcWmkE@breq> <2d249d1d3e729124f5f52b14ecf9759ba9abbc04.camel@sixdemonbag.org> Message-ID: > People who have difficulties to create a long passphrase and > remembering those, when using differrent ones for different use cases. Then why aren't you using PBKDF2 or Argon2? If you're writing a key derivation app -- use a key derivation function. > Had I used PBKDF2 for my litle program people would have a key which > they need to store somewhere, while my program does not store keys, What are you talking about? Here's the signature for PBKDF2 in Golang's crypto library: func Key(password []byte, salt []byte, iterations int, keyLength int, hashFunction func() hash.Hash) []byte If you need to generate the same key again later, just feed in the same inputs. You have nothing to keep track of so long as you remember the passphrase. > With that said would you say that when one inputs his password into an > online form that it is equally secure than if one would use my program > and use an easy to remember nonsense phrase which gets convert? I'd advise people to use Firefox's password safe and ability to generate pseudorandom keys for each site you visit. KeePassX is a good open-source alternative for people who want to keep passwords on their desktop machine instead of encrypted in the cloud. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x1DCBDC01B44427C7.asc Type: application/pgp-keys Size: 9919 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Mon Dec 14 12:37:35 2020 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 14 Dec 2020 06:37:35 -0500 Subject: Protecting your private key - passphrase In-Reply-To: References: Message-ID: <38cac960-89ac-49e4-accc-56874f0933fc@sixdemonbag.org> > you are one hundred percent correct that the output of my programs are *not* > random and that they do not generate random output like a CSPRNG does. I'm not going to discuss this with you further. It's clear you don't know what you're doing, and I trust that's been made clear to the mailing list. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x1DCBDC01B44427C7.asc Type: application/pgp-keys Size: 9919 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From m.fernandes.business at gmail.com Mon Dec 14 13:37:11 2020 From: m.fernandes.business at gmail.com (m.fernandes.business) Date: Mon, 14 Dec 2020 12:37:11 +0000 Subject: Best practice to use several smartcards for a single key? Message-ID: > > Date: Sun, 13 Dec 2020 21:22:44 +0000 > From: Andrew Gallagher > Message-ID: <9AE37DA2-0E50-46CD-8F16-05C4D55B3BDF at andrewg.com> > > > > On 13 Dec 2020, at 11:08, Nicolas Boullis > wrote: > > > > My idea was that there was little chance that a smartcard fails (Werner > > Koch told me that the failure I experienced was exceptionnal) and if it > > does I can set up a new encryption key and, using the second smartcard, > > decrypt all the files that were encrypted for the old key and re-encrypt > > them for the new key. > > How are you going to decrypt the old files if your old smartcard is > already dead? If you don?t want to lose all access to your encrypted files, > you *must* keep a backup of your encryption key material at the very least. > There is no recovering from a deleted encryption private key. > > I keep my key material on a Tails encrypted partition in a safe place. > Alternatively you could keep a paper backup in a safe place. But there?s no > getting around having some form of backup. What amounts to a ?safe place? > depends on your threat model of course... > > A > > Don't know whether you've considered USB security tokens, but you might find them less likely to 'die' than smartcards. Once you put your private key in one of the Nitrokey security-token products, it's supposed to be impossible to extract the key (not sure whether the same is *as much* true with the smartcards you are considering). I agree with Nicolas Boullis, that using duplicate smartcards (or USB security tokens) might be preferred for back-up purposes. If on the other hand, you want to back-up your private key in the more conventional way suggested by Andrew Gallagher, and you are worried about adversaries gaining access to your backup, you might want to do something like splitting the key into several parts, and then backing-up each of the parts with a different friend/colleague, perhaps each of whom is located very far away from the others: see Shamir's Secret Sharing . Kind regards, Mark Fernandes -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefanclaas at riseup.net Mon Dec 14 14:05:47 2020 From: stefanclaas at riseup.net (Stefan Claas) Date: Mon, 14 Dec 2020 05:05:47 -0800 Subject: Protecting your private key - passphrase In-Reply-To: References: <1661444.SRP0WcWmkE@breq> <2d249d1d3e729124f5f52b14ecf9759ba9abbc04.camel@sixdemonbag.org> Message-ID: On 2020-12-14 12:26, Robert J. Hansen via Gnupg-users wrote: >> People who have difficulties to create a long passphrase and >> remembering those, when using differrent ones for different use cases. > > Then why aren't you using PBKDF2 or Argon2? > > If you're writing a key derivation app -- use a key derivation function. > >> Had I used PBKDF2 for my litle program people would have a key which >> they need to store somewhere, while my program does not store keys, > > What are you talking about? Here's the signature for PBKDF2 in > Golang's crypto library: > > func Key(password []byte, > salt []byte, > iterations int, > keyLength int, > hashFunction func() hash.Hash) []byte > > If you need to generate the same key again later, just feed in the > same inputs. You have nothing to keep track of so long as you > remember the passphrase. I said that my program does *not* store any *keys* and the *required* parameters (which can be set manually and individually, in order to use the same passphrase again) ... Regards Stefan From casey.marshall at gmail.com Mon Dec 14 17:21:03 2020 From: casey.marshall at gmail.com (Casey Marshall) Date: Mon, 14 Dec 2020 10:21:03 -0600 Subject: [Keyserver] Hockeypuck 2.1.0 released Message-ID: > > Date: Fri, 11 Dec 2020 17:56:24 +0000 > From: Stefan Claas > To: Casey Marshall via Gnupg-users , > sks-devel at nongnu.org, Casey Marshall > Subject: Re: [Keyserver] Hockeypuck 2.1.0 released > Message-ID: > < > CAC6FiZ6EPR-eUD0AzMCVz7m4c9Hxga1iSfG7jSC2HXwsOvFmWA at mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > On Fri, Dec 11, 2020 at 10:25 AM Werner Koch wrote: > > > > On Thu, 10 Dec 2020 11:07, Casey Marshall said: > > > > > - Authenticated key management. This adds a couple of extra > endpoints > > > which allow a key owner to replace and delete their key, > authenticated by > > > signing the armored key in the request. This allows a key owner to > still > > > update their own key once it has been inflated beyond the key > > > > Finally after more than 20 years waiting for someone to implement such a > > feature. Yeah. Where can I find the specs? > > > > Did you consider that an authenticated request to delete a key may not > > actually remove the key from the keyserver? Instead the the primary key > > should be kept and the server prepared to receive and merge even > > unauthenticated revocation certificates. This is important in case of a > > lost key (or passphrase forgotten) so that a pre-created revocation > > certificate can be uploaded. Also avoids DoS after a key compromise. > Hi Werner and Casey, > I have a question for both of you. > When I reported a while ago on GitHub about a fake uat packet on Werner's > key you quickly fixed the issue and the added image of 'Donnie' no longer > showed up at the Ubuntu keyserver. Interestingly now GitHub shows zero > issues as of today, while yesterday still some issues where open and a lot > of them closed. > Hockeypuck has several issues still open on Github: https://github.com/hockeypuck/hockeypuck/issues > Now my second question how is/was this done with Werner's key? > SKS still shows Werner's key with signatures, while the Ubuntu keyserver > shows only a very small key now. Before that the Ubuntu key server showed > the sigs too and additionally the fake uat packet (Donnie image). > Does this mean that a GnuPG user can modify his key in such a way > and re-submit it, so that the result is now like Werner's key or can a > Hockerpuck operator do this (on behalf) of the key owner? The key > in question, on the Ubuntu keyserver has also no longer a UID, which > I thought only sequoia-pgp can handle and not GnuPG. > > https://keyserver.ubuntu.com/pks/lookup?search=0x7b96d396e6471601754be4db53b620d01ce0c630&fingerprint=on&op=vindex > > http://keys2.andreas-puls.de:11371/pks/lookup?search=0x7b96d396e6471601754be4db53b620d01ce0c630&fingerprint=on&op=vindex The fix to this issue was to have Hockeypuck remove all packets lacking a currently-valid self-signature from responses. This removes fake packets (like the uat example) as well as expired identities. The self-signature on the UID packet in your example expired 2008-12-31, so it (and all of its third-party signatures) are pruned from the response. Only the public key packet remains. > Regards > Stefan -------------- next part -------------- An HTML attachment was scrubbed... URL: From spam.trap.mailing.lists at gmail.com Mon Dec 14 18:00:45 2020 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Mon, 14 Dec 2020 18:00:45 +0100 Subject: [Keyserver] Hockeypuck 2.1.0 released In-Reply-To: References: Message-ID: On Mon, Dec 14, 2020 at 5:24 PM Casey Marshall via Gnupg-users wrote: >> [...] > The fix to this issue was to have Hockeypuck remove all packets lacking a currently-valid self-signature from responses. This removes fake packets (like the uat example) as well as expired identities. The self-signature on the UID packet in your example expired 2008-12-31, so it (and all of its third-party signatures) are pruned from the response. Only the public key packet remains. Thanks for the information, much appreciated! Regards Stefan From felix.klee at inka.de Tue Dec 15 04:13:05 2020 From: felix.klee at inka.de (Felix E. Klee) Date: Tue, 15 Dec 2020 11:13:05 +0800 Subject: Decrypting fails unless card status Message-ID: Since some time, maybe since a minor system update, before decrypting from my OpenPGP smart card, I always have to run: gpg --card-status Otherwise, I get an error message: $ gpg --faked-system-time 20200101T000000 -d world.gpg gpg: WARNING: running with faked system time: 2020-01-01 00:00:00 gpg: encrypted with 4096-bit RSA key, ID 04FDF78D1679DD94, created 2016-12-17 "Felix E. Klee " gpg: public key decryption failed: Invalid ID gpg: decryption failed: No secret key Note that I have to run with faked system time since I cannot extend the validity of my key. Anyhow, even without faking the time, I get the error message. *Any idea how to get `gpg` back to normal?* From wk at gnupg.org Tue Dec 15 09:08:44 2020 From: wk at gnupg.org (Werner Koch) Date: Tue, 15 Dec 2020 09:08:44 +0100 Subject: Decrypting fails unless card status In-Reply-To: (Felix E. Klee's message of "Tue, 15 Dec 2020 11:13:05 +0800") References: Message-ID: <87pn3b1ofn.fsf@wheatstone.g10code.de> On Tue, 15 Dec 2020 11:13, Felix E. Klee said: > *Any idea how to get `gpg` back to normal?* Update to GnuPG 2.2.25 (See the comments at https://dev.gnupg.org/T5052) Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From 2017-r3sgs86x8e-lists-groups at riseup.net Tue Dec 15 12:43:57 2020 From: 2017-r3sgs86x8e-lists-groups at riseup.net (MFPA) Date: Tue, 15 Dec 2020 11:43:57 +0000 Subject: Decrypting fails unless card status In-Reply-To: References: Message-ID: <1226229354.20201215114326@mail.riseup.net> Hi On Tuesday 15 December 2020 at 3:13:05 AM, in , Felix E. Klee wrote:- > Note that I have to run with faked system time since > I cannot extend the > validity of my key. Is that a consequence of using a card? -- Best regards MFPA Truth is what remains when all illusions have been stripped away. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 1207 bytes Desc: not available URL: From felix.klee at inka.de Tue Dec 15 13:49:26 2020 From: felix.klee at inka.de (Felix E. Klee) Date: Tue, 15 Dec 2020 20:49:26 +0800 Subject: Decrypting fails unless card status In-Reply-To: <1226229354.20201215114326@mail.riseup.net> References: <1226229354.20201215114326@mail.riseup.net> Message-ID: On Tue, 15 Dec 2020 at 19:45, MFPA <2017-r3sgs86x8e-lists-groups at riseup.net> wrote: > Is that a consequence of using a card? No. I do have an accessible private key, but it?s more than 9,000 km away, and traveling is not so easy these days. From spam.trap.mailing.lists at gmail.com Tue Dec 15 17:04:25 2020 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Tue, 15 Dec 2020 17:04:25 +0100 Subject: Protecting your private key - passphrase In-Reply-To: References: Message-ID: On Thu, Dec 10, 2020 at 4:11 PM Stefan Claas wrote: > > Hi all, > > while playing with hashcat, diceware passphrases and entropy > checkers I thought why not try to create a little program that > you can input your passphrase and it gets converted to a random > chars string (40 chars), based either on sha256+base91 or > ripemd-160 output. > > The idea here is to use phrases which makes no sense but > can easily been remembered and then get converted so that > you always have IMHO good random input for GnuPG. > > For that task I created two little Golang programs which > asks the user to input a phrase that makes no sense and > while the user is typing in his passphrase bullets are > displayed, like in pinentry, and then the random 40 chars > get copied to the clipboard, so that users can paste > the passphrase into GnuPG. > > In order that this works under Linux/Unix too you need > to install xclip or xsel and don't forget to clear the > clipboard after usage. > > Example #1 > > Input: Alice+eats&red+stones > > Output program #1: 8rW3 Output program #2 a6a549d45f1e5c3fabfba37003541c3fa7f26d13 > > Exampl #2 > > Input: gr?ne-F?chse-fliegen#weich (= green-foxes-flying#soft) > > Output program #1: $j{hDH!5m4O[9JcPVBbHLlM^]R]RJ%yJoPr:IxAD > Output program #2: 89216958ceed145dd03a6d23afa7ae93b27457e9 > > Example #3 > > Input mixed languages question: has*Bob*deutsche*???s? > > Output program #1 fq7Mr469cU#d%uOIX?zG?:^@^y[n152_OUvp8|gB > Output program #2 9f770781c96d72b9974421ea72b523c019714a1f > > Hope you like the idea and maybe others come up with better > solutions. Did some calculations with these simple example mini-passphrases above compared to diceware sixword word passphrases and decided to rename my programs to passphrase hasher, so that people do not follow these simple examples. Also added an clipboard overwrite button. https://ibb.co/VYkDN20 Regards Stefan From david.donnelly at daviddonnelly.com Tue Dec 15 21:29:19 2020 From: david.donnelly at daviddonnelly.com (david.donnelly at daviddonnelly.com) Date: Tue, 15 Dec 2020 12:29:19 -0800 Subject: GPG Encryption on Raspberry Pi 4 using custom e-mail address failure Message-ID: <001c01d6d320$f82e81e0$e88b85a0$@daviddonnelly.com> Good Day, This very novice would appreciate some help. My situation: I have several Raspberry Pi 4 computers running the Raspberry Operating System (Raspbian GNU/Linux [buster], Version ID=10) at my home. I need each of them to send me an email notification when certain functions are performed. I have gpg version 2.2.12-1+rpi1+deb10u1 installed. To this end, I have configured the mail system called msmtp on each Raspberry Pi 4 computer. I can send email to my myself via my Gmail and david.donnelly.com (IONOS.COM) accounts manually and interactively using msmtp on each of the Raspberry Pi 4 computers. Problem: However, following good internet security policies, I tried to encrypt my email account passwords using GPG (Gnu PG: https://gnupg.org/). These encrypted passwords are to be stored in a file on each Raspberry Pi4 computer. Now, first off, this encryption process worked fine for my Gmail Account. I was able to run the following command: gpg --encrypt -o .msmtp-gmail.gpg -r donnellydw at gmail.com - The password provided was encrypted with no problems and the associated file was created. However, when I try to run the same command using my david.donnelly.com (IONOS.COM) email account: gpg --encrypt -o .msmtp-ionos.gpg -r david.donnelly at daviddonnelly.com - or gpg --encrypt -o .msmtp-ionos.gpg -r 2d at daviddonnelly.com - I get the following three errors: gpg: error retrieving 'david.donnelly at daviddonnelly.com' via WKD: Network error gpg: david.donnelly at daviddonnelly.com : skipped: Network error gpg: [stdin]: encryption failed: Network error If I substitute and use my 2d at daviddonnelly.com email address, I get the same three errors: gpg: error retrieving '2d at daviddonnelly.com' via WKD: Network error gpg: 2d at daviddonnelly.com : skipped: Network error gpg: [stdin]: encryption failed: Network error I then reran the encryption command using my Gmail address: gpg --encrypt -o .msmtp-gmail.gpg -r donnellydw at gmail.com - and encryption and file creation was successful. At face value, I have internet access, my network is working, so I have concluded something is causing a problem in the gpg program with resolving/determining/? how to translate my IONOS.COM custom e-mail address: david.donnelly at daviddonnelly.com or 2d at daviddonnelly.com vice the GPG program fully understanding how to handle the "gmail.com" address. Your help in this matter is greatly appreciated, Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.donnelly at daviddonnelly.com Wed Dec 16 17:15:35 2020 From: david.donnelly at daviddonnelly.com (david.donnelly at daviddonnelly.com) Date: Wed, 16 Dec 2020 08:15:35 -0800 Subject: GPG Encryption on Raspberry Pi 4 using custom e-mail address failure In-Reply-To: <001c01d6d320$f82e81e0$e88b85a0$@daviddonnelly.com> References: <001c01d6d320$f82e81e0$e88b85a0$@daviddonnelly.com> Message-ID: <004b01d6d3c6$b0812f90$11838eb0$@daviddonnelly.com> Good Day, I appreciate your help in this matter, but I have learned additional information and I need to reformat and resubmit this help request. Thank you, Dave From: Gnupg-users On Behalf Of david.donnelly at daviddonnelly.com Sent: Tuesday, December 15, 2020 12:29 PM To: gnupg-users at gnupg.org Subject: GPG Encryption on Raspberry Pi 4 using custom e-mail address failure Good Day, This very novice would appreciate some help. My situation: I have several Raspberry Pi 4 computers running the Raspberry Operating System (Raspbian GNU/Linux [buster], Version ID=10) at my home. I need each of them to send me an email notification when certain functions are performed. I have gpg version 2.2.12-1+rpi1+deb10u1 installed. To this end, I have configured the mail system called msmtp on each Raspberry Pi 4 computer. I can send email to my myself via my Gmail and david.donnelly.com (IONOS.COM) accounts manually and interactively using msmtp on each of the Raspberry Pi 4 computers. Problem: However, following good internet security policies, I tried to encrypt my email account passwords using GPG (Gnu PG: https://gnupg.org/). These encrypted passwords are to be stored in a file on each Raspberry Pi4 computer. Now, first off, this encryption process worked fine for my Gmail Account. I was able to run the following command: gpg --encrypt -o .msmtp-gmail.gpg -r donnellydw at gmail.com - The password provided was encrypted with no problems and the associated file was created. However, when I try to run the same command using my david.donnelly.com (IONOS.COM) email account: gpg --encrypt -o .msmtp-ionos.gpg -r david.donnelly at daviddonnelly.com - or gpg --encrypt -o .msmtp-ionos.gpg -r 2d at daviddonnelly.com - I get the following three errors: gpg: error retrieving 'david.donnelly at daviddonnelly.com' via WKD: Network error gpg: david.donnelly at daviddonnelly.com : skipped: Network error gpg: [stdin]: encryption failed: Network error If I substitute and use my 2d at daviddonnelly.com email address, I get the same three errors: gpg: error retrieving '2d at daviddonnelly.com' via WKD: Network error gpg: 2d at daviddonnelly.com : skipped: Network error gpg: [stdin]: encryption failed: Network error I then reran the encryption command using my Gmail address: gpg --encrypt -o .msmtp-gmail.gpg -r donnellydw at gmail.com - and encryption and file creation was successful. At face value, I have internet access, my network is working, so I have concluded something is causing a problem in the gpg program with resolving/determining/? how to translate my IONOS.COM custom e-mail address: david.donnelly at daviddonnelly.com or 2d at daviddonnelly.com vice the GPG program fully understanding how to handle the "gmail.com" address. Your help in this matter is greatly appreciated, Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From boskov at bu.edu Wed Dec 16 20:47:38 2020 From: boskov at bu.edu (=?UTF-8?Q?Novak_Bo=c5=a1kov?=) Date: Wed, 16 Dec 2020 14:47:38 -0500 Subject: Does GPG Ever Store RSA Secret Keys On The Disk In Plain? Message-ID: <427aa3c8-2dab-90b2-007e-daa0386ae2a0@bu.edu> Hell everyone, On this link is the following statement: > To help safeguard your key, GnuPG does not store your raw private key > on disk. Instead it encrypts it using a symmetric encryption algorithm. However, I'm not entirely clear on what happens when I do: > gpg --export-secret-keys --armor Is the secret key block that appears on STDOUT my plain secret key or is it its encrypted version? Best regards, Novak -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xB8D4C9837C741FBD.asc Type: application/pgp-keys Size: 2448 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: OpenPGP digital signature URL: From 2017-r3sgs86x8e-lists-groups at riseup.net Thu Dec 17 00:19:17 2020 From: 2017-r3sgs86x8e-lists-groups at riseup.net (MFPA) Date: Wed, 16 Dec 2020 23:19:17 +0000 Subject: Decrypting fails unless card status In-Reply-To: References: <1226229354.20201215114326@mail.riseup.net> Message-ID: <326914377.20201216231852@mail.riseup.net> Hi On Tuesday 15 December 2020 at 12:49:26 PM, in , Felix E. Klee wrote:- > No. I do have an accessible private key, but it?s > more than 9,000 km > away, and traveling is not so easy these days. So not really that accessible (-; -- Best regards MFPA Colourless green ideas sleep furiously (Noam Chomsky) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 1207 bytes Desc: not available URL: From andrewg at andrewg.com Thu Dec 17 10:51:55 2020 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 17 Dec 2020 09:51:55 +0000 Subject: GPG Encryption on Raspberry Pi 4 using custom e-mail address failure In-Reply-To: <004b01d6d3c6$b0812f90$11838eb0$@daviddonnelly.com> References: <001c01d6d320$f82e81e0$e88b85a0$@daviddonnelly.com> <004b01d6d3c6$b0812f90$11838eb0$@daviddonnelly.com> Message-ID: On 16/12/2020 16:15, david.donnelly at daviddonnelly.com wrote: > However,? when I try to run the same command using my david.donnelly.com > (IONOS.COM) email account: > > gpg --encrypt -o .msmtp-ionos.gpg -r david.donnelly at daviddonnelly.com > - > > or > > gpg --encrypt -o .msmtp-ionos.gpg -r 2d at daviddonnelly.com > - > > I get the following three errors: > > gpg: error retrieving 'david.donnelly at daviddonnelly.com' via WKD: > Network error > > gpg: david.donnelly at daviddonnelly.com > : skipped: Network error > > gpg: [stdin]: encryption failed: Network error It appears that you don't already have a copy of the public key for david.donnelly at daviddonnelly.com on that machine. Is this expected? I can't find keys for any of your listed emails on the SKS pool, or on Hagrid (which appears to be down?), or via WKD. If you don't have the key locally either, then gpg won't be able to encrypt. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From donnellydw at gmail.com Thu Dec 17 20:00:05 2020 From: donnellydw at gmail.com (donnellydw at gmail.com) Date: Thu, 17 Dec 2020 11:00:05 -0800 Subject: GPG Encryption on Raspberry Pi 4 using custom e-mail address failure In-Reply-To: References: <001c01d6d320$f82e81e0$e88b85a0$@daviddonnelly.com> <004b01d6d3c6$b0812f90$11838eb0$@daviddonnelly.com> Message-ID: <006401d6d4a6$d6066010$82132030$@gmail.com> Andrew, I learned a few things after this post was submitted. Yes - I had not created my key...or keys? At any rate - once I create the key (with an associated passphrase), the encryption worked. Well - to some degree. Another problem cropped up which I will post via a different e-mail. Many thanks, this initial issue is solved. Many thanks, Dave -----Original Message----- From: Gnupg-users On Behalf Of Andrew Gallagher Sent: Thursday, December 17, 2020 1:52 AM To: gnupg-users at gnupg.org Subject: Re: GPG Encryption on Raspberry Pi 4 using custom e-mail address failure On 16/12/2020 16:15, david.donnelly at daviddonnelly.com wrote: > However,? when I try to run the same command using my > david.donnelly.com > (IONOS.COM) email account: > > gpg --encrypt -o .msmtp-ionos.gpg -r david.donnelly at daviddonnelly.com > - > > or > > gpg --encrypt -o .msmtp-ionos.gpg -r 2d at daviddonnelly.com > - > > I get the following three errors: > > gpg: error retrieving 'david.donnelly at daviddonnelly.com' via WKD: > Network error > > gpg: david.donnelly at daviddonnelly.com > : skipped: Network error > > gpg: [stdin]: encryption failed: Network error It appears that you don't already have a copy of the public key for david.donnelly at daviddonnelly.com on that machine. Is this expected? I can't find keys for any of your listed emails on the SKS pool, or on Hagrid (which appears to be down?), or via WKD. If you don't have the key locally either, then gpg won't be able to encrypt. -- Andrew Gallagher From donnellydw at gmail.com Thu Dec 17 20:28:57 2020 From: donnellydw at gmail.com (donnellydw at gmail.com) Date: Thu, 17 Dec 2020 11:28:57 -0800 Subject: GPG Decrypt Error based on a timeout function? Message-ID: <008e01d6d4aa$dde50170$99af0450$@gmail.com> Good Day, This very novice would appreciate some help. My situation: I have a Raspberry Pi 4 computer running the Raspberry Operating System (Raspbian GNU/Linux [buster], Version ID=10) at my home. I need it to send me an email notification when certain functions are performed. To this end, I have configured the mail system called msmtp on the Raspberry Pi 4 computer. I can send email to my myself via my email account manually and interactively using msmtp on the Raspberry Pi 4 computer, with the password not encrypted on the Raspberry Pi 4 computer. I have gpg version 2.2.12-1+rpi1+deb10u1 installed on this Raspberry Pi 4 Computer. Problem: Following good security policies, I encrypted my email account password using gpg. My encrypted password is stored in a file (/home/pi/.msmtp-2d-ionos.gpg) on the Raspberry Pi4 computer. I successfully created my gpg key. I was able to successfully run the following command: gpg --encrypt -o .msmtp-2d.ionos.gpg -r 2d at daviddonnelly.com - The password provided was encrypted with no problems and the associated file was created. However, when I run the following command, it initially works. Meaning the associated password is decrypted and the e-mail is sent: msmtp -t < message.txt But after a few minutes, when I retest the command: msmtp -t < message.txt I get the following error: gpg: decryption failed: No secret key When I run the following command: gpg --encrypt -o .msmtp-2d.ionos.gpg -r 2d at daviddonnelly.com - I am asked for my passphrase, once entered the file is decrypted and the contents displayed. I then rerun the command: msmtp -t < message.txt and the associated e-mail is sent. I wait a few minutes and the error repeats itself. Is there some sort of timeout associated with gpg? Or my implementation is wrong.or ? Also, I have noticed, at times, gpg will not accept the passphrase until I reboot the Raspberry pi 4. Your help in this matter is greatly appreciated, Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Untitled attachment 00042.txt URL: From angel at pgp.16bits.net Fri Dec 18 01:52:45 2020 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Fri, 18 Dec 2020 01:52:45 +0100 Subject: GPG Decrypt Error based on a timeout function? In-Reply-To: <008e01d6d4aa$dde50170$99af0450$@gmail.com> References: <008e01d6d4aa$dde50170$99af0450$@gmail.com> Message-ID: <711e7efdcb2538c741bfb4724bb4af226868d546.camel@16bits.net> On 2020-12-17 at 11:28 -0800, Dave via Gnupg-users wrote: > Good Day, > This very novice would appreciate some help. > > My situation: > > I have a Raspberry Pi 4 computer running the Raspberry Operating > System (Raspbian GNU/Linux [buster], Version ID=10) at my home. I > need it to send me an email notification when certain functions are > performed. > > To this end, I have configured the mail system called msmtp on the > Raspberry Pi 4 computer. I can send email to my myself via my email > account manually and interactively using msmtp on the Raspberry Pi 4 > computer, with the password not encrypted on the Raspberry Pi 4 > computer. > (...) > When I run the following command: > > gpg --encrypt -o .msmtp-2d.ionos.gpg -r 2d at daviddonnelly.com - > > I am asked for my passphrase, once entered the file is decrypted and > the contents displayed. I then rerun the command: Probably a mistake in pasting the same as before. This command wouldn't need the password for the private key. > msmtp -t < message.txt > > and the associated e-mail is sent. > > I wait a few minutes and the error repeats itself. > > Is there some sort of timeout associated with gpg? Or my > implementation is wrong?or ? > > Also, I have noticed, at times, gpg will not accept the passphrase > until I reboot the Raspberry pi 4. See gpg-agent settings. The few minutes it works, that's because gpg- agent has the decrypted gpg key cached. You would need to increase that timeout, or let the script provide the password directly to gpg / use a passwordless key. When the sending fails, it should perhaps be asking you to provide the gpg passphrase, my guess is that the way it runs ( --no-tty --batch maybe), it isn't able to launch a pinentry to ask the password to the user. If you really want the password decryption to be unattended, you could configure the gpg password in the script, but then that would be roughly equivalent to the email account password. It's turtles all way down. Regards From angel at pgp.16bits.net Fri Dec 18 01:43:09 2020 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Fri, 18 Dec 2020 01:43:09 +0100 Subject: Does GPG Ever Store RSA Secret Keys On The Disk In Plain? In-Reply-To: <427aa3c8-2dab-90b2-007e-daa0386ae2a0@bu.edu> References: <427aa3c8-2dab-90b2-007e-daa0386ae2a0@bu.edu> Message-ID: On 2020-12-16 at 14:47 -0500, Novak Bo?kov wrote: > Hell everyone, > > On this link is the following statement: > > To help safeguard your key, GnuPG does not store your raw private > > key on disk. Instead it encrypts it using a symmetric encryption > > algorithm. > However, I'm not entirely clear on what happens when I do: > > gpg --export-secret-keys --armor > Is the secret key block that appears on STDOUT my plain secret key > or is it its encrypted version? It is encrypted with your passphrase. You (or an attacker) will need the passphrase in order to use that exported secret key. Except if the secret key wasn't protected with a passphrase, in which case the exported key isn't, either. You can verify yourself if the key is protected or not by feeding it to gpg --list-packets. A key protected with a passphrase will have a packet similar to this: :secret sub key packet: version 4, algo 1, created 1608251624, expires 0 pkey[0]: [1024 bits] pkey[1]: [17 bits] iter+salt S2K, algo: 7, SHA1 protection, hash: 2, salt: 1546427246151681 protect count: 32505856 (239) protect IV: eb f7 79 f8 0c cc b8 a6 e7 e4 88 c1 7b a8 0f e4 skey[2]: [v4 protected] keyid: whereas if it didn't have a passphrase, you would see a simpler packet with the data directly available: :secret sub key packet: version 4, algo 1, created 1608251706, expires 0 pkey[0]: [1024 bits] pkey[1]: [17 bits] skey[2]: [1023 bits] skey[3]: [512 bits] skey[4]: [512 bits] skey[5]: [511 bits] checksum: 9f84 keyid: The confusion probably comes because it requests the passphrase before exporting. This didn't use to be the case (it just copied the protected key file), but the way gpg-agent is dealing with the private key, it now needs the passphrase to decrypt it, and then it is encrypted again with the same passphrase before being output. From a.yousar at informatik.hu-berlin.de Fri Dec 18 12:54:04 2020 From: a.yousar at informatik.hu-berlin.de (Annie Yousar) Date: Fri, 18 Dec 2020 12:54:04 +0100 Subject: Does GPG Ever Store RSA Secret Keys On The Disk In Plain? In-Reply-To: References: <427aa3c8-2dab-90b2-007e-daa0386ae2a0@bu.edu> Message-ID: <83cf1f93-b717-9d21-9b4f-500e458afd3d@informatik.hu-berlin.de> ?ngel, your answer is correct, but incomplete. The key is not encrypted with the passphrase, but with a secret key derived (by S2K) from the passphrase with the help of a salt. Therefore each export gives different export data, despite using the same passphrase. /Ann. Am 18.12.2020 um 01:43 schrieb ?ngel: > On 2020-12-16 at 14:47 -0500, Novak Bo?kov wrote: >> Hell everyone, >> >> On this link is the following statement: >>> To help safeguard your key, GnuPG does not store your raw private >>> key on disk. Instead it encrypts it using a symmetric encryption >>> algorithm. >> However, I'm not entirely clear on what happens when I do: >>> gpg --export-secret-keys --armor >> Is the secret key block that appears on STDOUT my plain secret key >> or is it its encrypted version? > It is encrypted with your passphrase. You (or an attacker) will need > the passphrase in order to use that exported secret key. > > Except if the secret key wasn't protected with a passphrase, in which > case the exported key isn't, either. > > You can verify yourself if the key is protected or not by feeding it to > gpg --list-packets. > > A key protected with a passphrase will have a packet similar to this: > :secret sub key packet: > version 4, algo 1, created 1608251624, expires 0 > pkey[0]: [1024 bits] > pkey[1]: [17 bits] > iter+salt S2K, algo: 7, SHA1 protection, hash: 2, salt: > 1546427246151681 > protect count: 32505856 (239) > protect IV: eb f7 79 f8 0c cc b8 a6 e7 e4 88 c1 7b a8 0f e4 > skey[2]: [v4 protected] > keyid: > > > whereas if it didn't have a passphrase, you would see a simpler packet > with the data directly available: > :secret sub key packet: > version 4, algo 1, created 1608251706, expires 0 > pkey[0]: [1024 bits] > pkey[1]: [17 bits] > skey[2]: [1023 bits] > skey[3]: [512 bits] > skey[4]: [512 bits] > skey[5]: [511 bits] > checksum: 9f84 > keyid: > > > > The confusion probably comes because it requests the passphrase before > exporting. This didn't use to be the case (it just copied the protected > key file), but the way gpg-agent is dealing with the private key, it > now needs the passphrase to decrypt it, and then it is encrypted again > with the same passphrase before being output. > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > From donnellydw at gmail.com Fri Dec 18 19:25:55 2020 From: donnellydw at gmail.com (donnellydw at gmail.com) Date: Fri, 18 Dec 2020 10:25:55 -0800 Subject: GPG Decrypt Error based on a timeout function? In-Reply-To: <711e7efdcb2538c741bfb4724bb4af226868d546.camel@16bits.net> References: <008e01d6d4aa$dde50170$99af0450$@gmail.com> <711e7efdcb2538c741bfb4724bb4af226868d546.camel@16bits.net> Message-ID: <005401d6d56b$3a8c2b90$afa482b0$@gmail.com> Angel, Yes, I want the script to run unattended, which the gpg process is not the right method, as you say: " you could configure the gpg password in the script, but then that would be roughly equivalent to the email account password." Many thanks and stay safe and healthy, Dave -----Original Message----- From: Gnupg-users On Behalf Of ?ngel Sent: Thursday, December 17, 2020 4:53 PM To: gnupg-users at gnupg.org Subject: Re: GPG Decrypt Error based on a timeout function? On 2020-12-17 at 11:28 -0800, Dave via Gnupg-users wrote: > Good Day, > This very novice would appreciate some help. > > My situation: > > I have a Raspberry Pi 4 computer running the Raspberry Operating > System (Raspbian GNU/Linux [buster], Version ID=10) at my home. I > need it to send me an email notification when certain functions are > performed. > > To this end, I have configured the mail system called msmtp on the > Raspberry Pi 4 computer. I can send email to my myself via my email > account manually and interactively using msmtp on the Raspberry Pi 4 > computer, with the password not encrypted on the Raspberry Pi 4 > computer. > (...) > When I run the following command: > > gpg --encrypt -o .msmtp-2d.ionos.gpg -r 2d at daviddonnelly.com - > > I am asked for my passphrase, once entered the file is decrypted and > the contents displayed. I then rerun the command: Probably a mistake in pasting the same as before. This command wouldn't need the password for the private key. > msmtp -t < message.txt > > and the associated e-mail is sent. > > I wait a few minutes and the error repeats itself. > > Is there some sort of timeout associated with gpg? Or my > implementation is wrong?or ? > > Also, I have noticed, at times, gpg will not accept the passphrase > until I reboot the Raspberry pi 4. See gpg-agent settings. The few minutes it works, that's because gpg- agent has the decrypted gpg key cached. You would need to increase that timeout, or let the script provide the password directly to gpg / use a passwordless key. When the sending fails, it should perhaps be asking you to provide the gpg passphrase, my guess is that the way it runs ( --no-tty --batch maybe), it isn't able to launch a pinentry to ask the password to the user. If you really want the password decryption to be unattended, you could configure the gpg password in the script, but then that would be roughly equivalent to the email account password. It's turtles all way down. Regards _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users From angel at pgp.16bits.net Sat Dec 19 00:50:20 2020 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Sat, 19 Dec 2020 00:50:20 +0100 Subject: GPG Decrypt Error based on a timeout function? In-Reply-To: <005401d6d56b$3a8c2b90$afa482b0$@gmail.com> References: <008e01d6d4aa$dde50170$99af0450$@gmail.com> <711e7efdcb2538c741bfb4724bb4af226868d546.camel@16bits.net> <005401d6d56b$3a8c2b90$afa482b0$@gmail.com> Message-ID: <96cea8341f87a386e2a8abb1c7ef5f54e43fe86d.camel@16bits.net> On 2020-12-18 at 10:25 -0800, Dave via Gnupg-users wrote: > Angel, > Yes, I want the script to run unattended, which the gpg process is > not the right method, as you say: " you could configure the gpg > password in the script, but then that would be roughly equivalent to > the email account password." > > Many thanks and stay safe and healthy, > Dave You cannot make a machine which needs a secret run fully unattended without having such secret *somewhere*. You can move pieces around, separate roles amongst different parts, protect a secret in a way that a _different_ secret is needed instead, etc. But in the end, as the machine needs that secret, you need to store it there. Or, alternatively, have a human input it and have it stored in memory, with the caveat that the machine won't be able to boot to a fully functional state until that is provided. From donnellydw at gmail.com Sat Dec 19 00:58:55 2020 From: donnellydw at gmail.com (donnellydw at gmail.com) Date: Fri, 18 Dec 2020 15:58:55 -0800 Subject: GPG Decrypt Error based on a timeout function? In-Reply-To: <96cea8341f87a386e2a8abb1c7ef5f54e43fe86d.camel@16bits.net> References: <008e01d6d4aa$dde50170$99af0450$@gmail.com> <711e7efdcb2538c741bfb4724bb4af226868d546.camel@16bits.net> <005401d6d56b$3a8c2b90$afa482b0$@gmail.com> <96cea8341f87a386e2a8abb1c7ef5f54e43fe86d.camel@16bits.net> Message-ID: <004001d6d599$bfd1d240$3f7576c0$@gmail.com> Angel, I came to that realization as I worked through with your guidance, the configuration I wanted. Technology, while here to help, can be a drawback at times. Or perhaps better said, has its own limitations. Many thanks and stay safe. Dave -----Original Message----- From: Gnupg-users On Behalf Of ?ngel Sent: Friday, December 18, 2020 3:50 PM To: gnupg-users at gnupg.org Subject: Re: GPG Decrypt Error based on a timeout function? On 2020-12-18 at 10:25 -0800, Dave via Gnupg-users wrote: > Angel, > Yes, I want the script to run unattended, which the gpg process is > not the right method, as you say: " you could configure the gpg > password in the script, but then that would be roughly equivalent to > the email account password." > > Many thanks and stay safe and healthy, Dave You cannot make a machine which needs a secret run fully unattended without having such secret *somewhere*. You can move pieces around, separate roles amongst different parts, protect a secret in a way that a _different_ secret is needed instead, etc. But in the end, as the machine needs that secret, you need to store it there. Or, alternatively, have a human input it and have it stored in memory, with the caveat that the machine won't be able to boot to a fully functional state until that is provided. _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users From wk at gnupg.org Sat Dec 19 18:36:25 2020 From: wk at gnupg.org (Werner Koch) Date: Sat, 19 Dec 2020 18:36:25 +0100 Subject: Does GPG Ever Store RSA Secret Keys On The Disk In Plain? In-Reply-To: <83cf1f93-b717-9d21-9b4f-500e458afd3d@informatik.hu-berlin.de> (Annie Yousar via Gnupg-users's message of "Fri, 18 Dec 2020 12:54:04 +0100") References: <427aa3c8-2dab-90b2-007e-daa0386ae2a0@bu.edu> <83cf1f93-b717-9d21-9b4f-500e458afd3d@informatik.hu-berlin.de> Message-ID: <87eejly9ye.fsf@wheatstone.g10code.de> On Fri, 18 Dec 2020 12:54, Annie Yousar said: > The key is not encrypted with the passphrase, but with a secret key > derived (by S2K) from the passphrase with the help of a > salt. Therefore each export gives different export data, despite using > the same passphrase. That is because GnuPG internally stores the secret key in a different format than what is specified for the OpenPGP secret key exchange format. Thus in general we need to re-encrypt the secret key for export and thus a fresh salt is used. Also not yet officially specified, it is also okay to export the internal format (those <40hexdigits>.key files). This is often useful if an encryption subkey needs to be shared between members of a team (role accounts etc.) Please take care if planning this because those key files may contain meta data (e.g. a description of the key) and the passphrase is not as strong as usual OpenPGP encryption. Thus convey only over a secure channel (i.e. with an additional encryption and authentication layer). Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From alexander at kriegisch.name Sun Dec 20 07:49:19 2020 From: alexander at kriegisch.name (Alexander Kriegisch) Date: Sun, 20 Dec 2020 07:49:19 +0100 (CET) Subject: Split private key in order to share among users Message-ID: <20201220064919.4308E3388C0C@dd39516.kasserver.com> The original PGP used to have this feature around 20 years ago already, maybe some people remember. In the list archive I found two threads, both several years old, asking about this feature in GnuPG, but there were no conclusive answers, only workaround suggestions like to split the binary or ASCII key file or print the password and share parts of the passwords, neither of which satisfy the original requirements covered by the original PGP functionality. Example: I split a private key file with PGP into these shares: -- User A gets a piece of key worth 2 shares. -- User B gets a piece of key worth 2 shares. -- User C gets a piece of key worth 1 share. -- User D gets a piece of key worth 1 share. -- User E gets a piece of key worth 1 share. -- User F gets a piece of key worth 1 share. I define that at least 5 shares are necessary to re-assemble a valid decryption key, i.e. we need for example -- A + B + one other user -- C + D + E + either A or B for decryption. I.e. neither the 4 minor nor the 2 major users alone can decrypt, we need at least 3 of 6 users and a majority of shares in order to decrypt. I remember I used to use this in the past and it worked flawlessly. I have no idea why this killer feature was omitted when implementing GnuPG. But maybe I am missing something in the documentation. If anyone knows how to do this using GnuPG or an alternative open source product, I would like to hear about it. Please do not suggest inadequate workarounds like the ones I mentioned above and which previously have been discussed here yet. Regards -- Alexander Kriegisch https://scrum-master.de From andrewg at andrewg.com Sun Dec 20 11:05:25 2020 From: andrewg at andrewg.com (Andrew Gallagher) Date: Sun, 20 Dec 2020 10:05:25 +0000 Subject: Split private key in order to share among users In-Reply-To: <20201220064919.4308E3388C0C@dd39516.kasserver.com> References: <20201220064919.4308E3388C0C@dd39516.kasserver.com> Message-ID: <762C7665-7626-4FEB-98C6-9BDA9F567E83@andrewg.com> > On 20 Dec 2020, at 09:19, Alexander Kriegisch wrote: > > ?The original PGP used to have this feature around 20 years ago already, > maybe some people remember. In the list archive I found two threads, > both several years old, asking about this feature in GnuPG, but there > were no conclusive answers, only workaround suggestions like to split > the binary or ASCII key file or print the password and share parts of > the passwords, neither of which satisfy the original requirements > covered by the original PGP functionality. Example: > > I split a private key file with PGP into these shares: > -- User A gets a piece of key worth 2 shares. > -- User B gets a piece of key worth 2 shares. > -- User C gets a piece of key worth 1 share. > -- User D gets a piece of key worth 1 share. > -- User E gets a piece of key worth 1 share. > -- User F gets a piece of key worth 1 share. > > I define that at least 5 shares are necessary to re-assemble a valid > decryption key, i.e. we need for example > -- A + B + one other user > -- C + D + E + either A or B > for decryption. > You?re referring to Shamir?s secret sharing scheme, for which several implementations exist. If you are using Linux, it should be as simple as installing the ?ssss? package. A From Alexander at Kriegisch.name Sun Dec 20 11:29:34 2020 From: Alexander at Kriegisch.name (Alexander Kriegisch) Date: Sun, 20 Dec 2020 17:29:34 +0700 Subject: Split private key in order to share among users In-Reply-To: <762C7665-7626-4FEB-98C6-9BDA9F567E83@andrewg.com> Message-ID: <20201220102937.AC7393380069@dd39516.kasserver.com> Thanks for the hint. Without searching the Web just yet in between two calls, do you happen to know of any option for Windows users??Regards?--?Alexander Kriegisch -------- Urspr?ngliche Nachricht --------Von: Andrew Gallagher Datum: 20.12.20 17:11 (GMT+07:00) An: Alexander Kriegisch Cc: gnupg-users at gnupg.org Betreff: Re: Split private key in order to share among users > On 20 Dec 2020, at 09:19, Alexander Kriegisch wrote:> > ?The original PGP used to have this feature around 20 years ago already,> maybe some people remember. In the list archive I found two threads,> both several years old, asking about this feature in GnuPG, but there> were no conclusive answers, only workaround suggestions like to split> the binary or ASCII key file or print the password and share parts of> the passwords, neither of which satisfy the original requirements> covered by the original PGP functionality. Example:> > I split a private key file with PGP into these shares:>? -- User A gets a piece of key worth 2 shares.>? -- User B gets a piece of key worth 2 shares.>? -- User C gets a piece of key worth 1 share.>? -- User D gets a piece of key worth 1 share.>? -- User E gets a piece of key worth 1 share.>? -- User F gets a piece of key worth 1 share.> > I define that at least 5 shares are necessary to re-assemble a valid> decryption key, i.e. we need for example>? -- A + B + one other user>? -- C + D + E + either A or B> for decryption.> You?re referring to Shamir?s secret sharing scheme, for which several implementations exist. If you are using Linux, it should be as simple as installing the ?ssss? package. A -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailinglist at chiraag.me Sun Dec 20 10:57:51 2020 From: mailinglist at chiraag.me (=?utf-8?B?4LKa4LK/4LKw4LK+4LKX4LONIOCyqOCyn+CysOCyvuCynOCzjQ==?=) Date: Sun, 20 Dec 2020 09:57:51 +0000 Subject: Split private key in order to share among users In-Reply-To: <20201220064919.4308E3388C0C@dd39516.kasserver.com> References: <20201220064919.4308E3388C0C@dd39516.kasserver.com> Message-ID: I believe you're talking about an implementation of Shamir's Secret Sharing Scheme. http://point-at-infinity.org/ssss/ should do what you want. - Chiraag -- ?????? ?????? Pronouns: he/him/his -------------- next part -------------- A non-text attachment was scrubbed... Name: publickey - mailinglist at chiraag.me - b0c8d720.asc Type: application/pgp-keys Size: 659 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 233 bytes Desc: OpenPGP digital signature URL: From spam.trap.mailing.lists at gmail.com Sun Dec 20 13:51:30 2020 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Sun, 20 Dec 2020 13:51:30 +0100 Subject: Split private key in order to share among users In-Reply-To: <20201220102937.AC7393380069@dd39516.kasserver.com> References: <762C7665-7626-4FEB-98C6-9BDA9F567E83@andrewg.com> <20201220102937.AC7393380069@dd39516.kasserver.com> Message-ID: On Sun, Dec 20, 2020 at 11:32 AM Alexander Kriegisch wrote: > > Thanks for the hint. Without searching the Web just yet in between two calls, do you happen to know of any option for Windows users? An option would be if you would install a modern programming language like Google's Golang which then would allow you to easily cross-compile apps, say you need for Windows, one of your friends needs for macOS and another one for various Linux flavors. https://golang.org/dl/ https://github.com/search?l=Go&q=shamirs+secret+sharing&type=Repositories Regards Stefan From spam.trap.mailing.lists at gmail.com Sun Dec 20 14:08:56 2020 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Sun, 20 Dec 2020 14:08:56 +0100 Subject: Split private key in order to share among users In-Reply-To: References: <762C7665-7626-4FEB-98C6-9BDA9F567E83@andrewg.com> <20201220102937.AC7393380069@dd39516.kasserver.com> Message-ID: On Sun, Dec 20, 2020 at 1:51 PM Stefan Claas wrote: > > On Sun, Dec 20, 2020 at 11:32 AM Alexander Kriegisch > wrote: > > > > Thanks for the hint. Without searching the Web just yet in between two calls, do you happen to know of any option for Windows users? > > An option would be if you would install a modern programming language like > Google's Golang which then would allow you to easily cross-compile apps, say > you need for Windows, one of your friends needs for macOS and another one for > various Linux flavors. > > https://golang.org/dl/ > > https://github.com/search?l=Go&q=shamirs+secret+sharing&type=Repositories And if you are a Windows 10 user you could additionally install from the Microsoft Store WSL (Windows Subsystem for Linux) so that you have a bash shell, same as cmd.exe or Powershell and then could install also Linux packages or with the Golang option use a script to cross-compile for all platforms automatically. That way you have the best of all worlds. :-) Regards Stefan From mark at truenorth.nu Sun Dec 20 15:32:02 2020 From: mark at truenorth.nu (Mark Gannon) Date: Sun, 20 Dec 2020 09:32:02 -0500 Subject: Unable to set values on Yubikey Message-ID: <2000695.xmpvqLtR4s@bluemeanie> Hello, Using GPG version 2.2.25 I am unable to set values other than the user and admin pins. When I use the verify function to check the pin, it is successful. This happens both on a new Yubikey 5 and a Yubikey 4 that was reset. Steps to reproduce 1. Set user and admin pins. 2. Run "gpg --card-edit" 3. Enter admin mode with the admin command 4. Enter name 5. Enter surname 6. Enter first name Produces the response: gpg: error setting Name: Bad PIN Note, it does not prompt me for the PIN before producing the error. gpg --card-status produces: Reader ...........: Yubico YubiKey OTP FIDO CCID 00 00 Application ID ...: D2760001240103040006157585540000 Application type .: OpenPGP Version ..........: 3.4 Manufacturer .....: Yubico Serial number ....: 15758554 Name of cardholder: [not set] Language prefs ...: [not set] Salutation .......: URL of public key : [not set] Login data .......: [not set] Signature PIN ....: not forced Key attributes ...: rsa2048 rsa2048 rsa2048 Max. PIN lengths .: 127 127 127 PIN retry counter : 0 0 0 Signature counter : 0 KDF setting ......: off Signature key ....: [none] Encryption key....: [none] Authentication key: [none] General key info..: [none] Thank you for your assistance. Mark Gannon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From kloecker at kde.org Sun Dec 20 17:59:41 2020 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Sun, 20 Dec 2020 17:59:41 +0100 Subject: Unable to set values on Yubikey In-Reply-To: <2000695.xmpvqLtR4s@bluemeanie> References: <2000695.xmpvqLtR4s@bluemeanie> Message-ID: <6439771.DdFoHc9PU5@breq> On Sonntag, 20. Dezember 2020 15:32:02 CET Mark Gannon wrote: > Hello, > > Using GPG version 2.2.25 I am unable to set values other than the user and > admin pins. When I use the verify function to check the pin, it is > successful. This happens both on a new Yubikey 5 and a Yubikey 4 that was > reset. > > Steps to reproduce > 1. Set user and admin pins. Did you set those PINs with gpg? Or did you use some other application? > 2. Run "gpg --card-edit" > 3. Enter admin mode with the admin command > 4. Enter name > 5. Enter surname > 6. Enter first name > > Produces the response: > gpg: error setting Name: Bad PIN > Note, it does not prompt me for the PIN before producing the error. > > > gpg --card-status produces: [snip] > PIN retry counter : 0 0 0 All PIN retry counters are 0, i.e. user PIN and admin PIN are both blocked. Either gpg reads the values incorrectly from the Yubikey or you have entered "wrong" PINs several times while experimenting with the Yubikey. Since even the admin PIN is blocked, I guess you need to factory-reset the Yubikey. To debug this run gpg --debug=ipc --card-status This will show the communication between gpg and scdaemon (the smartcard helper application that gpg uses to access smartcards). Regards, Ingo From cqcallaw at brainvitamins.net Sun Dec 20 22:12:34 2020 From: cqcallaw at brainvitamins.net (cqcallaw) Date: Sun, 20 Dec 2020 21:12:34 +0000 Subject: Browser extension to verify PGP-signed dWebpages Message-ID: Hi folks, Slightly off-topic, but in case anyone's interested, I've built a browser extension to verify PGP-signed dWebpages: https://github.com/cqcallaw/qui The extension won't (intentionally) leak private data, but constructive criticism and user feedback is welcome. Cheers, -Caleb -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander at kriegisch.name Mon Dec 21 01:50:59 2020 From: alexander at kriegisch.name (Alexander Kriegisch) Date: Mon, 21 Dec 2020 01:50:59 +0100 (CET) Subject: Split private key in order to share among users In-Reply-To: References: <20201220064919.4308E3388C0C@dd39516.kasserver.com> Message-ID: <20201221005059.2220B33806EA@dd39516.kasserver.com> ?????? ?????? schrieb am 20.12.2020 16:57 (GMT +07:00): > I believe you're talking about an implementation of Shamir's Secret > Sharing Scheme. http://point-at-infinity.org/ssss/ should do what you > want. Yes, that is exactly what I was looking for. I did some follow-up reading. Thanks for the enlightening pointer and greetings to Karnataka (I guess). Stefan Claas schrieb am 20.12.2020 19:51 (GMT +07:00): > An option would be if you would install a modern programming language > like Google's Golang which then would allow you to easily > cross-compile apps (...) > > https://github.com/search?l=Go&q=shamirs+secret+sharing&type=Repositories > > And if you are a Windows 10 user you could additionally install from > the Microsoft Store WSL (Windows Subsystem for Linux) so that you have > a bash shell, same as cmd.exe or Powershell and then could install > also Linux packages or with the Golang option use a script to > cross-compile for all platforms automatically. That way you have the > best of all worlds. :-) Thanks for the helpful information. I have WSL installed already and also know how to compile with MSYS2 or Cygwin. Cross-compilation I know from old times when I was using it in my Freetz project (Fritz!Box DSL router firmware cross-compilation). Instead of starting with Go and compiling native applications I took the easy route and searched GitHub for Java packages. This one works nicely and has a library as well as a CLI artifact available on Maven Central: https://github.com/secretsharing/secretsharing Cheers -- Alexander Kriegisch https://scrum-master.de From telegraph at gmx.net Mon Dec 21 11:47:43 2020 From: telegraph at gmx.net (Gregor Zattler) Date: Mon, 21 Dec 2020 11:47:43 +0100 Subject: pinentry-{qt,gtk2,gnome3} stopped working pinentry-fltk works, why? Message-ID: <20201221104743.GC12405@no.workgroup> Dear gnupg users, since Friday pinentry-{qt,gtk2,gnome3} stopped working. When I want to decrypt some .gpg file, no dialog appears and gpg-agent times out. Luckily pinentry-curses and pinentry-fltk still do work. This is on a debian buster system with gpg* packages from backports, pinentry* packages from buster (since there are no backports). I found the debug-level directive for gpg-agent and set it to expert. I edited the log, the edited parts are identical between the two sessions. This is the debug info when using pinentry-flkt, which succeeds: 2020-12-21 11:34:07 gpg-agent[4706] gpg-agent (GnuPG) 2.2.20 starting in supervised mode. 2020-12-21 11:34:07 gpg-agent[4706] using fd 3 for browser socket (/run/user/1000/gnupg/S.gpg-agent.browser) 2020-12-21 11:34:07 gpg-agent[4706] using fd 4 for ssh socket (/run/user/1000/gnupg/S.gpg-agent.ssh) 2020-12-21 11:34:07 gpg-agent[4706] using fd 5 for extra socket (/run/user/1000/gnupg/S.gpg-agent.extra) 2020-12-21 11:34:07 gpg-agent[4706] using fd 6 for std socket (/run/user/1000/gnupg/S.gpg-agent) 2020-12-21 11:34:07 gpg-agent[4706] listening on: std=6 extra=5 browser=3 ssh=4 2020-12-21 11:34:07 gpg-agent[4706] DBG: chan_10 -> OK Pleased to meet you, process 4704 2020-12-21 11:34:07 gpg-agent[4706] DBG: chan_10 <- RESET 2020-12-21 11:34:07 gpg-agent[4706] DBG: chan_10 -> OK 2020-12-21 11:34:07 gpg-agent[4706] DBG: chan_10 <- OPTION ttyname=/dev/pts/8 2020-12-21 11:34:07 gpg-agent[4706] DBG: chan_10 -> OK 2020-12-21 11:34:07 gpg-agent[4706] DBG: chan_10 <- OPTION ttytype=screen-256color-bce-s 2020-12-21 11:34:07 gpg-agent[4706] DBG: chan_10 -> OK 2020-12-21 11:34:07 gpg-agent[4706] DBG: chan_10 <- OPTION display=:0 2020-12-21 11:34:07 gpg-agent[4706] DBG: chan_10 -> OK 2020-12-21 11:34:07 gpg-agent[4706] DBG: chan_10 <- OPTION xauthority=/home/grfz/.Xauthority 2020-12-21 11:34:07 gpg-agent[4706] DBG: chan_10 -> OK 2020-12-21 11:34:07 gpg-agent[4706] DBG: chan_10 <- OPTION putenv=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus 2020-12-21 11:34:07 gpg-agent[4706] DBG: chan_10 -> OK 2020-12-21 11:34:07 gpg-agent[4706] DBG: chan_10 <- OPTION lc-ctype=de_DE.utf8 2020-12-21 11:34:07 gpg-agent[4706] DBG: chan_10 -> OK 2020-12-21 11:34:07 gpg-agent[4706] DBG: chan_10 <- OPTION lc-messages=C 2020-12-21 11:34:07 gpg-agent[4706] DBG: chan_10 -> OK 2020-12-21 11:34:07 gpg-agent[4706] DBG: chan_10 <- GETINFO version 2020-12-21 11:34:07 gpg-agent[4706] DBG: chan_10 -> D 2.2.20 2020-12-21 11:34:07 gpg-agent[4706] DBG: chan_10 -> OK 2020-12-21 11:34:07 gpg-agent[4706] DBG: chan_10 <- OPTION allow-pinentry-notify 2020-12-21 11:34:07 gpg-agent[4706] DBG: chan_10 -> OK 2020-12-21 11:34:07 gpg-agent[4706] DBG: chan_10 <- OPTION agent-awareness=2.1.0 2020-12-21 11:34:07 gpg-agent[4706] DBG: chan_10 -> OK 2020-12-21 11:34:07 gpg-agent[4706] DBG: chan_10 <- HAVEKEY xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 2020-12-21 11:34:07 gpg-agent[4706] DBG: chan_10 -> OK 2020-12-21 11:34:07 gpg-agent[4706] DBG: chan_10 <- HAVEKEY xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 2020-12-21 11:34:07 gpg-agent[4706] DBG: chan_10 -> OK 2020-12-21 11:34:07 gpg-agent[4706] DBG: chan_10 <- HAVEKEY xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 2020-12-21 11:34:07 gpg-agent[4706] DBG: chan_10 -> OK 2020-12-21 11:34:07 gpg-agent[4706] DBG: chan_10 <- RESET 2020-12-21 11:34:07 gpg-agent[4706] DBG: chan_10 -> OK 2020-12-21 11:34:07 gpg-agent[4706] DBG: chan_10 <- SETKEY xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 2020-12-21 11:34:07 gpg-agent[4706] DBG: chan_10 -> OK 2020-12-21 11:34:07 gpg-agent[4706] DBG: chan_10 <- SETKEYDESC Please+enter+the+passphrase+to+unlock+the+OpenPGP+secret+key:%0A%22Gregor+Zattler+(do+not+use+texmex at uni.de+any+more)+%22%0A4096-bit+ELG+key,+ID+0xAD8A61F5F877E5F0,%0Acreated+2001-09-29+(main+key+ID+0xF2EB825AD25307CA).%0A 2020-12-21 11:34:07 gpg-agent[4706] DBG: chan_10 -> OK 2020-12-21 11:34:07 gpg-agent[4706] DBG: chan_10 <- PKDECRYPT 2020-12-21 11:34:07 gpg-agent[4706] DBG: chan_10 -> S INQUIRE_MAXLEN 4096 2020-12-21 11:34:07 gpg-agent[4706] DBG: chan_10 -> INQUIRE CIPHERTEXT 2020-12-21 11:34:07 gpg-agent[4706] DBG: chan_10 <- [ xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx ...(982 byte(s) skipped) ] 2020-12-21 11:34:07 gpg-agent[4706] DBG: chan_10 <- [ xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx ...(84 byte(s) skipped) ] 2020-12-21 11:34:07 gpg-agent[4706] DBG: chan_10 <- END 2020-12-21 11:34:07 gpg-agent[4706] DBG: agent_get_cache 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'.0 (mode 2) ... 2020-12-21 11:34:07 gpg-agent[4706] DBG: ... miss 2020-12-21 11:34:07 gpg-agent[4706] starting a new PIN Entry 2020-12-21 11:34:07 gpg-agent[4706] DBG: connection to PIN entry established 2020-12-21 11:34:07 gpg-agent[4706] DBG: chan_10 -> INQUIRE PINENTRY_LAUNCHED 4708 fltk 1.1.0 /dev/pts/8 screen-256color-bce-s :0 2020-12-21 11:34:07 gpg-agent[4706] DBG: chan_10 <- END 2020-12-21 11:34:20 gpg-agent[4706] DBG: agent_put_cache 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'.0 (mode 2) requested ttl=0 2020-12-21 11:34:20 gpg-agent[4706] DBG: chan_10 -> [ xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx ...(517 byte(s) skipped) ] 2020-12-21 11:34:20 gpg-agent[4706] DBG: chan_10 -> OK 2020-12-21 11:34:20 gpg-agent[4706] DBG: chan_10 <- [eof] 2020-12-21 11:34:47 gpg-agent[4706] SIGTERM received - shutting down ... 2020-12-21 11:34:47 gpg-agent[4706] gpg-agent (GnuPG) 2.2.20 stopped This is the debug info when using pinentry-qt, which fails: 2020-12-21 11:35:02 gpg-agent[5108] gpg-agent (GnuPG) 2.2.20 starting in supervised mode. 2020-12-21 11:35:02 gpg-agent[5108] using fd 3 for browser socket (/run/user/1000/gnupg/S.gpg-agent.browser) 2020-12-21 11:35:02 gpg-agent[5108] using fd 4 for ssh socket (/run/user/1000/gnupg/S.gpg-agent.ssh) 2020-12-21 11:35:02 gpg-agent[5108] using fd 5 for extra socket (/run/user/1000/gnupg/S.gpg-agent.extra) 2020-12-21 11:35:02 gpg-agent[5108] using fd 6 for std socket (/run/user/1000/gnupg/S.gpg-agent) 2020-12-21 11:35:02 gpg-agent[5108] listening on: std=6 extra=5 browser=3 ssh=4 2020-12-21 11:35:02 gpg-agent[5108] DBG: chan_10 -> OK Pleased to meet you, process 5106 2020-12-21 11:35:02 gpg-agent[5108] DBG: chan_10 <- RESET 2020-12-21 11:35:02 gpg-agent[5108] DBG: chan_10 -> OK 2020-12-21 11:35:02 gpg-agent[5108] DBG: chan_10 <- OPTION ttyname=/dev/pts/8 2020-12-21 11:35:02 gpg-agent[5108] DBG: chan_10 -> OK 2020-12-21 11:35:02 gpg-agent[5108] DBG: chan_10 <- OPTION ttytype=screen-256color-bce-s 2020-12-21 11:35:02 gpg-agent[5108] DBG: chan_10 -> OK 2020-12-21 11:35:02 gpg-agent[5108] DBG: chan_10 <- OPTION display=:0 2020-12-21 11:35:02 gpg-agent[5108] DBG: chan_10 -> OK 2020-12-21 11:35:02 gpg-agent[5108] DBG: chan_10 <- OPTION xauthority=/home/grfz/.Xauthority 2020-12-21 11:35:02 gpg-agent[5108] DBG: chan_10 -> OK 2020-12-21 11:35:02 gpg-agent[5108] DBG: chan_10 <- OPTION putenv=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus 2020-12-21 11:35:02 gpg-agent[5108] DBG: chan_10 -> OK 2020-12-21 11:35:02 gpg-agent[5108] DBG: chan_10 <- OPTION lc-ctype=de_DE.utf8 2020-12-21 11:35:02 gpg-agent[5108] DBG: chan_10 -> OK 2020-12-21 11:35:02 gpg-agent[5108] DBG: chan_10 <- OPTION lc-messages=C 2020-12-21 11:35:02 gpg-agent[5108] DBG: chan_10 -> OK 2020-12-21 11:35:02 gpg-agent[5108] DBG: chan_10 <- GETINFO version 2020-12-21 11:35:02 gpg-agent[5108] DBG: chan_10 -> D 2.2.20 2020-12-21 11:35:02 gpg-agent[5108] DBG: chan_10 -> OK 2020-12-21 11:35:02 gpg-agent[5108] DBG: chan_10 <- OPTION allow-pinentry-notify 2020-12-21 11:35:02 gpg-agent[5108] DBG: chan_10 -> OK 2020-12-21 11:35:02 gpg-agent[5108] DBG: chan_10 <- OPTION agent-awareness=2.1.0 2020-12-21 11:35:02 gpg-agent[5108] DBG: chan_10 -> OK 2020-12-21 11:35:02 gpg-agent[5108] DBG: chan_10 <- HAVEKEY xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 2020-12-21 11:35:02 gpg-agent[5108] DBG: chan_10 -> OK 2020-12-21 11:35:02 gpg-agent[5108] DBG: chan_10 <- HAVEKEY xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 2020-12-21 11:35:02 gpg-agent[5108] DBG: chan_10 -> OK 2020-12-21 11:35:02 gpg-agent[5108] DBG: chan_10 <- HAVEKEY xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 2020-12-21 11:35:02 gpg-agent[5108] DBG: chan_10 -> OK 2020-12-21 11:35:02 gpg-agent[5108] DBG: chan_10 <- RESET 2020-12-21 11:35:02 gpg-agent[5108] DBG: chan_10 -> OK 2020-12-21 11:35:02 gpg-agent[5108] DBG: chan_10 <- SETKEY xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 2020-12-21 11:35:02 gpg-agent[5108] DBG: chan_10 -> OK 2020-12-21 11:35:02 gpg-agent[5108] DBG: chan_10 <- SETKEYDESC Please+enter+the+passphrase+to+unlock+the+OpenPGP+secret+key:%0A%22Gregor+Zattler+(do+not+use+texmex at uni.de+any+more)+%22%0A4096-bit+ELG+key,+ID+0xAD8A61F5F877E5F0,%0Acreated+2001-09-29+(main+key+ID+0xF2EB825AD25307CA).%0A 2020-12-21 11:35:02 gpg-agent[5108] DBG: chan_10 -> OK 2020-12-21 11:35:02 gpg-agent[5108] DBG: chan_10 <- PKDECRYPT 2020-12-21 11:35:02 gpg-agent[5108] DBG: chan_10 -> S INQUIRE_MAXLEN 4096 2020-12-21 11:35:02 gpg-agent[5108] DBG: chan_10 -> INQUIRE CIPHERTEXT 2020-12-21 11:35:02 gpg-agent[5108] DBG: chan_10 <- [ xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx ...(982 byte(s) skipped) ] 2020-12-21 11:35:02 gpg-agent[5108] DBG: chan_10 <- [ xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx ...(84 byte(s) skipped) ] 2020-12-21 11:35:02 gpg-agent[5108] DBG: chan_10 <- END 2020-12-21 11:35:02 gpg-agent[5108] DBG: agent_get_cache 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'.0 (mode 2) ... 2020-12-21 11:35:02 gpg-agent[5108] DBG: ... miss 2020-12-21 11:35:02 gpg-agent[5108] starting a new PIN Entry 2020-12-21 11:35:02 gpg-agent[5108] DBG: connection to PIN entry established 2020-12-21 11:35:02 gpg-agent[5108] DBG: chan_10 -> INQUIRE PINENTRY_LAUNCHED 5110 qt 1.1.0 /dev/pts/8 screen-256color-bce-s :0 2020-12-21 11:35:02 gpg-agent[5108] DBG: chan_10 <- END 2020-12-21 11:36:02 gpg-agent[5108] DBG: error calling pinentry: Timeout 2020-12-21 11:36:02 gpg-agent[5108] failed to unprotect the secret key: Timeout 2020-12-21 11:36:02 gpg-agent[5108] failed to read the secret key 2020-12-21 11:36:02 gpg-agent[5108] command 'PKDECRYPT' failed: Timeout 2020-12-21 11:36:02 gpg-agent[5108] DBG: chan_10 -> ERR 83886142 Timeout 2020-12-21 11:36:02 gpg-agent[5108] DBG: chan_10 <- [eof] Any idea who to get pinentry-qt working again? It simply shows most of the key uid in question. Ciao, Gregor -- -... --- .-. . -.. ..--.. ...-.- From telegraph at gmx.net Mon Dec 21 12:03:16 2020 From: telegraph at gmx.net (Gregor Zattler) Date: Mon, 21 Dec 2020 12:03:16 +0100 Subject: Forget it, user error (was: Re: pinentry-{qt,gtk2,gnome3} stopped working pinentry-fltk works, why?) In-Reply-To: <20201221104743.GC12405@no.workgroup> References: <20201221104743.GC12405@no.workgroup> Message-ID: <20201221110316.GD12405@no.workgroup> Dear gnupg users, the pinetry-qt window now shows up again, behind other windows... Sorry for the noise, Gregor * Gregor Zattler [21. Dez. 2020]: > Dear gnupg users, since Friday pinentry-{qt,gtk2,gnome3} > stopped working. When I want to decrypt some .gpg file, no dialog > appears and gpg-agent times out. Luckily pinentry-curses and > pinentry-fltk still do work. > > This is on a debian buster system with gpg* packages from backports, > pinentry* packages from buster (since there are no backports). [...] Ciao, Gregor -- -... --- .-. . -.. ..--.. ...-.- From wk at gnupg.org Mon Dec 21 19:26:37 2020 From: wk at gnupg.org (Werner Koch) Date: Mon, 21 Dec 2020 19:26:37 +0100 Subject: [Announce] GnuPG 2.2.26 released Message-ID: <87mty7vwv6.fsf@wheatstone.g10code.de> Hello! We are pleased to announce the availability of a new GnuPG release: version 2.2.26. This is a maintenance release improving support for LDAP keyservers and enterprise use. What is GnuPG ============= The GNU Privacy Guard (GnuPG, GPG) is a complete and free implementation of the OpenPGP and S/MIME standards. GnuPG 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. The separate library GPGME provides a uniform API to use the GnuPG engine by software written in common programming languages. A wealth of frontend applications and libraries making use of GnuPG are available. As an universal crypto engine 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. Noteworthy changes in version 2.2.26 ==================================== * gpg: New AKL method "ntds". * gpg: Fix --trusted-key with fingerprint arg. * scd: Fix writing of ECC keys to an OpenPGP card. [#5163] * scd: Make an USB error fix specific to SPR532 readers. [#5167] * dirmngr: With new LDAP keyservers store the new attributes. Never store the useless pgpSignerID. Fix a long standing bug storing some keys on an ldap server. * dirmngr: Support the new Active Direcory LDAP schema for keyservers. * dirmngr: Allow LDAP OpenPGP searches via fingerprint. * dirmngr: Do not block other threads during keyserver LDAP calls. * Support global configuration files. [#4788] * Fix the iconv fallback handling to UTF-8. [#5038] Release-info: https://dev.gnupg.org/T5153 Getting the Software ==================== Please follow the instructions found at or read on: GnuPG 2.2.26 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 . Note that GnuPG is not available at ftp.gnu.org. The GnuPG source code compressed using BZIP2 and its OpenPGP signature are available here: https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.26.tar.bz2 (7020k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.26.tar.bz2.sig An installer for Windows without any graphical frontend except for a very minimal Pinentry tool is available here: https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.26_20201221.exe (4249k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.26_20201221.exe.sig The source used to build the Windows installer can be found in the same directory with a ".tar.xz" suffix. New versions of the GnuPG VS-Desktop(tm) and Gpg4win featuring this version of GnuPG will be released shortly. 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.2.26.tar.bz2 you would use this command: gpg --verify gnupg-2.2.26.tar.bz2.sig gnupg-2.2.26.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 the end of this mail 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.2.26.tar.bz2, you run the command like this: sha1sum gnupg-2.2.26.tar.bz2 and check that the output matches the next line: 11ffe2ee80d594c3e83f123b9e189b630c0fe19d gnupg-2.2.26.tar.bz2 0ae3080532b53fe4fd5c05ae6efd1d05bb28365f gnupg-w32-2.2.26_20201221.tar.xz 6829e6250efedd8de09628104a9e15f5943b65c8 gnupg-w32-2.2.26_20201221.exe Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese (traditional and simplified), Czech, French, German, Italian, Japanese, Norwegian, Polish, Russian, and Ukrainian being almost completely translated. Documentation and Support ========================= 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 reference manual of the system. Separate man pages are included as well but they miss some of the details available only in thee manual. The manual is also available online at https://gnupg.org/documentation/manuals/gnupg/ or can be downloaded as PDF at https://gnupg.org/documentation/manuals/gnupg.pdf . You may also want to search the GnuPG mailing list archives or ask on the gnupg-users mailing list for advise on how to solve problems. Most of the new features are around for several years and thus enough public experience is available. https://wiki.gnupg.org has user contributed information around GnuPG and relate software. In case of build problems specific to this release please first check https://dev.gnupg.org/T5153 for updated information. Please consult the archive of the gnupg-users mailing list before reporting a bug: https://gnupg.org/documentation/mailing-lists.html. We suggest to send bug reports for a new release to this list in favor of filing a bug at https://bugs.gnupg.org. If you need commercial support go to https://gnupg.com or https://gnupg.org/service.html. If you are a developer and you need a certain feature for your project, please do not hesitate to bring it to the gnupg-devel mailing list for discussion. Thanks ====== Since 2001 maintenance and development of GnuPG is done by g10 Code GmbH and still mostly financed by donations. Two full-time employed developers as well as two contractors exclusively work on GnuPG and closely related software like Libgcrypt, GPGME and Gpg4win. We like to thank all the nice people who are helping the GnuPG project, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, or answering questions on the mailing lists. Many thanks to our numerous financial supporters, both corporate and individuals. Without you it would not be possible to keep GnuPG in a good and secure shape and to address all the small and larger requests made by our users. Thanks. Happy hacking, Your GnuPG hackers p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users'at'gnupg.org mailing list. p.p.s List of 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: ed25519 2020-08-24 [expires: 2030-06-30] Key fingerprint = 6DAA 6E64 A76D 2840 571B 4902 5288 97B8 2640 3ADA Werner Koch (dist signing 2020) rsa2048 2014-10-29 [expires: 2020-10-30] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa3072 2017-03-17 [expires: 2027-03-15] Key fingerprint = 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 Andre Heinecke (Release Signing Key) rsa2048 2011-01-12 [expires: 2021-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) The keys are available at https://gnupg.org/signature_key.html and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. -- "If privacy is outlawed, only outlaws will have privacy." - PRZ 1991 ... even the EU still does not get it. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 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 boskov at bu.edu Mon Dec 21 23:12:12 2020 From: boskov at bu.edu (=?UTF-8?Q?Novak_Bo=c5=a1kov?=) Date: Mon, 21 Dec 2020 17:12:12 -0500 Subject: Does GPG Ever Store RSA Secret Keys On The Disk In Plain? In-Reply-To: <83cf1f93-b717-9d21-9b4f-500e458afd3d@informatik.hu-berlin.de> References: <83cf1f93-b717-9d21-9b4f-500e458afd3d@informatik.hu-berlin.de> Message-ID: I am not sure that I follow. First, it looks like multiple exports _do_ result in the exactly same export data: > $ FIRST=$(gpg --export-secret-keys --armor ) > $ SECOND=$(gpg --export-secret-keys --armor ) > $ if [ "$FIRST" == "$SECOND" ]; then echo "Outputs are equal"; fi > $ Outputs are equal Which makes perfect sense to me. I would indeed expect my secret key encrypted with my passphrase to be the same across multiple invocations of the export command. If a salt is used, how come that I can take my key that I've gotten through a `gpg --export-secret-keys --armor ...` call and import it on a different machine using only my passphrase? Could you please elaborate a bit more on this or/and provide some useful resources? /Best regards, Novak / -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xB8D4C9837C741FBD.asc Type: application/pgp-keys Size: 2448 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Mon Dec 21 23:42:15 2020 From: wk at gnupg.org (Werner Koch) Date: Mon, 21 Dec 2020 23:42:15 +0100 Subject: Does GPG Ever Store RSA Secret Keys On The Disk In Plain? In-Reply-To: ("Novak \=\?utf-8\?Q\?Bo\=C5\=A1kov\=22's\?\= message of "Mon, 21 Dec 2020 17:12:12 -0500") References: <83cf1f93-b717-9d21-9b4f-500e458afd3d@informatik.hu-berlin.de> Message-ID: <87czz2wzlk.fsf@wheatstone.g10code.de> On Mon, 21 Dec 2020 17:12, Novak Bo?kov said: > First, it looks like multiple exports _do_ result in the exactly same > export data: What version of GnuPG are you using? A legacy 1.4 version or, worse, the unmaintained 2.0 version? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From boskov at bu.edu Tue Dec 22 00:47:15 2020 From: boskov at bu.edu (=?UTF-8?Q?Novak_Bo=c5=a1kov?=) Date: Mon, 21 Dec 2020 18:47:15 -0500 Subject: Does GPG Ever Store RSA Secret Keys On The Disk In Plain? In-Reply-To: <1937fe5e-b814-b6fd-5b98-c2f7a98b3efe@bu.edu> References: <83cf1f93-b717-9d21-9b4f-500e458afd3d@informatik.hu-berlin.de> <87czz2wzlk.fsf@wheatstone.g10code.de> <1937fe5e-b814-b6fd-5b98-c2f7a98b3efe@bu.edu> Message-ID: <2d2bf48d-4bb1-f110-ad08-c93e23e921ff@bu.edu> It is gpg version 2.2.4 with libgcrypt 1.8.1. So, the two subsequent exports are supposed to give me my private key encrypted with two different AES keys (same passphrase + a different salt)? How does transferring the keys to a different machine is supposed to work then? On 12/21/20 5:42 PM, Werner Koch wrote: > On Mon, 21 Dec 2020 17:12, Novak Bo?kov said: > >> First, it looks like multiple exports _do_ result in the exactly same >> export data: > What version of GnuPG are you using?? A legacy 1.4 version or, worse, > the unmaintained 2.0 version? > > > Shalom-Salam, > >??? Werner > -- Novak On 12/21/20 5:53 PM, Novak Bo?kov wrote: > So, the two subsequent exports are supposed to give me my private key > encrypted with two different AES keys (same passphrase + a different salt)? > How does transferring the keys to a different machine is supposed to > work then? > > On 12/21/20 5:42 PM, Werner Koch wrote: >> On Mon, 21 Dec 2020 17:12, Novak Bo?kov said: >> >>> First, it looks like multiple exports _do_ result in the exactly same >>> export data: >> What version of GnuPG are you using? A legacy 1.4 version or, worse, >> the unmaintained 2.0 version? >> >> >> Shalom-Salam, >> >> Werner >> > -- Novak -- ????Novak Bo?kov ????/PhD Student/ ????/Electrical & Computer Engineering Department/ ????/Boston University/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xB8D4C9837C741FBD.asc Type: application/pgp-keys Size: 2448 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Tue Dec 22 07:46:12 2020 From: wk at gnupg.org (Werner Koch) Date: Tue, 22 Dec 2020 07:46:12 +0100 Subject: Does GPG Ever Store RSA Secret Keys On The Disk In Plain? In-Reply-To: <2d2bf48d-4bb1-f110-ad08-c93e23e921ff@bu.edu> ("Novak \=\?utf-8\?Q\?Bo\=C5\=A1kov\=22's\?\= message of "Mon, 21 Dec 2020 18:47:15 -0500") References: <83cf1f93-b717-9d21-9b4f-500e458afd3d@informatik.hu-berlin.de> <87czz2wzlk.fsf@wheatstone.g10code.de> <1937fe5e-b814-b6fd-5b98-c2f7a98b3efe@bu.edu> <2d2bf48d-4bb1-f110-ad08-c93e23e921ff@bu.edu> Message-ID: <8735zywd6z.fsf@wheatstone.g10code.de> On Mon, 21 Dec 2020 18:47, Novak Bo?kov said: > So, the two subsequent exports are supposed to give me my private key > encrypted with two different AES keys (same passphrase + a different salt)? Right: First packet of the first export: # off=0 ctb=95 tag=5 hlen=3 plen=1414 :secret key packet: version 4, algo 1, created 1568715099, expires 0 pkey[0]: [3072 bits] pkey[1]: [17 bits] iter+salt S2K, algo: 7, SHA1 protection, hash: 2, salt: E28C8328510DEDC0 protect count: 30408704 (237) protect IV: 6e a3 36 63 19 2c fc 87 b2 c6 be d3 03 41 09 56 skey[2]: [v4 protected] keyid: F29010625F3EDDDA First packet of the second export: # off=0 ctb=95 tag=5 hlen=3 plen=1414 :secret key packet: version 4, algo 1, created 1568715099, expires 0 pkey[0]: [3072 bits] pkey[1]: [17 bits] iter+salt S2K, algo: 7, SHA1 protection, hash: 2, salt: 24725FA6DAA0883C protect count: 30408704 (237) protect IV: f5 29 51 fe 73 02 1a 31 19 fd bf fe ae 37 ef 23 skey[2]: [v4 protected] keyid: F29010625F3EDDDA You see that the salt and the IV are both different. The protection count is the same because this is a constant computed by gpg-agent at startup my measuring the speed of the KDF. The actual encrypted key data (not shown) is also different. > How does transferring the keys to a different machine is supposed to > work then? box1$ gpg --export-secret-key FINGERPRINT >key.sec box2$ gpg --import key.sec You need to enter the passphrase during export. For import the re-encryption is delayed until the key is used and thus you won't need a passphrase immediately. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From x10an14 at gmail.com Tue Dec 22 13:31:42 2020 From: x10an14 at gmail.com (Christian Chavez) Date: Tue, 22 Dec 2020 13:31:42 +0100 Subject: Rationale/reasons for splitting Sign and Authenticate into two separate subkeys in a work-environment? Message-ID: Hi! I'm currently helping my workplace test out Yubikeys - to see how/if they could help us with our software development. One expected benefit is to allow developers cryptographically sign Git commits/tags (e.g). My question is based on this awesome answer by Thomas Pornin: https://security.stackexchange.com/a/43591; *In a work-environment, what benefits does one gain by having separate Authentication/Signing (sub)keys?* I understand and agree with the rationale of keeping a separate Encryption key (so that this could be shared with your employer), but that rationale does not extend for Signing/Authenticating (presuming a trustworthy workplace which doesn't need to fake authentication/signing of employees). -- Med vennlig hilsen/Kind regards, Christian Chavez Phone/Tlf: +47 922 22 603 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dirkx at webweaving.org Tue Dec 22 14:54:40 2020 From: dirkx at webweaving.org (Dirk-Willem van Gulik) Date: Tue, 22 Dec 2020 14:54:40 +0100 Subject: Rationale/reasons for splitting Sign and Authenticate into two separate subkeys in a work-environment? In-Reply-To: References: Message-ID: <12BC79B5-E43D-4F13-9BBE-09EA9D026492@webweaving.org> On 22 Dec 2020, at 13:31, Christian Chavez via Gnupg-users wrote: > My question is based on this awesome answer by Thomas Pornin: https://security.stackexchange.com/a/43591 ; > In a work-environment, what benefits does one gain by having separate Authentication/Signing (sub)keys? > > I understand and agree with the rationale of keeping a separate Encryption key (so that this could be shared with your employer), but that rationale does not extend for Signing/Authenticating (presuming a trustworthy workplace which doesn't need to fake authentication/signing of employees). Keep in mind that in some workplaces the building of that trust explicitly includes the need for counter-intelligence - and hence a legitimate use of fake signatures. Though I have a hard time imagining a use case in the european private sector for that. Dw. -------------- next part -------------- An HTML attachment was scrubbed... URL: From x10an14 at gmail.com Tue Dec 22 16:16:19 2020 From: x10an14 at gmail.com (Christian Chavez) Date: Tue, 22 Dec 2020 16:16:19 +0100 Subject: Rationale/reasons for splitting Sign and Authenticate into two separate subkeys in a work-environment? In-Reply-To: <12BC79B5-E43D-4F13-9BBE-09EA9D026492@webweaving.org> References: <12BC79B5-E43D-4F13-9BBE-09EA9D026492@webweaving.org> Message-ID: Hi Dirk-Willem! Thanks for your reply - but I'm unfortunately lost as to your (what I surmise is your implied) hypothetical use-case? Ref: On Tue, Dec 22, 2020 at 2:56 PM Dirk-Willem van Gulik wrote: > Keep in mind that in some workplaces the building of that trust explicitly > includes the need for counter-intelligence - and hence a legitimate use of > fake signatures. > Though I have a hard time imagining a use case in the european private > sector for that. > Would you mind elaborating on when you'd foresee/imagine such a non-european/non-private sector have a need for this? There's nothing that would stop the user in question utilizing multiple separate "main" keys, and not just separate sub-keys per A, S, E capability in your scenario (even when A and S capabilities reside on the _same_ private/public sub-key pair). -- Med vennlig hilsen/Kind regards, Christian Chavez Phone/Tlf: +47 922 22 603 -------------- next part -------------- An HTML attachment was scrubbed... URL: From x10an14 at gmail.com Tue Dec 22 16:20:25 2020 From: x10an14 at gmail.com (Christian Chavez) Date: Tue, 22 Dec 2020 16:20:25 +0100 Subject: Rationale/reasons for splitting Sign and Authenticate into two separate subkeys in a work-environment? In-Reply-To: References: <12BC79B5-E43D-4F13-9BBE-09EA9D026492@webweaving.org> Message-ID: Nvm, apologies for the spam. I retract my question now after having conferred with a third-party. I understand now your hypothetical scenario - thanks! Does anyone else have any thoughts on the reduced complexity of juggling multiple (sub?)keys vs the security implications of not separating Authentication/Signing to different (sub?)keys? On Tue, Dec 22, 2020 at 4:16 PM Christian Chavez wrote: > Hi Dirk-Willem! > Thanks for your reply - but I'm unfortunately lost as to your (what I > surmise is your implied) hypothetical use-case? > > Ref: > On Tue, Dec 22, 2020 at 2:56 PM Dirk-Willem van Gulik < > dirkx at webweaving.org> wrote: > >> Keep in mind that in some workplaces the building of that trust >> explicitly includes the need for counter-intelligence - and hence a >> legitimate use of fake signatures. >> Though I have a hard time imagining a use case in the european private >> sector for that. >> > > Would you mind elaborating on when you'd foresee/imagine such a > non-european/non-private sector have a need for this? > There's nothing that would stop the user in question utilizing multiple > separate "main" keys, and not just separate sub-keys per A, S, E > capability in your scenario (even when A and S capabilities reside on the > _same_ private/public sub-key pair). > > -- > Med vennlig hilsen/Kind regards, > Christian Chavez > Phone/Tlf: +47 922 22 603 > -- Med vennlig hilsen/Kind regards, Christian Chavez Phone/Tlf: +47 922 22 603 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dirkx at webweaving.org Tue Dec 22 16:19:47 2020 From: dirkx at webweaving.org (Dirk-Willem van Gulik) Date: Tue, 22 Dec 2020 16:19:47 +0100 Subject: Rationale/reasons for splitting Sign and Authenticate into two separate subkeys in a work-environment? In-Reply-To: References: <12BC79B5-E43D-4F13-9BBE-09EA9D026492@webweaving.org> Message-ID: On 22 Dec 2020, at 16:16, Christian Chavez wrote: > Thanks for your reply - but I'm unfortunately lost as to your (what I surmise is your implied) hypothetical use-case? It is a very common requirement that you find in gov. procurement documents/requirements of cryptographic technology that lives in a chipcard, HSM, etc -- the need to be able to forge signatures for counter intelligence. Dw. From Shelley.Ford at celero.ca Tue Dec 22 16:17:40 2020 From: Shelley.Ford at celero.ca (Shelley Ford) Date: Tue, 22 Dec 2020 15:17:40 +0000 Subject: How Do I Overwrite Files in GnuPG? Message-ID: Hi, I'm trying to overwrite existing files that have been encrypted. I've read that adding --yes and --batch --yes is the way to go; however with both I get: gpg: Note: '--yes' is not considered an option gpg: Note: '--batch' is not considered an option What I'm using: gpg --output e:\temp\test.txt.pgp --encrypt --recipient recipient at org e:\temp\test.txt --batch --yes I'm using this on Windows 2016. I'm not sure what I'm missing...any ideas? Shelley Ford This e-mail and any attachments may contain confidential and privileged information. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this e-mail and destroy any copies. Any dissemination or use of this information by a person other than the intended recipient is unauthorized and may be illegal. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrewg at andrewg.com Tue Dec 22 17:55:33 2020 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 22 Dec 2020 16:55:33 +0000 Subject: How Do I Overwrite Files in GnuPG? In-Reply-To: References: Message-ID: <7D9DC1FD-A676-40E9-B2F0-6EEE6E2B0867@andrewg.com> > On 22 Dec 2020, at 16:49, Shelley Ford wrote: > > gpg: Note: '--yes' is not considered an option > > gpg: Note: '--batch' is not considered an option > > What I'm using: > > gpg --output e:\temp\test.txt.pgp --encrypt --recipient recipient at org e:\temp\test.txt --batch --yes > > I'm using this on Windows 2016. I'm not sure what I'm missing...any ideas? > This is one of gpg?s little UI idiosyncrasies. '?batch', '?yes' etc. must come before actions such as '?encrypt' on the command line. A -------------- next part -------------- An HTML attachment was scrubbed... URL: From boskov at bu.edu Tue Dec 22 19:32:21 2020 From: boskov at bu.edu (=?UTF-8?Q?Novak_Bo=c5=a1kov?=) Date: Tue, 22 Dec 2020 13:32:21 -0500 Subject: Does GPG Ever Store RSA Secret Keys On The Disk In Plain? In-Reply-To: <8735zywd6z.fsf@wheatstone.g10code.de> References: <83cf1f93-b717-9d21-9b4f-500e458afd3d@informatik.hu-berlin.de> <87czz2wzlk.fsf@wheatstone.g10code.de> <1937fe5e-b814-b6fd-5b98-c2f7a98b3efe@bu.edu> <2d2bf48d-4bb1-f110-ad08-c93e23e921ff@bu.edu> <8735zywd6z.fsf@wheatstone.g10code.de> Message-ID: <6c2fd34c-d8d3-bc36-3386-0eb327da3fd2@bu.edu> > box1$ gpg --export-secret-key FINGERPRINT >key.sec > > box2$ gpg --import key.sec OK, I see why this works. Because the salt, IV and protect count are all stored in plain alongside the encrypted version of the secret key. However, my secret key packets do not have that `iter+salt`, `protect count` and `protect IV` parts. They have the plain `skey` parts. That may be the reason why my subsequent exports are byte-equal. Now, the issue that I have is that `gpg --passwd ` says that my key is protected by a passphrase. It asks for the current passphrase before it lets me type in the new one. How can it be that `gpg --passwd ` asks for the passphrase if `gpg --list-packets ` does not have the `iter+salt` part? In other words, is protected by a passphrase or not? On 12/22/20 1:46 AM, Werner Koch wrote: > On Mon, 21 Dec 2020 18:47, Novak Bo?kov said: > >> So, the two subsequent exports are supposed to give me my private key >> encrypted with two different AES keys (same passphrase + a different salt)? > Right: > > First packet of the first export: > > # off=0 ctb=95 tag=5 hlen=3 plen=1414 > :secret key packet: > version 4, algo 1, created 1568715099, expires 0 > pkey[0]: [3072 bits] > pkey[1]: [17 bits] > iter+salt S2K, algo: 7, SHA1 protection, hash: 2, salt: E28C8328510DEDC0 > protect count: 30408704 (237) > protect IV: 6e a3 36 63 19 2c fc 87 b2 c6 be d3 03 41 09 56 > skey[2]: [v4 protected] > keyid: F29010625F3EDDDA > > First packet of the second export: > > # off=0 ctb=95 tag=5 hlen=3 plen=1414 > :secret key packet: > version 4, algo 1, created 1568715099, expires 0 > pkey[0]: [3072 bits] > pkey[1]: [17 bits] > iter+salt S2K, algo: 7, SHA1 protection, hash: 2, salt: 24725FA6DAA0883C > protect count: 30408704 (237) > protect IV: f5 29 51 fe 73 02 1a 31 19 fd bf fe ae 37 ef 23 > skey[2]: [v4 protected] > keyid: F29010625F3EDDDA > > You see that the salt and the IV are both different. The protection > count is the same because this is a constant computed by gpg-agent at > startup my measuring the speed of the KDF. The actual encrypted key > data (not shown) is also different. > >> How does transferring the keys to a different machine is supposed to >> work then? > box1$ gpg --export-secret-key FINGERPRINT >key.sec > > box2$ gpg --import key.sec > > You need to enter the passphrase during export. For import the > re-encryption is delayed until the key is used and thus you won't need a > passphrase immediately. > > > Shalom-Salam, > > Werner > -- ????Novak Bo?kov ????/PhD Student/ ????/Electrical & Computer Engineering Department/ ????/Boston University/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xB8D4C9837C741FBD.asc Type: application/pgp-keys Size: 2448 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: OpenPGP digital signature URL: From boskov at bu.edu Tue Dec 22 19:34:04 2020 From: boskov at bu.edu (=?UTF-8?Q?Novak_Bo=c5=a1kov?=) Date: Tue, 22 Dec 2020 13:34:04 -0500 Subject: Does GPG Ever Store RSA Secret Keys On The Disk In Plain? In-Reply-To: References: Message-ID: This is confusing. If I do: > $ gpg --output sec_key.pgp --export-secret-keys > $ gpg --list-packets sec_key.pgp My :secret sub key packet: looks more like the latter, which Angel says indicates my key is _not_ protected by a passphrase. However, if I do: > $ gpg --passwd It asks me to enter the key's passphrase to "unlock it". Now, why does it ask me to enter the passphrase if there is no passphrase for the given key? Ultimately, which one of the two is right; is my key stored in plane on the disk because it does not have the `iter+salt` part in `gpg --list-packets`, or is it stored encrypted using my passphrase that `gpg --passwd` asks for? I would be surprised if both can be true at the same time. -- ??? Novak -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xB8D4C9837C741FBD.asc Type: application/pgp-keys Size: 2448 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Tue Dec 22 19:45:13 2020 From: wk at gnupg.org (Werner Koch) Date: Tue, 22 Dec 2020 19:45:13 +0100 Subject: How Do I Overwrite Files in GnuPG? In-Reply-To: <7D9DC1FD-A676-40E9-B2F0-6EEE6E2B0867@andrewg.com> (Andrew Gallagher's message of "Tue, 22 Dec 2020 16:55:33 +0000") References: <7D9DC1FD-A676-40E9-B2F0-6EEE6E2B0867@andrewg.com> Message-ID: <87r1nhvfwm.fsf@wheatstone.g10code.de> > This is one of gpg?s little UI idiosyncrasies. '?batch', '?yes' > etc. must come before actions such as '?encrypt' on the command line. That is actually classic Unix behaviour (in contrast to GNU's way of processing options): First the options and then the arguments. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From Shelley.Ford at celero.ca Tue Dec 22 19:55:53 2020 From: Shelley.Ford at celero.ca (Shelley Ford) Date: Tue, 22 Dec 2020 18:55:53 +0000 Subject: How Do I Overwrite Files in GnuPG? In-Reply-To: <7D9DC1FD-A676-40E9-B2F0-6EEE6E2B0867@andrewg.com> References: <7D9DC1FD-A676-40E9-B2F0-6EEE6E2B0867@andrewg.com> Message-ID: Thanks so much! That worked! Shelley Ford From: Andrew Gallagher Sent: Tuesday, December 22, 2020 10:56 AM To: Shelley Ford Cc: gnupg-users at gnupg.org Subject: Re: How Do I Overwrite Files in GnuPG? On 22 Dec 2020, at 16:49, Shelley Ford > wrote: gpg: Note: '--yes' is not considered an option gpg: Note: '--batch' is not considered an option What I'm using: gpg --output e:\temp\test.txt.pgp --encrypt --recipient recipient at org e:\temp\test.txt --batch --yes I'm using this on Windows 2016. I'm not sure what I'm missing...any ideas? This is one of gpg?s little UI idiosyncrasies. '?batch', '?yes' etc. must come before actions such as '?encrypt' on the command line. A This e-mail and any attachments may contain confidential and privileged information. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this e-mail and destroy any copies. Any dissemination or use of this information by a person other than the intended recipient is unauthorized and may be illegal. -------------- next part -------------- An HTML attachment was scrubbed... URL: From spam.trap.mailing.lists at gmail.com Tue Dec 22 20:40:30 2020 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Tue, 22 Dec 2020 20:40:30 +0100 Subject: Split private key in order to share among users In-Reply-To: <20201221005059.2220B33806EA@dd39516.kasserver.com> References: <20201220064919.4308E3388C0C@dd39516.kasserver.com> <20201221005059.2220B33806EA@dd39516.kasserver.com> Message-ID: On Mon, Dec 21, 2020 at 1:54 AM Alexander Kriegisch wrote: > Thanks for the helpful information. I have WSL installed already and > also know how to compile with MSYS2 or Cygwin. Cross-compilation I know > from old times when I was using it in my Freetz project (Fritz!Box DSL > router firmware cross-compilation). > > Instead of starting with Go and compiling native applications I took the > easy route and searched GitHub for Java packages. This one works nicely > and has a library as well as a CLI artifact available on Maven Central: Cool, glad that you have found a soulution. Regards Stefan From boskov at bu.edu Mon Dec 21 23:02:48 2020 From: boskov at bu.edu (=?UTF-8?Q?Novak_Bo=c5=a1kov?=) Date: Mon, 21 Dec 2020 17:02:48 -0500 Subject: Does GPG Ever Store RSA Secret Keys On The Disk In Plain? In-Reply-To: <83cf1f93-b717-9d21-9b4f-500e458afd3d@informatik.hu-berlin.de> References: <83cf1f93-b717-9d21-9b4f-500e458afd3d@informatik.hu-berlin.de> Message-ID: <61c33c5d-4748-87c0-aef3-7d415fc63ef2@bu.edu> Hi Annie, I am not sure that I follow. First, it looks like multiple exports _do_ result in the exactly same export data: > FIRST=$(gpg --export-secret-keys --armor ) > SECOND=$(gpg --export-secret-keys --armor ) > if [ "$FIRST" == "$SECOND" ]; then echo "Outputs are equal"; fi > Outputs are equal Which makes perfect sense to me. I would indeed expect my secret key encrypted with my passphrase to be the same across multiple invocations of the export command. If a salt is used, how come that I can take my key that I've gotten through a `gpg --export-secret-keys --armor ...` call and import it on a different machine using only my passphrase? Could you please elaborate a bit more on this or/and provide some useful resources? Best regards, Novak -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xB8D4C9837C741FBD.asc Type: application/pgp-keys Size: 2448 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: OpenPGP digital signature URL: From spam.trap.mailing.lists at gmail.com Thu Dec 24 10:08:12 2020 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Thu, 24 Dec 2020 10:08:12 +0100 Subject: Protecting your private key - passphrase In-Reply-To: References: Message-ID: On Tue, Dec 15, 2020 at 5:04 PM Stefan Claas wrote: > Did some calculations with these simple example mini-passphrases above > compared to diceware sixword word passphrases and decided to rename > my programs to passphrase hasher, so that people do not follow these > simple examples. Also added an clipboard overwrite button. > > https://ibb.co/VYkDN20 Decided, as little exercise, to use Argon2id, with fixed parameters, which users can change to their liking. https://github.com/sac001/Argon2id/ Merry Christmas to all of you! Regards Stefan From philihp at gmail.com Thu Dec 24 13:29:31 2020 From: philihp at gmail.com (Philihp Busby) Date: Thu, 24 Dec 2020 12:29:31 +0000 Subject: Rationale/reasons for splitting Sign and Authenticate into two separate subkeys in a work-environment? In-Reply-To: References: Message-ID: On 2020-12-22T13:31:42+0100 Christian Chavez via Gnupg-users wrote 2.8K bytes: >I'm currently helping my workplace test out Yubikeys - to see how/if >they could help us with our software development. One expected benefit >is to allow developers cryptographically sign Git commits/tags (e.g). I hope I'm not the only one on this list that may have left innocuous commits forged under the name of someone who didn't work there anymore to prove that a less ethical person may have already gotten away with actually committing malicious code. I was in an org once that had a neat system of generating SSH keys on hardware tokens, and then distributing them to the servers that each person should have access to. It was hella cool. I did something similar with my home LAN by swapping ssh-agent for gpg-agent on my terminals, and using a keyserver to distribute my public key to devices. From mac3iii at gmail.com Thu Dec 24 15:28:58 2020 From: mac3iii at gmail.com (Sandy) Date: Thu, 24 Dec 2020 09:28:58 -0500 Subject: error msg from gpg 2.2.26 on Ubuntu 20.10 for raspberry pi Message-ID: Hello gnupg users - I came across a strange error message from GnuPG 2.2.26 using the raspberry pi 4 and the new Ubuntu 20.10 64 bit operating system for ARM. The GnuPG speedo compile went to completion without any problems. However after a reboot trying to bring up gpg gives: ? $ gpg --verbose --version ? gpg: symbol lookup error: gpg: undefined symbol: gpgrt_access, version GPG_ERROR_1.0 Interestingly this error does not show up in a regular compile of GnuPG 2.2.26 in the normal raspberry pi OS and also is not a problem in Ubuntu 20.04 on my regular AMD Ryzen 7 3800XT desktop. I have been afraid to test it on my laptop running Ubuntu 20.10 for fear of ruining the current version 2.2.25 which runs fine (that's why I always test on RPi first). I suspect (from googling similar errors) a problem with LD_LIBRARY_PATH, but have not found a solution. Anybody else out there try this and find a solution? Happy Hollidays, Murphy -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0xE5A1A5E9600FBA11.asc Type: application/pgp-keys Size: 2438 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From mac3iii at gmail.com Thu Dec 24 17:24:19 2020 From: mac3iii at gmail.com (Sandy) Date: Thu, 24 Dec 2020 11:24:19 -0500 Subject: error msg from gpg 2.2.26 on Ubuntu 20.10 for raspberry pi Message-ID: <4c82401a-b5c0-07ce-f344-be6ed4d78ad7@gmail.com> Hello again gnupg users - I found a solution to the problem. It is actually an old problem that cropped up for me on 32 bit machines that I didn't expect on the 64 bit Ubuntu 20.10 on the Raspberry pi. $ sudo nano /etc/ld.so.conf type in as the first line: include /etc/ld.so.conf.d/libc.conf save and then: $ sudo ldconfig And now gpg --version recognizes and runs GnuPG 2.2.26 without error msgs.? I hope this is of some use to other RPi Ubuntu users out there who like to use the newest version of GnuPG. Cheers - Sandy (Murphy) -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0xE5A1A5E9600FBA11.asc Type: application/pgp-keys Size: 2438 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From plr.vincent at gmail.com Sun Dec 27 05:17:56 2020 From: plr.vincent at gmail.com (Vincent Pelletier) Date: Sun, 27 Dec 2020 04:17:56 +0000 Subject: [developer preview] smartcard + opengp as a linux gadget Message-ID: <20201227041724.110c1395@vincent> Hello, First: this is announce is aimed at potential contributors (code, documentation, ...) and experimentation (seeing what this is about, identifying bugs, ...). It is not aimed at general use: do not use this (yet) with valuable keys or data. I would like to announce my implementation of a software CCID card reader targeting the Linux gadget subsystem, along with a smartcard OS and openpgp card application to use with this reader. - CCID card reader: https://github.com/vpelletier/python-usb-f-ccid - smartcard OS: https://github.com/vpelletier/python-smartcard - OpenPGP app: https://github.com/vpelletier/python-smartcard-app-openpgp I describe at length the thought process which led to this project in the README: https://github.com/vpelletier/python-smartcard-app-openpgp/blob/master/README.rst but in a nutshell this project should be seen as yet another computer holding private keys (with all the attack surfaces this implies), with the extra capability of being seen as a smartcard from a host computer. So, why not a real smartcard, with its minimal attack surface ? For the hardware flexibility: I wanted an inter-operable token capable of displaying a grid of random PINs, so that I can use it on an untrusted computer without leaking the PIN or using it behind my back, for uses where token theft (for actual use/exposure of the contained secrets) is not as important as resisting remote accesses. With this implementation, I can pick up a Pi Zero, put a 2 inches screen on it and get such functionality. I'm sure more creative uses of commonly available hardware can be found, and this is what this project is hoping to allow. The CCID card reader is considered to be feature-complete. The OpenPGP app passes the most important tests from the gnuk test suite (with a few minor patches I sent to its maintainer). Specifically, it fails strict ATR and Extended Capabilities comparison, because it does not implement the exact same set of features, and the non-standard admin-less test variants. The smartcard OS is the least polished part: it is supposed to be application-independent, but only the codepaths exercised by OpenPGP are known to work. I did implement a bit beyond that, but there is still a lot of work needed - although it is second in priority to OpenPGP implementation. Regards, -- Vincent Pelletier From bernhard at intevation.de Mon Dec 28 14:53:05 2020 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 28 Dec 2020 14:53:05 +0100 Subject: GPA packages for CentOS, Fedora Message-ID: <202012281453.14283.bernhard@intevation.de> Hello, is anyone aware of GPA packages for current Fedora or CentOS GNU/Linux distributions? My search did not turn up any. (Tried pkgs.org pm.pbone.net) What is the right place to wish for an updated GPA package in Fedora? v0.10.0 is current. Would be useful if someone could make a wish or help otherwise. Thanks, Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From gnupg-users at storiepvtride.it Tue Dec 29 15:13:19 2020 From: gnupg-users at storiepvtride.it (Journeyman) Date: Tue, 29 Dec 2020 15:13:19 +0100 Subject: Unlock smartcard PIN without decrypting a file Message-ID: <87o8ic1ziu.fsf@nyarlathotep> Howdy, usually I unlock my Yubikey and enter its PIN when I need to decrypt a file. Sometimes I'd like to unlock the smartcard without really interacting with the private key stored there. Is there an SCD command that allows me to do this? I've read the GNUPG manual but couldnt really find anything for this, my (perhaps limited) understanding is that SCD commands do not require the PIN. thanks for any suggestion! regards, From wk at gnupg.org Tue Dec 29 21:59:23 2020 From: wk at gnupg.org (Werner Koch) Date: Tue, 29 Dec 2020 21:59:23 +0100 Subject: Unlock smartcard PIN without decrypting a file In-Reply-To: <87o8ic1ziu.fsf@nyarlathotep> (Journeyman's message of "Tue, 29 Dec 2020 15:13:19 +0100") References: <87o8ic1ziu.fsf@nyarlathotep> Message-ID: <87r1n8pbv8.fsf@wheatstone.g10code.de> On Tue, 29 Dec 2020 15:13, Journeyman said: > that SCD commands do not require the PIN. The PIN is passed to the card and processed by the card. Thus the card decides on whether an operation needs a PIN. Usually the PIN is required only once and valid until the card is powered down (e.g. unplugged). The OpenPGP card may require a PIN for each signing operaion - this behaviour can be controlled using the "forcesig" command of gpg --card-edit. To do the verification without any operation you can use "gpg --card-edit" and then enter "verify". If you want to see the commands send to the scd run gpg --debug ipc --card-edit Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From gnupg-users at storiepvtride.it Wed Dec 30 12:58:59 2020 From: gnupg-users at storiepvtride.it (jman) Date: Wed, 30 Dec 2020 12:58:59 +0100 Subject: Unlock smartcard PIN without decrypting a file In-Reply-To: <87r1n8pbv8.fsf@wheatstone.g10code.de> Message-ID: <874kk34i9o.fsf@nyarlathotep> > To do the verification without any operation you can use "gpg > --card-edit" and then enter "verify". > If you want to see the commands send to the scd run > gpg --debug ipc --card-edit Thank you so much for the detailed anwser! Based on your suggestion I could debug that the "verify" command sends: gpg/card> verify gpg: DBG: chan_4 -> SCD CHECKPIN AAABBBCCCDDD gpg: DBG: chan_4 <- INQUIRE PINENTRY_LAUNCHED 401855 tty 1.1.0 /dev/pts/0 xterm-kitty - gpg: DBG: chan_4 -> END therefore the onliner I was looking for could look like this: gpg-connect-agent 'SCD CHECKPIN AAABBBCCCDDD' /bye ("AAABBBCCCDDD" being the serial number of the smartcard) regards,