From abbot at monksofcool.net Wed Jan 1 03:56:01 2020 From: abbot at monksofcool.net (Ralph Seichter) Date: Wed, 01 Jan 2020 03:56:01 +0100 Subject: Syncing GnuPG data between computers In-Reply-To: <30ae07e1-26bb-899d-8b06-359ac5cd2841@gmail.com> References: <30ae07e1-26bb-899d-8b06-359ac5cd2841@gmail.com> Message-ID: <87d0c351ha.fsf@wedjat.horus-it.com> * Steve McKown via Gnupg-users: > I currently only manage one GnuPG identity, and its private key > material is stored on a smart card (Yubikey). So I think I'm only > caring about other's keys, trust relationships, and the like. If you can limit yourself to modifying files on only one computer before a "sync", I recommend using Git pull/push operations for your key rings, trust-DB etc. I have been using this method for a long time to sync macOS and Linux, and it works fine for me. The PGP files are binary and therefore opaque, but apparently platform-independent. -Ralph From skquinn at rushpost.com Wed Jan 1 04:33:37 2020 From: skquinn at rushpost.com (Shawn K. Quinn) Date: Tue, 31 Dec 2019 21:33:37 -0600 Subject: Syncing GnuPG data between computers In-Reply-To: <30ae07e1-26bb-899d-8b06-359ac5cd2841@gmail.com> References: <30ae07e1-26bb-899d-8b06-359ac5cd2841@gmail.com> Message-ID: <92d69b25-8985-ee07-16bb-875eea19efe4@rushpost.com> On 12/31/19 16:46, Steve McKown via Gnupg-users wrote: > I use different computers at different times, either my office computer > or one on-site provided by a customer. > > I want to be able to propagate changes I make to GnuPG on one computer > to other computer I use, without resorting to duplicating the changes > manually. > > I currently only manage one GnuPG identity, and its private key material > is stored on a smart card (Yubikey). So I think I'm only caring about > other's keys, trust relationships, and the like. Move your .gnupg to a thumb drive, symlink .gnupg to its mount point, and move the thumb drive back and forth? You might have to fiddle with permissions/ownership if your numeric uid is different on both of them, or maybe use something like VFAT that doesn't track ownership/permissions for better or worse. This is what I did for my music and my music player's database, I have not tried it with any other software including GnuPG. -- Shawn K. Quinn http://www.rantroulette.com http://www.skqrecordquest.com From beatles46290 at gmail.com Wed Jan 1 23:08:43 2020 From: beatles46290 at gmail.com (Billy Watts) Date: Wed, 1 Jan 2020 17:08:43 -0500 Subject: Syncing GnuPG data between computers Message-ID: -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Thu Jan 2 13:50:02 2020 From: wk at gnupg.org (Werner Koch) Date: Thu, 02 Jan 2020 13:50:02 +0100 Subject: Syncing GnuPG data between computers In-Reply-To: <30ae07e1-26bb-899d-8b06-359ac5cd2841@gmail.com> (Steve McKown via Gnupg-users's message of "Tue, 31 Dec 2019 15:46:27 -0700") References: <30ae07e1-26bb-899d-8b06-359ac5cd2841@gmail.com> Message-ID: <878smqc9ad.fsf@wheatstone.g10code.de> On Tue, 31 Dec 2019 15:46, Steve McKown said: > The GnuPG configuration files are simple enough, but the database files > are another story I imagine. We have always used a platform independent on-disk format for all files. Thus copying the files between different platforms is no problem at all. > My search-fu keeps suggesting using gpg import and export, like: Yes, that is the official way because the on-disk data format is not standardized. Newer GnuPG versions may add new data items to the files which might not be fully compatible with older GnuPG versions. If you use the same GnuPG versions (e.g. 2.2.x) on all machines you won't run into problems. We take great care not to break anything. 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 civitas at dipohl.de Fri Jan 3 13:53:00 2020 From: civitas at dipohl.de (Gabriele Pohl) Date: Fri, 3 Jan 2020 13:53:00 +0100 Subject: Decryption fails with "No secret key" Message-ID: <20200103135300.700ef755@niva.dipohl.de> Hi After upgrading my PC to Fedora 30 gnupg2-2.2.17-1.fc30.x86_64 gnupg2-smime-2.2.17-1.fc30.x86_64 gpgme-1.12.0-1.fc30.x86_64 gnutls-3.6.10-1.fc30.x86_64 libgcrypt-1.8.5-1.fc30.x86_64 libgpg-error-1.33-2.fc30.x86_64 a problem with decrypting came up. Encryption works: $ gpg --verbose --output test.txt.gpg --recipient contact at dipohl.de --encrypt test.txt gpg: Note: signature key E747789CEA208551 expired Fri 06 Jun 2014 07:46:32 PM CEST gpg: using pgp trust model gpg: using subkey 4BB3049F19616A80 instead of primary key 9C7646202CE0CBB2 gpg: automatically retrieved 'contact at dipohl.de' via Local gpg: This key belongs to us gpg: reading from 'test.txt' gpg: writing to 'test.txt.gpg' gpg: RSA/AES256 encrypted for: "4BB3049F19616A80 Gabriele Pohl " $ ls -l test.txt* -rw-rw-r--. 1 gap gap 119 Jan 3 13:04 test.txt -rw-rw-r--. 1 gap gap 697 Jan 3 13:07 test.txt.gpg But decrypting fails: $ gpg --verbose --decrypt test.txt.gpg gpg: public key is 4BB3049F19616A80 gpg: using subkey 4BB3049F19616A80 instead of primary key 9C7646202CE0CBB2 gpg: encrypted with 4096-bit RSA key, ID 4BB3049F19616A80, created 2016-09-05 "Gabriele Pohl " gpg: decryption failed: No secret key The secret key is available: gpg> list sec rsa2048/9C7646202CE0CBB2 created: 2012-09-05 expires: 2020-03-16 usage: SC trust: ultimate validity: ultimate ssb rsa2048/51E12CABCB4F0264 created: 2012-09-05 expired: 2016-09-04 usage: E sub rsa4096/4BB3049F19616A80 created: 2016-09-05 expires: 2020-03-16 usage: E [ultimate] (1). Gabriele Pohl .. My gpg-agent.conf: # Cache settings default-cache-ttl 10800 default-cache-ttl-ssh 10800 max-cache-ttl 10800 # Environment file #write-env-file /home/gap/.gpg-agent-info # Keyboard control no-grab # PIN entry program #pinentry-program /usr/bin/pinentry pinentry-program /usr/bin/pinentry-curses #pinentry-program /usr/bin/pinentry-qt4 #pinentry-program /usr/bin/pinentry-kwallet #pinentry-program /usr/bin/pinentry-gtk-2 #pinentry-program /usr/bin/pinentry-gtk #pinentry-program /usr/bin/pinentry-qt disable-scdaemon allow-mark-trusted keep-display display :0.0 debug-level basic I hope you can help me to solve the problem. Thanks and kind regards, Gabriele From sac at 300baud.de Fri Jan 3 19:02:38 2020 From: sac at 300baud.de (Stefan Claas) Date: Fri, 3 Jan 2020 19:02:38 +0100 Subject: New OpenPGP packet request Message-ID: <20200103190238.00002957.sac@300baud.de> Hi Werner and all GnuPG hackers, I would like to ask if it is possible in a future version of GnuPG to have a new OpenPGP packet defined, which would allow GnuPG users that their public key can be no longer uploaded to the the old SKS keyserver Network, so that SKS rejects the OpenPGP Public Key Block? Maybe this packet request could be added in form of the key-generation process, so that GnuPG users will be asked by GnuPG if they like to have old-style SKS support or not. I ask this because I can imagine that some people do not want that their new public key block is accidently uploaded and distributed without their consent. It is assumed that the SKS Network will not go away in the near future and it is assumed once such a new non-compatible SKS packet would be supported by GnuPG it could be quickly supported by modern Hagrid, Mailvelope and hockeypuck. Best Regards Stefan -- NaClbox: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From johndoe65534 at mail.com Fri Jan 3 19:06:42 2020 From: johndoe65534 at mail.com (john doe) Date: Fri, 3 Jan 2020 19:06:42 +0100 Subject: master key certify capability Message-ID: <659f4310-1fc6-8d22-40a0-0cfa31b9595f@mail.com> Hi, I use the following command to test my new key setup: $ gpg --batch --passphrase '' --yes --quick-gen 'Firstname Lastname ' rsa4096 cert 1d&& for u in sign sign encrypt; do gpg --batch --passphrase '' --yes --quick-add-key $(gpg --with-colons -k test | awk -F::::::::: 'NR==3{print substr($2,1,length($2)-1)}') rsa4096 $u 1d || exit $?; done which give the following: $ gpg -K ----------------------------- sec rsa4096 2020-01-03 [C] [expires: 2020-01-04] 3C5CFD620005347A62052A6B596CB80D30E8829D uid [ultimate] Firstname Lastname ssb rsa4096 2020-01-03 [S] [expires: 2020-01-04] ssb rsa4096 2020-01-03 [S] [expires: 2020-01-04] ssb rsa4096 2020-01-03 [E] [expires: 2020-01-04] Is there any downside to have my master key with the certify capability only? In other words, is it required for the master key to have the sign and certify capabilities. -- John Doe From sac at 300baud.de Fri Jan 3 19:21:55 2020 From: sac at 300baud.de (Stefan Claas) Date: Fri, 3 Jan 2020 19:21:55 +0100 Subject: New OpenPGP packet request In-Reply-To: <20200103190238.00002957.sac@300baud.de> References: <20200103190238.00002957.sac@300baud.de> Message-ID: <20200103192155.00002d38.sac@300baud.de> Stefan Claas via Gnupg-users wrote: > It is assumed that the SKS Network will not go away in the near > future and it is assumed once such a new non-compatible SKS packet > would be supported by GnuPG it could be quickly supported by modern > Hagrid, Mailvelope and hockeypuck. Mmmh, while thinking of it, if the hockepuck author would support this (if implemented in GnuPG) then the SKS folks could later jump on huckepuck...like the Ubuntu folks :-( (*PLEASE DEAR HOCKEYPUCK AUTHOR DO NOT IMPLEMENT THIS SHOULD THIS PROPOSAL BE FRUITFUL*) Regards Stefan -- NaClbox: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From konstantin at linuxfoundation.org Fri Jan 3 21:18:22 2020 From: konstantin at linuxfoundation.org (Konstantin Ryabitsev) Date: Fri, 3 Jan 2020 15:18:22 -0500 Subject: master key certify capability In-Reply-To: <659f4310-1fc6-8d22-40a0-0cfa31b9595f@mail.com> References: <659f4310-1fc6-8d22-40a0-0cfa31b9595f@mail.com> Message-ID: <20200103201822.hixtpxza7afhbyii@chatter.i7.local> On Fri, Jan 03, 2020 at 07:06:42PM +0100, john doe wrote: > $ gpg -K > > ----------------------------- > sec rsa4096 2020-01-03 [C] [expires: 2020-01-04] > 3C5CFD620005347A62052A6B596CB80D30E8829D > uid [ultimate] Firstname Lastname > ssb rsa4096 2020-01-03 [S] [expires: 2020-01-04] > ssb rsa4096 2020-01-03 [S] [expires: 2020-01-04] > ssb rsa4096 2020-01-03 [E] [expires: 2020-01-04] > > > Is there any downside to have my master key with the certify capability > only? None. > In other words, is it required for the master key to have the sign and > certify capabilities. It's not, and having a separate S subkey allows you to remove your certify key to offline storage for better safekeeping (e.g. see https://github.com/lfit/itpol/blob/master/protecting-code-integrity.md#moving-your-master-key-to-offline-storage) Regards, -K From sac at 300baud.de Fri Jan 3 23:02:09 2020 From: sac at 300baud.de (Stefan Claas) Date: Fri, 3 Jan 2020 23:02:09 +0100 Subject: New OpenPGP packet request In-Reply-To: <20200103192155.00002d38.sac@300baud.de> References: <20200103190238.00002957.sac@300baud.de> <20200103192155.00002d38.sac@300baud.de> Message-ID: <20200103230209.00005cab.sac@300baud.de> Stefan Claas via Gnupg-users wrote: > Stefan Claas via Gnupg-users wrote: > > > It is assumed that the SKS Network will not go away in the near > > future and it is assumed once such a new non-compatible SKS packet > > would be supported by GnuPG it could be quickly supported by modern > > Hagrid, Mailvelope and hockeypuck. > > Mmmh, while thinking of it, if the hockepuck author would support this > (if implemented in GnuPG) then the SKS folks could later jump on > huckepuck...like the Ubuntu folks :-( (*PLEASE DEAR HOCKEYPUCK AUTHOR > DO NOT IMPLEMENT THIS SHOULD THIS PROPOSAL BE FRUITFUL*) Another possible solution, maybe worth to discuss, is that if all SKS key servers would be replaced with hockeypuck that the author implements the key server no modify flag, GnuPG offers. Regards Stefan -- NaClbox: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From johndoe65534 at mail.com Sat Jan 4 09:53:07 2020 From: johndoe65534 at mail.com (john doe) Date: Sat, 4 Jan 2020 09:53:07 +0100 Subject: Different key pare for e-mail and signing code Message-ID: Hello all, Following my thread at (1), unless I'm missing something, it became apparent that Enigmail/Tunderbird does not fit the bill anymore. My plan is to use something like the following: ----------------------------- sec rsa4096 2020-01-03 [C] [expires: 2020-01-04] 3C5CFD620005347A62052A6B596CB80D30E8829D uid [ultimate] Firstname Lastname ssb rsa4096 2020-01-03 [S] [expires: 2020-01-04] ssb rsa4096 2020-01-03 [S] [expires: 2020-01-04] ssb rsa4096 2020-01-03 [E] [expires: 2020-01-04] With mabey more signing subkeys. My goal is to sign code and sign/encrypt e-mail but I'm not sure what's the best way forward: - One key pare for e-mail (sign/encrypt) and an other key pare for signing code - Finding a way to do what I want with only one key pare (multiple signing subkeys and one encryption subkey) - Am I missing something/better approach For now I'm considering notmuch/sup to get what I want, it looks like Mutt uses 'ncurses' which is not an option for me. Any input is welcome 1) https://admin.hostpoint.ch/pipermail/enigmail-users_enigmail.net/2020-January/005562.html P.S. By key pare, I mean private/public key. -- John Doe From rjh at sixdemonbag.org Sat Jan 4 10:10:13 2020 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 4 Jan 2020 04:10:13 -0500 Subject: Different key pare for e-mail and signing code In-Reply-To: References: Message-ID: <4bb9a920-51f9-9888-1687-59a9c71e0350@sixdemonbag.org> > Following my thread at (1), unless I'm missing something, it became > apparent that Enigmail/Tunderbird does not fit the bill anymore. It should be noted that Enigmail hasn't changed how it does anything. > My goal is to sign code and sign/encrypt e-mail but I'm not sure what's > the best way forward: We don't know, either. It's going to depend on your own personal risk profile. > - Am I missing something/better approach If you want to segregate your code signing from your email, the best way to do that is with a second certificate -- not adding subkeys to your current one. Ask yourself this: how often have you noticed that my signed messages bear *two* signatures from *two* subkeys belonging to the same certificate? I've been doing this for years and nobody's ever noticed. (Or at least, nobody's ever mentioned it to me to ask why I'm doing something so weird.) So if you're depending on people ascribing special semantic value to which subkey is used -- honestly, I doubt people will ever even notice which subkey you're using. It's simply not a use case that comes up very often, if ever. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 821 bytes Desc: OpenPGP digital signature URL: From wiktor at metacode.biz Sat Jan 4 11:54:45 2020 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Sat, 4 Jan 2020 11:54:45 +0100 Subject: Different key pare for e-mail and signing code In-Reply-To: References: Message-ID: <1bffee7f-7ed6-8c5e-0802-be51129c813f@metacode.biz> Hi John, On 04.01.2020 09:53, john doe wrote: > My goal is to sign code and sign/encrypt e-mail but I'm not sure what's > the best way forward: > - One key pare for e-mail (sign/encrypt) and an other key pare for > signing code > - Finding a way to do what I want with only one key pare (multiple > signing subkeys and one encryption subkey) > - Am I missing something/better approach There is no single answer to this question. Some people use one keypair for signing e-mails and software because it's simpler (especially if people have or use Web of Trust to validate keys). Apache, for example, recommends using separate keypair for code signing with specific guidelines (such as having UID comment "CODE SIGNING KEY" [0]). I guess this is due to the fact that one rarely signs code but when they do it they use a different hardware token thus avoiding the risk of misuse of their frequently used key (e-mail signing). OpenPGP lacks extended key usage flags so if an object is signed, it's not clear what was the intention of the signer and it's theoretically possible to trick someone into signing an e-mail (via auto-reply or so) that then could be misinterpreted as software [1]. Kind regards, Wiktor [0]: https://www.apache.org/dev/release-signing.html#key-comment [1]: https://stackoverflow.com/q/35840196 -- https://metacode.biz/@wiktor From sac at 300baud.de Sat Jan 4 13:31:41 2020 From: sac at 300baud.de (Stefan Claas) Date: Sat, 4 Jan 2020 13:31:41 +0100 Subject: New OpenPGP packet request In-Reply-To: <20200103230209.00005cab.sac@300baud.de> References: <20200103190238.00002957.sac@300baud.de> <20200103192155.00002d38.sac@300baud.de> <20200103230209.00005cab.sac@300baud.de> Message-ID: <20200104133141.00003441.sac@300baud.de> Stefan Claas via Gnupg-users wrote: > Another possible solution, maybe worth to discuss, is that if all > SKS key servers would be replaced with hockeypuck that the author > implements the key server no modify flag, GnuPG offers. https://github.com/hockeypuck/hockeypuck/issues/71 Regards Stefan -- NaClbox: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From sac at 300baud.de Sat Jan 4 14:08:00 2020 From: sac at 300baud.de (Stefan Claas) Date: Sat, 4 Jan 2020 14:08:00 +0100 Subject: add-photo continued ... In-Reply-To: <20191230012327.000065f1.sac@300baud.de> References: <20190904204525.00006bbb.sac@300baud.de> <20190904234310.fvjtiaaiidm36lnv@raf.org> <20190905172719.0000698d.sac@300baud.de> <20191230012327.000065f1.sac@300baud.de> Message-ID: <20200104140800.00006d08.sac@300baud.de> Stefan Claas via Gnupg-users wrote: > Stefan Claas via Gnupg-users wrote: > > > raf via Gnupg-users wrote: > > > > > Stefan Claas via Gnupg-users wrote: > > > > > > > Hi all, > > > > > > > > some of you may remember the add-photo thread we had a while ago > > > > and I wondered why the max image size for a UAT packet is 16 MB. > > > > > > > > Recently I saw a Twitter post explaining that a .jpeg image header > > > > can contain 16 MB of data. > > > > > > That's just decadence. :-) > > > Just because it can, doesn't mean it should. > > > 16MB is plenty. Use tinypng.com. > > > > Well, at least people can use this teqnique to fire-up important > > documents, which should be preserverd for the next generations, > > since SKS is censor resistant and the Ubuntu keyserver allows > > easy retrival of documents ... > > > > BTW. I just found also the authors link on twitter. > > > > https://twitter.com/David3141593/status/1057042085029822464 > > In case people here haven't seen yet. > > https://github.com/hockeypuck/hockeypuck/issues/68 Regards Stefan -- NaClbox: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From kloecker at kde.org Sun Jan 5 16:17:04 2020 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Sun, 05 Jan 2020 16:17:04 +0100 Subject: Decryption fails with "No secret key" In-Reply-To: <20200103135300.700ef755@niva.dipohl.de> References: <20200103135300.700ef755@niva.dipohl.de> Message-ID: <11449201.ELIMPtl7NR@thufir> On Freitag, 3. Januar 2020 13:53:00 CET Gabriele Pohl wrote: > After upgrading my PC to Fedora 30 [...] > a problem with decrypting came up. > > Encryption works: > > $ gpg --verbose --output test.txt.gpg --recipient contact at dipohl.de > --encrypt test.txt [...] > gpg: RSA/AES256 encrypted for: "4BB3049F19616A80 Gabriele Pohl > " [...] > But decrypting fails: > > $ gpg --verbose --decrypt test.txt.gpg > gpg: public key is 4BB3049F19616A80 > gpg: using subkey 4BB3049F19616A80 instead of primary key 9C7646202CE0CBB2 > gpg: encrypted with 4096-bit RSA key, ID 4BB3049F19616A80, created > 2016-09-05 "Gabriele Pohl " > gpg: decryption failed: No secret key > > The secret key is available: > > gpg> list > > sec rsa2048/9C7646202CE0CBB2 > created: 2012-09-05 expires: 2020-03-16 usage: SC > trust: ultimate validity: ultimate > ssb rsa2048/51E12CABCB4F0264 === > created: 2012-09-05 expired: 2016-09-04 usage: E > sub rsa4096/4BB3049F19616A80 === > created: 2016-09-05 expires: 2020-03-16 usage: E > [ultimate] (1). Gabriele Pohl The secret key of subkey 4BB3049F19616A80 is not available (it's listed as "sub", but not as "ssb"). Only the secret keys of the main key and the expired subkey are available. I suspect a gpg1 vs. gpg2 problem, i.e. the secret key of subkey 4BB3049F19616A80 is only available to gpg1 or gpg2, but not to both (they use different key storages). Fedora 30 probably used gpg2 when you run 'gpg' while the previous version used gpg1. Possible solution: * Make a backup (just to be sure). * Re-run the migration of the keys from the old storage format to the new one. I think all you have to do is to remove the file ~/.gnupg/.gpg-v21-migrated. Regards, Ingo From azbigdogs at gmx.com Sun Jan 5 20:02:27 2020 From: azbigdogs at gmx.com (azbigdogs at gmx.com) Date: Sun, 5 Jan 2020 20:02:27 +0100 Subject: Changes in GnuPG Message-ID: An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Mon Jan 6 01:16:37 2020 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 5 Jan 2020 19:16:37 -0500 Subject: Changes in GnuPG In-Reply-To: References: Message-ID: > Is there anything that really details the changes in this new format > and why it changed? https://www.gnupg.org/faq/whats-new-in-2.1.html#keybox > Also no more secring.gpg. Those files got moved in that "private > -keys" directory. What I'm also trying to understand is now their > files names don't really correspond to the key details itself, (real > name, email, Key ID, etc). Why the change in that as well? https://www.gnupg.org/faq/whats-new-in-2.1.html#nosecring From johndoe65534 at mail.com Mon Jan 6 07:26:25 2020 From: johndoe65534 at mail.com (john doe) Date: Mon, 6 Jan 2020 07:26:25 +0100 Subject: Different key pare for e-mail and signing code In-Reply-To: <4bb9a920-51f9-9888-1687-59a9c71e0350@sixdemonbag.org> References: <4bb9a920-51f9-9888-1687-59a9c71e0350@sixdemonbag.org> Message-ID: On 1/4/2020 10:10 AM, Robert J. Hansen wrote: >> Following my thread at (1), unless I'm missing something, it became >> apparent that Enigmail/Tunderbird does not fit the bill anymore. > > It should be noted that Enigmail hasn't changed how it does anything. > No argument there, Patrick is doing an outstanding job with Enigmail. I should have said that enigmail does not fit the bill for my needs anymore, sorry about that. >> My goal is to sign code and sign/encrypt e-mail but I'm not sure what's >> the best way forward: > > We don't know, either. It's going to depend on your own personal risk > profile. > >> - Am I missing something/better approach > > If you want to segregate your code signing from your email, the best way > to do that is with a second certificate -- not adding subkeys to your > current one. > > Ask yourself this: how often have you noticed that my signed messages > bear *two* signatures from *two* subkeys belonging to the same > certificate? I've been doing this for years and nobody's ever noticed. > (Or at least, nobody's ever mentioned it to me to ask why I'm doing > something so weird.) > > So if you're depending on people ascribing special semantic value to > which subkey is used -- honestly, I doubt people will ever even notice > which subkey you're using. It's simply not a use case that comes up > very often, if ever. > From the answer in this thread, it looks like having two key pares (one for signing and one for e-mailing) is somewhat more flexible but this approach is more complicated for the web of trust. I guess , I'll go with separate key pares. Thanks Robert for your answer in all my threads! :) I'd like to also thank (1) for his answer, and (2) for his answer in an other thread (3). 1) Wiktor Kwapisiewicz 2) Konstantin Ryabitsev 3) https://lists.gnupg.org/pipermail/gnupg-users/2020-January/063190.html -- John Doe From civitas at dipohl.de Mon Jan 6 11:50:20 2020 From: civitas at dipohl.de (Gabriele Pohl) Date: Mon, 6 Jan 2020 11:50:20 +0100 Subject: Decryption fails with "No secret key" In-Reply-To: <11449201.ELIMPtl7NR@thufir> References: <20200103135300.700ef755@niva.dipohl.de> <11449201.ELIMPtl7NR@thufir> Message-ID: <20200106115020.7911561c@niva.dipohl.de> Hi Ingo, On Sun, 05 Jan 2020 16:17:04 +0100 Ingo Kl?cker wrote: with your recipe > all you have to do is to remove the file ~/.gnupg/.gpg-v21-migrated the missing secret key was migrated again and decryption is possible now :-) The key listing now shows: ----------- snip ----------- Secret key is available. sec rsa2048/9C7646202CE0CBB2 created: 2012-09-05 expires: 2020-03-16 usage: SC trust: ultimate validity: ultimate ssb rsa2048/51E12CABCB4F0264 created: 2012-09-05 expired: 2016-09-04 usage: E ssb rsa4096/4BB3049F19616A80 created: 2016-09-05 expires: 2020-03-16 usage: E ssb rsa4096/534EADA0332CFAAF created: 2016-09-09 expired: 2018-09-09 usage: S [ultimate] (1). Gabriele Pohl ----------- snip ----------- > The secret key of subkey 4BB3049F19616A80 is not available (it's listed as > "sub", but not as "ssb"). Only the secret keys of the main key and the expired > subkey are available. > > I suspect a gpg1 vs. gpg2 problem, i.e. the secret key of subkey > 4BB3049F19616A80 is only available to gpg1 or gpg2, but not to both (they use > different key storages). Fedora 30 probably used gpg2 when you run 'gpg' while > the previous version used gpg1. hmmm, I searched for fedora bug reports (before I wrote to this mailing list) but didn't find my issue there. I reckon there are not many users who add encryption keys to an existent key and this special case may be the reason for the problem arising in my case. I think it is too late to file a bug report now as the move from Fedora 29 to 30 is no longer relevant. And by searching the internet this thread may arise in the future for lucky finders ;-) Thank you very much for your help and kind regards, Gabriele From azbigdogs at gmx.com Mon Jan 6 16:42:40 2020 From: azbigdogs at gmx.com (azbigdogs at gmx.com) Date: Mon, 6 Jan 2020 16:42:40 +0100 Subject: Changes in GnuPG In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From dgouttegattat at incenp.org Mon Jan 6 23:43:51 2020 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Mon, 6 Jan 2020 22:43:51 +0000 Subject: Changes in GnuPG In-Reply-To: References: Message-ID: <20200106224351.l6isnesfo4t5xysh@dynein.local.incenp.org> On Mon, Jan 06, 2020 at 04:42:40PM +0100, azbigdogs at gmx.com wrote: >I'm still a bit confused on the changes in secring. How does it come up >with the names for those "new" keys as it doesn't seem to corrolate >with anything I can see on the keys. Files under the $GNUPGHOME/private-keys-v1.d directory are named after the *keygrips* of the keys. A keygrip is similar in principle to an OpenPGP fingerprint, but is computed on a data structure that is independent of any protocol (contrary to an OpenPGP fingerprint, which is computed over an OpenPGP packet). GnuPG, which since its version 2.0 implements both OpenPGP and S/MIME, uses keygrips internally to refer to a key independently of the protocol with which the key is to be used. You can use the --with-keygrip option when listing keys to have GnuPG display the keygrips, and check that they match the filenames you see in the $GNUPGHOME/private-keys-v1.d directory. >For them to go away from the OpenPGP standard it obviously had to make >sense to them The OpenPGP standard dictates how compliant implementations interoperate. It says nothing about what the implementations shall do internally. Keygrips are strictly an internal implementation detail of GnuPG. When it interacts with the outside world (e.g. when exporting a key), GnuPG still follows the OpenPGP standard. Cheers, - Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From rjh at sixdemonbag.org Tue Jan 7 08:37:30 2020 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 7 Jan 2020 02:37:30 -0500 Subject: Changes in GnuPG In-Reply-To: References: Message-ID: <7079a8e1-70e3-bee8-bc04-4f5e1f907bab@sixdemonbag.org> > I'm still a bit confused on the changes in secring. How does it come up > with the names for those "new" keys as it doesn't seem to corrolate with > anything I can see on the keys. The names are actually keygrips, not fingerprints. > For them to go away from the OpenPGP standard it obviously had to make > sense to them? They didn't. RFC4880 doesn't define how to store certificates. Way back when, PGP Corporation stored its two keyrings as "pubring.pkr" and "secring.skr". These two files were incredibly simple: each was effectively an OpenPGP message containing nothing but a long sequence of certificates. When PGP started it read each file into RAM, populated a master keyring, and that was that. When GnuPG came along they decided to use the exact same format so that people could migrate just by renaming their .pkr and .skr files to have .gpg extensions. And this was likely a good decision, in that it made it easy for people to switch from PGP. PGP is no longer a serious player in the OpenPGP space. Symantec bought PGP years ago and seem to have been neglecting it ever since. Consequentially, we no longer *need* to use old PGP formats to encourage people to cross over. And at the same time, keyrings are getting a lot bigger -- back in 2000 few people had more than a couple of dozen certificates; twenty years later it's easy to have a few *hundred* certificates. And the old, inefficient PGP keyring format doesn't work very well any more. We don't need the PGP compatibility any more and it's holding us back. That's the root reason for the changes. From christoph at grothesque.org Tue Jan 7 00:26:14 2020 From: christoph at grothesque.org (Christoph Groth) Date: Tue, 07 Jan 2020 00:26:14 +0100 Subject: What are some threats against which OpenPGP smartcards are useful? Message-ID: <87d0bwqi95.fsf@grothesque.org> Hello, Through an article [1] in LWN, I stumbled across a thread [2] on this list that dealt with the usefulness of smartcards for storing OpenPGP keys. I understand that OpenPGP smartcards do not protect from a compromise of the computer system that they are used with. As Peter Lebbing puts it [3]: > You don't even have to decrypt the document they're interested in > yourself, and no external push button will save you. Just decrypt > a document twice, and the second time, the attacker can use your > smartcard for their own good while providing the session key they > logged the first time for your decryption. But then, what are threats against which smartcards *are* useful? Robert J. Hansen justifies [4] his use of a smartcard as follows: > Why don't I want to store the private key on multiple computers? > Because a good rule of thumb in a forensics lab is "store the minimum > personal data possible on your systems". But then he also mentions his 128-bit passphrase and that he would be OK to publish his (passphrase-protected) private key in a newspaper. Why then not store it on the disks of multiple computers? Because the decrypted private key could be stolen from RAM by an attacker? But then Robert also says that the computer being compromised is a game-over condition anyway. I got a smartcard to ssh from computers that I trust reasonably but where I am not (the only) root to other (more trusted) machines that I control exclusively and that hold data that I would not store on the less-trusted machines. From a fundamental point of view a smartcard does not provide any additional security here, but I have the imporession that in practice it does, because gaining access to the remote machines becomes more difficult for an attacker (without a smartcard, installing a simple keylogger is enough). This is the same kind of imperfect security we rely on in real life, for example with door locks. Would you agree with me? Thanks Christoph [1] https://lwn.net/Articles/734767/ [2] https://lists.gnupg.org/pipermail/gnupg-users/2017-April/057995.html [3] https://lists.gnupg.org/pipermail/gnupg-users/2017-April/058136.html [4] https://lists.gnupg.org/pipermail/gnupg-users/2017-April/058050.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From wiktor at metacode.biz Tue Jan 7 14:09:50 2020 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Tue, 7 Jan 2020 14:09:50 +0100 Subject: What are some threats against which OpenPGP smartcards are useful? In-Reply-To: <87d0bwqi95.fsf@grothesque.org> References: <87d0bwqi95.fsf@grothesque.org> Message-ID: Hi Christoph, There is one feature of smartcards that's hard to reproduce otherwise: once you pull the smartcard out of the port the attacker can't use it. If they steal your private keys they can do as they please with it (until you revoke keys and users refresh your key... that can take some time). For example if they steal your private encryption subkey they'll be able to decrypt future communications with you. When you pull out the smartcard that's where the attack ends. (One way or another someone having code execution privileges on your computer is bad.) Additionally smartcards require PINs and lock the card after several tries. This is not possible with keys on USB drives. These two things are really useful when using the same token on multiple devices (e.g. I use the same card on my laptop and phone). Kind regards, Wiktor -- https://metacode.biz/@wiktor From andrewg at andrewg.com Tue Jan 7 15:25:22 2020 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 7 Jan 2020 14:25:22 +0000 Subject: What are some threats against which OpenPGP smartcards are useful? In-Reply-To: References: <87d0bwqi95.fsf@grothesque.org> Message-ID: On 07/01/2020 13:09, Wiktor Kwapisiewicz via Gnupg-users wrote: > These two things are really useful when using the same token on multiple > devices (e.g. I use the same card on my laptop and phone). This is also a very good argument for smartcards - transferring a private key between devices is error-prone and potentially catastrophic. Yes, it can be done securely but for non-experts (and even experts!) having a physical "key" is much more intuitive. How often have we heard of people accidentally distributing their private key instead of their public one? Few of them will have a 128-bit secure passphrase like RJH. :-) -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From andrewg at andrewg.com Tue Jan 7 15:39:34 2020 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 7 Jan 2020 14:39:34 +0000 Subject: Fwd: Re: What are some threats against which OpenPGP smartcards are useful? [ ref:_00D58dJQM._5004Iy476n:ref ] In-Reply-To: References: Message-ID: <10d223ed-3156-c909-ea7d-6a0cd5bdcfe1@andrewg.com> Could one of the admins please twit this subscriber? Their autoreply has been firing since November. A -------------- next part -------------- An embedded message was scrubbed... From: Informa D&B Subject: Re: What are some threats against which OpenPGP smartcards are useful? [ ref:_00D58dJQM._5004Iy476n:ref ] Date: Tue, 7 Jan 2020 14:33:01 +0000 (GMT) Size: 11010 URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Tue Jan 7 15:53:33 2020 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 07 Jan 2020 09:53:33 -0500 Subject: What are some threats against which OpenPGP smartcards are =?UTF-8?Q?useful=3F?= In-Reply-To: <87d0bwqi95.fsf@grothesque.org> References: <87d0bwqi95.fsf@grothesque.org> Message-ID: <455318a2e8fba9a1ea4aea3733baa8cf@mail.monkeyblade.net> On 2020-01-06 18:26, Christoph Groth wrote: > Robert J. Hansen justifies [4] his use of a smartcard as follows: > >> Why don't I want to store the private key on multiple computers? >> Because a good rule of thumb in a forensics lab is "store the minimum >> personal data possible on your systems". > > But then he also mentions his 128-bit passphrase and that he would be > OK > to publish his (passphrase-protected) private key in a newspaper. Why > then not store it on the disks of multiple computers? Hint: because the phrase "forensics lab" is extremely important in what I wrote. I used to (don't any more) work in a forensics lab doing R&D into recovering data from memory, SSD, and spinning-platter media. While I was doing this my colleagues were reverse-engineering malware. Our network was airgapped from the rest of the network, but we were still paranoid about data getting out -- including information about our identities. When you're doing reverse engineering on a botnet belonging to an organized crime syndicate, you really don't want the organized crime syndicate to discover your name. I was also using OpenPGP to help move data into and out of our airgapped network. When a CD came into our lab containing data to be loaded onto machines, we used OpenPGP to verify its provenance. When we burned a CD containing data to be removed from the lab, we'd put a signature on it so the system administrators in the lab outside could be certain that a specific human being was taking responsibility for the contents of that CD. Problem: I didn't want there to be any certificate stored on the lab machines... because any user ID that identified me would be personal information of the kind I didn't want to be stored. Solution: use a smartcard. A smartcard allowed me to make these signatures while leaving minimal forensic traces. But, outside of that laboratory environment, I didn't -- still don't -- need to use a smartcard. Usually I just keep the key on the hard drive of whatever machine I'm using. From rjh at sixdemonbag.org Tue Jan 7 15:57:46 2020 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 07 Jan 2020 09:57:46 -0500 Subject: What are some threats against which OpenPGP smartcards are =?UTF-8?Q?useful=3F?= In-Reply-To: References: <87d0bwqi95.fsf@grothesque.org> Message-ID: <39e03cba02d00c7ec27f491044284a9b@mail.monkeyblade.net> > Few of them will have a 128-bit secure passphrase like RJH. :-) Dude, the lab I worked in *required* me to use 128-bit secure passphrases. It was *awful*. And a 180-day change policy. But the good news is that once you prove to yourself you can do that, the idea of keeping a 128-bit passphrase on your certificate no longer seems so crazy. To quote the movie _Men in Black_, "Give it a few months. You'll get used to it, or you'll have a psychotic episode." From mtg at gnu.org Wed Jan 8 04:18:47 2020 From: mtg at gnu.org (Mike Gerwitz) Date: Tue, 07 Jan 2020 22:18:47 -0500 Subject: What are some threats against which OpenPGP smartcards are useful? References: <87d0bwqi95.fsf@grothesque.org> Message-ID: <87woa2skiw.fsf@gnu.org> On Tue, Jan 07, 2020 at 14:09:50 +0100, Wiktor Kwapisiewicz via Gnupg-users wrote: > Additionally smartcards require PINs and lock the card after several > tries. This is not possible with keys on USB drives. PINs can also be changed confidently. The passphrase of the _copy_ of a key on disk can be changed, but you can't necessarily be confident that it's the only copy. It could have been copied with or without your knowledge, by you or an adversary. If you enter your passphrase somewhere and realize after the fact that someone may have been standing over your shoulder, or there's a security camera in the distance, an audio recording of your keypresses, or _anything_ that reduces the keyspace of your passphrase, then an attacker can brute force the rest offline forever using an old copy of your key, and there's nothing you can do about it. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 818 bytes Desc: not available URL: From mtg at gnu.org Wed Jan 8 04:54:59 2020 From: mtg at gnu.org (Mike Gerwitz) Date: Tue, 07 Jan 2020 22:54:59 -0500 Subject: What are some threats against which OpenPGP smartcards are useful? In-Reply-To: <87d0bwqi95.fsf@grothesque.org> (Christoph Groth's message of "Tue, 07 Jan 2020 00:26:14 +0100") References: <87d0bwqi95.fsf@grothesque.org> Message-ID: <87blrer4a4.fsf@gnu.org> On Tue, Jan 07, 2020 at 00:26:14 +0100, Christoph Groth wrote: > Through an article [1] in LWN, I stumbled across a thread [2] on this > list that dealt with the usefulness of smartcards for storing > OpenPGP keys. I don't have time to read what I already wrote in that thread, so I'm sorry if I repeated myself here. > I understand that OpenPGP smartcards do not protect from a compromise > of the computer system that they are used with. As Peter Lebbing puts > it [3]: > >> You don't even have to decrypt the document they're interested in >> yourself, and no external push button will save you. Just decrypt >> a document twice, and the second time, the attacker can use your >> smartcard for their own good while providing the session key they >> logged the first time for your decryption. > > But then, what are threats against which smartcards *are* useful? That's too coarse of a conclusion. Let's say I decided to plug my Nitrokey into some adversary's computer, willingly, and enter my PIN. The attacker can make use of the card while it's plugged in. But operations using the card are very slow, and I'll notice the light going on more than once. I'll unplug it. Attack mitigated. The only thing lost is whatever the attacker managed to do within that time period---decrypt files, sign documents, SSH into remote machines, etc. (Don't get me wrong: all those are really bad.) Then I go to a safe location and change my PIN. Or maybe I'm punched out and my smartcard stolen. I go home, revoke my subkeys, and have to pay for a new smartcard. And let some people know that I was beat up and you shouldn't trust anything that was signed in that time period. But consider the alternative: if you weren't using a smartcard, and your key were on disk, all of that still would have happened. But in addition, your private key has been compromised. You now have to revoke your entire key. If you've built a web of trust, you have to start again. Smart cards _are_ useful even if your system is compromised, because it still protects your key from offline use. It gives me peace of mind when it's capped and stored in a safe location. If you just leave your smart card plugged into your computer 24/7 and leave your computer on while you're sleeping, that's a problem. It won't protect you from bad practices. You can get some of those benefits by e.g. using a laptop as a thin client and forwarding the GPG agent to a remote box over SSH, and store the private key on the laptop. The risk is still higher than a smartcard though. It all depends on your threat model. > I got a smartcard to ssh from computers that I trust reasonably but > where I am not (the only) root to other (more trusted) machines that > I control exclusively and that hold data that I would not store on the > less-trusted machines. From a fundamental point of view a smartcard > does not provide any additional security here, but I have the > imporession that in practice it does, because gaining access to the > remote machines becomes more difficult for an attacker (without > a smartcard, installing a simple keylogger is enough). This is the same > kind of imperfect security we rely on in real life, for example with > door locks. Would you agree with me? I use my Nitrokey for SSH as well. Prior to having it, I would store an SSH key to personal accounts on e.g. my work computer. I cannot fully trust that system. But today I don't need to do that: I insert the Nitrokey only when prompted by GPG, immediately remove it, and change my PIN when I get home. While there's still the risk that the card may be used for other things by a malicious process, it's pretty well mitigated. I know how long the light on the smartcard should be on for and watch it the entire time. I never allow the card to be out of my view when connected to a system. Of course, there's also the risk that someone has physically tampered with the smartcard to suppress the LED under certain circumstances. This isn't foolproof. But it's better than SSH keys on my work system. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 818 bytes Desc: not available URL: From christoph at grothesque.org Tue Jan 7 23:38:34 2020 From: christoph at grothesque.org (Christoph Groth) Date: Tue, 07 Jan 2020 23:38:34 +0100 Subject: What are some threats against which OpenPGP smartcards are useful? In-Reply-To: (Wiktor Kwapisiewicz's message of "Tue, 7 Jan 2020 14:09:50 +0100") References: <87d0bwqi95.fsf@grothesque.org> Message-ID: <87r20aopsl.fsf@grothesque.org> Wiktor Kwapisiewicz wrote: > There is one feature of smartcards that's hard to reproduce otherwise: > once you pull the smartcard out of the port the attacker can't use it. > > (...) Thanks, that?s a good point! So if one?s concern is signing or authentication, this is indeed useful. However, if one?s concern is protecting encrypted secrets that are regularly accessed (like passwords) and can be thus stolen, there seems to be less of a gain. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From christoph at grothesque.org Tue Jan 7 23:58:44 2020 From: christoph at grothesque.org (Christoph Groth) Date: Tue, 07 Jan 2020 23:58:44 +0100 Subject: What are some threats against which OpenPGP smartcards are useful? References: <87d0bwqi95.fsf@grothesque.org> <455318a2e8fba9a1ea4aea3733baa8cf@mail.monkeyblade.net> Message-ID: <87blreoouz.fsf@grothesque.org> Robert J. Hansen wrote: > On 2020-01-06 18:26, Christoph Groth wrote: > > > > But then he also mentions his 128-bit passphrase and that he would > > be OK to publish his (passphrase-protected) private key in > > a newspaper. Why then not store it on the disks of multiple > > computers? > > Hint: because the phrase "forensics lab" is extremely important in > what I wrote. > > (...) Thanks a lot for the explaination, Rob. Now I understand what you meant. > But, outside of that laboratory environment, I didn't -- still > don't -- need to use a smartcard. Usually I just keep the key on the > hard drive of whatever machine I'm using. How about the alternative of keeping small USB keycards (like a Yubikey nano) permanently plugged into the machines that you are using? Assuming that you trust the keycards to keep their secrets, wouldn?t that provide at least the advantage of a much shorter passphrase? Are there any security disadvantages of such a scheme? By the way, I would be still interested in expert opinion about the last paragraph of my original mail, in case someone could spare the time. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From andrewg at andrewg.com Wed Jan 8 13:51:58 2020 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 8 Jan 2020 12:51:58 +0000 Subject: What are some threats against which OpenPGP smartcards are useful? In-Reply-To: <87blreoouz.fsf@grothesque.org> References: <87d0bwqi95.fsf@grothesque.org> <455318a2e8fba9a1ea4aea3733baa8cf@mail.monkeyblade.net> <87blreoouz.fsf@grothesque.org> Message-ID: <10007b69-f7d8-cf0e-ce94-644a7a478b91@andrewg.com> On 07/01/2020 22:58, Christoph Groth wrote: > How about the alternative of keeping small USB keycards (like a Yubikey > nano) permanently plugged into the machines that you are using? > Assuming that you trust the keycards to keep their secrets, wouldn?t > that provide at least the advantage of a much shorter passphrase? Are > there any security disadvantages of such a scheme? That effectively uses the smartcard as a hardware security module, which does have some advantages. The disadvantages are that if an attacker has code execution access to your machine they still have full access to use the key material. However, they cannot exfiltrate that key material, so any malfeasance must be performed on your machine directly, which makes it noisy. That may or may not be a deterrent, depending on your threat model. It is more secure than having your private keys on disk, it just may not be sufficiently secure. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From brian at minton.name Wed Jan 8 14:54:31 2020 From: brian at minton.name (Brian Minton) Date: Wed, 8 Jan 2020 08:54:31 -0500 Subject: Forward entire gnupg $HOME In-Reply-To: <1568065141.1086.7.camel@16bits.net> References: <20190904204122.GA27946@debs.ak-online.be> <72ed0a5f-5c9d-4318-a180-38c45e88ab90@mail.com> <1568065141.1086.7.camel@16bits.net> Message-ID: <20200108135430.GA17066@pops-mintonw10.globe.nemgint.com> On Mon, Sep 09, 2019 at 11:39:01PM +0200, ?ngel wrote: > On 2019-09-05 at 08:59 +0200, john doe wrote: > > On 9/4/2019 10:41 PM, Andre Kl?rner wrote: > > > I usually use my workstation to do everything, but since I can't > > > access my mailbox via NFS anymore (different story), I resorted to > > > sshing into my email server, and doing all the mailing needs right > > > there, locally. > (...) > > > > The obvious solution would be to use mutt on your work station! :) > > Using mutt locally seems much simpler than forcing gnupg to work that > way. You mention that you can no longer access your mailbox via nfs, > but since you can ssh to the email server, maybe you could mount it > with sshfs? There are some problems with sshfs, however, such as slowness and locking. It would probably be better to run an imap daemon on your mail server, and have mutt use imap to access the mailbox. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 390 bytes Desc: not available URL: From andrewg at andrewg.com Wed Jan 8 18:35:20 2020 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 8 Jan 2020 17:35:20 +0000 Subject: What are some threats against which OpenPGP smartcards are useful? In-Reply-To: References: <87d0bwqi95.fsf@grothesque.org> <455318a2e8fba9a1ea4aea3733baa8cf@mail.monkeyblade.net> <87blreoouz.fsf@grothesque.org> <10007b69-f7d8-cf0e-ce94-644a7a478b91@andrewg.com> Message-ID: On 2020/01/08 17:29, Franck Routier (perso) wrote: > Notice that some features, like the metal contact toggle on some yubikey > can mitigate the problem of having an attacker with full local access. > You then have to touch the key each time you want to use it, so > illegitimate access would be noticed. On my yubikey at least, the touch contact is only used for the FIDO 2FA - the PGP smartcard feature is secured by PIN as per any other smartcard. -- Andrew Gallagher From alci at mecadu.org Wed Jan 8 18:50:39 2020 From: alci at mecadu.org (Franck Routier (perso)) Date: Wed, 08 Jan 2020 18:50:39 +0100 Subject: What are some threats against which OpenPGP smartcards are useful? In-Reply-To: References: <87d0bwqi95.fsf@grothesque.org> <455318a2e8fba9a1ea4aea3733baa8cf@mail.monkeyblade.net> <87blreoouz.fsf@grothesque.org> <10007b69-f7d8-cf0e-ce94-644a7a478b91@andrewg.com> Message-ID: <0760FF77-7208-4F87-81CE-F8A6DC3AD6C7@mecadu.org> I think this can be configured: ykman openpgp touch enc on ykman openpgp touch sig on Franck Le 8 janvier 2020 18:35:20 GMT+01:00, Andrew Gallagher a ?crit : >On 2020/01/08 17:29, Franck Routier (perso) wrote: >> Notice that some features, like the metal contact toggle on some >yubikey >> can mitigate the problem of having an attacker with full local >access. >> You then have to touch the key each time you want to use it, so >> illegitimate access would be noticed. > >On my yubikey at least, the touch contact is only used for the FIDO 2FA >- the PGP smartcard feature is secured by PIN as per any other >smartcard. > >-- >Andrew Gallagher -- Envoy? de /e/ Mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alci at mecadu.org Wed Jan 8 18:29:25 2020 From: alci at mecadu.org (Franck Routier (perso)) Date: Wed, 08 Jan 2020 18:29:25 +0100 Subject: What are some threats against which OpenPGP smartcards are useful? In-Reply-To: <10007b69-f7d8-cf0e-ce94-644a7a478b91@andrewg.com> References: <87d0bwqi95.fsf@grothesque.org> <455318a2e8fba9a1ea4aea3733baa8cf@mail.monkeyblade.net> <87blreoouz.fsf@grothesque.org> <10007b69-f7d8-cf0e-ce94-644a7a478b91@andrewg.com> Message-ID: Notice that some features, like the metal contact toggle on some yubikey can mitigate the problem of having an attacker with full local access. You then have to touch the key each time you want to use it, so illegitimate access would be noticed. Le 8 janvier 2020 13:51:58 GMT+01:00, Andrew Gallagher a ?crit : >On 07/01/2020 22:58, Christoph Groth wrote: >> How about the alternative of keeping small USB keycards (like a >Yubikey >> nano) permanently plugged into the machines that you are using? >> Assuming that you trust the keycards to keep their secrets, wouldn?t >> that provide at least the advantage of a much shorter passphrase? >Are >> there any security disadvantages of such a scheme? > >That effectively uses the smartcard as a hardware security module, >which >does have some advantages. The disadvantages are that if an attacker >has >code execution access to your machine they still have full access to >use >the key material. However, they cannot exfiltrate that key material, so >any malfeasance must be performed on your machine directly, which makes >it noisy. That may or may not be a deterrent, depending on your threat >model. It is more secure than having your private keys on disk, it just >may not be sufficiently secure. > >-- >Andrew Gallagher -- Envoy? de /e/ Mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnupg-users at spodhuis.org Wed Jan 8 20:01:04 2020 From: gnupg-users at spodhuis.org (Phil Pennock) Date: Wed, 8 Jan 2020 14:01:04 -0500 Subject: Re-sign subkey binding with changed digest? Message-ID: <20200108190103.GA26246@breadbox.private.spodhuis.org> So, this SHA-1 mess is "fun". To get a fresh self-sig user ID signature on the main key, I can do this: gpg --expert --cert-digest-algo SHA256 --sign-key ${KEYID:?} The `--expert` overrides the "already signed" safety check, letting you confirm that yes you really want this. Alas, it seems that `--ask-cert-expire` is not enough, it no-ops out. For sub-key bindings, for encryption keys it's easy: just generate a new encryption sub-key, let it be signed with a modern hash, and future messages encrypted to you will just use the new subkey. For non-encryption subkeys, I'm looking really at signing subkeys: it seems useful to make sure that existing signatures can continue to be verified. How do I re-sign the subkey binding for a [S] signing subkey, to keep the same key but make the association from the main key be with SHA256 please? Thanks, -Phil -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 996 bytes Desc: Digital signature URL: From andrewg at andrewg.com Wed Jan 8 22:37:28 2020 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 8 Jan 2020 21:37:28 +0000 Subject: Re-sign subkey binding with changed digest? In-Reply-To: <20200108190103.GA26246@breadbox.private.spodhuis.org> References: <20200108190103.GA26246@breadbox.private.spodhuis.org> Message-ID: <4D7EED05-9227-45EF-87E8-8CE1429DCA5E@andrewg.com> > On 8 Jan 2020, at 20:05, Phil Pennock via Gnupg-users wrote: > > How do I re-sign the subkey binding for a [S] signing subkey, to keep > the same key but make the association from the main key be with SHA256 > please? Have you tried changing the subkey expiry? Or does that reuse the same hash? A From wk at gnupg.org Thu Jan 9 12:56:42 2020 From: wk at gnupg.org (Werner Koch) Date: Thu, 09 Jan 2020 12:56:42 +0100 Subject: Re-sign subkey binding with changed digest? In-Reply-To: <4D7EED05-9227-45EF-87E8-8CE1429DCA5E@andrewg.com> (Andrew Gallagher's message of "Wed, 8 Jan 2020 21:37:28 +0000") References: <20200108190103.GA26246@breadbox.private.spodhuis.org> <4D7EED05-9227-45EF-87E8-8CE1429DCA5E@andrewg.com> Message-ID: <87muawg7wl.fsf@wheatstone.g10code.de> On Wed, 8 Jan 2020 21:37, Andrew Gallagher said: > Have you tried changing the subkey expiry? Or does that reuse the same hash? That is what I would also suggest. The expire sub-command is useful for all such things. It should always use the current default digest algorithms. Regarding the SHA-1 collisions: GnuPG 2.2 still considers SHA-1 based self-signatures (either on a user-id or a subkey) has valid. If we would disallow that all dsa1024 keys would be rendered useless. dsa1024 requires SHA-1. Compared to the trouble we already had with removing PGP-2 keys, removing dsa1024 would be a much loader outcry. Nevertheless, moving away from dsa1024 is important. We just can't force users to do that. 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 azbigdogs at gmx.com Thu Jan 9 20:58:26 2020 From: azbigdogs at gmx.com (Mark) Date: Thu, 9 Jan 2020 12:58:26 -0700 Subject: Changes in GnuPG In-Reply-To: <20200106224351.l6isnesfo4t5xysh@dynein.local.incenp.org> References: <20200106224351.l6isnesfo4t5xysh@dynein.local.incenp.org> Message-ID: Damien, Thanks for the explanation on the keygrips. That makes sense why it is some "random" set of characters.? I understand (I think) it is acting like a place marker but still trying to understand the why part. I guess I need to export my keys to make it accessible to other apps that use PGP (LibreOffice, PowerArchiver, etc) On 1/6/2020 3:43 PM, Damien Goutte-Gattat wrote: > On Mon, Jan 06, 2020 at 04:42:40PM +0100, azbigdogs at gmx.com wrote: >> I'm still a bit confused on the changes in secring. How does it come up >> with the names for those "new" keys as it doesn't seem to corrolate >> with anything I can see on the keys. > > Files under the $GNUPGHOME/private-keys-v1.d directory are named after > the *keygrips* of the keys. > > A keygrip is similar in principle to an OpenPGP fingerprint, but is > computed on a data structure that is independent of any protocol > (contrary to an OpenPGP fingerprint, which is computed over an OpenPGP > packet). > > GnuPG, which since its version 2.0 implements both OpenPGP and S/MIME, > uses keygrips internally to refer to a key independently of the > protocol with which the key is to be used. > > You can use the --with-keygrip option when listing keys to have GnuPG > display the keygrips, and check that they match the filenames you see > in the $GNUPGHOME/private-keys-v1.d directory. > > >> For them to go away from the OpenPGP standard it obviously had to make >> sense to them > > The OpenPGP standard dictates how compliant implementations > interoperate. It says nothing about what the implementations shall do > internally. > > Keygrips are strictly an internal implementation detail of GnuPG. When > it interacts with the outside world (e.g. when exporting a key), GnuPG > still follows the OpenPGP standard. > > > Cheers, > > - Damien From azbigdogs at gmx.com Thu Jan 9 21:01:43 2020 From: azbigdogs at gmx.com (Mark) Date: Thu, 9 Jan 2020 13:01:43 -0700 Subject: Changes in GnuPG In-Reply-To: <7079a8e1-70e3-bee8-bc04-4f5e1f907bab@sixdemonbag.org> References: <7079a8e1-70e3-bee8-bc04-4f5e1f907bab@sixdemonbag.org> Message-ID: <77d0170b-1a05-6917-f7c3-350f1f9bba5c@gmx.com> Robert, Thanks for the explantion of the new public key format. If I understand it correctly, the old system was like a flat file an this new one is more like an indexed database that allows faster lookups. On 1/7/2020 12:37 AM, Robert J. Hansen wrote: >> I'm still a bit confused on the changes in secring. How does it come up >> with the names for those "new" keys as it doesn't seem to corrolate with >> anything I can see on the keys. > The names are actually keygrips, not fingerprints. > >> For them to go away from the OpenPGP standard it obviously had to make >> sense to them? > They didn't. RFC4880 doesn't define how to store certificates. > > Way back when, PGP Corporation stored its two keyrings as "pubring.pkr" > and "secring.skr". These two files were incredibly simple: each was > effectively an OpenPGP message containing nothing but a long sequence of > certificates. When PGP started it read each file into RAM, populated a > master keyring, and that was that. > > When GnuPG came along they decided to use the exact same format so that > people could migrate just by renaming their .pkr and .skr files to have > .gpg extensions. And this was likely a good decision, in that it made > it easy for people to switch from PGP. > > PGP is no longer a serious player in the OpenPGP space. Symantec bought > PGP years ago and seem to have been neglecting it ever since. > Consequentially, we no longer *need* to use old PGP formats to encourage > people to cross over. And at the same time, keyrings are getting a lot > bigger -- back in 2000 few people had more than a couple of dozen > certificates; twenty years later it's easy to have a few *hundred* > certificates. And the old, inefficient PGP keyring format doesn't work > very well any more. > > We don't need the PGP compatibility any more and it's holding us back. > That's the root reason for the changes. > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From wk at gnupg.org Thu Jan 9 21:44:12 2020 From: wk at gnupg.org (Werner Koch) Date: Thu, 09 Jan 2020 21:44:12 +0100 Subject: Changes in GnuPG In-Reply-To: <77d0170b-1a05-6917-f7c3-350f1f9bba5c@gmx.com> (Mark's message of "Thu, 9 Jan 2020 13:01:43 -0700") References: <7079a8e1-70e3-bee8-bc04-4f5e1f907bab@sixdemonbag.org> <77d0170b-1a05-6917-f7c3-350f1f9bba5c@gmx.com> Message-ID: <87woa0e4wz.fsf@wheatstone.g10code.de> On Thu, 9 Jan 2020 13:01, Mark said: > Thanks for the explantion of the new public key format. If I understand > it correctly, the old system was like a flat file an this new one is > more like an indexed database that allows faster lookups. Right. The keybox format includes meta data so that there is no requirement to parse each and every key in the keyring to compute the fingerprint while gpg is searching for a key with a specific fingerprint. Actually there is no index although the format is prepared for this. I don't think that we will ever add an inde, though. The next major version instead will come with an option to store the keys in an SQLite database file. Thus, as it has been always said, please use the --import and --export options to convey OpenPGP or X.509 keys. Only if you want to keep two GnuPG installations of the same version in sync you may copy the entire GNUPGHOME (e.g. ~/.gnupg) - even between different platforms. Salam-Shalom, Werner @rjh: I guess you will now remark about random_seed, but I don't think tha this is anymore an issue with modern versions. The entropy gathering changed quite a bit in the 2.2 and we may eventually remove that file. (Due to the new JitterRNG which is sufficient on Windows and the faster getrandom call on Linux). -- 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 Fri Jan 10 01:13:27 2020 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 9 Jan 2020 19:13:27 -0500 Subject: Changes in GnuPG In-Reply-To: <87woa0e4wz.fsf@wheatstone.g10code.de> References: <7079a8e1-70e3-bee8-bc04-4f5e1f907bab@sixdemonbag.org> <77d0170b-1a05-6917-f7c3-350f1f9bba5c@gmx.com> <87woa0e4wz.fsf@wheatstone.g10code.de> Message-ID: > @rjh: I guess you will now remark about random_seed, but I don't think > tha this is anymore an issue with modern versions. The entropy > gathering changed quite a bit in the 2.2 and we may eventually remove > that file. (Due to the new JitterRNG which is sufficient on Windows and > the faster getrandom call on Linux). Growing up in a family of hunters, I learned at an early age that even if someone tells you a firearm is unloaded you should still clear the chamber and store it pointed in a safe direction... especially if someone tells you "no, really, it's perfectly safe, I just checked it". I apply the same to any file claiming to be a random seed. No matter who tells me it's safe to copy it I'm not going to copy it, and I think other people would be best served to adopt the same rule. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 821 bytes Desc: OpenPGP digital signature URL: From deisner at gmail.com Fri Jan 10 16:48:38 2020 From: deisner at gmail.com (David Eisner) Date: Fri, 10 Jan 2020 10:48:38 -0500 Subject: GnuPG website docs Message-ID: The Documentation pages on gnupg.org should be updated to let users (especially new users) know which information there is out of date. Users are encouraged to use GnuPG version 2. Put yourself in the position of a new user. You visit the Documentation menu on the home page (already a bit overwhelming -- HOWTOs, Manuals, Guides, ...) and go to HOWTOs. It says up front, "You may get the best overview about the GnuPG system by reading the mini HOWTO ..." great. Except that the Mini Howto (in English, at least) is from 2004, two years before the release of GnuPG 2.0.0. This will often be the first doc new users will read, and it will be misleading. 1. I think there should be a notice near the top of https://gnupg.org/documentation/howtos.html that says something like this: "The mini HOWTO is out-of date and documents an older version of GnuPG. For more up-to-date documentation, please see ..." 2. "HOWTOs" should be moved to a lower spot in the Documentation menu on the website. -David -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Mon Jan 13 09:51:47 2020 From: wk at gnupg.org (Werner Koch) Date: Mon, 13 Jan 2020 09:51:47 +0100 Subject: GnuPG website docs In-Reply-To: (David Eisner via Gnupg-users's message of "Fri, 10 Jan 2020 10:48:38 -0500") References: Message-ID: <87k15vpwm4.fsf@wheatstone.g10code.de> On Fri, 10 Jan 2020 10:48, David Eisner said: > 1. I think there should be a notice near the top of > https://gnupg.org/documentation/howtos.html that says something like this: > "The mini HOWTO is out-of date and documents an older version of GnuPG. For > more up-to-date documentation, please see ..." I added some notices but I am not sure what to suggest as replacement. > 2. "HOWTOs" should be moved to a lower spot in the Documentation menu on > the website. Yes, the HOWTOS _used_ to be more useful than the manuals etc. 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 mailinglisten at posteo.de Mon Jan 13 08:16:47 2020 From: mailinglisten at posteo.de (mailing list) Date: Mon, 13 Jan 2020 08:16:47 +0100 Subject: Automatic encryption to several recipients Message-ID: <8a84115a-d0ce-d3bc-ad32-a2f49c36c0bc@posteo.de> Hi there, for automatic encryption to several always repeating recipients, especially to own keys, you use the --encrypt-to option. I?d like to use it in gpg.conf. I wonder, can it be used to encrypt to more than one key? What would be the correct syntax? Something like encrypt-to KEY1 encrypt-to KEY2 encrypt-to KEY3 or "encrypt-to KEY1 KEY2 KEY3" Thanks in advance! From wk at gnupg.org Mon Jan 13 12:00:53 2020 From: wk at gnupg.org (Werner Koch) Date: Mon, 13 Jan 2020 12:00:53 +0100 Subject: Automatic encryption to several recipients In-Reply-To: <8a84115a-d0ce-d3bc-ad32-a2f49c36c0bc@posteo.de> (mailing list via Gnupg-users's message of "Mon, 13 Jan 2020 08:16:47 +0100") References: <8a84115a-d0ce-d3bc-ad32-a2f49c36c0bc@posteo.de> Message-ID: <8736cjpqmy.fsf@wheatstone.g10code.de> On Mon, 13 Jan 2020 08:16, mailing list said: > Something like > encrypt-to KEY1 > encrypt-to KEY2 > encrypt-to KEY3 Right. It works the same as --recipient and thus the argument to the option is the specification of a single key. Please use the fingerprint to specify the key. Using the keyid or user-id is also possible but there is a chance that the worn key is picked up if the specification is non-unique. 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 wangqr at wangqr.tk Tue Jan 14 22:39:16 2020 From: wangqr at wangqr.tk (wangqr) Date: Tue, 14 Jan 2020 16:39:16 -0500 Subject: NXDOMAIN for hkps.pool.sks-keyservers.net Message-ID: <495cc949-2862-f120-6359-23f812bc4b04@wangqr.tk> GnuPG uses hkps://hkps.pool.sks-keyservers.net as the default dirmnger key server. But this domain does not exist. From https://sks-keyservers.net/status/ I see no server in the pool supports hkps. I wonder if this is the reason for the non-existence of the domain. I understand that user can always use --keyserver option to specify a working key server. I'm just asking if we should change the default value, if it is not working anymore. wangqr drill output: $ drill hkps.pool.sks-keyservers.net @s01.sks-keyservers.net. ;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 3611 ;; flags: qr aa rd ; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;; hkps.pool.sks-keyservers.net.??????? IN????? A ;; ANSWER SECTION: ;; AUTHORITY SECTION: sks-keyservers.net.???? 600???? IN????? SOA ns2.kfwebs.net. kf.kfwebs.net. 3200114222 600 14400 172800 600 ;; ADDITIONAL SECTION: ;; Query time: 122 msec ;; SERVER: 192.146.137.185 ;; WHEN: Tue Jan 14 21:23:37 2020 ;; MSG SIZE? rcvd: 96 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bortzmeyer at nic.fr Wed Jan 15 12:25:29 2020 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 15 Jan 2020 12:25:29 +0100 Subject: NXDOMAIN for hkps.pool.sks-keyservers.net In-Reply-To: <495cc949-2862-f120-6359-23f812bc4b04@wangqr.tk> References: <495cc949-2862-f120-6359-23f812bc4b04@wangqr.tk> Message-ID: <20200115112529.GA3901@nic.fr> On Tue, Jan 14, 2020 at 04:39:16PM -0500, wangqr via Gnupg-users wrote a message of 122 lines which said: > GnuPG uses hkps://hkps.pool.sks-keyservers.net as the default > dirmnger key server. But this domain does not exist. I do not share this assessment. % dig +short hkps.pool.sks-keyservers.net A 209.244.105.201 82.148.229.254 192.146.137.98 37.191.231.105 192.146.137.99 Most RIPE Atlas probes agree with me: % blaeu-resolve --type A --requested 100 hkps.pool.sks-keyservers.net. [192.146.137.98 192.146.137.99 209.244.105.201 37.191.231.105 82.148.229.254] : 93 occurrences [ERROR: NXDOMAIN] : 1 occurrences [192.146.137.98 209.244.105.201 37.191.231.105 82.148.229.254] : 4 occurrences [ERROR: SERVFAIL] : 2 occurrences Test #23834618 done at 2020-01-15T11:23:19Z You DNS resolver has probably a problem. From kristian.fiskerstrand at sumptuouscapital.com Wed Jan 15 15:19:55 2020 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Wed, 15 Jan 2020 15:19:55 +0100 Subject: NXDOMAIN for hkps.pool.sks-keyservers.net In-Reply-To: <495cc949-2862-f120-6359-23f812bc4b04@wangqr.tk> References: <495cc949-2862-f120-6359-23f812bc4b04@wangqr.tk> Message-ID: <1b288c54-c465-66f2-7961-3f499bd0d5b5@sumptuouscapital.com> On 14.01.2020 22:39, wangqr via Gnupg-users wrote: > GnuPG uses hkps://hkps.pool.sks-keyservers.net as the default dirmnger > key server. But this domain does not exist. From > https://sks-keyservers.net/status/ I see no server in the pool supports > hkps. I wonder if this is the reason for the non-existence of the domain. > > I understand that user can always use --keyserver option to specify a > working key server. I'm just asking if we should change the default > value, if it is not working anymore. > Right.. there was an outage tonight affecting the hkps pool due to expiry of the CRL -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Corruptissima re publica plurim? leges The greater the degeneration of the republic, the more of its laws -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From deisner at gmail.com Wed Jan 15 20:37:48 2020 From: deisner at gmail.com (David Eisner) Date: Wed, 15 Jan 2020 14:37:48 -0500 Subject: GnuPG website docs In-Reply-To: <87k15vpwm4.fsf@wheatstone.g10code.de> References: <87k15vpwm4.fsf@wheatstone.g10code.de> Message-ID: On Mon, Jan 13, 2020 at 3:55 AM Werner Koch wrote: > > I added some notices but I am not sure what to suggest as replacement. > Vielen Dank. My guess is that the HOWTOs won't be updated anytime soon, so this might be the best you can do for the time being. -David -------------- next part -------------- An HTML attachment was scrubbed... URL: From wangqr at wangqr.tk Wed Jan 15 16:41:49 2020 From: wangqr at wangqr.tk (wangqr) Date: Wed, 15 Jan 2020 10:41:49 -0500 Subject: NXDOMAIN for hkps.pool.sks-keyservers.net In-Reply-To: <1b288c54-c465-66f2-7961-3f499bd0d5b5@sumptuouscapital.com> References: <495cc949-2862-f120-6359-23f812bc4b04@wangqr.tk> <1b288c54-c465-66f2-7961-3f499bd0d5b5@sumptuouscapital.com> Message-ID: <1f9a00ce-293e-5a52-ed51-d016507554dc@wangqr.tk> On 2020-01-15 9:19, Kristian Fiskerstrand wrote: > > Right.. there was an outage tonight affecting the hkps pool due to > expiry of the CRL > Thanks. Good to know that it is just a temporary issue and me being unlucky. wangqr From azbigdogs at gmx.com Fri Jan 17 14:47:10 2020 From: azbigdogs at gmx.com (Mark) Date: Fri, 17 Jan 2020 06:47:10 -0700 Subject: Passphrase and Key Structure Message-ID: <23fd2d4c-b66f-4978-bebd-b58812aabd0b@gmx.com> I was wondering what effect changing the passphrase has on the keys. Not only the keygrip file but also on the exported copy of it that can be used with other programs. If you change the passphrase, do you need to re-backup those keygrip files and re-export those keys again? Thanks From mailinglisten at posteo.de Sat Jan 18 11:32:44 2020 From: mailinglisten at posteo.de (mailing list) Date: Sat, 18 Jan 2020 11:32:44 +0100 Subject: Automatic encryption to several recipients In-Reply-To: <8736cjpqmy.fsf@wheatstone.g10code.de> References: <8a84115a-d0ce-d3bc-ad32-a2f49c36c0bc@posteo.de> <8736cjpqmy.fsf@wheatstone.g10code.de> Message-ID: <2057e467-6d88-425e-c3de-20faf41d6e43@posteo.de> On 13.01.20 at 12:00 talked Werner Koch: > On Mon, 13 Jan 2020 08:16, mailing list said: > >> Something like >> encrypt-to KEY1 >> encrypt-to KEY2 >> encrypt-to KEY3 > > Right. It works the same as --recipient and thus the argument to the > option is the specification of a single key. Please use the fingerprint > to specify the key. Using the keyid or user-id is also possible but > there is a chance that the worn key is picked up if the specification is > non-unique. Ah,ok. By the way, why is there no option like "--use-secret"? I know, GnuPG has some magic to use the correct secret key to decode data, but if you have some (a lot) secret key, this magic may waste time or be inconvenient in some way. A "--use-secret-key" option would give the user full control to use a chosen secret key without depending on any auto mechanism. Maybe something to consider. Best regards From 2017-r3sgs86x8e-lists-groups at riseup.net Sat Jan 18 19:20:35 2020 From: 2017-r3sgs86x8e-lists-groups at riseup.net (MFPA) Date: Sat, 18 Jan 2020 18:20:35 +0000 Subject: Automatic encryption to several recipients In-Reply-To: <2057e467-6d88-425e-c3de-20faf41d6e43@posteo.de> References: <8a84115a-d0ce-d3bc-ad32-a2f49c36c0bc@posteo.de> <8736cjpqmy.fsf@wheatstone.g10code.de> <2057e467-6d88-425e-c3de-20faf41d6e43@posteo.de> Message-ID: <494665543.20200118182035@my_localhost_LG> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Saturday 18 January 2020 at 10:32:44 AM, in , mailing list via Gnupg-users wrote:- > By the way, why is there no option like "--use-secret"? It's called "--try-secret-key name". - -- Best regards MFPA Only dead fish go with the flow -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCXiNMkV8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju +vLiAP4qsyrN5ifqnysTcyrYNeAX9HUgKAe26zgM3e/a5wWMlwEAtP7lj47B59RI 9iLJJRY3GblrslEJBxvrwVp4vxJhNQGJApMEAQEKAH0WIQRSX6konxd5jbM7JygT DfUWES/A/wUCXiNMkl8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMw REY1MTYxMTJGQzBGRgAKCRATDfUWES/A/3OLEACRzoqSPkpzoLFxScd7+zTL+/hZ V0mvjFxDu18+a9PfxvATtAEbHtXrDCfvhPz8m5k/EDJ2vmmgFHFg5YmriJFPONtN 3yQAcY4SGOlEMUj2ypz+oXNHKQb+SmtpSQgQUJoPMoHXlwpHYZIB9KV2sXzj3Jwo /tiHkCUmOqh/PxFy9W+RSUftEGUzmP4vlK0Vkmk+Tz4oYKs2McCFPfim+4/p85+l k9/X+8+UAzNXoHkH1zhyKpGdfvjiWLxceCNitzA+UGJE276Yv1wi4XN+Y6XQBZ+Z jjVZCcw/Nn93iiqKWeHCsulJRauEF8gZpx9jpik/lR3TQSb/1SsymqpKQv/jG5Nb z3GJ4f0FUGBjnCtx4eKLjOqlsOlePVVshz8kZaT3LqivEaH54Dff5HTxpWaPK2Oa Du0QfSQtBaPLUhq08BQ4/MwIW92MruBQx435tslBmb7Ucq9Oqc3Jm66M19DsSUP/ kHvj9MAqSXdOnTXlNlIMlmGND5tGwCSysRU1sVgU0tsSlkelsc8UfgtlnWHgsNQD 95/TC3sWsb/w4mmhXcFYudU3qjYiDRHSn4elXGH357bI2T3qQXv0JTnlPHI8EFjm ResUrC8kXfm+HuctbgYw8cIoFUvRSoK5ZC4GAsj4huuTf77dKuw8gIlSRULW+OQm xiDXD+KiRk9B/odOAQ== =BqI+ -----END PGP SIGNATURE----- From gibboris at gmail.com Sun Jan 19 00:54:48 2020 From: gibboris at gmail.com (Raph) Date: Sat, 18 Jan 2020 20:54:48 -0300 Subject: local key as smartcard *fallback* Message-ID: <20200118235448.GA15340@kratos> Hi, When using keytocard, the keyring is informed that the key is now stored on a smartcard... only (unless removed explicitly). If the smartcard is unavailable (lost or whatever), is there an *easy* way to tell the agent to automatically use the local key, if present ? Basically: *If* the smartcard is not present, *Then* *If* a local and password-protected version exists, *Then* use it as a fallback. I do understand that smartcard security depends on *not* having the local key present. But such a (more flexible) key lookup policy would still be useful in some situations like for a smoother transition to smartcard or smartcard used optionally on several computers, ... Thank you. Related question: https://security.stackexchange.com/questions/183226/how-to-force-gpg-to-use-a-keycard-when-it-is-available From wk at gnupg.org Mon Jan 20 15:21:51 2020 From: wk at gnupg.org (Werner Koch) Date: Mon, 20 Jan 2020 15:21:51 +0100 Subject: setrlimit failure on aarch64 (was: Interesting failure on aarch64) In-Reply-To: <20191220162212.qsi7yr5cmgdivmpd@chatter.i7.local> (Konstantin Ryabitsev's message of "Fri, 20 Dec 2019 11:22:12 -0500") References: <20191220162212.qsi7yr5cmgdivmpd@chatter.i7.local> Message-ID: <875zh6nr7k.fsf@wheatstone.g10code.de> On Fri, 20 Dec 2019 11:22, Konstantin Ryabitsev said: > On x86_64 this succeeds, but when I tried building on aarch64, that step [...] > gpg: Fatal: can't disable core dumps: Operation not permitted setrlimit returns an unexpected error code: if (getrlimit (RLIMIT_CORE, &limit)) limit.rlim_max = 0; limit.rlim_cur = 0; if( !setrlimit (RLIMIT_CORE, &limit) ) return 0; if( errno != EINVAL && errno != ENOSYS ) log_fatal (_("can't disable core dumps: %s\n"), strerror(errno) ); This is the first time I see a report that EPERM is returned. Disabling core dumps is an easy and not to invasive security feature. The man gae for setrlimit mentions this: EPERM An unprivileged process tried to raise the hard limit; the CAP_SYS_RESOURCE capability is required to do this. EPERM The caller tried to increase the hard RLIMIT_NOFILE limit above the maximum defined by /proc/sys/fs/nr_open (see proc(5)) We are not increasing the limit so we should not see this error. For the linux specific prlimit, which we do not use, there is an additional erro code reason: EPERM (prlimit()) The calling process did not have permission to set limits for the process specified by pid. Next step would be look into glibc and then into aarch64 kernel specific implementation details of setrlimit. 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 sac at 300baud.de Tue Jan 21 21:08:52 2020 From: sac at 300baud.de (Stefan Claas) Date: Tue, 21 Jan 2020 21:08:52 +0100 Subject: Message Padding for GnuPG Message-ID: <20200121210852.00004581.sac@300baud.de> Hi all, some of you may remember that I proposed years ago 'message padding' for GnuPG, but it was never implemented nor did I received a reply here. A while ago Justus proposed this on the IETF GnuPG working group ML: https://mailarchive.ietf.org/arch/msg/openpgp/wnwdiGRBrKpJos_djj6bgPd0IWU and I thought why wait ... Here is a solution for all users of encryption software and not only GnuPG: https://github.com/sac001/pad Regards Stefan -- NaClbox: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From sac at 300baud.de Tue Jan 21 23:02:59 2020 From: sac at 300baud.de (Stefan Claas) Date: Tue, 21 Jan 2020 23:02:59 +0100 Subject: Message Padding for GnuPG In-Reply-To: <20200121210852.00004581.sac@300baud.de> References: <20200121210852.00004581.sac@300baud.de> Message-ID: <20200121230259.00001cbe.sac@300baud.de> Stefan Claas via Gnupg-users wrote: > Hi all, > > some of you may remember that I proposed years ago 'message padding' for > GnuPG, but it was never implemented nor did I received a reply here. > > A while ago Justus proposed this on the IETF GnuPG working group ML: > > https://mailarchive.ietf.org/arch/msg/openpgp/wnwdiGRBrKpJos_djj6bgPd0IWU > > and I thought why wait ... > > Here is a solution for all users of encryption software and not only GnuPG: > > https://github.com/sac001/pad Maybe also useful for some of you, when encrypting symmetrically with GnuPG, because 'gpg --list-packets' shows the original byte size of the unencrypted message or file, including the original filename. Regards Stefan -- NaClbox: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From wk at gnupg.org Wed Jan 22 09:08:35 2020 From: wk at gnupg.org (Werner Koch) Date: Wed, 22 Jan 2020 09:08:35 +0100 Subject: Message Padding for GnuPG In-Reply-To: <20200121230259.00001cbe.sac@300baud.de> (Stefan Claas via Gnupg-users's message of "Tue, 21 Jan 2020 23:02:59 +0100") References: <20200121210852.00004581.sac@300baud.de> <20200121230259.00001cbe.sac@300baud.de> Message-ID: <87pnfblxq4.fsf@wheatstone.g10code.de> On Tue, 21 Jan 2020 23:02, Stefan Claas said: > because 'gpg --list-packets' shows the original byte size of the unencrypted > message or file, including the original filename. --list-packets can't show the original filename because that info is encrypted. Note that --list-packets decrypts if it has access to the secret key. 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 stefanclaas at riseup.net Wed Jan 22 09:45:39 2020 From: stefanclaas at riseup.net (Stefan Claas) Date: Wed, 22 Jan 2020 00:45:39 -0800 Subject: Message Padding for GnuPG In-Reply-To: <87pnfblxq4.fsf@wheatstone.g10code.de> References: <20200121210852.00004581.sac@300baud.de> <20200121230259.00001cbe.sac@300baud.de> <87pnfblxq4.fsf@wheatstone.g10code.de> Message-ID: <36515c0de2b1b3a0f67cbe2b95595173@riseup.net> On 2020-01-22 09:08, Werner Koch via Gnupg-users wrote: > On Tue, 21 Jan 2020 23:02, Stefan Claas said: > >> because 'gpg --list-packets' shows the original byte size of the unencrypted >> message or file, including the original filename. > > --list-packets can't show the original filename because that info is > encrypted. Note that --list-packets decrypts if it has access to the > secret key. Thank you for pointing that out, but I don't understand then when I do not enter my passphrase for symmetric decryption of how GnuPG does this, or are you referring to asymmetric encryption? Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From stefanclaas at riseup.net Wed Jan 22 12:04:26 2020 From: stefanclaas at riseup.net (Stefan Claas) Date: Wed, 22 Jan 2020 03:04:26 -0800 Subject: Message Padding for GnuPG In-Reply-To: <36515c0de2b1b3a0f67cbe2b95595173@riseup.net> References: <20200121210852.00004581.sac@300baud.de> <20200121230259.00001cbe.sac@300baud.de> <87pnfblxq4.fsf@wheatstone.g10code.de> <36515c0de2b1b3a0f67cbe2b95595173@riseup.net> Message-ID: On 2020-01-22 09:45, Stefan Claas via Gnupg-users wrote: > On 2020-01-22 09:08, Werner Koch via Gnupg-users wrote: >> On Tue, 21 Jan 2020 23:02, Stefan Claas said: >> >>> because 'gpg --list-packets' shows the original byte size of the unencrypted >>> message or file, including the original filename. >> >> --list-packets can't show the original filename because that info is >> encrypted. Note that --list-packets decrypts if it has access to the >> secret key. > > Thank you for pointing that out, but I don't understand then when I do > not > enter my passphrase for symmetric decryption of how GnuPG does this, or > are you referring to asymmetric encryption? Stupid me, just checked by switching on and off my computer ... Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From sac at 300baud.de Thu Jan 23 18:11:08 2020 From: sac at 300baud.de (Stefan Claas) Date: Thu, 23 Jan 2020 18:11:08 +0100 Subject: Message Padding for GnuPG In-Reply-To: <20200121230259.00001cbe.sac@300baud.de> References: <20200121210852.00004581.sac@300baud.de> <20200121230259.00001cbe.sac@300baud.de> Message-ID: <20200123181108.00004fdb.sac@300baud.de> Stefan Claas via Gnupg-users wrote: > > https://github.com/sac001/pad For those who like to try out, without installing Golang: https://keybase.pub/stefan_claas/software/pad/ Regards Stefan -- NaClbox: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From jcross at gmail.com Thu Jan 23 17:32:37 2020 From: jcross at gmail.com (Jonathan Cross) Date: Thu, 23 Jan 2020 17:32:37 +0100 Subject: Batch generate keys without revocation cert? Message-ID: Hello, I would like to batch generate keys, but *not* have a revocation cert generated. I do not see an option for this, how can it be done? Thanks, Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Thu Jan 23 17:46:16 2020 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 23 Jan 2020 17:46:16 +0100 Subject: (GPG1) Download of false key? Key not included? Message-ID: <20200123164616.kbjVG%steffen@sdaoden.eu> Hello. Can anyone tell me what is actually going on here. If it is as easy as "use GPG2" do not waste that much time, however, doesn't the below use RSA plus SHA-512, what v1 supports? ( Supported algorithms: Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 And you will not go for zstd i have seen fly by, right, even though it decompresses very, very fast, and is a small and self- sufficient implementation. Do you.) #?0|kent:gmake.tar_bomb_git-no_reduce$ gpg --verify make-4.3.tar.lz.sig Reading passphrase from file descriptor 4 gpg: assuming signed data in `make-4.3.tar.lz' gpg: Signature made Sun 19 Jan 2020 11:24:51 PM CET using RSA key ID DB78137A gpg: Can't check signature: public key not found #?2|kent:gmake.tar_bomb_git-no_reduce$ gpg --search-key DB78137A Reading passphrase from file descriptor 4 gpg: searching for "DB78137A" from hkps server hkps.pool.sks-keyservers.net (1) Paul D. Smith Paul D. Smith 4096 bit RSA key 20C79BB2, created: 2016-10-22 Keys 1-1 of 1 for "DB78137A". Enter number(s), N)ext, or Q)uit > 1 gpg: requesting key 20C79BB2 from hkps server hkps.pool.sks-keyservers.net gpg: Total number processed: 1 gpg: skipped new keys: 1 Why is it skipped? GPG1 does support RSA and SHA-512 digests (see below)? $ gpg --list-keys|grep -B1 -A1 Smith pub 1024D/6338B6D4 2004-01-04 uid Paul Smith (Mad Scientist) sub 2048g/E0EB03CE 2004-01-04 #?0|kent:gmake.tar_bomb_git-no_reduce$ gpg --delete-keys 6338B6D4 pub 1024D/6338B6D4 2004-01-04 Paul Smith (Mad Scientist) Delete this key from the keyring? (y/N) y #?0|kent:gmake.tar_bomb_git-no_reduce$ gpg -vvvvv --search-key DB78137A gpg: using character set `utf-8' Reading passphrase from file descriptor 4 gpg: searching for "DB78137A" from hkps server hkps.pool.sks-keyservers.net (1) Paul D. Smith Paul D. Smith 4096 bit RSA key 20C79BB2, created: 2016-10-22 Keys 1-1 of 1 for "DB78137A". Enter number(s), N)ext, or Q)uit > 1 gpg: requesting key 20C79BB2 from hkps server hkps.pool.sks-keyservers.net gpg: armor: BEGIN PGP PUBLIC KEY BLOCK gpg: armor header: Version: SKS 1.1.6 gpg: armor header: Comment: Hostname: sks.pod02.fleetstreetops.com :public key packet: version 4, algo 1, created 1477170443, expires 0 pkey[0]: [4096 bits] pkey[1]: [17 bits] keyid: 80CB727A20C79BB2 :user ID packet: "Paul D. Smith " :signature packet: algo 1, keyid 80CB727A20C79BB2 version 4, created 1477172043, md5len 0, sigclass 0x13 digest algo 10, begin of digest 3a bd hashed subpkt 2 len 4 (sig created 2016-10-22) hashed subpkt 27 len 1 (key flags: 03) hashed subpkt 11 len 4 (pref-sym-algos: 9 8 7 3) hashed subpkt 21 len 4 (pref-hash-algos: 10 9 8 11) hashed subpkt 22 len 4 (pref-zip-algos: 2 3 1 0) hashed subpkt 30 len 1 (features: 01) hashed subpkt 23 len 1 (key server preferences: 80) subpkt 16 len 8 (issuer key ID 80CB727A20C79BB2) data: [4095 bits] :signature packet: algo 17, keyid 96B047156338B6D4 version 4, created 1477178301, md5len 0, sigclass 0x13 digest algo 10, begin of digest 93 10 hashed subpkt 2 len 4 (sig created 2016-10-22) subpkt 16 len 8 (issuer key ID 96B047156338B6D4) data: [158 bits] data: [157 bits] :user ID packet: "Paul D. Smith " :signature packet: algo 1, keyid 80CB727A20C79BB2 version 4, created 1477172069, md5len 0, sigclass 0x13 digest algo 10, begin of digest e3 f0 hashed subpkt 27 len 1 (key flags: 03) hashed subpkt 11 len 4 (pref-sym-algos: 9 8 7 3) hashed subpkt 21 len 4 (pref-hash-algos: 10 9 8 11) hashed subpkt 22 len 4 (pref-zip-algos: 2 3 1 0) hashed subpkt 30 len 1 (features: 01) hashed subpkt 23 len 1 (key server preferences: 80) hashed subpkt 2 len 4 (sig created 2016-10-22) hashed subpkt 25 len 1 (primary user ID) subpkt 16 len 8 (issuer key ID 80CB727A20C79BB2) data: [4095 bits] :signature packet: algo 17, keyid 96B047156338B6D4 version 4, created 1477178301, md5len 0, sigclass 0x13 digest algo 10, begin of digest 89 10 hashed subpkt 2 len 4 (sig created 2016-10-22) subpkt 16 len 8 (issuer key ID 96B047156338B6D4) data: [160 bits] data: [159 bits] :public sub key packet: version 4, algo 1, created 1477170443, expires 0 pkey[0]: [4096 bits] pkey[1]: [17 bits] keyid: 609DAAD35F61D607 :signature packet: algo 1, keyid 80CB727A20C79BB2 version 4, created 1477170443, md5len 0, sigclass 0x18 digest algo 10, begin of digest e7 70 hashed subpkt 2 len 4 (sig created 2016-10-22) hashed subpkt 27 len 1 (key flags: 0C) subpkt 16 len 8 (issuer key ID 80CB727A20C79BB2) data: [4092 bits] :public sub key packet: version 4, algo 1, created 1477172175, expires 0 pkey[0]: [4096 bits] pkey[1]: [17 bits] keyid: DEACCAAEDB78137A :signature packet: algo 1, keyid 80CB727A20C79BB2 version 4, created 1477172175, md5len 0, sigclass 0x18 digest algo 10, begin of digest 74 4e hashed subpkt 2 len 4 (sig created 2016-10-22) hashed subpkt 27 len 1 (key flags: 02) hashed subpkt 9 len 4 (key expires after 10y0d0h0m) subpkt 16 len 8 (issuer key ID 80CB727A20C79BB2) subpkt 32 len 540 (signature: v4, class 0x19, algo 1, digest algo 10) data: [4095 bits] gpg: pub 4096R/20C79BB2 2016-10-22 Paul D. Smith gpg: key 20C79BB2: new key - skipped gpg: Total number processed: 1 gpg: skipped new keys: 1 #?0|kent:gmake.tar_bomb_git-no_reduce$ Thanks. And ciao from (and to) Germany, --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From angel at pgp.16bits.net Fri Jan 24 04:02:13 2020 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Fri, 24 Jan 2020 04:02:13 +0100 Subject: Batch generate keys without revocation cert? In-Reply-To: References: Message-ID: <1579834933.941.1.camel@16bits.net> On 2020-01-23 at 17:32 +0100, Jonathan Cross via Gnupg-users wrote: > Hello, > I would like to batch generate keys, but *not* have a revocation cert > generated. > I do not see an option for this, how can it be done? > > > Thanks, Jonathan Hello Jonathan See if this helps https://www.gnupg.org/documentation/manuals/gnupg/Unattended-GPG-key-generation.html Anyway, you could always generate a revocation certificate and then discard it. Kind regards From tmz at pobox.com Fri Jan 24 19:58:45 2020 From: tmz at pobox.com (Todd Zullinger) Date: Fri, 24 Jan 2020 13:58:45 -0500 Subject: Interesting failure on aarch64 In-Reply-To: <20191220162212.qsi7yr5cmgdivmpd@chatter.i7.local> References: <20191220162212.qsi7yr5cmgdivmpd@chatter.i7.local> Message-ID: <20200124185845.GE4046@pobox.com> Hi Konstantin, Konstantin Ryabitsev wrote: > I came across an interesting gpg failure while trying to build > git-2.24.1 RPM for Fedora COPR. As part of RPM build, the prep stage > attempts to verify the tarball signature using Junio's PGP key: > > %prep > # Verify GPG signatures > gpghome="$(mktemp -qd)" # Ensure we don't use any existing gpg keyrings > # Convert the ascii-armored key to binary > # (use --yes to ensure an existing dearmored key is overwritten) > gpg2 --homedir "$gpghome" --dearmor --quiet --yes %{SOURCE9} > xz -dc %{SOURCE0} | # Upstream signs the uncompressed tarballs > gpgv2 --homedir "$gpghome" --quiet --keyring %{SOURCE9}.gpg %{SOURCE1} - > rm -rf "$gpghome" # Cleanup tmp gpg home dir > > On x86_64 this succeeds, but when I tried building on aarch64, that step > returned the following error: > > Building for target aarch64 > Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.FYxOmt > + umask 022 > + cd /builddir/build/BUILD > ++ mktemp -qd > + gpghome=/tmp/tmp.dndOuot6S2 > + gpg2 --homedir /tmp/tmp.dndOuot6S2 --dearmor --quiet --yes /builddir/build/SOURCES/gpgkey-junio.asc > gpg: Fatal: can't disable core dumps: Operation not permitted > error: Bad exit status from /var/tmp/rpm-tmp.FYxOmt (%prep) [...] > I'm curious what exactly is at fault here -- is there something in the > COPR build environment that causes this error, or is there something > that gnupg is not checking correctly? I noticed this recently as well. It only happens on EPEL-7 aarch64, which has gnupg2-2.0.22-5.el7_5. Builds for EPEL-8 aarch64 work fine. I've tested this on one of the Fedora package maintainer aarch64 instances as well and it fails there too. That doesn't narrow it down much, other than likely ruling out something specific to the COPR build environment. It could still be a bug in gnupg-2.0.22, in the RHEL-7 packages (gnupg2 or otherwise), or when used with mock on aarch64. For those unfamiliar, mock is a Fedora/EPEL rpm build tool. -- Todd -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 543 bytes Desc: not available URL: From sac at 300baud.de Sun Jan 26 01:09:26 2020 From: sac at 300baud.de (Stefan Claas) Date: Sun, 26 Jan 2020 01:09:26 +0100 Subject: key pair without user id data Message-ID: <20200126010926.00000ec0.sac@300baud.de> Hi all, I am a bit out of the loop regarding GnuPG and I also do not have the latest version (yet) installed. I would like to know if it is possible to generate a key pair without any user-id data, like Hagrid stores, when not verifying the email address? If so, what are the required parameters and which version does support it? Regards Stefan -- NaClbox: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From angel at pgp.16bits.net Mon Jan 27 01:56:22 2020 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Mon, 27 Jan 2020 01:56:22 +0100 Subject: Passphrase and Key Structure In-Reply-To: <23fd2d4c-b66f-4978-bebd-b58812aabd0b@gmx.com> References: <23fd2d4c-b66f-4978-bebd-b58812aabd0b@gmx.com> Message-ID: <1580086582.939.8.camel@16bits.net> On 2020-01-17 at 06:47 -0700, Mark wrote: > I was wondering what effect changing the passphrase has on the keys. Not > only the keygrip file but also on the exported copy of it that can be > used with other programs. If you change the passphrase, do you need to > re-backup those keygrip files and re-export those keys again? > > Thanks Only if you want the backup to have the new passphrase. The old files will still work perfectly fine as a backup. As long as you remember the old passphrase. Kind regards From sarunint at sarunint.com Mon Jan 27 02:03:55 2020 From: sarunint at sarunint.com (Sarun Intaralawan) Date: Mon, 27 Jan 2020 08:03:55 +0700 Subject: GPGME-JSON to bundle with GnuPG (not Gpg4win) installer? (Or standalone installer) Message-ID: Hi all, I've been using GnuPG for a while now, but I'm not able to use GnuPG with Mailvelope, since Mailvelope requires GPGME-JSON, which is not bundled with minimal GnuPG installer . (I strictly use GnuPG via command line, so I don't want other software to be installed.) Is there any chance that I can install GPGME-JSON separately? Regards, Sarun -------------- next part -------------- An HTML attachment was scrubbed... URL: From azbigdogs at gmx.com Mon Jan 27 19:30:17 2020 From: azbigdogs at gmx.com (Mark) Date: Mon, 27 Jan 2020 11:30:17 -0700 Subject: Passphrase and Key Structure In-Reply-To: <1580086582.939.8.camel@16bits.net> References: <23fd2d4c-b66f-4978-bebd-b58812aabd0b@gmx.com> <1580086582.939.8.camel@16bits.net> Message-ID: Thanks for the reply... Probably safer to back them up again just in case I forget it, especially since I have another program that uses PGP to encrypt/decrypt archives. On 1/26/2020 5:56 PM, ?ngel wrote: > On 2020-01-17 at 06:47 -0700, Mark wrote: >> I was wondering what effect changing the passphrase has on the keys. Not >> only the keygrip file but also on the exported copy of it that can be >> used with other programs. If you change the passphrase, do you need to >> re-backup those keygrip files and re-export those keys again? >> >> Thanks > Only if you want the backup to have the new passphrase. > > The old files will still work perfectly fine as a backup. As long as you > remember the old passphrase. > > Kind regards > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From mailinglisten at posteo.de Thu Jan 30 23:24:54 2020 From: mailinglisten at posteo.de (mailing list) Date: Thu, 30 Jan 2020 23:24:54 +0100 Subject: private data objects on smartcard Message-ID: <38a179a0-533a-f1e1-aaed-f0dbdc562609@posteo.de> Hi there, The opnPGP smartcards seem to have private data objects to store arbitrary data, right? It seems even the old 1.1 version cards feature these objects. How do you write to these objects? Can GnuPG do this? I didn?t found any way with --card-edit or --card-status. And can GnuPG read these objects? I read somewhere, the size of these objects is 2048 bytes each. How many of these objects do exist on a smartcard? Thanks! From dgouttegattat at incenp.org Fri Jan 31 00:14:15 2020 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Thu, 30 Jan 2020 23:14:15 +0000 Subject: private data objects on smartcard In-Reply-To: <38a179a0-533a-f1e1-aaed-f0dbdc562609@posteo.de> References: <38a179a0-533a-f1e1-aaed-f0dbdc562609@posteo.de> Message-ID: <20200130231415.ybjfxkqpxp3i4ahk@dynein.local.incenp.org> Hi, On Thu, Jan 30, 2020 at 11:24:54PM +0100, mailing list via Gnupg-users wrote: >How do you write to these objects? Can GnuPG do this? I didn?t found >any way with --card-edit or --card-status. You can use the (undocumented) command "privatedo" from GnuPG's --card-edit menu. For example, to write into the private DO #1: $ gpg --card-edit gpg/card> privatedo 1 Private DO data: [enter whatever value you want to store into the DO] Or, to write the contents of a file into the private DO #2: $ gpg --card-edit gpg/card> privatedo 2 < [filename] > And can GnuPG read these objects? Yes. If a private DO contains a value, it will be listed in the output from the --card-status command. >I read somewhere, the size of these objects is 2048 bytes each. How >many of these objects do exist on a smartcard? First, note that private DOs are an optional feature of the OpenPGP smart card; not all implementations support them. You can use the following command to check if an OpenPGP smart card supports private DOs: $ gpg-connect-agent 'SCD LEARN --force' /bye | grep EXTCAP S EXTCAP gc=1+ki=1+fc=1+pd=1+mcl3=2048+aac=1+sm=0+si=5+dec=0+bt=1+kdf=1 Here, "pd=1" means the card does have private DOs. "pd=0" would indicate that private DOs are not supported. When private DOs are supported, there are four of them. For cards compatible with versions 1.x or 2.x of the specification, they have a size of 254 bytes. For 3.x cards, the size of the private DOs is defined by the implementation (the OpenPGP smart card from FLOSS Shop [1] has indeed 2048-bytes private DOs). Cheers, - Damien [1] https://www.floss-shop.de/en/security-privacy/smartcards/13/openpgp-smart-card-v3.3?c=40 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From mailinglisten at posteo.de Fri Jan 31 00:39:11 2020 From: mailinglisten at posteo.de (mailing list) Date: Fri, 31 Jan 2020 00:39:11 +0100 Subject: private data objects on smartcard In-Reply-To: <20200130231415.ybjfxkqpxp3i4ahk@dynein.local.incenp.org> References: <38a179a0-533a-f1e1-aaed-f0dbdc562609@posteo.de> <20200130231415.ybjfxkqpxp3i4ahk@dynein.local.incenp.org> Message-ID: On 31.01.20 at 00:14 it was said by Damien Goutte-Gattat: > On Thu, Jan 30, 2020 at 11:24:54PM +0100, mailing list via Gnupg-users > wrote: >> How do you write to these objects? Can GnuPG do this? I didn?t found >> any way with --card-edit or --card-status. > > You can use the (undocumented) command "privatedo" from GnuPG's > --card-edit menu. For example, to write into the private DO #1: Great, thanks! > ?S EXTCAP gc=1+ki=1+fc=1+pd=1+mcl3=2048+aac=1+sm=0+si=5+dec=0+bt=1+kdf=1 By the way, is mcl3 the length of the key currently living on the smartcard or the maximum key length supported by this card? I just play with a card version 1.1 and mcl3 is 0 there..... Version 1.1 support 1024 RSA AFAIK. Thanks! From mailinglisten at posteo.de Fri Jan 31 00:55:05 2020 From: mailinglisten at posteo.de (mailing list) Date: Fri, 31 Jan 2020 00:55:05 +0100 Subject: private data objects on smartcard In-Reply-To: <20200130231415.ybjfxkqpxp3i4ahk@dynein.local.incenp.org> References: <38a179a0-533a-f1e1-aaed-f0dbdc562609@posteo.de> <20200130231415.ybjfxkqpxp3i4ahk@dynein.local.incenp.org> Message-ID: <4d20231a-bb25-769b-41af-8d3d9cfb23c5@posteo.de> > (...) > You can use the (undocumented) command "privatedo" from GnuPG's > --card-edit menu. For example, to write into the private DO #1: > (...) >> And can GnuPG read these objects? > > Yes. If a private DO contains a value, it will be listed in the output > from the --card-status command. I hoped these objects may have been (read) protected by the PIN, but they?re world readable if you have the card, a bit sad... From dgouttegattat at incenp.org Fri Jan 31 00:57:28 2020 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Thu, 30 Jan 2020 23:57:28 +0000 Subject: private data objects on smartcard In-Reply-To: References: <38a179a0-533a-f1e1-aaed-f0dbdc562609@posteo.de> <20200130231415.ybjfxkqpxp3i4ahk@dynein.local.incenp.org> Message-ID: <20200130235728.ob2u57kzcloxi7ye@dynein.local.incenp.org> On Fri, Jan 31, 2020 at 12:39:11AM +0100, mailing list wrote: >By the way, is mcl3 the length of the key currently living on the >smartcard or the maximum key length supported by this card? Neither of those. It's the maximum length of the "Cardholder certificate DO". This is another data object available on a OpenPGP smart card, intended to store a X.509 certificate. You can write to that DO using the (undocumented) writecert command. For example, assumimg the cert.der file contains a DER-encoded X.509 certificate: $ gpg --card-edit gpg/card> writecert 3 < cert.der GnuPG allows to write into that DO but does not actually use it. As far as I know the only component that makes use of the Cardholder certificate DO is Scute [1], for TLS client authentication (and even for that the DO is actually dispensable: if Scute does not find the desired certificate in that DO, it will obtain it from GpgSM.) >I just play with a card version 1.1 and mcl3 is 0 there..... The Cardholder certificate DO was added in version 2.0 of the specification, so nothing surprising here. Cheers, - Damien [1] http://scute.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From dgouttegattat at incenp.org Fri Jan 31 01:06:43 2020 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Fri, 31 Jan 2020 00:06:43 +0000 Subject: private data objects on smartcard In-Reply-To: <4d20231a-bb25-769b-41af-8d3d9cfb23c5@posteo.de> References: <38a179a0-533a-f1e1-aaed-f0dbdc562609@posteo.de> <20200130231415.ybjfxkqpxp3i4ahk@dynein.local.incenp.org> <4d20231a-bb25-769b-41af-8d3d9cfb23c5@posteo.de> Message-ID: <20200131000643.cb3lez7szshhv7hx@dynein.local.incenp.org> On Fri, Jan 31, 2020 at 12:55:05AM +0100, mailing list wrote: >I hoped these objects may have been (read) protected by the PIN, but >they?re world readable if you have the card, a bit sad... Only Private DOs #1 and #2 are readable without any PIN. Reading the private DO #3 requires the user PIN, and reading the private DO #4 requires the admin PIN. If no PIN has been verified, the --card-status command will only ever print out the contents of private DOs #1 and #2. While we are at it, *writing* to the private DOs #1 and #3 requires the user PIN, and writing to the private DOs #2 and #4 requires the admin PIN. You can find the details about those DOs and all the other features of the OpenPGP smart card in the specifications for the different versions, which are all available on GnuPG's site [1]. Cheers, - Damien [1] https://gnupg.org/ftp/specs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From mailinglisten at posteo.de Fri Jan 31 16:24:48 2020 From: mailinglisten at posteo.de (mailing list) Date: Fri, 31 Jan 2020 16:24:48 +0100 Subject: private data objects on smartcard In-Reply-To: <20200131000643.cb3lez7szshhv7hx@dynein.local.incenp.org> References: <38a179a0-533a-f1e1-aaed-f0dbdc562609@posteo.de> <20200130231415.ybjfxkqpxp3i4ahk@dynein.local.incenp.org> <4d20231a-bb25-769b-41af-8d3d9cfb23c5@posteo.de> <20200131000643.cb3lez7szshhv7hx@dynein.local.incenp.org> Message-ID: > (...) > If no PIN has been verified, the --card-status command will only ever > print out the contents of private DOs #1 and #2. > > While we are at it, *writing* to the private DOs #1 and #3 requires the > user PIN, and writing to the private DOs #2 and #4 requires the admin PIN. > > You can find the details about those DOs and all the other features of > the OpenPGP smart card in the specifications for the different versions, > which are all available on GnuPG's site [1]. > Thanks a lot for the support!