From sac at 300baud.de Sun Sep 1 14:14:37 2019 From: sac at 300baud.de (Stefan Claas) Date: Sun, 1 Sep 2019 14:14:37 +0200 Subject: ProtonMail and Anonymity In-Reply-To: <20190506161546.0e40e685.sac@300baud.de> References: <20190505121014.06cab2fe@pitti.ddsn.net> <93fb66be-7e4a-9c17-a3c4-ee370656f240@gmail.com> <20190505193602.41827424.sac@300baud.de> <9d8eb962c72e9b90a4dea34d3d2035b6c5eae89e.camel@gentoo.org> <20190506161546.0e40e685.sac@300baud.de> Message-ID: <20190901141437.00001f98.sac@300baud.de> Stefan Claas wrote: > Am Mon, 6 May 2019 08:53:14 -0400 > schrieb Jeff Allen : > > > > People who don't trust ProtonMail shouldn't use it. > > Absolutely! But I think it does not hurt to post > such things to educate PGP users how different > services or software applications etc. handle such > privacy related things, especially when using the > word anonymous. Also interesting. https://eprint.iacr.org/2018/1121.pdf Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From peter at digitalbrains.com Sun Sep 1 15:18:36 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 1 Sep 2019 15:18:36 +0200 Subject: ProtonMail and Anonymity In-Reply-To: <20190901141437.00001f98.sac@300baud.de> References: <20190505121014.06cab2fe@pitti.ddsn.net> <93fb66be-7e4a-9c17-a3c4-ee370656f240@gmail.com> <20190505193602.41827424.sac@300baud.de> <9d8eb962c72e9b90a4dea34d3d2035b6c5eae89e.camel@gentoo.org> <20190506161546.0e40e685.sac@300baud.de> <20190901141437.00001f98.sac@300baud.de> Message-ID: Hello Stefan, On 01/09/2019 14:14, Stefan Claas via Gnupg-users wrote: > Also interesting. > > https://eprint.iacr.org/2018/1121.pdf If you post URL's to this mailing list, could you please provide a short description of what can be found at the URL? This prevents the situation that people should visit the URL to know if they want to visit the URL, and helps a lot when searching the archives. In this case, since it's a scientific paper, I think the following would be a good way to share it (I used the BibTeX citation to quickly get all the relevant fields). But at least include a short description, please. Here: A scientific paper by Nadim Kobeissi published in 2018 in the Cryptology ePrint Archive, titled "An Analysis of the ProtonMail Cryptographic Architecture": https://eprint.iacr.org/2018/1121 Abstract: ProtonMail is an online email service that claims to offer end-to-end encryption such that "even [ProtonMail] cannot read and decrypt [user] emails." The service, based in Switzerland, offers email access via webmail and smartphone applications to over five million users as of November 2018. In this work, we provide the first independent analysis of ProtonMail's cryptographic architecture. We find that for the majority of ProtonMail users, no end-to-end encryption guarantees have ever been provided by the ProtonMail service and that the "Zero-Knowledge Password Proofs" are negated by the service itself. We also find and document weaknesses in ProtonMail's "Encrypt-to-Outside" feature. We justify our findings against well-defined security goals and conclude with recommendations. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From stefanclaas at riseup.net Sun Sep 1 15:51:31 2019 From: stefanclaas at riseup.net (Stefan Claas) Date: Sun, 01 Sep 2019 06:51:31 -0700 Subject: ProtonMail and Anonymity In-Reply-To: References: <20190505121014.06cab2fe@pitti.ddsn.net> <93fb66be-7e4a-9c17-a3c4-ee370656f240@gmail.com> <20190505193602.41827424.sac@300baud.de> <9d8eb962c72e9b90a4dea34d3d2035b6c5eae89e.camel@gentoo.org> <20190506161546.0e40e685.sac@300baud.de> <20190901141437.00001f98.sac@300baud.de> Message-ID: On 2019-09-01 15:18, Peter Lebbing wrote: Hi Peter, > Hello Stefan, > > On 01/09/2019 14:14, Stefan Claas via Gnupg-users wrote: >> Also interesting. >> >> https://eprint.iacr.org/2018/1121.pdf > > If you post URL's to this mailing list, could you please provide a short > description of what can be found at the URL? This prevents the situation > that people should visit the URL to know if they want to visit the URL, > and helps a lot when searching the archives. > > In this case, since it's a scientific paper, I think the following would > be a good way to share it (I used the BibTeX citation to quickly get all > the relevant fields). But at least include a short description, please. O.k., sorry, next time I will do so. Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From maxim at fomin.one Sun Sep 1 20:59:06 2019 From: maxim at fomin.one (Maksim Fomin) Date: Sun, 01 Sep 2019 18:59:06 +0000 Subject: ProtonMail and Anonymity In-Reply-To: <20190901141437.00001f98.sac@300baud.de> References: <20190505121014.06cab2fe@pitti.ddsn.net> <93fb66be-7e4a-9c17-a3c4-ee370656f240@gmail.com> <20190505193602.41827424.sac@300baud.de> <9d8eb962c72e9b90a4dea34d3d2035b6c5eae89e.camel@gentoo.org> <20190506161546.0e40e685.sac@300baud.de> <20190901141437.00001f98.sac@300baud.de> Message-ID: ??????? Original Message ??????? On Sunday, September 1, 2019 12:14 PM, Stefan Claas via Gnupg-users wrote: > Stefan Claas wrote: > > > Am Mon, 6 May 2019 08:53:14 -0400 > > schrieb Jeff Allen jrallen at runbox.com: > > > > > People who don't trust ProtonMail shouldn't use it. > > > > Absolutely! But I think it does not hurt to post > > such things to educate PGP users how different > > services or software applications etc. handle such > > privacy related things, especially when using the > > word anonymous. > > Also interesting. > > https://eprint.iacr.org/2018/1121.pdf > > Regards > Stefan > > --------------------------------------------------------------------------- > > box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 > certified OpenPGP key blocks available on keybase.io/stefan_claas > > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users The paper overstated protonmail security weaknesses. The paper does not point to possible or actual attacks, nor reviews code. It merely boils down to two analytical (hypothetical thinking) conclusions: 1) protonmail server can be compromised, verified smartphone app is more reliable in this aspect 2) for outside encryption protonmail allows to use weak passwords. From thomas.orgis at uni-hamburg.de Wed Sep 4 13:50:06 2019 From: thomas.orgis at uni-hamburg.de (Dr. Thomas Orgis) Date: Wed, 4 Sep 2019 13:50:06 +0200 Subject: Fresh certificate marked as expired / messed-up certificate chain pulling expired root cert in gpgsm In-Reply-To: <20190730132832.60ce70a5@cortex.rrz.uni-hamburg.de> References: <20190718183341.46b5b7a4@cortex.rrz.uni-hamburg.de> <1a62fe5742d096d35d4ef5d6b8a7722b3fb43e44.camel@googlemail.com> <20190720200737.6b6f69c4@plasteblaster> <1563749048.1449.5.camel@16bits.net> <20190730132832.60ce70a5@cortex.rrz.uni-hamburg.de> Message-ID: <20190904135006.51682e17@cortex.rrz.uni-hamburg.de> Am Tue, 30 Jul 2019 13:28:32 +0200 schrieb "Dr. Thomas Orgis" : > And even with it present, is it > correct behaviour for gpgsm to consider the chain invalid instead of > just the cross-signature? It _does_ trust the new root cert already ? > no need for any further signature. Just now the third colleague (all people working at German universities) contacted me about having even a more persisting variant of this issue, with the old root cert cross-signature being re-imported by gpgsm and thus practically permanently breaking the use of the new certificate. Can we consider this a bug in gpgsm's handling of signatures or is this really working as designed? Regards, Thomas > PS: Just for fun, I'm trying to sign this post now. Maybe it won't even > be broken by the list? The list does break the signature. I'm not adding one now ? -- Dr. Thomas Orgis HPC @ Universit?t Hamburg From sac at 300baud.de Wed Sep 4 20:45:25 2019 From: sac at 300baud.de (Stefan Claas) Date: Wed, 4 Sep 2019 20:45:25 +0200 Subject: add-photo continued ... Message-ID: <20190904204525.00006bbb.sac@300baud.de> 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. I do not have the link currently handy, sorry! So here is a little keyserver test showing data in a .jpeg header of a UAT packet. It is a zipped folder containing 10 little 'messages' created with openssl. As keyserver I used the Ubuntu keyserver because it is then easier for users to extract the data. Simple right-click on the image and then once saved as index.jpg do an 'unzip index.jpg' to obtain the folder with the text files. Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From kandre at ak-online.be Wed Sep 4 22:41:22 2019 From: kandre at ak-online.be (Andre =?iso-8859-1?Q?Kl=E4rner?=) Date: Wed, 4 Sep 2019 22:41:22 +0200 Subject: Forward entire gnupg $HOME Message-ID: <20190904204122.GA27946@debs.ak-online.be> Hi all, is there a way to properly shared the entire keyring and trust settings between two machines? My use case is the following: Mutt, my email client, runs on a containerized mailserver on another machine right under my desk. My GPG key is stored on a Yubikey attached to my workstation (another physical machine compared to the mailserver's host system) 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. My Yubikey also is used as the SSH key for everything, and hence plugged into my workstation. After following https://wiki.gnupg.org/AgentForwarding and batteling with the autostarting gpg-agent (fixed with no-autostart in the remote system's gpg.conf), masking all but the dirmngr systemd socket and service units, and struggeling with the removal of /run/user/1000/gnupg on logout, I finally got it to work. (Nice how the last one doesn't matter, if dirmngr.socket is enabled.) Now I have another problem: my main machine knows all my internet friend's keys, my mailserver not. I can of cause gpg --export, scp and gpg --import, but that is nothing scalable and needs to be repeated over and over again when anything changes. Do I expect to much, or is this simply and typically invalid usecase? Is there a simpler way to configure a remote GPG just for a session, so that it uses another socket to connect to the gpg-agent (I also sign git commits, sometimes with etckeeper even on remote machines). Thanks a lot for reading, and best regards, Andre -- Andre Kl?rner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From sac at 300baud.de Thu Sep 5 01:16:44 2019 From: sac at 300baud.de (Stefan Claas) Date: Thu, 5 Sep 2019 01:16:44 +0200 Subject: add-photo continued ... In-Reply-To: <20190904204525.00006bbb.sac@300baud.de> References: <20190904204525.00006bbb.sac@300baud.de> Message-ID: <20190905011644.0000041f.sac@300baud.de> Stefan Claas via Gnupg-users wrote: > Recently I saw a Twitter post explaining that a .jpeg image header > can contain 16 MB of data. I do not have the link currently handy, > sorry! I think I talked nonsense here about the 16 MB header size! Hopefully I can find the authors technique again, because he posted the source code too ... Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From gnupg at raf.org Thu Sep 5 01:43:10 2019 From: gnupg at raf.org (raf) Date: Thu, 5 Sep 2019 09:43:10 +1000 Subject: add-photo continued ... In-Reply-To: <20190904204525.00006bbb.sac@300baud.de> References: <20190904204525.00006bbb.sac@300baud.de> Message-ID: <20190904234310.fvjtiaaiidm36lnv@raf.org> 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. From johndoe65534 at mail.com Thu Sep 5 08:59:16 2019 From: johndoe65534 at mail.com (john doe) Date: Thu, 5 Sep 2019 08:59:16 +0200 Subject: Forward entire gnupg $HOME In-Reply-To: <20190904204122.GA27946@debs.ak-online.be> References: <20190904204122.GA27946@debs.ak-online.be> Message-ID: <72ed0a5f-5c9d-4318-a180-38c45e88ab90@mail.com> On 9/4/2019 10:41 PM, Andre Kl?rner wrote: > Hi all, > > is there a way to properly shared the entire keyring and trust settings > between two machines? > > My use case is the following: > > Mutt, my email client, runs on a containerized mailserver on another machine > right under my desk. > > My GPG key is stored on a Yubikey attached to my workstation (another > physical machine compared to the mailserver's host system) > > 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. > > My Yubikey also is used as the SSH key for everything, and hence plugged > into my workstation. > > After following https://wiki.gnupg.org/AgentForwarding and batteling with > the autostarting gpg-agent (fixed with no-autostart in the remote system's > gpg.conf), masking all but the dirmngr systemd socket and service units, and > struggeling with the removal of /run/user/1000/gnupg on logout, I finally > got it to work. (Nice how the last one doesn't matter, if dirmngr.socket is > enabled.) > > Now I have another problem: my main machine knows all my internet friend's > keys, my mailserver not. I can of cause gpg --export, scp and gpg --import, > but that is nothing scalable and needs to be repeated over and over again > when anything changes. > > Do I expect to much, or is this simply and typically invalid usecase? > Is there a simpler way to configure a remote GPG just for a session, so > that it uses another socket to connect to the gpg-agent (I also sign git > commits, sometimes with etckeeper even on remote machines). > The obvious solution would be to use mutt on your work station! :) I would also use one signing key per device on which you need to sign commits/tags/... That way if one device is compromised you simply revoke that subkey. Sorry for not directly answering your question! -- John Doe From gnupg at eckner.net Thu Sep 5 09:16:54 2019 From: gnupg at eckner.net (Erich Eckner) Date: Thu, 5 Sep 2019 09:16:54 +0200 (CEST) Subject: Forward entire gnupg $HOME In-Reply-To: <72ed0a5f-5c9d-4318-a180-38c45e88ab90@mail.com> References: <20190904204122.GA27946@debs.ak-online.be> <72ed0a5f-5c9d-4318-a180-38c45e88ab90@mail.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Thu, 5 Sep 2019, john doe wrote: > On 9/4/2019 10:41 PM, Andre Kl?rner wrote: >> Hi all, >> >> is there a way to properly shared the entire keyring and trust settings >> between two machines? [ snip ] > The obvious solution would be to use mutt on your work station! :) > I would also use one signing key per device on which you need to sign > commits/tags/... > That way if one device is compromised you simply revoke that subkey. While this would work for signing, it will not work for decryption. regards, Erich -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAl1wtmgACgkQCu7JB1Xa e1o06A//QjHAhXVhjtQCqPrWIvOySXHZh7ISrzqN/Zs9XyhK6U4Zul698pr4FQKr mj0R25EkwN8Xsqqneg+ZS7mwDPrp2RBqymlOifYGt4/xYHdoL18rwHDxwZ1ZiEk8 BNuZspl7h4Ka5mcGZT7ajFKT3+NiTZiq0TH9itanI6WBfg+H44oQb7HBVvsDuJeX MGZGwUXsby6Q+lMB5KcHa+6FJVaRBAzLaOn0UjJ3ce/h9OOxPMCTPdgfE/14+Zez 0UGLyEGfe1qL2Fl8Gnq+LvB3f0hchE4fqd5F6fMOMqSByLi6lxsPveFdYMGT81Rt sWzBPStMcQaHjdCI61egBCXj+Hd8h7PciyHvjGYJlFSz2/dAN+omlHgrujW7Ic81 Phkc7QPRq80983ee4dKJWdlKAkOaaURN30m/K/m1w1CQ4Mjza4lc+kBypJly7qVr UtAptrDXl2awsx6mpK/ekp501db2suy7+4Y6X8TUArJbZVCL0EyZz8nIgCkJembx Ye9EnofX5gbkFTkOol2u0i90K9ANnvhN8jjYuKJLqMk6RHE7SJM9LpOBDZzGtvc+ /t6hRrP60fOW3Z+SkhlzdWtGnfc5Dk40FTeeSY9UZzwNGT8J+2090yq/5MGOUq3q DvX4TW5g6w0vkwCdRU5qrGBi/qU/SNJHwRWq8KiymkTQMXFbgaQ= =dDKv -----END PGP SIGNATURE----- From stefanclaas at riseup.net Thu Sep 5 09:44:12 2019 From: stefanclaas at riseup.net (Stefan Claas) Date: Thu, 05 Sep 2019 00:44:12 -0700 Subject: add-photo continued ... In-Reply-To: <20190905011644.0000041f.sac@300baud.de> References: <20190904204525.00006bbb.sac@300baud.de> <20190905011644.0000041f.sac@300baud.de> Message-ID: <671f3254a61a72fa3feb83740256e307@riseup.net> On 2019-09-05 01:16, Stefan Claas via Gnupg-users wrote: > Stefan Claas via Gnupg-users wrote: > >> Recently I saw a Twitter post explaining that a .jpeg image header >> can contain 16 MB of data. I do not have the link currently handy, >> sorry! > > I think I talked nonsense here about the 16 MB header size! Hopefully > I can find the authors technique again, because he posted the source > code too ... No, seems not to be nonsense, as understood. https://dev.exiv2.org/projects/exiv2/wiki/The_Metadata_in_JPEG_files 2.4 ICC The maximum size of an ICC profile is limited to 256 * (63535 - 16) = 16,261,888 bytes. This is quite a large profile! I wonder what kind of data would require such a max size. -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From kandre at ak-online.be Thu Sep 5 14:36:58 2019 From: kandre at ak-online.be (Andre =?iso-8859-1?Q?Kl=E4rner?=) Date: Thu, 5 Sep 2019 14:36:58 +0200 Subject: Forward entire gnupg $HOME In-Reply-To: Message-ID: <20190905123658.GA6236@debs.ak-online.be> Hi all, On Thu 05.09.2019 09:16:54, Erich Eckner via Gnupg-users wrote: > On Thu, 5 Sep 2019, john doe wrote: > > > On 9/4/2019 10:41 PM, Andre Kl?rner wrote: > >> Hi all, > >> > >> is there a way to properly shared the entire keyring and trust settings > >> between two machines? > > [ snip ] > > > The obvious solution would be to use mutt on your work station! :) > > I would also use one signing key per device on which you need to sign > > commits/tags/... > > That way if one device is compromised you simply revoke that subkey. > > While this would work for signing, it will not work for decryption. It also would contradict my security model: there are exactly three copies of my private key: one in my Yubikey 5 NFC, one in my Yubikey 5 nano, one in my OpenPGP smartcard. There are no other keys at all. And unless I actively use one of them, they are all offline and not usable. The Yubikeys even go a step further: even plugged in and with my PIN used once they are not usable, unless someone is physically present to confirm the operation by touching them. Especially the last part is the main reason I was drawn to Yubikeys: our company uses SSH extensively, and due to Audit restrictions SSHAgentForwarding must be enabled so that the audit box can log all SSH plaintext traffic. But once I am logged on to one of our servers I have root access as many of our colleagues - so a knowledgable person easily can reuse my agent for anything else. With a physical confirmation required this is no longer a problem. So I hope you now know how my requirements came to be, and that simply using multiple subkeys doesn't scale. The only thing saving my is proper and secure forwarding. Thanks and best regards, Andre -- Andre Kl?rner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From sac at 300baud.de Thu Sep 5 17:27:19 2019 From: sac at 300baud.de (Stefan Claas) Date: Thu, 5 Sep 2019 17:27:19 +0200 Subject: add-photo continued ... In-Reply-To: <20190904234310.fvjtiaaiidm36lnv@raf.org> References: <20190904204525.00006bbb.sac@300baud.de> <20190904234310.fvjtiaaiidm36lnv@raf.org> Message-ID: <20190905172719.0000698d.sac@300baud.de> 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 Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From abbot at monksofcool.net Thu Sep 5 20:06:36 2019 From: abbot at monksofcool.net (Ralph Seichter) Date: Thu, 05 Sep 2019 20:06:36 +0200 Subject: Forward entire gnupg $HOME In-Reply-To: <20190904204122.GA27946@debs.ak-online.be> References: <20190904204122.GA27946@debs.ak-online.be> Message-ID: <87sgpak47n.fsf@wedjat.horus-it.com> * Andre Kl?rner: > is there a way to properly shared the entire keyring and trust > settings between two machines? What "properly" means is quite subjective. My own .gnupg directories are under Git control. Imagine two computers, let's call them alpha and bravo, in my local network, which both only allow access via SSH key based authentication. Assuming that alpha is the "master" (meaning I add keys and modify trust settings there), I can initially transfer the data by running cd /home/ralph git clone ralph at alpha:/home/ralph/.gnupg on machine bravo. All future updates can then be transferred by simply invoking "git pull". For obvious reasons one should not put GnuPG key material on GitHub or similar, but if you do have your own, secure Git repository (which I have), you can add that to the mix. A nice side effect of this method is that my GPG key rings are fully version controlled. -Ralph From angel at pgp.16bits.net Fri Sep 6 00:33:50 2019 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Fri, 06 Sep 2019 00:33:50 +0200 Subject: Generating bitwise identical keyrings with GnuPG 1 + 2 In-Reply-To: <0889c2f9-b8ac-eb76-f65c-2d1666ad21e4@ionic.de> References: <0889c2f9-b8ac-eb76-f65c-2d1666ad21e4@ionic.de> Message-ID: <1567722830.918.25.camel@16bits.net> On 2019-08-18 at 08:24 +0200, Mihai Moldovan wrote: > So, to summarize, if I process a keyring file generated by gpg 2.2 > with a 1.4 binary, i.e., read-in the former, export all keys and > import it again, gpg 1.4 generates exactly the same file as it would > when importing the keys directly. I'm baffled by this. Could you run gpg2 --list-packets on both keyrings and compare their outputs? That should hint which packets are being included by 1.4 that are not by 2.2 Best regards From patrick at enigmail.net Sun Sep 8 13:40:55 2019 From: patrick at enigmail.net (Patrick Brunschwig) Date: Sun, 8 Sep 2019 13:40:55 +0200 Subject: Invitation to the 5th OpenPGP Email Summit In-Reply-To: References: Message-ID: Up to now, I only got 12 replies. *Reminder: Please send me a mail if you plan to come* Thanks, Patrick On 18.06.2019 13:05, Patrick Brunschwig wrote: > I'm happy to announce the 5th OpenPGP Email Summit which will take place > > Saturday, October 12 until Sunday, October 13, 2019 > in Berlin (Germany) at the Onion Space. > > Last year, the idea came up that it would be nice if some of the topics > discussed could directly be prototyped. I have therefore booked the > Onion Space for Monday and Tuesday (October 14/15), such that those who > are interested can directly start working on their product. > > ABOUT THE OpenPGP EMAIL SUMMIT > ============================== > > This is an event open for anybody involved in the development of email > clients using OpenPGP for encryption, and related software. > > We already had four OpenPGP Email Summits at various locations in > Europe. These are meetings by technical experts of projects and tools > dealing with OpenPGP with a focus on email encryption. The goals are to > better get to know each other, and to discuss and work on several > technical issues that hopefully improve certain aspects of OpenPGP-based > email encryption. For details, see > https://wiki.gnupg.org/OpenPGPEmailSummits > > > REGISTRATION > ============ > If you want to attend, please *send an informal email* to: > patrick at enigmail.net > > Please let me know if you plan to stay on Monday and/or Tuesday. > > If you need funding for your travel/hotel expenses, then please get > in contact with me. > > > NOTES > ===== > This is a meeting of those who develop software. Thus, we will have a > lot of tech talk about key servers, key exchange, subject encryption, > password recovery, etc. If you just are interested in these topics as a > user, you probably will be bored to death . > > Thus, feel free to join us if you are working in the area of > - TECHNICAL DETAILS > - for SENDING or PROCESSING ENCRYPTED EMAILS > - with OpenPGP > - in a project or product. > > Note however, that due to capacity reasons we cannot have more > than 1-2 people from each project. We can host about 30 attendees. > > Note that this is still neither a well-organized conference nor a > commercial meeting. The agenda will be driven by the attendees. Anyone > may propose any topic for discussion, as long as he/she is ready to lead > the discussion. > > More details are/will be available on the web site: > https://wiki.gnupg.org/OpenPGPEmailSummit201910 > > > Looking forward to meeting you in Berlin > -Patrick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From aheinecke at gnupg.org Mon Sep 9 10:10:44 2019 From: aheinecke at gnupg.org (Andre Heinecke) Date: Mon, 09 Sep 2019 10:10:44 +0200 Subject: [openpgp-email] Invitation to the 5th OpenPGP Email Summit In-Reply-To: References: Message-ID: <1718080.SjUlb2uN3x@esus> Hi, On Sunday 8 September 2019 13:40:55 CEST Patrick Brunschwig wrote: > Up to now, I only got 12 replies. > > *Reminder: Please send me a mail if you plan to come* The GnuPG e.V. would cover the costs for privateers, those of you that do not work for OpenPGP-Email at your Job, again. Just send a request to board at gnupg.org Best Regards, Andre -- GnuPG.com - a brand of g10 Code, the GnuPG experts. g10 Code GmbH, Erkrath/Germany, AG Wuppertal HRB14459 GF Werner Koch, USt-Id DE215605608, www.g10code.com. GnuPG e.V., Rochusstr. 44, D-40479 D?sseldorf. VR 11482 D?sseldorf Vorstand: W.Koch, M.Gollowitzer, A.Heinecke. Mail: board at gnupg.org Finanzamt D-Altstadt, St-Nr: 103/5923/1779. Tel: +49-2104-4938799 From angel at pgp.16bits.net Mon Sep 9 23:39:01 2019 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Mon, 09 Sep 2019 23:39:01 +0200 Subject: Forward entire gnupg $HOME In-Reply-To: <72ed0a5f-5c9d-4318-a180-38c45e88ab90@mail.com> References: <20190904204122.GA27946@debs.ak-online.be> <72ed0a5f-5c9d-4318-a180-38c45e88ab90@mail.com> Message-ID: <1568065141.1086.7.camel@16bits.net> 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? From stefanclaas at riseup.net Tue Sep 10 18:00:29 2019 From: stefanclaas at riseup.net (Stefan Claas) Date: Tue, 10 Sep 2019 09:00:29 -0700 Subject: Info for GnuPG users which have a keybase account Message-ID: <843bd535201039dbe97a81f3ea94cc07@riseup.net> Hi all, slightly OT, but since some of you are on keybase I would like to inform you about a current promo from Stellar Network running on keybase. https://keybase.io/a/i/r/d/r/o/p/spacedrop2019 I received yesterday my free Lumens, currently worth $21.29 USD :-) Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From johndoe65534 at mail.com Tue Sep 10 18:31:36 2019 From: johndoe65534 at mail.com (john doe) Date: Tue, 10 Sep 2019 18:31:36 +0200 Subject: Info for GnuPG users which have a keybase account In-Reply-To: <843bd535201039dbe97a81f3ea94cc07@riseup.net> References: <843bd535201039dbe97a81f3ea94cc07@riseup.net> Message-ID: <3e5b2f0e-e8d6-b4d1-e7f9-af7d34534878@mail.com> On 9/10/2019 6:00 PM, Stefan Claas via Gnupg-users wrote: > Hi all, > > slightly OT, but since some of you are on keybase I would > like to inform you about a current promo from Stellar Network > running on keybase. > > https://keybase.io/a/i/r/d/r/o/p/spacedrop2019 > > I received yesterday my free Lumens, currently worth $21.29 USD :-) > Who are you, anything to disclose? I don't think this is appropriate to advertise on this list. -- John Doe From sac at 300baud.de Tue Sep 10 18:58:54 2019 From: sac at 300baud.de (Stefan Claas) Date: Tue, 10 Sep 2019 18:58:54 +0200 Subject: Info for GnuPG users which have a keybase account In-Reply-To: <3e5b2f0e-e8d6-b4d1-e7f9-af7d34534878@mail.com> References: <843bd535201039dbe97a81f3ea94cc07@riseup.net> <3e5b2f0e-e8d6-b4d1-e7f9-af7d34534878@mail.com> Message-ID: <20190910185854.00004f20.sac@300baud.de> john doe wrote: > On 9/10/2019 6:00 PM, Stefan Claas via Gnupg-users wrote: > > Hi all, > > > > slightly OT, but since some of you are on keybase I would > > like to inform you about a current promo from Stellar Network > > running on keybase. > > > > https://keybase.io/a/i/r/d/r/o/p/spacedrop2019 > > > > I received yesterday my free Lumens, currently worth $21.29 USD :-) > > > > Who are you, anything to disclose? I am a happy keybase user. :-) > > > I don't think this is appropriate to advertise on this list. Well, Werner and other prominent ML members are on keybase, so I think it is perfectly appropriate to let them know, in case they have not seen it yet, due to the fact that they may have not set up a Stellar address yet. ;-) Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From wk at gnupg.org Tue Sep 10 20:27:22 2019 From: wk at gnupg.org (Werner Koch) Date: Tue, 10 Sep 2019 20:27:22 +0200 Subject: Info for GnuPG users which have a keybase account In-Reply-To: <20190910185854.00004f20.sac@300baud.de> (Stefan Claas via Gnupg-users's message of "Tue, 10 Sep 2019 18:58:54 +0200") References: <843bd535201039dbe97a81f3ea94cc07@riseup.net> <3e5b2f0e-e8d6-b4d1-e7f9-af7d34534878@mail.com> <20190910185854.00004f20.sac@300baud.de> Message-ID: <87r24ouhv9.fsf@wheatstone.g10code.de> On Tue, 10 Sep 2019 18:58, gnupg-users at gnupg.org said: > Well, Werner and other prominent ML members are on keybase, so I am not. I once tested it and thus there may still be an account or whatever. And I do not know what Stellar or Lumen are in this context. But no need to explain it. Anyway, I don't mind to see such pointers on this ML once in a while. For easier parsing you should have biefly explained the key terms. 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 dgouttegattat at incenp.org Wed Sep 11 16:36:32 2019 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Wed, 11 Sep 2019 15:36:32 +0100 Subject: Scute 1.6.0 released Message-ID: <20190911143632.v4leyeyyzkzmnuhh@aurora.local.incenp.org> Hi, The GnuPG Project is pleased to announce the availability of Scute 1.6.0. Scute is a PKCS#11 module built around the GnuPG Agent and the GnuPG Smart Card Daemon. It allows you to use an OpenPGP or a PIV smart card for TLS client authentication and S/MIME mail and document signing. Noteworthy changes in version 1.6.0 (2019-09-10) =================================== * PIV cards are now supported in addition to OpenPGP cards. * Key selection is delegated to GpgSM, resulting in faster operations. * The license has been changed to the GNU Lesser General Public License, version 2.1 or later. * Scute now requires at a minimum the current stable version of GnuPG (2.2.0); advanced PIV card support needs the current GnuPG development version. Release-info: https://dev.gnupg.org/T4697 Download ======== Source code is hosted at the GnuPG FTP server and its mirror as listed as . On the primary server the source tarball and its signature are: ftp://ftp.gnupg.org/gcrypt/scute/scute-1.6.0.tar.bz2 ftp://ftp.gnupg.org/gcrypt/scute/scute-1.6.0.tar.bz2.sig The same files are also available via HTTP: https://gnupg.org/ftp/gcrypt/scute/scute-1.6.0.tar.bz2 https://gnupg.org/ftp/gcrypt/scute/scute-1.6.0.tar.bz2.sig Signing key =========== The tarball is signed by the maintainer's key: rsa4096 2014-03-14 Key fingerprint = 4FA2 0823 62FE 73AD 03B8 8830 A8DC 7067 E25F BABB Damien Goutte-Gattat That key is available via a WKD lookup: $ gpg --locate-key dgouttegattat at incenp.org Copying ======= Scute is copyright by g10 Code GmbH and licensed under the GNU Lesser General Public License version 2.1 or later (LGPLv2.1+). The full text of the license is included in the COPYING.LESSER file of the source distribution. Note that this is a change compared to previous releases of Scute, which were licensed under the GNU General Public License version 2 or later with an additional exception. Support ======= The Scute manual is included in the source distribution and is also available online at . For community support, you may ask on the gnupg-users mailing list . If you need commercial support, check out . Maintenance and development of Scute and of GnuPG as a whole is mostly financed by donations. Please consider donating via . Happy hacking! -------------- 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 Wed Sep 11 16:36:32 2019 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Wed, 11 Sep 2019 15:36:32 +0100 Subject: [Announce] Scute 1.6.0 released Message-ID: <20190911143632.v4leyeyyzkzmnuhh@aurora.local.incenp.org> Hi, The GnuPG Project is pleased to announce the availability of Scute 1.6.0. Scute is a PKCS#11 module built around the GnuPG Agent and the GnuPG Smart Card Daemon. It allows you to use an OpenPGP or a PIV smart card for TLS client authentication and S/MIME mail and document signing. Noteworthy changes in version 1.6.0 (2019-09-10) =================================== * PIV cards are now supported in addition to OpenPGP cards. * Key selection is delegated to GpgSM, resulting in faster operations. * The license has been changed to the GNU Lesser General Public License, version 2.1 or later. * Scute now requires at a minimum the current stable version of GnuPG (2.2.0); advanced PIV card support needs the current GnuPG development version. Release-info: https://dev.gnupg.org/T4697 Download ======== Source code is hosted at the GnuPG FTP server and its mirror as listed as . On the primary server the source tarball and its signature are: ftp://ftp.gnupg.org/gcrypt/scute/scute-1.6.0.tar.bz2 ftp://ftp.gnupg.org/gcrypt/scute/scute-1.6.0.tar.bz2.sig The same files are also available via HTTP: https://gnupg.org/ftp/gcrypt/scute/scute-1.6.0.tar.bz2 https://gnupg.org/ftp/gcrypt/scute/scute-1.6.0.tar.bz2.sig Signing key =========== The tarball is signed by the maintainer's key: rsa4096 2014-03-14 Key fingerprint = 4FA2 0823 62FE 73AD 03B8 8830 A8DC 7067 E25F BABB Damien Goutte-Gattat That key is available via a WKD lookup: $ gpg --locate-key dgouttegattat at incenp.org Copying ======= Scute is copyright by g10 Code GmbH and licensed under the GNU Lesser General Public License version 2.1 or later (LGPLv2.1+). The full text of the license is included in the COPYING.LESSER file of the source distribution. Note that this is a change compared to previous releases of Scute, which were licensed under the GNU General Public License version 2 or later with an additional exception. Support ======= The Scute manual is included in the source distribution and is also available online at . For community support, you may ask on the gnupg-users mailing list . If you need commercial support, check out . Maintenance and development of Scute and of GnuPG as a whole is mostly financed by donations. Please consider donating via . Happy hacking! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From ionic at ionic.de Fri Sep 13 21:28:55 2019 From: ionic at ionic.de (Mihai Moldovan) Date: Fri, 13 Sep 2019 21:28:55 +0200 Subject: Generating bitwise identical keyrings with GnuPG 1 + 2 In-Reply-To: <1567722830.918.25.camel@16bits.net> References: <0889c2f9-b8ac-eb76-f65c-2d1666ad21e4@ionic.de> <1567722830.918.25.camel@16bits.net> Message-ID: * On 9/6/19 12:33 AM, ?ngel wrote: > I'm baffled by this. > > Could you run gpg2 --list-packets on both keyrings and compare their > outputs? > > That should hint which packets are being included by 1.4 that are not by > 2.2 Hmm, interesting indeed. The output is *almost* the same. A diff looks like that (truncated, but you'll get the general idea): --- keyringdump.gpg2 2019-09-13 20:50:26.839951269 +0200 +++ keyringdump.gpg1 2019-09-13 20:50:44.186005825 +0200 @@ -19,13 +19,15 @@ hashed subpkt 23 len 1 (keyserver preferences: 80) subpkt 16 len 8 (issuer key ID E1F958385BFE2B6E) data: [2046 bits] -# off=635 ctb=b9 tag=14 hlen=3 plen=269 +# off=635 ctb=b0 tag=12 hlen=2 plen=2 +:trust packet: sig flag=00 sigcache=03 +# off=639 ctb=b9 tag=14 hlen=3 plen=269 :public sub key packet: version 4, algo 1, created 1299793310, expires 0 pkey[0]: [2048 bits] pkey[1]: [17 bits] keyid: 71F21F68F489CDCF -# off=907 ctb=89 tag=2 hlen=3 plen=287 +# off=911 ctb=89 tag=2 hlen=3 plen=287 :signature packet: algo 1, keyid E1F958385BFE2B6E version 4, created 1299793310, md5len 0, sigclass 0x18 digest algo 2, begin of digest 77 f5 @@ -33,7 +35,9 @@ hashed subpkt 27 len 1 (key flags: 0C) subpkt 16 len 8 (issuer key ID E1F958385BFE2B6E) data: [2044 bits] -# off=1197 ctb=99 tag=6 hlen=3 plen=418 +# off=1201 ctb=b0 tag=12 hlen=2 plen=2 +:trust packet: sig flag=00 sigcache=03 +# off=1205 ctb=99 tag=6 hlen=3 plen=418 :public key packet: version 4, algo 17, created 1234173545, expires 0 pkey[0]: [1024 bits] It looks like the gpg1 output has additional "trust" packets. Are that owner trust values? I wonder why gpg2 doesn't generate these packets? According to RFC 4880 these are really owner trust values that SHOULD NOT be exported to files that are supposed to be handed to other users, but GPG can't determine whether such a keyring file will be used locally or not. Either way, my best guess is that GPG 2.2+ drops the trust packets because the trust is not explicitly set (i.e., default value) - as an optimization. Can I instruct gpg2 to not do that? --export-ownertrust doesn't seem appropriate and then there's also the special concept of a trustdb, so I don't quite understand why trust packets would be exported to keyrings in the first place? Mihai From lists at binarus.de Sat Sep 14 13:15:44 2019 From: lists at binarus.de (Binarus) Date: Sat, 14 Sep 2019 13:15:44 +0200 Subject: keys.openpgp.org not sending confirmation email Message-ID: <07b77e95-57f7-9cbd-b9f4-dbeb4e395058@binarus.de> Dear all, at first, thank you very much for providing privacy and safety for such a long time free of charge to us! Second, the following question could be slightly off-topic because it is partly about the behavior of a key server which clearly is not part of the GPG software. However, I think I have done something bad to my Gpg4Win configuration, so I hope I don't get flamed. I have used the Thunderbird / Enigmail / Gpg4Win troika for quite a while without any issue. Yesterday, I had to reinstall, and while doing so, upgraded to the newest versions of that packages, and while I was at it, revoked my old (1024-bit) keys and generated new (4096-bit) ones (using Enigmail's key management). So I got four new key pairs, each of them associated with exactly one email address. I uploaded the four public keys, again using Enigmail's key management, to Enigmail's default key server, keys.openpgp.org. Enigmail reported success each time. I got confirmation emails for three of that four keys, but it seems that the key server isn't in the mood to send a confirmation email for the fourth. I have uploaded that one multiple times since then (again via Enigmail's key management), each time getting a success message, but still getting no confirmation email. I am absolutely sure that this isn't some spam-filter-related issue or similar. I had a look onto what the MX for the email address in question was logging when uploading the key. I did this several times, and each time I watched the logs at least for five minutes after having uploaded the key. No email message from the key server arrived. I have carefully checked multiple times that there is no typo in the email address which is associated with the key in question. And as expected, when searching for the first three keys on that key server, they are found, while the fourth is not found. Now I fear I have done something silly to the Gpg4Win settings (although I haven't changed its configuration by intention), and I hope that somebody could explain what could have gone wrong here. I have quite a good idea of how PGP encryption works in general, but I never (until now) have used GPG's command line interface (just hadn't to do so because Enigmail did its job quite good), so it would be nice if the issue could be explained in simple words :-) Thank you very much in advance, Binarus P.S. If it would help, I wouldn't have a problem with publishing the email address and the public key in question here. From look at my.amazin.horse Sat Sep 14 14:58:55 2019 From: look at my.amazin.horse (Vincent Breitmoser) Date: Sat, 14 Sep 2019 14:58:55 +0200 Subject: keys.openpgp.org not sending confirmation email In-Reply-To: <07b77e95-57f7-9cbd-b9f4-dbeb4e395058@binarus.de> References: <07b77e95-57f7-9cbd-b9f4-dbeb4e395058@binarus.de> Message-ID: <2JKLK8TQ8MIE9.33OSMGWGN9IMR@my.amazin.horse> Hi Binarus, > I got confirmation emails for three of that four keys, but it seems that > the key server isn't in the mood to send a confirmation email for the > fourth. I have uploaded that one multiple times since then (again via > Enigmail's key management), each time getting a success message, but > still getting no confirmation email. keys.openpgp.org admin here! Can you please contact support at keys.openpgp.org from the address in question? I'll try to help you from there, if we tried to deliver mails there will surely be something in the logs or bounces. Cheers - V From lists at binarus.de Sat Sep 14 15:12:01 2019 From: lists at binarus.de (Binarus) Date: Sat, 14 Sep 2019 15:12:01 +0200 Subject: keys.openpgp.org not sending confirmation email In-Reply-To: <2JKLK8TQ8MIE9.33OSMGWGN9IMR@my.amazin.horse> References: <07b77e95-57f7-9cbd-b9f4-dbeb4e395058@binarus.de> <2JKLK8TQ8MIE9.33OSMGWGN9IMR@my.amazin.horse> Message-ID: <70e6d665-5cf8-397d-6a43-ef89fddc4097@binarus.de> Dear Vincent, On 14.09.2019 14:58, Vincent Breitmoser wrote: >> I got confirmation emails for three of that four keys, but it seems that >> the key server isn't in the mood to send a confirmation email for the >> fourth. I have uploaded that one multiple times since then (again via >> Enigmail's key management), each time getting a success message, but >> still getting no confirmation email. > > keys.openpgp.org admin here! Can you please contact support at keys.openpgp.org > from the address in question? I'll try to help you from there, if we tried to > deliver mails there will surely be something in the logs or bounces. > Thank you very much for your fast reply! I have sent an email from the address in question to support at keys.openpgp.org as you have advised. I am looking forward to what (silly thing) I have done wrong ... Again, thank you very much for your support and time. Regards, Binarus From wk at gnupg.org Sun Sep 15 15:56:05 2019 From: wk at gnupg.org (Werner Koch) Date: Sun, 15 Sep 2019 15:56:05 +0200 Subject: Generating bitwise identical keyrings with GnuPG 1 + 2 In-Reply-To: (Mihai Moldovan's message of "Fri, 13 Sep 2019 21:28:55 +0200") References: <0889c2f9-b8ac-eb76-f65c-2d1666ad21e4@ionic.de> <1567722830.918.25.camel@16bits.net> Message-ID: <87lfupr7d6.fsf@wheatstone.g10code.de> On Fri, 13 Sep 2019 21:28, ionic at ionic.de said: > Either way, my best guess is that GPG 2.2+ drops the trust packets > because the trust is not explicitly set (i.e., default value) - as an The trust packets are for internal use of gpg and are never exported. These packets are one of the reasons why we stated for decades that the interface is "gpg --export" and that the files in ~/.gnupg are internal to gnupg. gnupg/doc/DETAILS tells this about the trust packets: * Format of the OpenPGP TRUST packet According to RFC4880 (5.10), the trust packet (aka ring trust) is only used within keyrings and contains data that records the user's specifications of which key holds trusted introducers. The RFC also states that the format of this packet is _implementation defined_ and SHOULD NOT be emitted to output streams or should be ignored on import. GnuPG uses this packet in several additional ways: - 1 octet :: Trust-Value (only used by Subtype SIG) - 1 octet :: Signature-Cache (only used by Subtype SIG; value must be less than 128) - 3 octets :: Fixed value: "gpg" - 1 octet :: Subtype - 0 :: Signature cache (SIG) - 1 :: Key source on the primary key (KEY) - 2 :: Key source on a user id (UID) - 1 octet :: Key Source; i.e. the origin of the key: - 0 :: Unknown source. - 1 :: Public keyserver. - 2 :: Preferred keyserver. - 3 :: OpenPGP DANE. - 4 :: Web Key Directory. - 5 :: Import from a trusted URL. - 6 :: Import from a trusted file. - 7 :: Self generated. - 4 octets :: Time of last update. This is a a four-octet scalar with the seconds since Epoch. - 1 octet :: Scalar with the length of the following field. - N octets :: String with the URL of the source. This may be a zero-length string. If the packets contains only two octets a Subtype of 0 is assumed; this is the only format recognized by GnuPG versions < 2.1.18. Trust-Value and Signature-Cache must be zero for all subtypes other than SIG. If you use "--export-options backup" these trust packets are exported anyway so that they can be imported with "--import-otions restore". 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 lists at binarus.de Mon Sep 16 09:06:07 2019 From: lists at binarus.de (Binarus) Date: Mon, 16 Sep 2019 09:06:07 +0200 Subject: keys.openpgp.org not sending confirmation email In-Reply-To: <07b77e95-57f7-9cbd-b9f4-dbeb4e395058@binarus.de> References: <07b77e95-57f7-9cbd-b9f4-dbeb4e395058@binarus.de> Message-ID: <2cf58502-9d7f-c65e-87ff-b77918450c96@binarus.de> On 14.09.2019 13:15, Binarus wrote: > I have used the Thunderbird / Enigmail / Gpg4Win troika for quite a > while without any issue. Yesterday, I had to reinstall, and while doing > so, upgraded to the newest versions of that packages, and while I was at > it, revoked my old (1024-bit) keys and generated new (4096-bit) ones > (using Enigmail's key management). > > So I got four new key pairs, each of them associated with exactly one > email address. I uploaded the four public keys, again using Enigmail's > key management, to Enigmail's default key server, keys.openpgp.org. > Enigmail reported success each time. > > I got confirmation emails for three of that four keys, but it seems that > the key server isn't in the mood to send a confirmation email for the > fourth. I have uploaded that one multiple times since then (again via > Enigmail's key management), each time getting a success message, but > still getting no confirmation email. The issue is solved now. I am documenting the solution for people who are affected by the same problem and find this thread when searching. Credits go to Vincent Breitmoser who has confirmed my own suspicion and who was very helpful and fast with his support. The point is that the key server failed to parse the key's ID as an email address. The ID had the following structure (not the real ID, just to make clear the structure): Surname, Forename | Company Commas are not allowed as part of email addresses. While I knew that, I made the wrong assumption that only the part between the brackets would be considered the email address, and that I could use any characters for the "name" part (expect brackets, of course ...). Obviously, I was wrong, and the name part must obey the same rules as the actual email address. Vincent has told me that a certain number of other people had the same problem, so they are thinking of making their parsers less strict, as far as it concerns the name part. After my correspondence with him, I think that they will be quite fast in implementing the changes. However, I recommend everybody to make their whole key ID match the rules for email addresses if they intend to upload it to a key server. Personally, I have revoked all four of the new keys and generated new ones with the ID being only the email address without a name part. While this was not possible using Enigmail (because Enigmail insisted that I had to add a name to the key), it was very easy by using gpg directly on the command line (by the way, its documentation is quite good). As a last tip, keys.openpgp.org offers to upload a public key directly. When you do that, it will emit helpful messages in case of failure. In my case, with the problematic key / ID, it clearly told the the ID could not be parsed as an email address. Unfortunately, I didn't know about the direct upload offer before asking here ... Regards, and thanks again, Binarus From ionic at ionic.de Mon Sep 16 10:11:44 2019 From: ionic at ionic.de (Mihai Moldovan) Date: Mon, 16 Sep 2019 10:11:44 +0200 Subject: 37.191.231.105 (part of keyserver pool) redirects to ... unknown location? Message-ID: <1518414a-3b4b-0a1d-2151-e48e5919c005@ionic.de> Hi Since I know that the keyserver maintainers follow this list, I wonder what happened to 37.191.231.105, which is part of the keyserver pool? It currently HTTP-301-redirects to https://analytics.sumptuouscapital.com/ - which also means that requests to URLs like http://keys.gnupg.net will sometimes redirect a user to that location. Mihai -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 899 bytes Desc: OpenPGP digital signature URL: From daniel.bossert at dabo.ch Mon Sep 16 11:29:19 2019 From: daniel.bossert at dabo.ch (Daniel Bossert) Date: Mon, 16 Sep 2019 11:29:19 +0200 Subject: Which version of GnuPG to use? Message-ID: <6f2792bf-bc77-87c4-63d9-f4d4507f1ce6@dabo.ch> Hi all Some years ago I used GnuPG, but somewhen stopped with it. Now I want to start again. However there are many rumors that it is unsecure meanwhile. I need recommendations: - Which version of software shall I install? - Create key via cli-commands or is Windows-Version ok? - Which keys shall I take (there was an article not to encrypt/sign with El-Gamal)? Many thanks and kind regards Daniel From ca+gnupg-users at esmtp.org Mon Sep 16 12:58:56 2019 From: ca+gnupg-users at esmtp.org (Claus Assmann) Date: Mon, 16 Sep 2019 03:58:56 -0700 Subject: keys.openpgp.org not sending confirmation email In-Reply-To: <2cf58502-9d7f-c65e-87ff-b77918450c96@binarus.de> References: <07b77e95-57f7-9cbd-b9f4-dbeb4e395058@binarus.de> <2cf58502-9d7f-c65e-87ff-b77918450c96@binarus.de> Message-ID: <20190916105856.GA9285@x2.esmtp.org> On Mon, Sep 16, 2019, Binarus wrote: > Surname, Forename | Company > Commas are not allowed as part of email addresses. While I knew that, I unless quoted, e.g., "Surname, Forename | Company" From dgouttegattat at incenp.org Mon Sep 16 14:41:00 2019 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Mon, 16 Sep 2019 13:41:00 +0100 Subject: Which version of GnuPG to use? In-Reply-To: <6f2792bf-bc77-87c4-63d9-f4d4507f1ce6@dabo.ch> References: <6f2792bf-bc77-87c4-63d9-f4d4507f1ce6@dabo.ch> Message-ID: <20190916124057.auna4rfgu5i6phhk@CHS-TMB-078.qmcr.qmul.ac.uk> Hi, On Mon, Sep 16, 2019 at 11:29:19AM +0200, Daniel Bossert wrote: >I need recommendations: >- Which version of software shall I install? The latest version available for your system, which should in any case be a version from the 2.2 branch. (If your system is Windows, that would be Gpg4Win 3.1.10, which provides GnuPG 2.2.17.) You should *not* use GnuPG 1.4.x unless you have some very specific needs (such as working on a "exotic" system or having to interoperate with PGP versions from the mid-1990s), and you should *not* use any version from the 2.0 or 2.1 branch which are not supported anymore. >- Create key via cli-commands or is Windows-Version ok? This doesn't matter, really. You may use gnupg directly on the command line if you're familiar with it, but you don't have to. >- Which keys shall I take (there was an article not to encrypt/sign >with El-Gamal)? The usual recommandation is to stick to the default setting proposed by GnuPG (which currently and if I remember correctly is to generate a RSA-3072 master key for certifying and signing and a RSA-3072 encryption subkey). Note that modern versions of GnuPG do not ask you anymore to specify the type and/or size of key you want unless you explicitly request it. - Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From wk at gnupg.org Mon Sep 16 15:27:14 2019 From: wk at gnupg.org (Werner Koch) Date: Mon, 16 Sep 2019 15:27:14 +0200 Subject: 37.191.231.105 (part of keyserver pool) redirects to ... unknown location? In-Reply-To: <1518414a-3b4b-0a1d-2151-e48e5919c005@ionic.de> (Mihai Moldovan's message of "Mon, 16 Sep 2019 10:11:44 +0200") References: <1518414a-3b4b-0a1d-2151-e48e5919c005@ionic.de> Message-ID: <87muf4pe19.fsf@wheatstone.g10code.de> On Mon, 16 Sep 2019 10:11, ionic at ionic.de said: > which also means that requests to URLs like http://keys.gnupg.net will sometimes > redirect a user to that location. That is not correct. For quite some time that address is a hardwired to avoid problems DNS problems (https://dev.gnupg.org/T3755): /* We used to have DNS CNAME redirection from the URLs below to * sks-keyserver pools. The idea was to allow for a quick way to * switch to a different set of pools. The problem with that * approach is that TLS needs to verify the hostname and - because * DNS is not secured - it can only check the user supplied hostname * and not a hostname from a CNAME RR. Thus the final server all * need to have certificates with the actual pool name as well as * for keys.gnupg.net - that would render the advantage of * keys.gnupg.net useless and so we better give up on this. Because * the keys.gnupg.net URL are still in widespread use we do a static * mapping here. */ if (!strcmp (uri, "hkps://keys.gnupg.net") || !strcmp (uri, "keys.gnupg.net")) uri = "hkps://hkps.pool.sks-keyservers.net"; else if (!strcmp (uri, "https://keys.gnupg.net")) uri = "https://hkps.pool.sks-keyservers.net"; else if (!strcmp (uri, "hkp://keys.gnupg.net")) uri = "hkp://hkps.pool.sks-keyservers.net"; else if (!strcmp (uri, "http://keys.gnupg.net")) uri = "http://hkps.pool.sks-keyservers.net"; else if (!strcmp (uri, "hkps://http-keys.gnupg.net") || !strcmp (uri, "http-keys.gnupg.net")) uri = "hkps://ha.pool.sks-keyservers.net"; else if (!strcmp (uri, "https://http-keys.gnupg.net")) uri = "https://ha.pool.sks-keyservers.net"; else if (!strcmp (uri, "hkp://http-keys.gnupg.net")) uri = "hkp://ha.pool.sks-keyservers.net"; else if (!strcmp (uri, "http://http-keys.gnupg.net")) uri = "http://ha.pool.sks-keyservers.net"; 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 ionic at ionic.de Mon Sep 16 15:41:39 2019 From: ionic at ionic.de (Mihai Moldovan) Date: Mon, 16 Sep 2019 15:41:39 +0200 Subject: Generating bitwise identical keyrings with GnuPG 1 + 2 In-Reply-To: <87lfupr7d6.fsf@wheatstone.g10code.de> References: <0889c2f9-b8ac-eb76-f65c-2d1666ad21e4@ionic.de> <1567722830.918.25.camel@16bits.net> <87lfupr7d6.fsf@wheatstone.g10code.de> Message-ID: <2e1a68c7-f618-0cb6-b7c1-ca5a235ad322@ionic.de> * On 9/15/19 3:56 PM, Werner Koch wrote: > The trust packets are for internal use of gpg and are never exported. But... that's the whole point. gpg 1.4 seems to export them, while gpg 2.x does not. > These packets are one of the reasons why we stated for decades that the > interface is "gpg --export" and that the files in ~/.gnupg are internal to > gnupg. I understand that this might be considered implementation defined, but getting unreproducible output for a specific operation is a bit weird. I don't know if the format GnuPG generates with the --export command is considered stable, though. > The RFC also states that the format of this packet is _implementation > defined_ and SHOULD NOT be emitted to output streams or should be ignored on > import. So it looks like GnuPG 1.x didn't adhere to this recommendation, while GnuPG 2.x does. > If you use "--export-options backup" these trust packets are exported anyway > so that they can be imported with "--import-otions restore". That might be a valid workaround for gpg >= 2.1.18 to make it spit out trust packets. I basically need to find a way to - either make gpg 1.4 NOT output trust packets - or make gpg 2.x generate them. Initially, I thought about using --export-options export-minimal, because it's supported by even ancient 1.4 versions and could have been the better solution here, given that a package archive keyring doesn't need to ship additional signatures (other than the most recent selfsigs). This said, I tried that option and it does not seem to force gpg 1.4 to drop trust packets, so that's sadly not a viable option. Haven't any other option that would stop gpg 1.4 from generating them either. Using --export-options backup, which seems to be supported by at least gpg 2.1.18+, made gpg 2.2 write out trust packets alright, but... more than gpg 1.4 generates. :( 1.4 seems to generate trust packets *only* after signatures, while 2.2, when used with the --export-options backup option, generates trust packets after key, user and signature packets. Excerpt: --- keyringdump.gpg1 2019-09-16 11:58:56.506758876 +0200 +++ keyringdump.gpg2 2019-09-16 12:02:14.967564877 +0200 @@ -4,9 +4,13 @@ pkey[0]: [2048 bits] pkey[1]: [17 bits] keyid: E1F958385BFE2B6E -# off=272 ctb=b4 tag=13 hlen=2 plen=46 +# off=272 ctb=b0 tag=12 hlen=2 plen=12 +:trust packet: key upd=0 src=0 +# off=286 ctb=b4 tag=13 hlen=2 plen=46 :user ID packet: "X2go Debian/Ubuntu Packaging " -# off=320 ctb=89 tag=2 hlen=3 plen=312 +# off=334 ctb=b0 tag=12 hlen=2 plen=12 +:trust packet: uid upd=0 src=0 +# off=348 ctb=89 tag=2 hlen=3 plen=312 :signature packet: algo 1, keyid E1F958385BFE2B6E version 4, created 1299793310, md5len 0, sigclass 0x13 digest algo 2, begin of digest a8 73 @@ -19,15 +23,15 @@ hashed subpkt 23 len 1 (keyserver preferences: 80) subpkt 16 len 8 (issuer key ID E1F958385BFE2B6E) data: [2046 bits] -# off=635 ctb=b0 tag=12 hlen=2 plen=2 +# off=663 ctb=b0 tag=12 hlen=2 plen=6 :trust packet: sig flag=00 sigcache=03 -# off=639 ctb=b9 tag=14 hlen=3 plen=269 +# off=671 ctb=b9 tag=14 hlen=3 plen=269 :public sub key packet: version 4, algo 1, created 1299793310, expires 0 pkey[0]: [2048 bits] pkey[1]: [17 bits] keyid: 71F21F68F489CDCF -# off=911 ctb=89 tag=2 hlen=3 plen=287 +# off=943 ctb=89 tag=2 hlen=3 plen=287 :signature packet: algo 1, keyid E1F958385BFE2B6E version 4, created 1299793310, md5len 0, sigclass 0x18 digest algo 2, begin of digest 77 f5 Looks like I'm stuck. The source code is also enlightening - build_packet_and_meta (which is used with backup) creates trust packets for KEY, SIG, and USER packets, while keyring.c in 1.4 ignores/skips over any trust packets but those coming right after a SIG packet. Mihai -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 899 bytes Desc: OpenPGP digital signature URL: From ionic at ionic.de Mon Sep 16 15:47:14 2019 From: ionic at ionic.de (Mihai Moldovan) Date: Mon, 16 Sep 2019 15:47:14 +0200 Subject: 37.191.231.105 (part of keyserver pool) redirects to ... unknown location? In-Reply-To: <87muf4pe19.fsf@wheatstone.g10code.de> References: <1518414a-3b4b-0a1d-2151-e48e5919c005@ionic.de> <87muf4pe19.fsf@wheatstone.g10code.de> Message-ID: <0ef8d804-b911-add7-55bc-4847d3ec1af6@ionic.de> * On 9/16/19 3:27 PM, Werner Koch wrote: > On Mon, 16 Sep 2019 10:11, ionic at ionic.de said: > >> which also means that requests to URLs like http://keys.gnupg.net will sometimes >> redirect a user to that location. > > That is not correct. For quite some time that address is a hardwired to > avoid problems DNS problems (https://dev.gnupg.org/T3755): I probably should have been more specific. Yes, that holds for the GnuPG tool, but I was talking about users accessing the keyserver web interface directly using a normal browser (e.g., for checking on own or foreign public keys). The CNAME is still used in this case. :) I was quite surprised to browse to http://keys.gnupg.net and be redirected to https://analytics.sumptuouscapital.com/ - though luckily only the one mentioned node does that. Mihai -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 899 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Mon Sep 16 19:44:08 2019 From: wk at gnupg.org (Werner Koch) Date: Mon, 16 Sep 2019 19:44:08 +0200 Subject: Generating bitwise identical keyrings with GnuPG 1 + 2 In-Reply-To: <2e1a68c7-f618-0cb6-b7c1-ca5a235ad322@ionic.de> (Mihai Moldovan's message of "Mon, 16 Sep 2019 15:41:39 +0200") References: <0889c2f9-b8ac-eb76-f65c-2d1666ad21e4@ionic.de> <1567722830.918.25.camel@16bits.net> <87lfupr7d6.fsf@wheatstone.g10code.de> <2e1a68c7-f618-0cb6-b7c1-ca5a235ad322@ionic.de> Message-ID: <871rwgp253.fsf@wheatstone.g10code.de> On Mon, 16 Sep 2019 15:41, ionic at ionic.de said: > * On 9/15/19 3:56 PM, Werner Koch wrote: >> The trust packets are for internal use of gpg and are never exported. > > But... that's the whole point. gpg 1.4 seems to export them, while gpg > 2.x does not. I just checked the code and I can't see how they get exported. In the loop over the packets you find: /* Make sure that ring_trust packets never get exported. */ if (node->pkt->pkttype == PKT_RING_TRUST) continue; which should skip them while exporting. Can you please provide a test keyring and tell us the exact gpg 1.4 version you are using? > unreproducible output for a specific operation is a bit weird. I don't know if > the format GnuPG generates with the --export command is considered > stable, though. Yes it is the interchange format as specified by RFC-4880. > I basically need to find a way to > - either make gpg 1.4 NOT output trust packets The solution is simple; Do not use gpg 1.4 except for decrypting legacy data which either does not use MDC or is encrypted with a v3 key. There is no other use case for gpg 1.4. > 1.4 seems to generate trust packets *only* after signatures, while 2.2, when > used with the --export-options backup option, generates trust packets after key, They are implementation defined and thus do not go into the key interchange format (transferable public/secret key). The backup/restore options are an exception for, well, backup and restore of *GnuPG*'s internal key data storage. 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 sac at 300baud.de Mon Sep 16 23:49:20 2019 From: sac at 300baud.de (Stefan Claas) Date: Mon, 16 Sep 2019 23:49:20 +0200 Subject: Which version of GnuPG to use? In-Reply-To: <6f2792bf-bc77-87c4-63d9-f4d4507f1ce6@dabo.ch> References: <6f2792bf-bc77-87c4-63d9-f4d4507f1ce6@dabo.ch> Message-ID: <20190916234920.00002172.sac@300baud.de> Daniel Bossert wrote: > Hi all > > Some years ago I used GnuPG, but somewhen stopped with it. > > Now I want to start again. However there are many rumors that it is > unsecure meanwhile. Can you tell us what rumors you have heared? I would say the encryption in GnuPG is secure, but sadly people tend to use encryption software on online computers due to many tutorials, MUA plug-ins and their lazyness and therefore it can never been guaranteed that the communications are always secure. P.S. Question for Werner and all the other hackers. Would it be very difficult to read out the required decryption parameters, like p&q so to speak, with a specially crafted software, when using an online computer with a SmardCard? I have read that the secret key can not been copied from the card, but what about the 'bits and pieces' in memory when decrypting? Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From wk at gnupg.org Tue Sep 17 08:06:01 2019 From: wk at gnupg.org (Werner Koch) Date: Tue, 17 Sep 2019 08:06:01 +0200 Subject: Which version of GnuPG to use? In-Reply-To: <20190916234920.00002172.sac@300baud.de> (Stefan Claas via Gnupg-users's message of "Mon, 16 Sep 2019 23:49:20 +0200") References: <6f2792bf-bc77-87c4-63d9-f4d4507f1ce6@dabo.ch> <20190916234920.00002172.sac@300baud.de> Message-ID: <87pnjzo3sm.fsf@wheatstone.g10code.de> On Mon, 16 Sep 2019 23:49, gnupg-users at gnupg.org said: > speak, with a specially crafted software, when using an online computer > with a SmardCard? I have read that the secret key can not been copied from > the card, but what about the 'bits and pieces' in memory when decrypting? Side-channel attacks on smartcards are an pretty old thing dating back to the late 80ies. Current smartcards are hardened against most such attacks. Unless you have physical access to the card the secrets and their use on the card/token are well protected against any sniffing by the host. 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 lists at binarus.de Tue Sep 17 09:12:12 2019 From: lists at binarus.de (Binarus) Date: Tue, 17 Sep 2019 09:12:12 +0200 Subject: keys.openpgp.org not sending confirmation email In-Reply-To: <20190916105856.GA9285@x2.esmtp.org> References: <07b77e95-57f7-9cbd-b9f4-dbeb4e395058@binarus.de> <2cf58502-9d7f-c65e-87ff-b77918450c96@binarus.de> <20190916105856.GA9285@x2.esmtp.org> Message-ID: <205fc2ee-a688-ea81-6627-eb03b94e51e2@binarus.de> On 16.09.2019 12:58, Claus Assmann wrote: > On Mon, Sep 16, 2019, Binarus wrote: > >> Surname, Forename | Company > >> Commas are not allowed as part of email addresses. While I knew that, I > > unless quoted, e.g., > "Surname, Forename | Company" Thanks, Claus, for the clarification / correction, and for your continuous support and expertise. Additionally, I just did a quick test. Using Thunderbird, I sent two messages to somebody else, one from an account where the name contained a comma and another one from an account where the name only contained [a-zA-Z] and spaces. Interestingly enough, Thunderbird did its thing right, at least in generating the "FROM:" line. It wrapped the name in quotes in the first case and left away the quotes in the second case. In other words, the receiver got two messages with "FROM:" lines which were formatted differently: FROM: "Surname, Forename | Company" FROM: Forename Surname So Thunderbird seems to add the quotes automatically if necessary, and I am asking myself why Enigmail doesn't. I am not sure (and can't test at the moment) how GnuPG would behave if given a problematic name when generating a key; I hope it would give a warning or would add the quotes automatically. >From a quick glance at the web API (VKS interface) and at the HKP implementation of keys.openpgp.org, I got the impression that there isn't a status code or return value from which tools like Enigmail could see that there was a problem with parsing a key's ID. Perhaps the extended status codes in the HKP protocol could be used to return that sort of error, but even that is questionable, and I guess that this is not implemented anywhere. In other words, the key server currently is not able to report such errors when a key is being uploaded via HKP or the web API. Am I correct here? If yes, should we consider this a design flaw in these key server APIs? After all, tools like Enigmail then wouldn't have the chance to report such errors to the user when trying to upload a key. Vincent, could you eventually elaborate a bit on that problem? If we only would be able to read every RFC which affects any software we use for our daily work ... Regards, Binarus From me at halfdog.net Tue Sep 17 08:51:11 2019 From: me at halfdog.net (halfdog) Date: Tue, 17 Sep 2019 06:51:11 +0000 Subject: Regenerate Openpgp Public Key from Private Key Message-ID: <2663-1568703071.553907@g3pJ.PqA9.rUG5> Hello list, Regenerating private keys is mathematically trivial but tool-wise a little tricky. It seems that quite some people were troubled by this problem due to different reasons (I not attempted to confirm all of these): * Using (old) backups of keys for decrypting with only private key available. * Smartcards with only private key on them * Forensic scenarios Since a Gnupg update the tool will refuse to perform decryption with private keys only. As gpg seems to provide no easy option to regenerate/calculate the public key from the private keys or ignore the missing keys, I used the method described in [0] as a hacky way to regenerate 4096 bit public keys from private keys using peculiarities of the Openpgp storage format and minimal binary editing. I needed this to decrypt some old data, maybe someone else might find it useful too. hd [0] https://www.halfdog.net/Blog/2019/OpenpgpRegeneratePublicKeyFromPrivate/ From wk at gnupg.org Tue Sep 17 12:06:46 2019 From: wk at gnupg.org (Werner Koch) Date: Tue, 17 Sep 2019 12:06:46 +0200 Subject: Regenerate Openpgp Public Key from Private Key In-Reply-To: <2663-1568703071.553907@g3pJ.PqA9.rUG5> (halfdog's message of "Tue, 17 Sep 2019 06:51:11 +0000") References: <2663-1568703071.553907@g3pJ.PqA9.rUG5> Message-ID: <877e67nsnd.fsf@wheatstone.g10code.de> On Tue, 17 Sep 2019 06:51, me at halfdog.net said: > Regenerating private keys is mathematically trivial but tool-wise > a little tricky. It seems that quite some people were troubled What's wrong with gpg --import backup-of-private-key.gpg the private key include the entire public 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 wk at gnupg.org Tue Sep 17 12:17:00 2019 From: wk at gnupg.org (Werner Koch) Date: Tue, 17 Sep 2019 12:17:00 +0200 Subject: keys.openpgp.org not sending confirmation email In-Reply-To: <205fc2ee-a688-ea81-6627-eb03b94e51e2@binarus.de> (Binarus's message of "Tue, 17 Sep 2019 09:12:12 +0200") References: <07b77e95-57f7-9cbd-b9f4-dbeb4e395058@binarus.de> <2cf58502-9d7f-c65e-87ff-b77918450c96@binarus.de> <20190916105856.GA9285@x2.esmtp.org> <205fc2ee-a688-ea81-6627-eb03b94e51e2@binarus.de> Message-ID: <8736gvns6b.fsf@wheatstone.g10code.de> On Tue, 17 Sep 2019 09:12, lists at binarus.de said: > I am asking myself why Enigmail doesn't. I am not sure (and can't test > at the moment) how GnuPG would behave if given a problematic name when > generating a key; I hope it would give a warning or would add the gpg generates such a key just fine: gpg --quick-gen-key "foo, bar | baz " results in pub rsa3072 2019-09-17 [SC] [expires: 2021-09-16] D5A13F45AD29FAD517FEB157F29010625F3EDDDA uid foo, bar | baz and gpg's internal mail-addr extraction function simply looks for the left angle bracket to find the mail-address and then checks whether that mail-addr is valid. The code also allows for a user-id consisting only of the mail-addr without the angle brackets. The reason for this is that this de-facto standard only resembles an rfc-822 address but is not necessary valid. For example due to the utf-8 encoding. 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 me at halfdog.net Tue Sep 17 13:09:58 2019 From: me at halfdog.net (halfdog) Date: Tue, 17 Sep 2019 11:09:58 +0000 Subject: Regenerate Openpgp Public Key from Private Key In-Reply-To: <877e67nsnd.fsf@wheatstone.g10code.de> References: <2663-1568703071.553907@g3pJ.PqA9.rUG5> <877e67nsnd.fsf@wheatstone.g10code.de> Message-ID: <3384-1568718598.341944@grDk.cdKJ.F116> Werner Koch writes: > On Tue, 17 Sep 2019 06:51, me at halfdog.net said: > >> Regenerating private keys is mathematically trivial but tool-wise >> a little tricky. It seems that quite some people were troubled > > What's wrong with > > gpg --import backup-of-private-key.gpg > > the private key include the entire public key. That it won't work in some circumstances, e.g. those cited the line below those you have quoted (fixing the wrong private/public you got obviously right anyway drafting your reply): """Regenerating public keys is mathematically trivial but tool-wise a little tricky. It seems that quite some people were troubled by this problem due to different reasons (I not attempted to confirm all of these): * Using (old) backups of keys for decrypting with only private key available. * Smartcards with only private key on them * Forensic scenarios """ Therefore some exports (or copies of old secring.gpg) just do no include the public key, otherwise import would be trivial. Usually problem reports of other users look like [0] and do not contain any direct solution, only workarounds e.g. "get your missing public key from somewhere else". As the key causing me problems was very old, I do not have the software at hand that was used to create it, nor it is clear if I only stored away the secring or an explicit private key export, therefore I cannot find out what exactly caused the situation, just that for me as for many others import or decrypt does not work any more. I believe that decryption worked with older gpg1 versions and this kind of key data but I do not remember when and the gpg1 software version used back then. hd [0] https://unix.stackexchange.com/questions/267844/gpg-secret-key-not-available-when-sec-pub-key-are-in-keyring From wk at gnupg.org Tue Sep 17 13:24:22 2019 From: wk at gnupg.org (Werner Koch) Date: Tue, 17 Sep 2019 13:24:22 +0200 Subject: Regenerate Openpgp Public Key from Private Key In-Reply-To: <3384-1568718598.341944@grDk.cdKJ.F116> (halfdog's message of "Tue, 17 Sep 2019 11:09:58 +0000") References: <2663-1568703071.553907@g3pJ.PqA9.rUG5> <877e67nsnd.fsf@wheatstone.g10code.de> <3384-1568718598.341944@grDk.cdKJ.F116> Message-ID: <87pnjzmahl.fsf@wheatstone.g10code.de> On Tue, 17 Sep 2019 11:09, me at halfdog.net said: > Therefore some exports (or copies of old secring.gpg) just do > no include the public key, otherwise import would be trivial. Nope. It is not possible to create an OpenPGP secret keyblok without the public key parts. > As the key causing me problems was very old, I do not have the > software at hand that was used to create it, nor it is clear We removed v3 key support in 2.1 for security reasons. You need to use gpg 1.4 wo work with these keys. > https://unix.stackexchange.com/questions/267844/gpg-secret-key-not-available-when-sec-pub-key-are-in-keyring That is about the old 2.0 (or a 1.4) version which is end-of-life and did not allow to merge secret and public keyblocks. That might be the problem at hand. 2.2 fixes this problem by not trying to sync a secring.gpg and pubring.gpg. The secring.gpg is actually not anymore used but the secret parts of the key have been moved to the gpg-agent's secret key store. 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 me at halfdog.net Tue Sep 17 14:31:14 2019 From: me at halfdog.net (halfdog) Date: Tue, 17 Sep 2019 12:31:14 +0000 Subject: Regenerate Openpgp Public Key from Private Key In-Reply-To: <87pnjzmahl.fsf@wheatstone.g10code.de> References: <2663-1568703071.553907@g3pJ.PqA9.rUG5> <877e67nsnd.fsf@wheatstone.g10code.de> <3384-1568718598.341944@grDk.cdKJ.F116> <87pnjzmahl.fsf@wheatstone.g10code.de> Message-ID: <3750-1568723474.085953@uz7I.ayic.q3Ri> Werner Koch writes: > On Tue, 17 Sep 2019 11:09, me at halfdog.net said: > >> Therefore some exports (or copies of old secring.gpg) just >> do no include the public key, otherwise import would be trivial. > > Nope. It is not possible to create an OpenPGP secret keyblok > without the public key parts. There must have been some easy/likely pathes to reach such a state regarding the number people searching for such a solution, e.g. checking only 'gpg "secret key without public key"', which is only one possible error message in such an incomplete-private-key scenario. One cause seems loss of pubring.gpg (or zeroing out, not replaying it from backup, ...) as documented in [0]. Others might be related only to the missing user_id or sig packets, maybe because these expired during the whole timeline. >> As the key causing me problems was very old, I do not have >> the software at hand that was used to create it, nor it is >> clear > > We removed v3 key support in 2.1 for security reasons. You > need to use gpg 1.4 wo work with these keys. At least my problematic keys were already v4 ones, I cannot say for sure for similar problem reports on the net, they might have used v3s. >> https://unix.stackexchange.com/questions/267844/gpg-secret-key-not-available-when-sec-pub-key-are-in-keyring > > That is about the old 2.0 (or a 1.4) version which is end-of-life > and did not allow to merge secret and public keyblocks. That > might be the problem at hand. 2.2 fixes this problem by not > trying to sync a secring.gpg and pubring.gpg. The secring.gpg > is actually not anymore used but the secret parts of the key > have been moved to the gpg-agent's secret key store. As the problem might be related to long-time compatibility of gpg, most of the reports and possible solutions are quite old and may affect outdated software. As it seems quite important for some users to decrypt old data also years after creating it and that seems to fail sometimes, the probability to have an outdated version in the whole scenario is nearly 100%. Hence I did not spend much time to figure out how the problem happened over the years, just took it as granted and tried to find an easy fix - not recreating all the frames with some Python opengpg framework as one poster suggested. hd [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640241 From lists at binarus.de Tue Sep 17 14:57:27 2019 From: lists at binarus.de (Binarus) Date: Tue, 17 Sep 2019 14:57:27 +0200 Subject: keys.openpgp.org not sending confirmation email In-Reply-To: <8736gvns6b.fsf@wheatstone.g10code.de> References: <07b77e95-57f7-9cbd-b9f4-dbeb4e395058@binarus.de> <2cf58502-9d7f-c65e-87ff-b77918450c96@binarus.de> <20190916105856.GA9285@x2.esmtp.org> <205fc2ee-a688-ea81-6627-eb03b94e51e2@binarus.de> <8736gvns6b.fsf@wheatstone.g10code.de> Message-ID: At first, thank you very much for your explanations! On 17.09.2019 12:17, Werner Koch wrote: > On Tue, 17 Sep 2019 09:12, lists at binarus.de said: > >> I am asking myself why Enigmail doesn't. I am not sure (and can't test >> at the moment) how GnuPG would behave if given a problematic name when >> generating a key; I hope it would give a warning or would add the > > gpg generates such a key just fine: > > gpg --quick-gen-key "foo, bar | baz " > > results in > > pub rsa3072 2019-09-17 [SC] [expires: 2021-09-16] > D5A13F45AD29FAD517FEB157F29010625F3EDDDA > uid foo, bar | baz I really hope that I don't annoy anybody (being in no way an experienced user in this field and probably still missing many basics), but as far as I have understood my communication with Vincent, it's such IDs which are a problem for keys.openpgp.org. When I first used Enigmail to generate and upload a key with such an ID to keys.openpgp.org, I never got the confirmation email. When I uploaded that key using the web form (https://keys.openpgp.org/upload), it told me that it couldn't parse the key's ID as an email address. Consequently, it couldn't send a confirmation email, and the key, although having been stored on the server, could not be found when being searched for by mail address. > and gpg's internal mail-addr extraction function simply looks for the > left angle bracket to find the mail-address and then checks whether that > mail-addr is valid. Thank you very much for that insight. > The code also allows for a user-id consisting only > of the mail-addr without the angle brackets. This is the way I am going now. After the bad experience, I have decided to use only key IDs consisting solely of the actual mail address hereafter (with or without the angle brackets - I can live with both variants :-)). Enigmail refuses to generate such keys (it insists on entering a non-empty name and doesn't complete the key generation process otherwise). But I could easily generate such keys using the GnuPG command line interface. > The reason for this is > that this de-facto standard only resembles an rfc-822 address but is not > necessary valid. For example due to the utf-8 encoding. I see. Then the problem might be due to standards which are "only" de-facto, leading to parsers (on the key servers) which interpret those IDs subtly differently from what GnuPG / Enigmail and friends expect. By the way, I did not test yet how keys.openpgp.org would behave when given a key ID with a comma in the name, but with the name quoted. In every case, I am happy now, as long as IDs consisting only of the actual mail address remain allowed. Personally, I currently don't need to have my name or other fancy text in my keys' IDs. I suppose that somebody who wants to write me an encrypted message will search for my public key at first by email address (and not by other criteria). At least, I would do so ... Regards, and thanks again, Binarus From look at my.amazin.horse Tue Sep 17 15:08:53 2019 From: look at my.amazin.horse (Vincent Breitmoser) Date: Tue, 17 Sep 2019 15:08:53 +0200 Subject: keys.openpgp.org not sending confirmation email In-Reply-To: References: <07b77e95-57f7-9cbd-b9f4-dbeb4e395058@binarus.de> <2cf58502-9d7f-c65e-87ff-b77918450c96@binarus.de> <20190916105856.GA9285@x2.esmtp.org> <205fc2ee-a688-ea81-6627-eb03b94e51e2@binarus.de> <8736gvns6b.fsf@wheatstone.g10code.de> Message-ID: <2Y2WWTOHMCDY9.2H3S209XOEP5S@my.amazin.horse> > but as far as I have understood my communication with Vincent, it's such IDs > which are a problem for keys.openpgp.org. Right, that's because we currently use an actual rfc2822 parser on keys.openpgp.org. This works fine for *most* users, but in the end causes more trouble than it's worth, so we will probably switch to something more lenient soon. See also dkg's thoughts on the matter on the openpgp-wg mailing list, to align the specification with reality: https://mailarchive.ietf.org/arch/msg/openpgp/wNo27-0STfGR9JZSlC7s6OYOJkI - V From daniel.bossert at dabo.ch Tue Sep 17 15:12:09 2019 From: daniel.bossert at dabo.ch (Daniel Bossert) Date: Tue, 17 Sep 2019 15:12:09 +0200 Subject: Automatically delete old keys from servers Message-ID: Hi all On the key servers are many old keys lying around which aren't valid anymore. Could you implement a function on the servers which delete keys after let's say one year automatically,reminding the user via email one month ahead to reupload the keys? Me too have some old, useless keys there and people shouldn't use an invalid public key anymore. Regards Daniel -- Skickat fr?n min Android-enhet med K-9 Mail. Urs?kta min f?ordighet. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at binarus.de Tue Sep 17 15:50:15 2019 From: lists at binarus.de (Binarus) Date: Tue, 17 Sep 2019 15:50:15 +0200 Subject: keys.openpgp.org not sending confirmation email In-Reply-To: <2Y2WWTOHMCDY9.2H3S209XOEP5S@my.amazin.horse> References: <07b77e95-57f7-9cbd-b9f4-dbeb4e395058@binarus.de> <2cf58502-9d7f-c65e-87ff-b77918450c96@binarus.de> <20190916105856.GA9285@x2.esmtp.org> <205fc2ee-a688-ea81-6627-eb03b94e51e2@binarus.de> <8736gvns6b.fsf@wheatstone.g10code.de> <2Y2WWTOHMCDY9.2H3S209XOEP5S@my.amazin.horse> Message-ID: <9cc31e24-7e2c-f043-afdf-b1e52efc02ad@binarus.de> On 17.09.2019 15:08, Vincent Breitmoser wrote: > >> but as far as I have understood my communication with Vincent, it's such IDs >> which are a problem for keys.openpgp.org. > > Right, that's because we currently use an actual rfc2822 parser on > keys.openpgp.org. This works fine for *most* users, but in the end causes more > trouble than it's worth, so we will probably switch to something more lenient > soon. > > See also dkg's thoughts on the matter on the openpgp-wg mailing list, to align > the specification with reality: > https://mailarchive.ietf.org/arch/msg/openpgp/wNo27-0STfGR9JZSlC7s6OYOJkI Thank you very much for the link. That was an interesting reading. There are much more differences between IDs in the wild and RFC2822 than I ever would have suspected. Did I get this right? That post has been published just yesterday? Glad that I noticed this just in time - I already was typing "Does anybody know how widespread those proposals are, and which one has won?" :-) Regards, Binarus From lists at binarus.de Tue Sep 17 16:09:46 2019 From: lists at binarus.de (Binarus) Date: Tue, 17 Sep 2019 16:09:46 +0200 Subject: Automatically delete old keys from servers In-Reply-To: References: Message-ID: <100fe5f3-424b-5bd3-dd40-89ec621692cd@binarus.de> On 17.09.2019 15:12, Daniel Bossert wrote: > Hi all > > On the key servers are many old keys lying around which aren't valid > anymore. > > Could you implement a function on the servers which delete keys after > let's say one year automatically,reminding the user via email one month > ahead to reupload the keys? > > Me too have some old, useless keys there and people shouldn't use an > invalid public key anymore. I am far from being an expert, but I think that the usual way to deal with this problem is to revoke the key in question and upload the revocation to the key server. Maybe I have missed some basics here and that I am completely wrong, but this at least is what Enigmail proposes if you revoke a key in its key management window: Upload the revoked key. There is a second solution to your problem: Limit the validity of the key when generating it. You can easily generate keys which are valid exactly one year from the date of generation. Any reasonable MUA will refuse to encrypt a message using an expired public key, or will at least show a warning. That way, you can get close to the behavior you want. Your key expires after a year, and although it still remains on the key server after that time, nobody will use it to encrypt a message to you. Furthermore, if memory serves me right, your public key is needed to check your signature; remember that signing works in the opposite direction than encrypting (signing means: you encrypt a message hash with your private key, the receiver decrypts the hash using your public key and checks if the decrypted hash matches the message). So deleting public keys from a key server might be a bad idea anyway. Regards, Binarus From wk at gnupg.org Tue Sep 17 16:25:08 2019 From: wk at gnupg.org (Werner Koch) Date: Tue, 17 Sep 2019 16:25:08 +0200 Subject: keys.openpgp.org not sending confirmation email In-Reply-To: (Binarus's message of "Tue, 17 Sep 2019 14:57:27 +0200") References: <07b77e95-57f7-9cbd-b9f4-dbeb4e395058@binarus.de> <2cf58502-9d7f-c65e-87ff-b77918450c96@binarus.de> <20190916105856.GA9285@x2.esmtp.org> <205fc2ee-a688-ea81-6627-eb03b94e51e2@binarus.de> <8736gvns6b.fsf@wheatstone.g10code.de> Message-ID: <87h85bm24b.fsf@wheatstone.g10code.de> On Tue, 17 Sep 2019 14:57, lists at binarus.de said: > to use only key IDs consisting solely of the actual mail address > hereafter (with or without the angle brackets - I can live with both That is actually what I suggest for quite some time. The extra stuff is not required and may lead only to confusion if the user id does not match the mail address as taken from an addressbook, or a received mail. Further there are mail providers who do only allow keys which only the mail address. The Web Key Directory takes this in account and gnupg will create a new user id for such providers in the publishing process. > I see. Then the problem might be due to standards which are "only" > de-facto, leading to parsers (on the key servers) which interpret those > IDs subtly differently from what GnuPG / Enigmail and friends expect. BTW, for a long time PGP 5 and later had no idea about the charset of user-ids and happily copied verbatim whatever the OS supplied as a string. The result is that all MUAs and gpg's command line implement a heuristic to detect and convert on display the Latin-1 encoding of German Umlauts. > By the way, I did not test yet how keys.openpgp.org would behave when > given a key ID with a comma in the name, but with the name quoted. FWIW, tehre are obvious cases which gpg does not catch either. I added two test cases to show this: +++ b/common/t-mbox-util.c @@ -77,6 +77,12 @@ run_mbox_test (void) { " ()", "fo()o at example.org" }, { "fo()o at example.org", NULL}, { "Mr. Foo ", "foo at example.org"}, + { "Surname, Forename | company ", "foo at example.org"}, + /* The next one is for sure not RFC-822 correct but nevertheless + * the way gpg does it. We won't change it because the user-id + * is only rfc-822 alike and not compliant (think only of our + * utf-8 requirement). */ + { "\"\" ", "foo at example.org"}, { NULL, NULL } }; > to have my name or other fancy text in my keys' IDs. I suppose that > somebody who wants to write me an encrypted message will search for my > public key at first by email address (and not by other criteria). At Actually we parse the address out of the user-id and put it into the Signer's User ID subpacket of a signature if possible. Mail addresses have the advantage that they maps to a global directory of identities which full user-ids won't. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Tue Sep 17 16:27:16 2019 From: wk at gnupg.org (Werner Koch) Date: Tue, 17 Sep 2019 16:27:16 +0200 Subject: Automatically delete old keys from servers In-Reply-To: (Daniel Bossert's message of "Tue, 17 Sep 2019 15:12:09 +0200") References: Message-ID: <87d0fzm20r.fsf@wheatstone.g10code.de> On Tue, 17 Sep 2019 15:12, daniel.bossert at dabo.ch said: > On the key servers are many old keys lying around which aren't valid anymore. Old keys are still useful to verify signatures. This is even true for expired keys. The user then needs to decide what to do with the verification result. 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 wk at gnupg.org Tue Sep 17 17:21:52 2019 From: wk at gnupg.org (Werner Koch) Date: Tue, 17 Sep 2019 17:21:52 +0200 Subject: keys.openpgp.org not sending confirmation email In-Reply-To: <2Y2WWTOHMCDY9.2H3S209XOEP5S@my.amazin.horse> (Vincent Breitmoser via Gnupg-users's message of "Tue, 17 Sep 2019 15:08:53 +0200") References: <07b77e95-57f7-9cbd-b9f4-dbeb4e395058@binarus.de> <2cf58502-9d7f-c65e-87ff-b77918450c96@binarus.de> <20190916105856.GA9285@x2.esmtp.org> <205fc2ee-a688-ea81-6627-eb03b94e51e2@binarus.de> <8736gvns6b.fsf@wheatstone.g10code.de> <2Y2WWTOHMCDY9.2H3S209XOEP5S@my.amazin.horse> Message-ID: <875zlrlzhr.fsf@wheatstone.g10code.de> On Tue, 17 Sep 2019 15:08, gnupg-users at gnupg.org said: > See also dkg's thoughts on the matter on the openpgp-wg mailing list, to align > the specification with reality: OpenPGP has never defined what goes into the User ID except for the encoding which should be UTF-8. Anything else does not belong into the specs unless the X.509 mess is a desired outcome. Thus the current wording is sufficient and has served us well over the last 25 years [1]: | ## User ID Packet (Tag 13) | | A User ID packet consists of UTF-8 text that is intended to represent | the name and email address of the key holder. By convention, it | includes an RFC 2822 [](#RFC2822) mail name-addr, but there are no | restrictions on its content. The packet length in the header specifies | the length of the User ID. Salam-Shalom, Werner [1] RFC-1991 is oldest spec I have instantly available; it describes the 1991 data format of PGP2, it differes from OpenPGP only by using ASCII for the encoding: |6.7 User ID Packet | | Purpose. A user ID packet identifies a user and is associated with a | public or private key. | | Definition. A user ID packet is the concatenation of the following | fields: | | (a) packet structure field (2 bytes); | (b) User ID string. | | The User ID string may be any string of printable ASCII characters. | However, since the purpose of this packet is to uniquely identify an | individual, the usual practice is for the User ID string to consist | of the user's name followed by an e-mail address for that user, the | latter enclosed in angle brackets. -- 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 look at my.amazin.horse Tue Sep 17 17:35:22 2019 From: look at my.amazin.horse (Vincent Breitmoser) Date: Tue, 17 Sep 2019 17:35:22 +0200 Subject: keys.openpgp.org not sending confirmation email In-Reply-To: <875zlrlzhr.fsf@wheatstone.g10code.de> References: <875zlrlzhr.fsf@wheatstone.g10code.de> <07b77e95-57f7-9cbd-b9f4-dbeb4e395058@binarus.de> <2cf58502-9d7f-c65e-87ff-b77918450c96@binarus.de> <20190916105856.GA9285@x2.esmtp.org> <205fc2ee-a688-ea81-6627-eb03b94e51e2@binarus.de> <8736gvns6b.fsf@wheatstone.g10code.de> <2Y2WWTOHMCDY9.2H3S209XOEP5S@my.amazin.horse> Message-ID: <2YITTW8UAT56W.3DYYZMX1NSXVA@my.amazin.horse> > Thus the current wording is sufficient and has served us well over the last 25 > years If your statement here includes the "by convention contains an rfc2822 name-addr" part of the wording, please bring this opinion up on the openpgp-wg thread. The argument is being made (and I agree) that it's plain to see that implementations neither emit user ids as rfc2822, nor parse them as such, by convention or otherwise. The spec is factually wrong and misleading for implementors in this aspect, and should be updated to reflect reality. - V From tlikonen at iki.fi Tue Sep 17 18:10:02 2019 From: tlikonen at iki.fi (Teemu Likonen) Date: Tue, 17 Sep 2019 19:10:02 +0300 Subject: Automatically delete old keys from servers In-Reply-To: References: Message-ID: <87tv9azyxx.fsf@iki.fi> Daniel Bossert [2019-09-17T15:12:09+02] wrote: > On the key servers are many old keys lying around which aren't valid > anymore. > > Could you implement a function on the servers which delete keys after > let's say one year automatically,reminding the user via email one > month ahead to reupload the keys? That is the very purpose of invalid (revoked, expired) keys in the server: tell people that the keys are invalid and not to be used. If the keys were removed from servers (which won't happen) it would be more difficult to share that important information. A reminder email doesn't sound like a good idea: a key might be revoked or expired because the owner's email address is no longer valid. The server can't know if user wants to update key's expiration date or if the key is expired or revoked for good. keys.openpgp.org is different from usual SKS keyservers so there might be different policies. My views in above paragraphs are about SKS keyservers. -- /// OpenPGP key: 4E1055DC84E9DFF613D78557719D69D324539450 // https://keys.openpgp.org/search?q=tlikonen at iki.fi / https://keybase.io/tlikonen https://github.com/tlikonen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 694 bytes Desc: not available URL: From look at my.amazin.horse Tue Sep 17 18:28:07 2019 From: look at my.amazin.horse (Vincent Breitmoser) Date: Tue, 17 Sep 2019 18:28:07 +0200 Subject: Automatically delete old keys from servers In-Reply-To: References: Message-ID: <2YH0AW024PR4T.2909DHG418085@my.amazin.horse> The simple truth is: For the SKS servers, it is not technically possible to remove keys, and never will be. People have speculated, postulated, counterargued, rambled on several mailing lists about how great or terrible a thing that is. But no matter what anyone tells you or how many mails are written - the simple truth is: For the SKS servers, it is not technically possible to remove keys, and never will be. Cheers - V From sac at 300baud.de Tue Sep 17 18:59:34 2019 From: sac at 300baud.de (Stefan Claas) Date: Tue, 17 Sep 2019 18:59:34 +0200 Subject: Which version of GnuPG to use? In-Reply-To: <87pnjzo3sm.fsf@wheatstone.g10code.de> References: <6f2792bf-bc77-87c4-63d9-f4d4507f1ce6@dabo.ch> <20190916234920.00002172.sac@300baud.de> <87pnjzo3sm.fsf@wheatstone.g10code.de> Message-ID: <20190917185934.00004244.sac@300baud.de> Werner Koch wrote: > On Mon, 16 Sep 2019 23:49, gnupg-users at gnupg.org said: > > > speak, with a specially crafted software, when using an online computer > > with a SmardCard? I have read that the secret key can not been copied from > > the card, but what about the 'bits and pieces' in memory when decrypting? > > Side-channel attacks on smartcards are an pretty old thing dating back > to the late 80ies. Current smartcards are hardened against most such > attacks. Unless you have physical access to the card the secrets and > their use on the card/token are well protected against any sniffing by > the host. Unfortunately I am no programmer but I was thinking about the following: I assume that in order to decrypt a message the secret key data must be unlocked and loaded for a very short time into the computers RAM, in order to perform the decryption, or am I wrong with my assumption? And if I am not wrong, would that be very difficult to get the parameters from the secret key or does GnuPG somehow (tries to) prevent this? Sorry for this question but I like to learn more about how this works and if I should invest in a smardcard in the future, for online usage. Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From peter at digitalbrains.com Tue Sep 17 19:16:06 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 17 Sep 2019 19:16:06 +0200 Subject: Smartcard operation In-Reply-To: <20190917185934.00004244.sac@300baud.de> References: <6f2792bf-bc77-87c4-63d9-f4d4507f1ce6@dabo.ch> <20190916234920.00002172.sac@300baud.de> <87pnjzo3sm.fsf@wheatstone.g10code.de> <20190917185934.00004244.sac@300baud.de> Message-ID: On 17/09/2019 18:59, Stefan Claas via Gnupg-users wrote: > I assume that in order to decrypt a message the secret key data must be > unlocked and loaded for a very short time into the computers RAM, in order > to perform the decryption, or am I wrong with my assumption? OpenPGP messages encrypted to a public key are hybrid encryption: the asymmetric (public/private) crypto is used to establish a per-message shared secret. This shared secret is used by a symmetric encryption algorithm to encrypt the actual data. The smartcard does the asymmetric part of it all by itself, the computer just asks it to decrypt something and gets the per-message shared secret back from the card. Then the PC will do the symmetric decryption of the actual data. During regular use, knowledge about the private key contents never leaves the smartcard, not for the briefest period. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From dgouttegattat at incenp.org Tue Sep 17 19:16:39 2019 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Tue, 17 Sep 2019 18:16:39 +0100 Subject: Which version of GnuPG to use? In-Reply-To: <20190917185934.00004244.sac@300baud.de> References: <6f2792bf-bc77-87c4-63d9-f4d4507f1ce6@dabo.ch> <20190916234920.00002172.sac@300baud.de> <87pnjzo3sm.fsf@wheatstone.g10code.de> <20190917185934.00004244.sac@300baud.de> Message-ID: <20190917171639.dpk5wki554kncuo3@CHS-TMB-078.qmcr.qmul.ac.uk> On Tue, Sep 17, 2019 at 06:59:34PM +0200, Stefan Claas via Gnupg-users wrote: >I assume that in order to decrypt a message the secret key data must be >unlocked and loaded for a very short time into the computers RAM, in order >to perform the decryption No. The secret key data remains on the smartcard and is *not* sent to the host computer. The host computer sends the data to be decrypted to the smartcard, the smartcard does the decryption itself then sends the decrypted data back to the host. (Actually the "data" sent to the card is not an entire OpenPGP message, just the asymetrically encrypted session key which the hosts then uses to decrypt the bulk of the message. But this is a detail which does not change the fact that the host never sees the secret private key.) - Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From sac at 300baud.de Tue Sep 17 19:31:14 2019 From: sac at 300baud.de (Stefan Claas) Date: Tue, 17 Sep 2019 19:31:14 +0200 Subject: Which version of GnuPG to use? In-Reply-To: <20190917171639.dpk5wki554kncuo3@CHS-TMB-078.qmcr.qmul.ac.uk> References: <6f2792bf-bc77-87c4-63d9-f4d4507f1ce6@dabo.ch> <20190916234920.00002172.sac@300baud.de> <87pnjzo3sm.fsf@wheatstone.g10code.de> <20190917185934.00004244.sac@300baud.de> <20190917171639.dpk5wki554kncuo3@CHS-TMB-078.qmcr.qmul.ac.uk> Message-ID: <20190917193114.000026dd.sac@300baud.de> Damien Goutte-Gattat wrote: > On Tue, Sep 17, 2019 at 06:59:34PM +0200, Stefan Claas via Gnupg-users wrote: > >I assume that in order to decrypt a message the secret key data must be > >unlocked and loaded for a very short time into the computers RAM, in order > >to perform the decryption > > No. The secret key data remains on the smartcard and is *not* sent to > the host computer. The host computer sends the data to be decrypted to > the smartcard, the smartcard does the decryption itself then sends the > decrypted data back to the host. > > (Actually the "data" sent to the card is not an entire OpenPGP message, > just the asymetrically encrypted session key which the hosts then uses > to decrypt the bulk of the message. But this is a detail which does not > change the fact that the host never sees the secret private key.) > > - Damien Thank you Damien and Peter, both of your detailed replies are much appreciated! Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From wk at gnupg.org Tue Sep 17 20:04:38 2019 From: wk at gnupg.org (Werner Koch) Date: Tue, 17 Sep 2019 20:04:38 +0200 Subject: keys.openpgp.org not sending confirmation email In-Reply-To: <2YITTW8UAT56W.3DYYZMX1NSXVA@my.amazin.horse> (Vincent Breitmoser's message of "Tue, 17 Sep 2019 17:35:22 +0200") References: <875zlrlzhr.fsf@wheatstone.g10code.de> <07b77e95-57f7-9cbd-b9f4-dbeb4e395058@binarus.de> <2cf58502-9d7f-c65e-87ff-b77918450c96@binarus.de> <20190916105856.GA9285@x2.esmtp.org> <205fc2ee-a688-ea81-6627-eb03b94e51e2@binarus.de> <8736gvns6b.fsf@wheatstone.g10code.de> <2Y2WWTOHMCDY9.2H3S209XOEP5S@my.amazin.horse> <2YITTW8UAT56W.3DYYZMX1NSXVA@my.amazin.horse> Message-ID: <87impqlryh.fsf@wheatstone.g10code.de> On Tue, 17 Sep 2019 17:35, look at my.amazin.horse said: > convention or otherwise. The spec is factually wrong and misleading for > implementors in this aspect, and should be updated to reflect reality. The specs are not wrong if you would read them: | the name and email address of the key holder. *By convention*, it | includes an RFC 2822 [](#RFC2822) mail name-addr, but there are no Convention \Con*ven"tion\, n. [L. conventio: cf. F. convention. 5. An agreement or contract less formal than, or preliminary to, a treaty; an informal compact, as between commanders of armies in respect to suspension of hostilities, or between states; also, a formal agreement between governments or sovereign powers; as, a postal convention between two governments. [1913 Webster] In German "Sitte" oder "Brauch". In contrast: specification \spec`i*fi*ca"tion\ 4. A detailed listing or description of the required properties of some object proposed to be built or bought; -- usually used in the plural; as, the building specifications require that it withstand an earthquake of magnitude 8; the program specifications require an option to change the menus. [PJC] Instead of finalizing RFC4880bis, which has all its goals already implemented, some members of the WG kept on raising new items for what the WG has never been chartered. The outcome of all that mess is that implementers will simply ignore the fact that there won't be an RFC and implement the current I-D. 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 brian at minton.name Tue Sep 17 20:16:09 2019 From: brian at minton.name (Brian Minton) Date: Tue, 17 Sep 2019 14:16:09 -0400 Subject: Which version of GnuPG to use? In-Reply-To: <20190917185934.00004244.sac@300baud.de> References: <6f2792bf-bc77-87c4-63d9-f4d4507f1ce6@dabo.ch> <20190916234920.00002172.sac@300baud.de> <87pnjzo3sm.fsf@wheatstone.g10code.de> <20190917185934.00004244.sac@300baud.de> Message-ID: <881b5291-4e7e-e977-2680-32bc4c392a49@minton.name> On 9/17/19 12:59 PM, Stefan Claas via Gnupg-users wrote: > Unfortunately I am no programmer but I was thinking about the following: > I assume that in order to decrypt a message the secret key data must be > unlocked and loaded for a very short time into the computers RAM, in order > to perform the decryption, or am I wrong with my assumption? No, the decryption (of the message's session key) is performed entirely within the smart card, using the smart card's internal processor.? The session key is then in copied to the computer's main memory to perform AES or whatever symmetrical encryption the message is encrypted with.? The smart card is actually as a separate computer that performs basic? encryption on the user's behalf, while making it as difficult as possible to access the private keys. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 456 bytes Desc: OpenPGP digital signature URL: From sac at 300baud.de Tue Sep 17 21:03:39 2019 From: sac at 300baud.de (Stefan Claas) Date: Tue, 17 Sep 2019 21:03:39 +0200 Subject: Which version of GnuPG to use? In-Reply-To: <881b5291-4e7e-e977-2680-32bc4c392a49@minton.name> References: <6f2792bf-bc77-87c4-63d9-f4d4507f1ce6@dabo.ch> <20190916234920.00002172.sac@300baud.de> <87pnjzo3sm.fsf@wheatstone.g10code.de> <20190917185934.00004244.sac@300baud.de> <881b5291-4e7e-e977-2680-32bc4c392a49@minton.name> Message-ID: <20190917210339.000010ec.sac@300baud.de> Brian Minton wrote: > On 9/17/19 12:59 PM, Stefan Claas via Gnupg-users wrote: > > Unfortunately I am no programmer but I was thinking about the following: > > I assume that in order to decrypt a message the secret key data must be > > unlocked and loaded for a very short time into the computers RAM, in order > > to perform the decryption, or am I wrong with my assumption? > > > No, the decryption (of the message's session key) is performed entirely > within the smart card, using the smart card's internal processor.? The > session key is then in copied to the computer's main memory to perform > AES or whatever symmetrical encryption the message is encrypted with.? > The smart card is actually as a separate computer that performs basic? > encryption on the user's behalf, while making it as difficult as > possible to access the private keys. Thank you too, much appreciated! Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From lists at binarus.de Tue Sep 17 21:21:43 2019 From: lists at binarus.de (Binarus) Date: Tue, 17 Sep 2019 21:21:43 +0200 Subject: keys.openpgp.org not sending confirmation email In-Reply-To: <875zlrlzhr.fsf@wheatstone.g10code.de> References: <07b77e95-57f7-9cbd-b9f4-dbeb4e395058@binarus.de> <2cf58502-9d7f-c65e-87ff-b77918450c96@binarus.de> <20190916105856.GA9285@x2.esmtp.org> <205fc2ee-a688-ea81-6627-eb03b94e51e2@binarus.de> <8736gvns6b.fsf@wheatstone.g10code.de> <2Y2WWTOHMCDY9.2H3S209XOEP5S@my.amazin.horse> <875zlrlzhr.fsf@wheatstone.g10code.de> Message-ID: On 17.09.2019 17:21, Werner Koch wrote: > On Tue, 17 Sep 2019 15:08, gnupg-users at gnupg.org said: > >> See also dkg's thoughts on the matter on the openpgp-wg mailing list, to align >> the specification with reality: > > OpenPGP has never defined what goes into the User ID except for the > encoding which should be UTF-8. Anything else does not belong into the > specs unless the X.509 mess is a desired outcome. Thus the current > wording is sufficient and has served us well over the last 25 years [1]: > > | ## User ID Packet (Tag 13) > | > | A User ID packet consists of UTF-8 text that is intended to represent > | the name and email address of the key holder. By convention, it > | includes an RFC 2822 [](#RFC2822) mail name-addr, but there are no > | restrictions on its content. The packet length in the header specifies > | the length of the User ID. I totally agree that the ID in general should be encoded in UTF-8 and that there should be no further restrictions. That would have solved me from the hassle which has initiated this discussion (which, by the way, gets more and more interesting). However, just in case this discussion really leads to updates of conventions or even RFCs, I'd like to throw in the following thought: Some years ago (might be more than ten years, I really don't remember), there was an article in the well-known German computer magazine c't, written by one of Heise's long-time authors. In that article, the author complained and was really upset because some "idiots" (I am citing him here) constantly generated PGP keys with *his* email address in the ID, and uploaded those keys to all key servers they knew. Consequently, he constantly was receiving encrypted emails (probably with important content - think of him being an investigative journalist) which he could not decrypt. It was unclear if the "idiots" just wanted to bother him, if they seriously wanted to prevent sensitive material from being mailed to him, or if this was part of a greater attack on the PGP system as a whole (assuming that other journalists were suffering in a similar manner). The current policy of some key servers (including keys.openpgp.org) is to send a confirmation email to each email address which is contained in an uploaded key's ID. Although this policy probably mainly has arisen from data protection obligations, it makes the scam described above much more difficult (if it doesn't prevent it at all). Of course, a key server can only send a confirmation email if there is a valid email address in the ID of a key. Hence, a future convention / standard eventually should provide some sort of structure: One part of the ID must contain the (valid) email addresses (addr) which should be associated with the key, and another part has absolutely no restrictions, or perhaps the only restriction that the @ character is forbidden (to prevent people from smuggle in something which resembles an email address). Key servers then must send a confirmation email each time a key is uploaded (if its ID contains an address entry), and must use only the address entries (addr) to match search queries which contain the @ character. I am aware that this is similar to what we have today, i.e. to the convention described above. However, that convention, as experience shows, is interpreted differently by different software packages, and it is not mandatory. I am also aware that this would not prevent other sorts of scams. For example, an attacker could upload a key with his own correct email address in the respective ID "field", but with my name in the "free text" part. However, I believe that the overwhelming majority of people who are searching for my public key are searching by my email address (and not by my name). Perhaps Vincent has a statistic ... If there were dedicated "fields" for the address part (addr) in the ID, the complicated parsing of the name-addr wouldn't be necessary; just the addr part (i.e. each field) would have to be parsed. The rest of the ID wouldn't have to be checked, except for the absence of the @ character, which is trivial. A very simple ID structure providing that sort of "protection" which immediately came to my mind is the following: - The ID may consist of several lines, separated by LF. - Lines are not restricted in length (as long as the ID as a whole does not get too big). - A line is said to be empty if and only if it contains the LF character and no other character. - If the first line is empty, the ID does not contain an email address (addr), and the free text part of the ID starts at the second line. - If the first line is not empty, it must contain exactly one valid email address (addr), which is the first email address to be associated with the key, and all following non-empty lines must contain valid email addresses (addr) as well, one per line, which are the further email addresses to be associated with the key. That array of lines with valid email addresses (addr) is ended by an empty line. The free text part of the ID starts after that empty line. The free text part of the ID is encoded in UTF-8 and may contain any character except the @ character. Software must not generate IDs other than described above. Key servers must refuse publishing keys with IDs other than described above. Key servers must send a confirmation email to all email addresses (addr) which are in a key's ID, and must not publish an email address as being associated with a certain key until it has received an answer to the respective confirmation email. As far as I have understood, that structure could easily be put into tag 13; no new tag would have to be created (although a new tag for the email addresses (addr) would be a huge improvement). We even could allow the @ character in the free text part of the ID if the key servers would provide two different kinds of search: Search by mail address (addr) (here, the key server is only allowed to match the search string against the dedicated address entries), and search by free text (here, the key server is only allowed to match the search string against the free text part). As a final note, I am aware that many problems with scams can be prevented by mutual key signing or by publishing keys on web sites. But to be honest, I don't know many people who have their PGP / GPG keys signed by a noteworthy number of other people. Meeting others just for this purpose is painful, and validating the other party correctly is only possible with some knowledge. And of course, not every private person has a web site, and only a few companies publish more than one email address with its public key on their web site, even if they have dozens of employees with have PGP / GPG installed. Actually, I currently don't know anybody who I could ask to sign my keys, and furthermore, the problem is bigger the other way around. Can I trust the key which I found on the key server for the intended recipient's email address? Can I at least be sure that the key server has sent a confirmation email to that email address and has received the answer? Or has it failed to do so due to a malformed email address, but finds that address nevertheless because it performs a full-text search against the key IDs? So, in summary, my point is that there should be as few restrictions on the ID as possible, but it should be made sure that everything which resembles an email address (addr) and which could be found by querying a key server actually has been validated by having sent a confirmation email and having received an answer. This especially means that email addresses (addr) can't be part of surrounding free text, because parsing (and possibly removing) them from such an environment is technically complicated, implementation-wise error prone and subject to different interpretation. There is some risk that the confirmation / validation failed due to a malformed or wrongly interpreted addr, but that this addr can be found nevertheless on the key server. Therefore, we need to structure the ID so that there is one dedicated place where addrs can be stored and easily parsed, which again means to disallow them in normal free text. Just my two cents - and being happy and grateful for what we have already! Maybe it's too late - having had a long day ... Regards, Binarus From sac at 300baud.de Tue Sep 17 21:58:38 2019 From: sac at 300baud.de (Stefan Claas) Date: Tue, 17 Sep 2019 21:58:38 +0200 Subject: keys.openpgp.org not sending confirmation email In-Reply-To: References: <07b77e95-57f7-9cbd-b9f4-dbeb4e395058@binarus.de> <2cf58502-9d7f-c65e-87ff-b77918450c96@binarus.de> <20190916105856.GA9285@x2.esmtp.org> <205fc2ee-a688-ea81-6627-eb03b94e51e2@binarus.de> <8736gvns6b.fsf@wheatstone.g10code.de> <2Y2WWTOHMCDY9.2H3S209XOEP5S@my.amazin.horse> <875zlrlzhr.fsf@wheatstone.g10code.de> Message-ID: <20190917215838.00004e53.sac@300baud.de> Binarus wrote: > Actually, I currently don't know anybody who I could ask to sign my > keys, and furthermore, the problem is bigger the other way around. Can I > trust the key which I found on the key server for the intended > recipient's email address? Can I at least be sure that the key server > has sent a confirmation email to that email address and has received the > answer? Or has it failed to do so due to a malformed email address, but > finds that address nevertheless because it performs a full-text search > against the key IDs? If you would use your real name in your UID you could let Governikus certify your key. Governikus is a German CA run on behalf by the BSI. For that you will need a (certified) ID-card reader and AusweisApp2. https://pgp.governikus.de/pgp/ Regarding the other questions, it would be IMHO really nice if we would have internationally more CAs for GnuPG users, thus one must not rely on the classical WoT signatures. Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From lists at binarus.de Wed Sep 18 09:10:53 2019 From: lists at binarus.de (Binarus) Date: Wed, 18 Sep 2019 09:10:53 +0200 Subject: keys.openpgp.org not sending confirmation email In-Reply-To: <20190917215838.00004e53.sac@300baud.de> References: <07b77e95-57f7-9cbd-b9f4-dbeb4e395058@binarus.de> <2cf58502-9d7f-c65e-87ff-b77918450c96@binarus.de> <20190916105856.GA9285@x2.esmtp.org> <205fc2ee-a688-ea81-6627-eb03b94e51e2@binarus.de> <8736gvns6b.fsf@wheatstone.g10code.de> <2Y2WWTOHMCDY9.2H3S209XOEP5S@my.amazin.horse> <875zlrlzhr.fsf@wheatstone.g10code.de> <20190917215838.00004e53.sac@300baud.de> Message-ID: On 17.09.2019 21:58, Stefan Claas via Gnupg-users wrote: > Binarus wrote: > >> Actually, I currently don't know anybody who I could ask to sign my >> keys, and furthermore, the problem is bigger the other way around. Can I >> trust the key which I found on the key server for the intended >> recipient's email address? Can I at least be sure that the key server >> has sent a confirmation email to that email address and has received the >> answer? Or has it failed to do so due to a malformed email address, but >> finds that address nevertheless because it performs a full-text search >> against the key IDs? > > If you would use your real name in your UID you could let Governikus > certify your key. Governikus is a German CA run on behalf by the BSI. > > For that you will need a (certified) ID-card reader and AusweisApp2. > > https://pgp.governikus.de/pgp/ Thank you very much for that hint. That might be a solution for German citizens, and probably the citizens of a few other European countries. However, I see several problems: - People just refuse spending money or precious desk space on chip card readers. The best proof is the nonsense the German banks are currently doing to implement PSD2. I do not know anybody who has bought a chip card reader. Instead, everybody installs a TAN generator app (one for each bank) on the very same smart phone where the actual banking apps are running, which undoubtedly decreases security. - While I have no problem with one-time investments (chip card reader), my red line are regular payments. From a first quick look at the website you mentioned, I got the impression that the certification is currently free of charge. However, at a first glance, I couldn't find out how long a certification is valid, and experience tells me that they will begin to charge a substantial amount of money every year or so to refresh the certifications as soon as more than an infinitesimal number of people use them. - After the incidents at the web (SSL) CAs (Symantec, DigiNotar and so on), I do not trust any centralized certification any more, even if those incidents happened some years ago. By the way, when clicking "?ffentlicher Schl?ssel f?r die Beglaubigung" in the menu at the page bottom of https://pgp.governikus.de/pgp/, you currently just get an error page ("Es konnte leider nichts gefunden werden"). This for sure is the best way to generate trust ... Probably it's exactly what you should expect from a company which acts on behalf of German government. - The most important aspect is that I just can't force an addressee of a private message to get that certification. The addressee might live in another country where such certification is not available, or he might refuse to buy a card reader or to get the certification for other reasons. I don't have any figures (hopefully somebody else has), but I suppose that no more than 5% of PGP users have a chip card reader. In contrast, the email verification system for keys is by far less secure than the Governikus certification, but it is already available, works in every country and provides at least some level of security which is by far better than nothing. It just needs to be supported by making implementation easier, which primarily means eliminating the ambiguities when deciding what is an email address in the key IDs, which in turn means making dedicated addr entries mandatory and forbidding to treat anything outside these entries as an email address; all of this could be achieved with some small changes of the key ID convention / specification, which additionally would make parsing the key ID by key servers much more easy, less error-prone and reproducible. > Regarding the other questions, it would be IMHO really nice if we > would have internationally more CAs for GnuPG users, thus one must > not rely on the classical WoT signatures. As long as these CAs don't charge money, I totally agree with you (although I am mistrustful towards CAs as I stated above). Finally, I've got a question (no criticism, really just a question because I have absolutely no experience with AusweisApp and the like): You have stated that my real name must be in the key ID if I would like to have the key certified by Governikus. Does the key ID need to have other personal data in it? After all, as an example, there for sure are at least 1000 people in Germany whose name is "Peter Meier" (which is the reason why I personally will always use the email address (instead of the name) as the criterion when searching for a public key). If there is other personal data in the ID (like the address), what happens when people relocate? Regards, and thank you very much, Binarus From reynaldo.abeleda at nab.com.au Wed Sep 18 08:59:18 2019 From: reynaldo.abeleda at nab.com.au (Rey Abeleda) Date: Wed, 18 Sep 2019 06:59:18 +0000 Subject: C Compiler Error in AIX 5.3 During GnuPG Build Message-ID: Hi, I downloaded GnuPG and required libraries and am attempting build of the first required package npth-1.6. The ./configure step failed with the below error. configure:3552: error: in `/fin3/app/app/capplmgr/mlc-rot/gnupg/npth-1.6': configure:3554: error: C compiler cannot create executables See `config.log' for more details I looked in config.log and extracted the below excerpt that shows more details about the error. : IBM XL C/C++ Enterprise Edition for AIX, V9.0 Version: 09.00.0000.0000 configure:3463: $? = 0 configure:3483: checking whether the C compiler works configure:3505: cc $(INCLUDE_FLAGS) -U__STR__ -DAIXRIOS -DNLS_ASIA -DORE -D_BSD -DRIOS -qro -O -DAFSTUBS conftest.c >&5 cc: 1501-228 (W) input file $(INCLUDE_FLAGS) not found configure:3509: $? = 252 configure:3547: result: no configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "npth" | #define PACKAGE_TARNAME "npth" | #define PACKAGE_VERSION "1.6" | #define PACKAGE_STRING "npth 1.6" | #define PACKAGE_BUGREPORT "https://bugs.gnupg.org" | #define PACKAGE_URL "" | #define PACKAGE "npth" | #define VERSION "1.6" | /* end confdefs.h. */ | | int | main () | { | | ; | return 0; | } configure:3552: error: in `/fin3/app/app/capplmgr/mlc-rot/gnupg/npth-1.6': configure:3554: error: C compiler cannot create executables See `config.log' for more details : It seems that the key log entry here is the line: cc: 1501-228 (W) input file $(INCLUDE_FLAGS) not found I would appreciate any help/advise on how to fix this error. Thanks, Rey Reynaldo Abeleda Senior Analyst, Engineer Oracle Financials | Superannuation - Retail & Corporate | Wealth Technology National Australia Bank Level 7, 105 Miller St, North Sydney NSW 2060 ________________________________ The information contained in this email communication may be confidential. If you have received this email in error, please notify the sender by return email, delete this email and destroy any copy. Any advice contained in this email has been prepared without taking into account your objectives, financial situation or needs. Before acting on any advice in this email, National Australia Bank Limited (NAB) recommends that you consider whether it is appropriate for your circumstances. If this email contains reference to any financial products, NAB recommends you consider the Product Disclosure Statement (PDS) or other disclosure document available from NAB, before making any decisions regarding any products. If this email contains any promotional content that you do not wish to receive, please reply to the original sender and write "Don't email promotional material" in the subject. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sac at 300baud.de Wed Sep 18 17:30:47 2019 From: sac at 300baud.de (Stefan Claas) Date: Wed, 18 Sep 2019 17:30:47 +0200 Subject: keys.openpgp.org not sending confirmation email In-Reply-To: References: <07b77e95-57f7-9cbd-b9f4-dbeb4e395058@binarus.de> <2cf58502-9d7f-c65e-87ff-b77918450c96@binarus.de> <20190916105856.GA9285@x2.esmtp.org> <205fc2ee-a688-ea81-6627-eb03b94e51e2@binarus.de> <8736gvns6b.fsf@wheatstone.g10code.de> <2Y2WWTOHMCDY9.2H3S209XOEP5S@my.amazin.horse> <875zlrlzhr.fsf@wheatstone.g10code.de> <20190917215838.00004e53.sac@300baud.de> Message-ID: <20190918173047.000047b1.sac@300baud.de> Binarus wrote: > You have stated that my real name must be in the key ID if I would like > to have the key certified by Governikus. Does the key ID need to have > other personal data in it? After all, as an example, there for sure are > at least 1000 people in Germany whose name is "Peter Meier" (which is > the reason why I personally will always use the email address (instead > of the name) as the criterion when searching for a public key). If there > is other personal data in the ID (like the address), what happens when > people relocate? AusweisApp reads your personal data from your ID-card and then Governikus certifies your key, containing your real name. Your key does not need to have other personal data besides your real name. My UID for example looks like this: Stefan Claas *offline key* I know that there is as second Stefan Claas living in Germany, but he will not have the same email address like I have. So people looking up key servers could then find of course (if he would upload a key too) a second Stefan Claas. I have no expierence when one relocates, but as I see it it does not matter as long as you are a holder of a German ID-card. When in doubt always give a hint to your key in your email signature, so that people you are communicating with know the proper key to fetch. Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From lists at binarus.de Thu Sep 19 08:27:15 2019 From: lists at binarus.de (Binarus) Date: Thu, 19 Sep 2019 08:27:15 +0200 Subject: keys.openpgp.org not sending confirmation email In-Reply-To: <20190918173047.000047b1.sac@300baud.de> References: <07b77e95-57f7-9cbd-b9f4-dbeb4e395058@binarus.de> <2cf58502-9d7f-c65e-87ff-b77918450c96@binarus.de> <20190916105856.GA9285@x2.esmtp.org> <205fc2ee-a688-ea81-6627-eb03b94e51e2@binarus.de> <8736gvns6b.fsf@wheatstone.g10code.de> <2Y2WWTOHMCDY9.2H3S209XOEP5S@my.amazin.horse> <875zlrlzhr.fsf@wheatstone.g10code.de> <20190917215838.00004e53.sac@300baud.de> <20190918173047.000047b1.sac@300baud.de> Message-ID: <57cffbeb-a577-0619-3ffc-9171b8012ec2@binarus.de> On 18.09.2019 17:30, Stefan Claas via Gnupg-users wrote: > Binarus wrote: > >> You have stated that my real name must be in the key ID if I would like >> to have the key certified by Governikus. Does the key ID need to have >> other personal data in it? After all, as an example, there for sure are >> at least 1000 people in Germany whose name is "Peter Meier" (which is >> the reason why I personally will always use the email address (instead >> of the name) as the criterion when searching for a public key). If there >> is other personal data in the ID (like the address), what happens when >> people relocate? > > AusweisApp reads your personal data from your ID-card and then Governikus > certifies your key, containing your real name. Your key does not need to > have other personal data besides your real name. > > My UID for example looks like this: Stefan Claas *offline key* > > I know that there is as second Stefan Claas living in Germany, but > he will not have the same email address like I have. So people looking > up key servers could then find of course (if he would upload a key too) > a second Stefan Claas. > > I have no expierence when one relocates, but as I see it it does not matter > as long as you are a holder of a German ID-card. > > When in doubt always give a hint to your key in your email signature, > so that people you are communicating with know the proper key to fetch. OK, that makes sense. Thank you very much for the explanation. My question regarding the relocation was only meant for the case that Governikus would need other personal data besides the name (e.g. the address) in the ID to certify a key. So the real name is the only mandatory part in the ID of a key certified by Governikus, while other parts, notably the email address, are optional. Perhaps this policy is too relaxed. Personally, I always include the respective email address(es) in my keys' IDs, but some others probably don't (if they aren't forced to). IMHO, this system lacks a mandatory unique token in the key ID. The natural choice for such a token would be the email address, because in the first place it is the only thing you know for sure when writing a private message to somebody else who you haven't become acquainted with yet. Perhaps Governikus should think of making it mandatory. Regards, and thanks again, Binarus From sac at 300baud.de Thu Sep 19 12:31:48 2019 From: sac at 300baud.de (Stefan Claas) Date: Thu, 19 Sep 2019 12:31:48 +0200 Subject: keys.openpgp.org not sending confirmation email In-Reply-To: <57cffbeb-a577-0619-3ffc-9171b8012ec2@binarus.de> References: <07b77e95-57f7-9cbd-b9f4-dbeb4e395058@binarus.de> <2cf58502-9d7f-c65e-87ff-b77918450c96@binarus.de> <20190916105856.GA9285@x2.esmtp.org> <205fc2ee-a688-ea81-6627-eb03b94e51e2@binarus.de> <8736gvns6b.fsf@wheatstone.g10code.de> <2Y2WWTOHMCDY9.2H3S209XOEP5S@my.amazin.horse> <875zlrlzhr.fsf@wheatstone.g10code.de> <20190917215838.00004e53.sac@300baud.de> <20190918173047.000047b1.sac@300baud.de> <57cffbeb-a577-0619-3ffc-9171b8012ec2@binarus.de> Message-ID: <20190919123148.00000a8c.sac@300baud.de> Binarus wrote: > IMHO, this system lacks a mandatory unique token in the key ID. The > natural choice for such a token would be the email address, because in > the first place it is the only thing you know for sure when writing a > private message to somebody else who you haven't become acquainted with > yet. Perhaps Governikus should think of making it mandatory. Well, I was not clear enough, sorry! In order that Governikus can send you the signed key back it requires that you have an email address in your UID. Best regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From lists at binarus.de Fri Sep 20 08:37:02 2019 From: lists at binarus.de (Binarus) Date: Fri, 20 Sep 2019 08:37:02 +0200 Subject: keys.openpgp.org not sending confirmation email In-Reply-To: <20190919123148.00000a8c.sac@300baud.de> References: <07b77e95-57f7-9cbd-b9f4-dbeb4e395058@binarus.de> <2cf58502-9d7f-c65e-87ff-b77918450c96@binarus.de> <20190916105856.GA9285@x2.esmtp.org> <205fc2ee-a688-ea81-6627-eb03b94e51e2@binarus.de> <8736gvns6b.fsf@wheatstone.g10code.de> <2Y2WWTOHMCDY9.2H3S209XOEP5S@my.amazin.horse> <875zlrlzhr.fsf@wheatstone.g10code.de> <20190917215838.00004e53.sac@300baud.de> <20190918173047.000047b1.sac@300baud.de> <57cffbeb-a577-0619-3ffc-9171b8012ec2@binarus.de> <20190919123148.00000a8c.sac@300baud.de> Message-ID: <426bc6e2-93e3-1444-ab42-4c2931baa37a@binarus.de> On 19.09.2019 12:31, Stefan Claas via Gnupg-users wrote: > Binarus wrote: > >> IMHO, this system lacks a mandatory unique token in the key ID. The >> natural choice for such a token would be the email address, because in >> the first place it is the only thing you know for sure when writing a >> private message to somebody else who you haven't become acquainted with >> yet. Perhaps Governikus should think of making it mandatory. > > Well, I was not clear enough, sorry! In order that Governikus can send > you the signed key back it requires that you have an email address in > your UID. I see. That makes much more sense. Thank you very much again! Regards, Binarus From reynaldo.abeleda at nab.com.au Mon Sep 23 04:36:10 2019 From: reynaldo.abeleda at nab.com.au (Rey Abeleda) Date: Mon, 23 Sep 2019 02:36:10 +0000 Subject: Need Help with C Compiler Error in AIX 5.3 During GnuPG Build Message-ID: Hi, I am new to GnuPG and have recently subscribed to this mailing list to access to help from the GnuPG user community. I downloaded GnuPG and required libraries and am attempting build of the first required package npth-1.6. The ./configure step failed with the below error. configure:3552: error: in `/fin3/app/app/capplmgr/mlc-rot/gnupg/npth-1.6': configure:3554: error: C compiler cannot create executables See `config.log' for more details I looked in config.log and extracted the below excerpt that shows more details about the error. : IBM XL C/C++ Enterprise Edition for AIX, V9.0 Version: 09.00.0000.0000 configure:3463: $? = 0 configure:3483: checking whether the C compiler works configure:3505: cc $(INCLUDE_FLAGS) -U__STR__ -DAIXRIOS -DNLS_ASIA -DORE -D_BSD -DRIOS -qro -O -DAFSTUBS conftest.c >&5 cc: 1501-228 (W) input file $(INCLUDE_FLAGS) not found configure:3509: $? = 252 configure:3547: result: no configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "npth" | #define PACKAGE_TARNAME "npth" | #define PACKAGE_VERSION "1.6" | #define PACKAGE_STRING "npth 1.6" | #define PACKAGE_BUGREPORT "https://bugs.gnupg.org" | #define PACKAGE_URL "" | #define PACKAGE "npth" | #define VERSION "1.6" | /* end confdefs.h. */ | | int | main () | { | | ; | return 0; | } configure:3552: error: in `/fin3/app/app/capplmgr/mlc-rot/gnupg/npth-1.6': configure:3554: error: C compiler cannot create executables See `config.log' for more details : It seems that the key log entry here is the line: cc: 1501-228 (W) input file $(INCLUDE_FLAGS) not found I would appreciate any help/advise on how to fix this error. Thanks, Rey Reynaldo Abeleda Senior Analyst, Engineer Oracle Financials | Superannuation - Retail & Corporate | Wealth Technology National Australia Bank Level 7, 105 Miller St, North Sydney NSW 2060 ________________________________ The information contained in this email communication may be confidential. If you have received this email in error, please notify the sender by return email, delete this email and destroy any copy. Any advice contained in this email has been prepared without taking into account your objectives, financial situation or needs. Before acting on any advice in this email, National Australia Bank Limited (NAB) recommends that you consider whether it is appropriate for your circumstances. If this email contains reference to any financial products, NAB recommends you consider the Product Disclosure Statement (PDS) or other disclosure document available from NAB, before making any decisions regarding any products. If this email contains any promotional content that you do not wish to receive, please reply to the original sender and write "Don't email promotional material" in the subject. -------------- next part -------------- An HTML attachment was scrubbed... URL: From reynaldo.abeleda at nab.com.au Mon Sep 23 04:06:25 2019 From: reynaldo.abeleda at nab.com.au (Rey Abeleda) Date: Mon, 23 Sep 2019 02:06:25 +0000 Subject: Need Help with C Compiler Error in AIX 5.3 During GnuPG Build Message-ID: Hi, I am new to GnuPG and have recently subscribed to this mailing list to access to help from the GnuPG user community. I downloaded GnuPG and required libraries and am attempting build of the first required package npth-1.6. The ./configure step failed with the below error. configure:3552: error: in `/fin3/app/app/capplmgr/mlc-rot/gnupg/npth-1.6': configure:3554: error: C compiler cannot create executables See `config.log' for more details I looked in config.log and extracted the below excerpt that shows more details about the error. : IBM XL C/C++ Enterprise Edition for AIX, V9.0 Version: 09.00.0000.0000 configure:3463: $? = 0 configure:3483: checking whether the C compiler works configure:3505: cc $(INCLUDE_FLAGS) -U__STR__ -DAIXRIOS -DNLS_ASIA -DORE -D_BSD -DRIOS -qro -O -DAFSTUBS conftest.c >&5 cc: 1501-228 (W) input file $(INCLUDE_FLAGS) not found configure:3509: $? = 252 configure:3547: result: no configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "npth" | #define PACKAGE_TARNAME "npth" | #define PACKAGE_VERSION "1.6" | #define PACKAGE_STRING "npth 1.6" | #define PACKAGE_BUGREPORT "https://bugs.gnupg.org" | #define PACKAGE_URL "" | #define PACKAGE "npth" | #define VERSION "1.6" | /* end confdefs.h. */ | | int | main () | { | | ; | return 0; | } configure:3552: error: in `/fin3/app/app/capplmgr/mlc-rot/gnupg/npth-1.6': configure:3554: error: C compiler cannot create executables See `config.log' for more details : It seems that the key log entry here is the line: cc: 1501-228 (W) input file $(INCLUDE_FLAGS) not found I would appreciate any help/advise on how to fix this error. Thanks, Rey Reynaldo Abeleda Senior Analyst, Engineer Oracle Financials | Superannuation - Retail & Corporate | Wealth Technology National Australia Bank Level 7, 105 Miller St, North Sydney NSW 2060 ________________________________ The information contained in this email communication may be confidential. If you have received this email in error, please notify the sender by return email, delete this email and destroy any copy. Any advice contained in this email has been prepared without taking into account your objectives, financial situation or needs. Before acting on any advice in this email, National Australia Bank Limited (NAB) recommends that you consider whether it is appropriate for your circumstances. If this email contains reference to any financial products, NAB recommends you consider the Product Disclosure Statement (PDS) or other disclosure document available from NAB, before making any decisions regarding any products. If this email contains any promotional content that you do not wish to receive, please reply to the original sender and write "Don't email promotional material" in the subject. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Mon Sep 23 17:52:05 2019 From: wk at gnupg.org (Werner Koch) Date: Mon, 23 Sep 2019 17:52:05 +0200 Subject: Need Help with C Compiler Error in AIX 5.3 During GnuPG Build In-Reply-To: (Rey Abeleda via Gnupg-users's message of "Mon, 23 Sep 2019 02:36:10 +0000") References: Message-ID: <87k19z104a.fsf@wheatstone.g10code.de> On Mon, 23 Sep 2019 02:36, gnupg-users at gnupg.org said: > configure:3554: error: C compiler cannot create executables configure does an early test to see whether your C compiler works. This is done to detect crippled compilers delivered on some systems. Seems not the case here, though. > configure:3505: cc $(INCLUDE_FLAGS) -U__STR__ -DAIXRIOS -DNLS_ASIA > -DORE -D_BSD -DRIOS -qro -O -DAFSTUBS conftest.c >&5 > cc: 1501-228 (W) input file $(INCLUDE_FLAGS) not found ... $(INCLUDE_FLAGS) looks like a make macro and definitely does not belong here. Check whether you have set any of CFLAGS, CPPFLAGS, LDFLAGS set in your environment or whether the envvar CC specifies these flags. It is also possible that cc is shell script or other wrapper which invokes the real CC; check for uncommon things in your PATH. 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 robert.knutson at randstadglobalit.com Mon Sep 23 19:41:57 2019 From: robert.knutson at randstadglobalit.com (Robert Knutson) Date: Mon, 23 Sep 2019 13:41:57 -0400 Subject: Upgrade query In-Reply-To: References: Message-ID: We're currently running 1.4.7 and want to install and use gpg on a new server. I was hoping to install one of the latest 2.2.1.7 perhaps... Can someone tell me if that is even possible? I was hoping to just install the new one and then move my /.gnupg dir over there rock-n-roll.. Are these version compatible or do we need to just install that same old version? > -- The information contained in this e-mail communication is solely intended for the person/legal person to whom it ?has been sent, and as it may contain information of a personal or confidential nature, it may not be made public by virtue of law, regulations or agreement. If someone other than the intended recipient should receive or come into possession of this e-mail communication, he/she will not be entitled to read, disseminate, disclose or duplicate it. If you are not the intended recipient, you are requested to inform the sender of this e-mail message of this immediately, and to destroy the original e-mail communication. Neither Randstad N.V. nor its subsidiaries accept any liability for incorrect and incomplete transmission or delayed receipt of this e-mail. Randstad N.V. HR Amsterdam no.33216172 -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.knutson at randstadglobalit.com Mon Sep 23 19:34:21 2019 From: robert.knutson at randstadglobalit.com (Robert Knutson) Date: Mon, 23 Sep 2019 13:34:21 -0400 Subject: gnupg-2.2.17 install errors Message-ID: I am STILL getting the same errrors with the "configure" (missing libs) libgpg-error, libgcrypt, libassuan, libksba & npth even AFTER I installed each of them.... Is this a link issue of some kind? configure: *** *** You need libgpg-error to build this program. ** This library is for example available at *** https://gnupg.org/ftp/gcrypt/libgpg-error *** (at least version 1.24 is required.) *** configure: *** *** You need libgcrypt to build this program. ** This library is for example available at *** https://gnupg.org/ftp/gcrypt/libgcrypt/ *** (at least version 1.7.0 (API 1) is required.) *** configure: *** *** You need libassuan to build this program. *** This library is for example available at *** https://gnupg.org/ftp/gcrypt/libassuan/ *** (at least version 2.5.0 (API 2) is required). *** configure: *** *** You need libksba to build this program. *** This library is for example available at *** https://gnupg.org/ftp/gcrypt/libksba/ *** (at least version 1.3.4 using API 1 is required). *** configure: *** *** It is now required to build with support for the *** New Portable Threads Library (nPth). Please install this *** library first. The library is for example available at *** https://gnupg.org/ftp/gcrypt/npth/ *** (at least version 1.2 (API 1) is required). *** configure: error: *** *** Required libraries not found. Please consult the above messages *** and install them before running configure again. *** As far as I can tell they are all there as you see below...... # ls -ltr /usr/local/lib/ total 16088 -rwxr-xr-x 1 root system 158316 Sep 23 11:00 libnpth.a -rwxr-xr-x 1 root system 914 Sep 23 11:00 libnpth.la -rwxr-xr-x 1 root system 994985 Sep 23 11:58 libgpg-error.a -rwxr-xr-x 1 root system 939 Sep 23 11:58 libgpg-error.la -rwxr-xr-x 1 root system 5129134 Sep 23 12:34 libgcrypt.a -rwxr-xr-x 1 root system 972 Sep 23 12:34 libgcrypt.la -rwxr-xr-x 1 root system 796166 Sep 23 12:36 libassuan.a -rwxr-xr-x 1 root system 970 Sep 23 12:36 libassuan.la drwxr-xr-x 2 root system 256 Sep 23 12:36 pkgconfig -rwxr-xr-x 1 root system 1128722 Sep 23 12:38 libksba.a -rwxr-xr-x 1 root system 962 Sep 23 12:38 libksba.la # -- The information contained in this e-mail communication is solely intended for the person/legal person to whom it ?has been sent, and as it may contain information of a personal or confidential nature, it may not be made public by virtue of law, regulations or agreement. If someone other than the intended recipient should receive or come into possession of this e-mail communication, he/she will not be entitled to read, disseminate, disclose or duplicate it. If you are not the intended recipient, you are requested to inform the sender of this e-mail message of this immediately, and to destroy the original e-mail communication. Neither Randstad N.V. nor its subsidiaries accept any liability for incorrect and incomplete transmission or delayed receipt of this e-mail. Randstad N.V. HR Amsterdam no.33216172 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Tue Sep 24 03:54:37 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 23 Sep 2019 21:54:37 -0400 Subject: Upgrade query In-Reply-To: References: Message-ID: Please send your email as plain text, not HTML. > We're currently running 1.4.7 and want to install and use gpg on a new > server.? I was hoping to install one of the latest 2.2.1.7 perhaps... > Can someone tell me if that is even possible?? I was hoping to just > install the new one and then move my /.gnupg dir over there > rock-n-roll..? ? Are these version compatible or do we need to just > install that same old version? Migrating from 1.4 to 2.2 is not quite *that* simple, but it isn't hard. A while ago I put together some detailed how-to notes: let me dig them up and I'll get back to you. Some people will tell you that yes, you can just install-and-go. It's certainly possible to *for some users*, but there are corner cases that can complicate things -- which is why a checklist is useful. From rjh at sixdemonbag.org Tue Sep 24 04:53:31 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 23 Sep 2019 22:53:31 -0400 Subject: Upgrade query In-Reply-To: References: Message-ID: > Migrating from 1.4 to 2.2 is not quite *that* simple, but it isn't hard. > A while ago I put together some detailed how-to notes: let me dig them > up and I'll get back to you. Can't immediately find them, but here goes. This is a bit of a process but it will leave you with a fresh, clean GnuPG 2.2 directory with all of your GnuPG 1.4 data intact. And it should also cover the vast majority of the odd corner cases, too. 1. Start by backing up your ~/.gnupg directory. We're going to be nuking, paving, and rebuilding. Don't skip this, as there will be files in here you'll definitely need. 2. Get a list of every ultimately-trusted key on your keyring. I do this with standard command-line tools: $ gpg --fixed-list-mode --with-colons --list-keys | \ grep "^pub:u:" | cut -d ":" -f 5 > ~/trusted_keys.txt 3. Export your entire public and private keyrings. $ gpg --export-options export-local-sigs,export-sensitive-revkeys \ --export > ~/pubkeys.gpg $ gpg --export-secret-keys > ~/privkeys.gpg 4. Kill gpg-agent. $ killall gpg-agent 4. Empty the ~/.gnupg dir. $ rm -rf ~/.gnupg/* 5. From the backup you made in step 1, restore the following files. (You may not have all of them. If you're missing some, or even most, that's okay.) dirmngr.conf dirmngr.conf-1 dirmngr.conf-1.4 gpa.conf (no -1, -1.4 variants exist) gpg.conf gpg.conf-1 gpg.conf-1.4 gpg-agent.conf gpg-agent.conf-1 gpg-agent.conf-1.4 gpgsm.conf gpgsm.conf-1 gpgsm.conf-1.4 policies.txt scdaemon.conf scdaemon.conf-1 scdaemon.conf-1.4 scd-event sshcontrol trustlist.txt 6. Look in your new ~/.gnupg dir for GnuPG 1.4-specific configuration files: $ ls ~/.gnupg/*.conf-1* Then look for unversioned configuration files: $ ls ~/.gnupg/*.conf If you have, e.g., a gpg.conf-1 file but not a gpg.conf file, make a new unversioned file out of the old one. E.g., $ cp ~/.gnupg/gpg.conf-1 ~/.gnupg/gpg.conf 7. Import your secret keys into gpg2: $ gpg2 --import ~/sec.gpg $ gpg2 --import-options import-local-sigs,import-clean \ --import ~/pub.gpg 8. Mark your previously ultimate-trusted keys as ultimate-trusted again. For each key in your ~/trusted_keys.txt file, $ gpg2 --edit-key [insert key ID here] trust Set each trust to ultimate by typing '5'. ... You should be done! From reynaldo.abeleda at nab.com.au Tue Sep 24 08:21:37 2019 From: reynaldo.abeleda at nab.com.au (Rey Abeleda) Date: Tue, 24 Sep 2019 06:21:37 +0000 Subject: Request Help with: Error During make of libgpg-error-1.36 with compiling gpg-error.c Message-ID: Hello, After a successful ./configure of libgpg-error-1.36, the subsequent make failed with the error below. capplmgr at orafind: /fin3/app/app/capplmgr/mlc-rot/gnupg/libgpg-error-1.36> make make all-recursive Making all in m4 Target "all" is up to date. Making all in src make all-am source='gpg-error.c' object='gpg_error-gpg-error.o' libtool=no DEPDIR=.deps depmode=xlc /bin/sh ../build-aux/depcomp cc -qlanglvl=extc89 -DHAVE_CONFIG_H -I. -I.. -DPKGDATADIR=\"/usr/local/share/libgpg-error\" -DLOCALEDIR=\"/usr/local/share/locale\" -D_THREAD_SAFE -g -c -o gpg_error-gpg-error.o `test -f 'gpg-error.c' || echo './'`gpg-error.c "gpg-error.c", line 497.1: 1506-191 (E) The character # is not a valid C source character. "gpg-error.c", line 497.2: 1506-275 (S) Unexpected text 'if' encountered. "gpg-error.c", line 499.1: 1506-191 (E) The character # is not a valid C source character. "gpg-error.c", line 501.1: 1506-191 (E) The character # is not a valid C source character. "gpg-error.c", line 498.17: 1506-277 (S) Syntax error: possible missing ')' or ','? "gpg-error.c", line 496.5: 1506-045 (S) Undeclared identifier HAVE_W32_SYSTEM. make: 1254-004 The error code from the last command is 1. Stop. make: 1254-004 The error code from the last command is 2. Stop. make: 1254-004 The error code from the last command is 1. Stop. make: 1254-004 The error code from the last command is 2. Stop. I had a look inside the source src/gpg-error.c in the vicinity of lines 497 to 501. Below is a code snippet. I am not a C developer but it seems to me that the 4th call to ARGPARSE_c below which I've highlighted in RED is incorrect C code. +480 main (int argc, char *argv[]) +481 { +482 enum { CMD_DEFAULT = 0, +483 CMD_LIB_VERSION = 501, +484 CMD_LIST, +485 CMD_DEFINES, +486 CMD_LOCALE, +487 OPT_DESC +488 }; +489 static gpgrt_opt_t opts[] = { +490 ARGPARSE_c (CMD_LIB_VERSION, "lib-version", +491 "Print library version"), +492 ARGPARSE_c (CMD_LIST, "list", +493 "Print all error codes"), +494 ARGPARSE_c (CMD_DEFINES, "defines", +495 "Print all error codes as #define lines"), +496 ARGPARSE_c (CMD_LOCALE, "locale", +497 #if HAVE_W32_SYSTEM +498 "Return the locale used for gettext" +499 #else +500 "@" +501 #endif +502 ), +503 ARGPARSE_s_n (OPT_DESC, "desc", +504 "Print with error description"), +505 ARGPARSE_end() +506 }; +507 gpgrt_argparse_t pargs = { &argc, &argv }; Would appreciate any advise on how to fix this error. Thanks, Reynaldo Abeleda Senior Analyst, Engineer Oracle Financials | Superannuation - Retail & Corporate | Wealth Technology National Australia Bank ________________________________ The information contained in this email communication may be confidential. If you have received this email in error, please notify the sender by return email, delete this email and destroy any copy. Any advice contained in this email has been prepared without taking into account your objectives, financial situation or needs. Before acting on any advice in this email, National Australia Bank Limited (NAB) recommends that you consider whether it is appropriate for your circumstances. If this email contains reference to any financial products, NAB recommends you consider the Product Disclosure Statement (PDS) or other disclosure document available from NAB, before making any decisions regarding any products. If this email contains any promotional content that you do not wish to receive, please reply to the original sender and write "Don't email promotional material" in the subject. -------------- next part -------------- An HTML attachment was scrubbed... URL: From reynaldo.abeleda at nab.com.au Tue Sep 24 08:07:21 2019 From: reynaldo.abeleda at nab.com.au (Rey Abeleda) Date: Tue, 24 Sep 2019 06:07:21 +0000 Subject: Need Help with C Compiler Error in AIX 5.3 During GnuPG Build In-Reply-To: <87k19z104a.fsf@wheatstone.g10code.de> References: <87k19z104a.fsf@wheatstone.g10code.de> Message-ID: Hi Werner, You hit the nail on the head. Looks like CFLAGS was indeed set by another script that is run automatically after login. After ensuring that script is not run. The compile error I was experience went away. Thanks very much for your help. Regards, Reynaldo Abeleda Senior Analyst, Engineer Oracle Financials | Superannuation - Retail & Corporate | Wealth Technology National Australia Bank -----Original Message----- From: Werner Koch [mailto:wk at gnupg.org] Sent: Tuesday, 24 September 2019 1:52 AM To: Rey Abeleda via Gnupg-users Cc: Rey Abeleda Subject: Re: Need Help with C Compiler Error in AIX 5.3 During GnuPG Build On Mon, 23 Sep 2019 02:36, gnupg-users at gnupg.org said: > configure:3554: error: C compiler cannot create executables configure does an early test to see whether your C compiler works. This is done to detect crippled compilers delivered on some systems. Seems not the case here, though. > configure:3505: cc $(INCLUDE_FLAGS) -U__STR__ -DAIXRIOS -DNLS_ASIA > -DORE -D_BSD -DRIOS -qro -O -DAFSTUBS conftest.c >&5 > cc: 1501-228 (W) input file $(INCLUDE_FLAGS) not found ... $(INCLUDE_FLAGS) looks like a make macro and definitely does not belong here. Check whether you have set any of CFLAGS, CPPFLAGS, LDFLAGS set in your environment or whether the envvar CC specifies these flags. It is also possible that cc is shell script or other wrapper which invokes the real CC; check for uncommon things in your PATH. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. The information contained in this email and its attachments may be confidential. If you have received this email in error, please notify the sender by return email, delete this email and destroy any copy. Any advice contained in this email has been prepared without taking into account your objectives, financial situation or needs. Before acting on any advice in this email, National Australia Bank Limited (NAB) recommends that you consider whether it is appropriate for your circumstances. If this email contains reference to any financial products, NAB recommends you consider the Product Disclosure Statement (PDS) or other disclosure document available from NAB, before making any decisions regarding any products. If this email contains any promotional content that you do not wish to receive, please reply to the original sender and write "Don't email promotional material" in the subject. From huebener at gmail.com Wed Sep 25 12:44:02 2019 From: huebener at gmail.com (=?utf-8?Q?Robert_H=C3=BCbener?=) Date: Wed, 25 Sep 2019 12:44:02 +0200 Subject: ed25519 and sha256 Message-ID: Hello, I have a question regarding ed25519 as implemented in gnupg 2.2.17, libgcrypt 1.8.4. Let?s say I sign a file. When checking the signature with verbose output, I can see that sha256 was used gpg: binary signature, digest algorithm SHA256, key algorithm ed25519 According to Wikipedia "Ed25519 is the EdDSA signature scheme using SHA-512 and Curve25519?. Granted, I have sha256 in my preferences, but the standard should override that, correct? I wonder, because in a different application (iPGMail) using the same key with the same embedded preferences, sha512 is used. Curious, RH From rjh at sixdemonbag.org Wed Sep 25 22:35:50 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 25 Sep 2019 16:35:50 -0400 Subject: ed25519 and sha256 In-Reply-To: References: Message-ID: <204df18b-a326-221d-7c31-a13f4e94b2e3@sixdemonbag.org> > According to Wikipedia "Ed25519 is the EdDSA signature scheme using > SHA-512 and Curve25519?. Granted, I have sha256 in my preferences, > but the standard should override that, correct? Wikipedia is not a very good reference for low-level technical details. Ed25519 is shorthand for "EdDSA on a specific curve": it is silent on the subject of hash algorithms, although you can specify one as "Ed25519-SHA-512" or what-have-you. Many other applications, such as DNSSEC, call for SHA-256 to be used with Ed25519. >From the original paper defining Ed25519: "Our recommended curve for EdDSA is a twisted Edwards curve birationally equivalent to the curve Curve25519 from [12]. ... We use the name Ed25519 for EdDSA with this particular choice of curve. Specifically, Ed25519-SHA-512 is EdDSA with ... SHA-512." https://ed25519.cr.yp.to/ed25519-20110926.pdf From wk at gnupg.org Thu Sep 26 09:59:15 2019 From: wk at gnupg.org (Werner Koch) Date: Thu, 26 Sep 2019 09:59:15 +0200 Subject: ed25519 and sha256 In-Reply-To: <204df18b-a326-221d-7c31-a13f4e94b2e3@sixdemonbag.org> (Robert J. Hansen's message of "Wed, 25 Sep 2019 16:35:50 -0400") References: <204df18b-a326-221d-7c31-a13f4e94b2e3@sixdemonbag.org> Message-ID: <87v9tfwkrw.fsf@wheatstone.g10code.de> On Wed, 25 Sep 2019 16:35, rjh at sixdemonbag.org said: > Wikipedia is not a very good reference for low-level technical details. > Ed25519 is shorthand for "EdDSA on a specific curve": it is silent on > the subject of hash algorithms, although you can specify one as > "Ed25519-SHA-512" or what-have-you. Not quite true. We use ed25519 with SHA-512. However, what we sign is a hash value which often commonly happens to be a SHA-256 hash. The reasons for this is that this model better fits into the OpenPGP framework and - more important - this indirection allows us to implement ed25519/sha512 in a smartcard. Consider the case that you want to sign a large data blob with a smartcard: With the direct ed25519 method it would be required to send the entire data to the smartcard which would take way to long for any practical application. Smardcards communicate in the 300 kBit/sec range and even USB tokens or not much faster. Further they employ small 16 bit CPUs where taking a SHA-512 hash on a lot of data will take ages. 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 cameron at cameronelliott.com Thu Sep 26 08:53:32 2019 From: cameron at cameronelliott.com (Cameron Elliott) Date: Wed, 25 Sep 2019 23:53:32 -0700 Subject: ssh-add like behavior with gpg? Message-ID: Please CC me directly on the response. Okay, I am new, but I have read the FAQ and looked at the archive, but can't figure this out. I am using gpg 2.2.4 I am trying to use Apache sops, and I have a little experience with 'pass' and gpg 2 now. My issue is this: if I run $ sops -d file.yml And my pass phrase is not in the cache, the sops command will fail, which is okay, and understandable. There are two ways I know how to get the pass phrase into the cache: 1. pass abcd or 2. gpg -s >/dev/null dummy_file Both those cases will prompt for the passphrase and cache it for a while. But isn't there a more intuitive command to prompt for my pass phrase and cache it for a while? Something like 'ssh-add', where I just get asked for my pass phrase and it gets cached? Thanks in advance for any ideas. Cameron -------------- next part -------------- An HTML attachment was scrubbed... URL: From guru at unixarea.de Sun Sep 29 10:27:20 2019 From: guru at unixarea.de (Matthias Apitz) Date: Sun, 29 Sep 2019 10:27:20 +0200 Subject: unknown modified files in GNUPGHOME Message-ID: <20190929082720.GA2977@c720-r342378> Hello, While doing a backup of my $HOME it turned out (what I never saw before), that some file were changed in GNUPGHOME: -rw------- 1 guru wheel 157316 21 sept. 10:07 .gnupg-ccid/pubring.kbx -rw------- 1 guru wheel 155467 21 sept. 10:07 .gnupg-ccid/pubring.kbx~ drwx------ 2 guru wheel 1024 21 sept. 10:08 .gnupg-ccid/crls.d/ -rw------- 1 guru wheel 3997 21 sept. 10:08 .gnupg-ccid/crls.d/DIR.txt -rw------- 1 guru wheel 17715895 21 sept. 10:08 .gnupg-ccid/crls.d/crl-CDECFDC58640B7262B39CCB59B61E8EEFF2ED4D0.db All more or less at the same moment. Any ideas what could have caused this? Thanks matthias -- Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub Mientras haya voluntad de lucha habr? esperanza de vencer. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From wk at gnupg.org Sun Sep 29 19:30:26 2019 From: wk at gnupg.org (Werner Koch) Date: Sun, 29 Sep 2019 19:30:26 +0200 Subject: unknown modified files in GNUPGHOME In-Reply-To: <20190929082720.GA2977@c720-r342378> (Matthias Apitz's message of "Sun, 29 Sep 2019 10:27:20 +0200") References: <20190929082720.GA2977@c720-r342378> Message-ID: <87sgofui19.fsf@wheatstone.g10code.de> On Sun, 29 Sep 2019 10:27, guru at unixarea.de said: > Hello, > > While doing a backup of my $HOME it turned out (what I never saw > before), that some file were changed in GNUPGHOME: > > -rw------- 1 guru wheel 157316 21 sept. 10:07 .gnupg-ccid/pubring.kbx > -rw------- 1 guru wheel 155467 21 sept. 10:07 .gnupg-ccid/pubring.kbx~ The usual backup file without the last edit. gpg writes to a new file, renames the old file to *~, and then renames the new file to the original file. > drwx------ 2 guru wheel 1024 21 sept. 10:08 .gnupg-ccid/crls.d/ > -rw------- 1 guru wheel 3997 21 sept. 10:08 .gnupg-ccid/crls.d/DIR.txt > -rw------- 1 guru wheel 17715895 21 sept. 10:08 > .gnupg-ccid/crls.d/crl-CDECFDC58640B7262B39CCB59B61E8EEFF2ED4D0.db Some CRL was updated. CRLs are downloaded after the have expired, verified and the content then stored in a constant database (tinycdb) for index access to the entries. 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 aajaxx at gmail.com Sun Sep 29 19:29:21 2019 From: aajaxx at gmail.com (Ajax) Date: Sun, 29 Sep 2019 17:29:21 +0000 Subject: gpg WARNING server gpg-agent is older than us Message-ID: Hi The warning: gpg: WARNING: server 'gpg-agent' is older than us comes from gpg v 2.2.17 installed using the speedo build. $ gpg-agent --version gpg-agent: relocation error: gpg-agent: symbol assuan_sock_set_system_hooks, version LIBASSUAN_1.0 not defined in file libassuan.so.0 with link time reference PLAY/build/libassuan/src/.libs/alibassuan.so.0 -> libassuan.so.0.8.3 Contains: /==== This is Libassuan 2.5.3 - The GnuPG IPC Library Copyright 2001-2013 Free Software Foundation, Inc. Copyright 2001-2019 g10 Code GmbH SPDX-License-Identifier: LGPL-2.1-or-later (4de3154 ) \==== Is there a time reference there or elsewhere? What else should I be looking for? Thank you --ajax --- From siemons at cleanfuels.nl Mon Sep 30 10:58:09 2019 From: siemons at cleanfuels.nl (Roland Siemons) Date: Mon, 30 Sep 2019 10:58:09 +0200 Subject: We have GOT TO make things simpler In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From siemons at cleanfuels.nl Mon Sep 30 15:43:15 2019 From: siemons at cleanfuels.nl (Roland Siemons) Date: Mon, 30 Sep 2019 15:43:15 +0200 Subject: We have GOT TO make things simpler In-Reply-To: References: Message-ID: Dear GNUPG developers, We have GOT TO make things simpler. 1/ I do have some years of experience with GnuPG. Especially with convincing people to use it. It is not easy. But I do it because it is in my interest to be able to communicate privately. 2/ My latest experience is with a person who sent me his entire keypair per email. I had asked him to send me his public key only. I had instructed him how to prepare that file ("export public key, do NOT export the secret half of the keypair. Ensure this by ticking the right boxes. If you use GPA do it like this, if you use Kleopatra, follow those menu trails, if you use GPG Tools I do not know."). The person who made the horror of sending his secret key over email is properly educated. 3/ Please do appreciate that the persons who we are convincing and instructing are not particularly interested in privacy. They need simple approaches. 4/ Here is my proposal: 4.1/ Stimulate that people use a GUI like GPA or Kleopatra. Not Enigmail, although it offers the same, but it offers too much for beginners. Email integration comes after people have a basic understanding. Please do appreciate if people only want to be able to prepare encrypted documents for sending them as attachments. 4.2/ Ensure that, when generating a keypair, GnuPG creates one directory "Secretkeys", and one directory "Publickeys". Make GnuPG to store the public part and the secret part separately in those directories. If GnuPG needs also keypairs in a single file, store that under Secretkeys. 4.3/ Get rid of the confusing menu/Exportkeys/ vs menu/Exportsecretkey. etc. 4.5/ Get rid of the options to NOT publish keys on keyservers. Just work the opt-in alternative: If you want to publish to keyservers, make that a separate action that requires some effort. Best regards, Roland From sac at 300baud.de Mon Sep 30 16:45:23 2019 From: sac at 300baud.de (Stefan Claas) Date: Mon, 30 Sep 2019 16:45:23 +0200 Subject: We have GOT TO make things simpler In-Reply-To: References: Message-ID: <20190930164523.00006234.sac@300baud.de> Roland Siemons wrote: > Dear GNUPG developers, > > We have GOT TO make things simpler. > > 1/ I do have some years of experience with GnuPG. Especially with > convincing people to use it. It is not easy. But I do it because it is > in my interest to be able to communicate privately. > 2/ My latest experience is with a person who sent me his entire keypair > per email. I had asked him to send me his public key only. I had > instructed him how to prepare that file ("export public key, do NOT > export the secret half of the keypair. Ensure this by ticking the right > boxes. If you use GPA do it like this, if you use Kleopatra, follow > those menu trails, if you use GPG Tools I do not know."). The person who > made the horror of sending his secret key over email is properly educated. > 3/ Please do appreciate that the persons who we are convincing and > instructing are not particularly interested in privacy. They need simple > approaches. Maybe you can convince your friends to use Mailvelope or the new AutoCrypt from Vincent (who brought us Hagrid). Both are OpenPGP apps, and no longer require GnuPG and therefore should it make easier for your friends to use. Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From sac at 300baud.de Mon Sep 30 16:55:59 2019 From: sac at 300baud.de (Stefan Claas) Date: Mon, 30 Sep 2019 16:55:59 +0200 Subject: We have GOT TO make things simpler In-Reply-To: <20190930164523.00006234.sac@300baud.de> References: <20190930164523.00006234.sac@300baud.de> Message-ID: <20190930165559.000034f7.sac@300baud.de> Stefan Claas via Gnupg-users wrote: > Roland Siemons wrote: > > > Dear GNUPG developers, > > > > We have GOT TO make things simpler. > > > > 1/ I do have some years of experience with GnuPG. Especially with > > convincing people to use it. It is not easy. But I do it because it is > > in my interest to be able to communicate privately. > > 2/ My latest experience is with a person who sent me his entire keypair > > per email. I had asked him to send me his public key only. I had > > instructed him how to prepare that file ("export public key, do NOT > > export the secret half of the keypair. Ensure this by ticking the right > > boxes. If you use GPA do it like this, if you use Kleopatra, follow > > those menu trails, if you use GPG Tools I do not know."). The person who > > made the horror of sending his secret key over email is properly educated. > > 3/ Please do appreciate that the persons who we are convincing and > > instructing are not particularly interested in privacy. They need simple > > approaches. > > Maybe you can convince your friends to use Mailvelope or the new AutoCrypt > from Vincent (who brought us Hagrid). Both are OpenPGP apps, and no longer > require GnuPG and therefore should it make easier for your friends to use. > > Regards > Stefan > Forgot the links, sorry ... Mailvelope: https://www.mailvelope.com/en/ Key server for Mailvelope: https://keys.mailvelope.com/ Autocrypt for Thunderbird: Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From jrallen at runbox.com Mon Sep 30 16:38:36 2019 From: jrallen at runbox.com (Jeff Allen) Date: Mon, 30 Sep 2019 10:38:36 -0400 Subject: We have GOT TO make things simpler In-Reply-To: References: Message-ID: <29e0ec32-f1f2-7e2a-fa95-cdbdfbde1059@runbox.com> On 9/30/19 4:58 AM, Roland Siemons wrote: > Dear GNUPG developers, > > We have GOT TO make things simpler. > 3/ Please do appreciate that the persons who we are convincing and > instructing are not particularly interested in privacy. They need simple > approaches. ProtonMail or Tutanota. Both ensure far more privacy and security than Gmail. Both offer free accounts and smartphone apps. If you need to communicate privately with someone, have them get an account. > 4/ Here is my proposal: > 4.1/ Stimulate that people use a GUI like GPA or Kleopatra. Not > Enigmail, although it offers the same, but it offers too much for > beginners. Email integration comes after people have a basic > understanding. Please do appreciate if people only want to be able to > prepare encrypted documents for sending them as attachments. Few people not particularly interested in privacy are going to adopt a solution requiring selecting, cutting, encrypting and pasting text. If they already use Thunderbird, Enigmail is an easy enough to learn. The real stumbling block is that most people don't do email using Thunderbird or any MUA. Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From dclarke at blastwave.org Mon Sep 30 21:32:19 2019 From: dclarke at blastwave.org (Dennis Clarke) Date: Mon, 30 Sep 2019 15:32:19 -0400 Subject: We have GOT TO make things simpler In-Reply-To: <29e0ec32-f1f2-7e2a-fa95-cdbdfbde1059@runbox.com> References: <29e0ec32-f1f2-7e2a-fa95-cdbdfbde1059@runbox.com> Message-ID: > Few people not particularly interested in privacy are going to adopt a > solution requiring selecting, cutting, encrypting and pasting text. If > they already use Thunderbird, Enigmail is an easy enough to learn. The > real stumbling block is that most people don't do email using > Thunderbird or any MUA. > I use Thunderbird 70.0b2 and have used it for years. However it is a major pain to implement digital signage and encryption. A pain. Dennis